[tomboy-list] encryption support
alex at beatniksoftware.com
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.
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:
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.
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
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
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.
tomboy-list mailing list
tomboy-list at lists.beatniksoftware.com
More information about the tomboy-list