Re: org-mobile-use-encryption

[Carsten Dominik <carsten.dominik@gmail.com>]

Hi Greg,

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

On Oct 13, 2010, at 2:48 PM, Greg Troxel wrote:

>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> On Oct 13, 2010, at 2:23 AM, Greg Troxel wrote:
>>
>>> I am trying to test encryption for MobileOrg via a beta from  
>>> Richard.
>>> (We're still playing the 'convince itunes to let you run code on  
>>> your
>>> own phone game', so this report is preliminary about what Org itself
>>> is doing.)
>
> I have successfully viewed my org files and retrieved a captured note
> From the phone into emacs.
>
> This note is about release_7.01h-672-g7e29685, so I have
> your commit 9755e09bbcd630b6d0e20dbf6342bf1c1e66c819.
>
>>> I have in .emacs-local.el:
>>>
>>> (setq org-mobile-use-encryption t)
>>> (setq org-mobile-encryption-password "mypasswd")
>>>
>>> and I did org-mobile-push.  I found that there was an old  
>>> agendas.org
>>> that was not encrypted, and it seems that org-mobile-push omits
>>> agendas.org if org-mobile-use-encryption is t, but still creates it
>>> when
>>> nil.
>>
>> I have not been able to reproduce this.
>
> Apparently when in encryption mode the copy of the encrypted version
> agendas.org fails because it's trying to go to a file named by the  
> tramp
> syntax instead of interpreting it as remote:
>
> Agenda written to Org file /home/gdt/orgtmpcrypt
> /ssh:foo.example.com:/usr/home/gdt/ORG/agendas.org: No such file or  
> directory
> 3148034372:error:02001002:system library:fopen:No such file or  
> directory:/n0/gdt/NetBSD-5/src/crypto/dist/openssl/crypto/bio/ 
> bss_file.c:355:fopen('/ssh:foo.example.com:/usr/home/gdt/ORG/agendas.org','w')

Ah, you are using a tramp path?  OK, I see from your
other message that you have actually solved this
issue.  Thanks!

> I read the code and I don't follow how the invocation of copy-file is
> different in the encrypted case.
>
>>> checksums.dat is in cleartext.  This seems ok, but could be a missed
>>> opportunity for some integrity protection.
>>
>> I have a technical reason to not encrypt it - so unless there is
>> someone who really needs it encrypted, I want to keep it like this.
>
> That seems fine - the filenames are staying cleartext.

OK.

>  My point, not
> well made, was that encryption does not give you integrity protection.
> It seems the concern motivating this work is confidentiality, but in
> cryptography it's considered good practice to also provide integrity,
> via HMAC-SHA1 or a combined confidentiality/integrity mode.

Ah, I see what you mean now.

>  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.

>
>>> I'm not sure this level of paranoia is warranted, but typical
>>> encrypting filesystems also encrypt the filenames.  It probably
>>> suffices to just warn the user that the filenames of org files will
>>> still be exposed in the DAV area.
>>
>> I have just put this information into the manual.
>
> Thanks.
>
> minor issues:
>
> ~/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 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.

>
> During a pull that got a note, emacs asked me about visiting a buffer
> whose file (orgcrypttmp) had changed contents.  I'll see if I can
> reproduce that.

This should hopefully go away with the changes I have now made.

Thanks again.

- Carsten