Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:15:20
Lenny Foner (foner@media.mit.edu)
Tue, 6 Oct 1998 22:53:47 -0400
[Please respond directly to me; if you send it to the list instead, I
probably won't see it in a timely fashion. Thanks!]
An application I'm writing saves its state to disk every so often,
using IDEA in CBC mode. (It's using SSLeay's implementation of IDEA,
and makes sure to start with a random IV, etc.) Each time it does so,
it picks a new 128-bit session key for the encryption; this session
key is also stored on disk, and is hashed by a passphrase.
The question is, what's a reasonably safe way to do this?
My current guess is this. We generate a 128-bit session key, Ks,
which is used for keying the cipher. We also generate a (say) 32-bit
verifier, V, and some trivial hash of it (could be just V again, could
be its two's-complement, could be the first 32 bits of its MD5 hash,
whatever.) Let's call the hash Vh, and call the function that
generates it fn. We ask the user for a passphrase P. We compute:
Pmd = MD5(P)
Kx = Ks XOR Pmd
So we now have the session key XOR'ed with a hash of the passphrase.
We store it somewhere on disk. [Call that location Kstored. For reasons
internal to my application, Kstored will probably be a separate file
from the actual encrypted data, but in the future it might just be the
first 128 bits of the same file. Shouldn't matter; it's all on disk.]
Then, as the first 64 bits of the plaintext that we're storing,
we store <V,Vh>. Hence, we've got IDEA-CBC(Ks, <V,Vh,<rest-of-data>>)
in the actual file on disk (e.g., Ks is the key and <...> the data).
When it comes time to decrypt, we ask for P, compute Pmd, read Kx from
Kstored, and generate Ks = Kx XOR Pmd. We then decrypt the first 64
bits from the crypto file using Ks and verify that Vh = fn(V). If
they match, then the passphrase was correct, and we should finish
decrypting. If they don't, then the passphrase was wrong, and we
should ask for it again.
The verifier V exists only to verify that the passphrase was correct.
It might as well be short, so we use up less entropy in the random
pool, and because even 32 bits means the chances are 4 billion to 1
against a false positive on the correct passphrase. (If it's still
wrong, then we decrypt garbage & the application promptly barfs & says
"I can't interpret this!"---but it's a lot easier implementationwise
to learn this up front.) Vh exists only so we can tell that the
randomly-generated V is in fact good data and not garbage; since we're
depending on IDEA-CBC to actually be a good cipher, Vh = V would
probably work fine, but perhaps we should get a little more clever and
make it part of a two's-comp or MD5 hash in case V = Vh might leak
some info to cryptanalysis. V should not be a constant (or even a
low-entropy noncryptographic random number), because then it serves as
known plaintext for a KP attack.
Is this secure? Who knows? It -seems- like it's probably secure :) I
dislike coming up with my own crypto algorithms, for obvious reasons
about unvetted crypto. I attempted to figure out how PGP 5.x encrypts
keys on disk with passphrases, but after an hour or so of following
around too many levels of indirection and table lookups of which
algorithm was used where (trying to make an object system in C, it
appears), I decided this wasn't going to help much. Schneier's book
doesn't appear to have much of use on this topic either, interestingly
enough.
Thanks for any holes people can see in this, and/or a description of
the accepted wisdom on how people really do this sort of thing...
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:15:20