emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] org-mobile-use-encryption


From: Greg Troxel
Subject: Re: [Orgmode] org-mobile-use-encryption
Date: Thu, 14 Oct 2010 20:07:59 -0400
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (berkeley-unix)

Carsten Dominik <address@hidden> writes:

> thank you very much vor putting in the time to test the encryption
> for MobileOrg.

No problem - thank you for writing and sheparding Org.

>> But for org files on servers we believe are not messing with them,
>> this is probably in the 'best is the enemy of the good' category.
>> And if we want integrity (I know, ENOPATCH), then it's probably best
>> to do it outright, so I withdraw my complaint about checksums.dat
>> being in cleartext.
>
> Is is also so that the file transfer is happening in two one-way
> street.  agendas.org and the agenda files and index.org are uploaded,
> mobileorg.org is downloaded, and its contents are then applied
> locally.  Seems to be little room for problems here.

The issue is that the whole point of encryption is to use a webdav
server not under one's control, such as dropbox, or perhaps one accessed
not over SSL.  Encryption prevents the server admin from reading the
bits, and that's the most important thing.  But if the server admin
changes the ciphertext, they can cause the wrong plaintext to appear.
This is generally tricky, but it's a principle of cryptographic protocol
design that one can't assume that encryption provides integrity
(meaning, that just because the bits are encrypted doesn't mean it
prevents an adversary from manipulating the plaintext).

That said, the above is probably overly paranoid for most people.

>> ~/orgtmpcrypt seems to not always get cleaned up when I push/pull.
>> After a push, I found it to contain my index.org, unencrypted and 644
>> in my homedir.  Probably this should go in org-directory instead
>> which presumably would be protected as the user wants.
>
> I did not put it into org-directory because I don't know if users have
> this set to an accessible place, and I don't want the push
> to fail because of that.

I think this is the classic security/convenience tradeoff.  On a
multiuser system, I think Org now puts the orgtmpcrypt file with normal
umask, and that can be read by other users (albeit briefly).  I
suggested org-directory because someone who wants to keep other users
From seeing his org bits will protect that approriately - mine is 0700.

I suppose there could be someone who turns on encryption and has org
files in random places but no directory matching org-directory.  Getting
an error seems fair enough and better than risking exposing private bits.

(Again, I realize I'm on the paranoid side, but I do security
professionally so it comes naturally.)

> I have modified the code and hope that it does now in all cases
> clean up the temporary file.  Please let me know if you still
> find a case where this is not so.

Thanks - will do.  Right now all is working well.

Attachment: pgpq8nWXYH0oA.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]