[tomboy-list] encryption support

Sat Dec 2 20:53:45 PST 2006

Wow, great write up Roger. It's easy to see you've put a lot thought into this. 

At first blush, I'm pretty cautious of reimplementing a lot of the work of gnome-keyring. I don't think allowing multiple passwords for encrypted notes is something that warrants all this effort. The first time someone forgets a password and can't open an important note is probably the last time they use Tomboy. Plus I don't want to handle those bug reports ;-)

I'll try to reply with more depth after dinner. 

Thanks!
-Alex  

-----Original Message-----
From: Roger Nesbitt <roger.nesbitt at ecosm.com>
Date: Sun, 03 Dec 2006 11:18:52 
To:tomboy-list at lists.beatniksoftware.com
Subject: Re: [tomboy-list] encryption support

Boyd Timothy wrote:
> A couple people have brought up the idea here:
> http://live.gnome.org/Tomboy/PlaceForNewIdeas#head-8ce3244991dea1da6b80a6fbff0b7588434ebbc1

Thanks.  I've had a bit of a think and browse through the code, and 
would like to outline a way to implement encryption.  It would be great 
to get feedback from anyone who's interested.

* What's encrypted
My plan is to encrypt only the text of the note, leaving title and other 
metadata unencrypted.  Really this is just a personal preference thing. 
  What I'd like to use encryption support for is storing passwords and 
other confidential data that I don't want someone to have access to if 
they manage to break into my box.  It doesn't matter that they know 
there are passwords in there; I'm more concerned they don't get access 
to the passwords.  I'm open to other thoughts on this one!

* Encryption mechanism
There are two ways I can see to go about this:
  1. Encrypt the text with a hashed, salted password using AES
  2. Have a key store, with the keys encrypted by a password, and 
encrypt the text using the keys

I don't like number two for two reasons.  Firstly, you won't be able to 
copy your .note files to somewhere else without also copying your 
keyring file.  I'd like to keep the .note files as self-sufficient. 
Secondly, changing the password won't actually change the key the notes 
are encrypted with.  This is anti-intuitive: as user, you'd expect that 
if you change your password, someone who had access to your old password 
wouldn't be able to see the notes any more.  But if that person had kept 
a copy of your decrypted key, they would!

Number one has the disadvantage that changing your password means 
rewriting all the notes to disk.  But I still prefer this option.

* to gnome-keyring or not to gnome-keyring?
At the moment I can't see the benefit in using gnome-keyring.  Using a 
single password to unlock other passwords makes sense for external 
servers and services when you don't want to remember a myriad of 
passwords.  But in this case, we want explicit confirmation that these 
notes are to be unlocked.  There's also little point storing a password 
behind another password.

Some of the features that gnome-keyring provides, such as caching, are 
nice but easily implementable should we wish to go down that path.

Does anyone want to stick up for gnome-keyring?

* On-disk encryption
How about adding a tag:
   <encrypted type="AES-128" iv="[base64-encoded initialisation vector]">
between the <text> and <note-content> tags?  Or even adding attributes 
directly to the <note-content> tag?  In both cases, the note-content 
will be the base64-encoded ciphertext.

* Backend implementation
It's important that we only prompt for a password when an encrypted note 
is attempted to be viewed -- we definitely don't want prompting when all 
the notes are loaded on startup.  Although I imagine most people will 
only use one password for all the notes (and we'd encourage this in the 
UI), there's a possibility of multiple passwords being used if they 
import notes in from another installation.

So, I'll outline what I'm thinking at the moment.

1. When the data is loaded from disk by NoteArchiver.Load, it will note 
the encryption tag and write to a new field, NoteData.EncryptedData, 
instead of NoteData.Data.

2. A singleton class EncryptionManager will be created that can take a 
NoteData object and either decrypt it using a cached password or pop up 
a dialog for the user to enter a password.  NOTE: there may be some 
blocking/threading issues with popping up a dialog at this stage.  I 
don't know how GTK works well enough to know.

3. If NoteData.Data is called on an encrypted note, it's passed to the 
EncryptionManager for decrypting.  Data can now throw an exception if no 
password is found/entered, so code will have to be updated to gracefully 
handle this situation.  Otherwise it will return the decrypted note data.

This method should mean very little work needs to be done to plugins and 
the current codebase to support encryption.

* Caching
As implied above, we'll cache all the passwords that users enter (maybe 
a checkbox on the password entry dialog that says "Remember password for 
this session" or something.)

* UI implementation
Add an "Encrypted" toggleable button on the toolbar for each note.  By 
default, it will use the previously entered password as the password to 
encrypt it with, so it's a simple toggle on/off.  If the user hasn't 
entered a password in the current session, they'll be prompted for one 
to use.

Add a "Change password" to the Tools drop-down, just in case they want 
to change the password.

Instead of the blank yellow note paper on the traybar dropdown and 
search screens, have the yellow note paper with a small lock inside it 
to signify it's encrypted.

Add a "Forget all passwords" option to the right click menu.  This 
clears the password cache and deletes the decrypted data of all 
encrypted notes.

* Search
Searching through notes will be accessing all the Text attributes, so 
will throw up dialogs if the notes are encrypted.  This should work OK, 
unless the user doesn't know the passwords in which case they'll be 
bombarded with a dialog for each encrypted note.  Maybe adding a "Search 
encrypted notes" checkbox will help.  That might be unnecessary.

Hopefully that gives you all some idea of what I'm planning.  I love how 
Tomboy is simple and free of clutter, and I'd very much like to keep it 
that way.  Any and all comments greatly appreciated.

Cheers,
Roger
_______________________________________________
tomboy-list mailing list
tomboy-list at lists.beatniksoftware.com
http://lists.beatniksoftware.com/listinfo.cgi/tomboy-list-beatniksoftware.com