On Fri, 2006-02-10 at 09:27 +1100, Tony and Robyn Lewis wrote:
> Erik Grinaker wrote:
> >I've started working on a new file format for version 0.5.0 of
> >Revelation, and would like to get some comments on it before I go ahead
> >and implement it.
>
> 1. My main concern with something like Revelation (other than strength
> of cryptography of the encrypted file) is having *all* your passwords,
> in the clear, in memory, when you've unlocked Revelation. One solution
> would be to have more than one Revelation and password file, but I
> wonder if it's more elegant, and simple enough to do, to have an
> optional separate layer of encryption on selected folders, so you can
> put, say, your banking passwords in there. It might even have a
> separate timeout before it locks and purges memory.
Hm, this issue is a tricky one. The solution you outline probably isn't
the way to go, because the whole point of Revelation is to have a secure
place to store all your passwords. If we have two levels of security in
Revelation, then why don't we just as well use the highest level of
security all the time?
I think probably the only way to handle this is by having two layers of
encryption. The data file is just a plain XML file which is encrypted
with AES, but we could maybe encrypt the passwords as well, using a
different, randomly generated key which is embedded in the XML. So that
the XML would look something like this:
<revelationdata secretkey="42c0d194550e9781c94cdea5ce6e362a">
<account type="generic">
<name>Test</name>
<field type="username">erikg</field>
<field type="password">d7d36c451942c4e0</field>
</account>
</revelationdata>
Then we would just decrypt the password on-the-fly whenever we actually
need it (for display, copy to clipboard, etc). This way the actual
password is kept out of RAM as much as possible. However, as both the
file password and the password encryption key are stored in memory, it's
still not a problem to extract the encrypted password - it will just
take a bit more effort. So the way I see it, this is just another case
of security-through-obscurity, ie it doesn't really add any real
security.
There are also a few issues with implementing this - it's not
impossible, but it would make things more complex overall. So the
question is, is it worth going through all this trouble for what is
really a very small, if any, security gain? I'm leaning towards no
(unless, of course, I'm missing something here).
The only real benefit of doing this would be when Revelations memory is
swapped out to disk, where it could later be recovered by an attacker
(even if the data is overwritten, it's still possible to recover it). If
the data was swapped but not the password encryption key, then the data
would be useless to an attacker. However, this can also be solved by
telling the kernel to never swap out Revelations memory, by using
mlockall() - which is exactly what I'm going to do, as I just discovered
this wonderful syscall right now :D
> 2. Not directly related to encryption, but I'll throw it in: can we have
> custom fields, or be able to define our own templates? To be able to
> store things like the additional security questions ("what's your
> Mother's maiden name?") and answers, or a customer number along side
> your account number, or the phone number for the help desk for your
> bank, etc etc. This might take Rvl to be more of a PIM, but that might
> not be a bad thing. This will have a big impact on your XML schema :-)
Yep, this is one of the reasons I'm designing a new file format.
Sometime during the 0.5.x series it should be possible to either add
custom fields to accounts, define your own account types, or both. I'll
send a proposed solution to the list for comments once I've got
something ready.
--
Erik Grinaker <[EMAIL PROTECTED]>
http://erikg.codepoet.no/
"We act as though comfort and luxury were the chief requirements of
life, when all that we need to make us happy is something to be
enthusiastic about."
-- Albert Einstein
