On Mon, Aug 06, 2007 at 03:20:13PM +0100, Darren J Moffat wrote:
> Pawel Jakub Dawidek wrote:
> > Can't you simply store HMAC result, where password is the passphrase
> > given by the user, read from a file, etc. 
> 
> You mean the HMAC secret ?
> 
>  > and data is the wrapping key?
> 
> So an HMAC of the wrapping key itself ?

Please, forget what I wrote before, I was a bit confused.

I'll explain what I do in geli (disk encryption in FreeBSD) after
consulting sci.crypt.

MasterKey - key used to encrypt actual data on disk (equivalent of
        DSKEK - pool/master key, if I understand correctly [1]).
UserKey - user supplied key (passphrase, random bytes from a file, etc.;
        let's leave PKCS#11 tokens for now) (equivalent of wrapping key).

Now, what I do is to encrypt MasterKey and store it on disk, but also
HMAC MasterKey and store HMAC on disk. It is not recommended to use the
same key for encryption and HMAC, but we can easly generate two keys
from UserKey:

EncryptionUserKey = HMAC(UserKey, 0x00)
HMACUserKey = HMAC(UserKey, 0x01)

First argument to HMAC() is secret and second argument is one byte of
data. This was recommended as safe method of key cloning.

Now I can store MasterKey encrypted with EncryptionUserKey and its HMAC
calculated using HMACUserKey and later I'm able to verify correctness of
UserKey.

Of course PKCS#11 tokens make all this a bit more complex.
We could still HMAC, as you suggested, pool's GUID. Do you think about
using DSKEK (or key derived from it) as HMAC secret?

Another option is to use some kind of verification string. For example
we randomly generate a string, which we encrypt using DSKEK and store on
disk as well as we calculate SHA256 from this string and also store on
disk. When we want to verify if DSKEK was decrypted correctly, we
decrypt verification string, calculate SHA256 and compare with hash from
disk.

We could also think about simply storing hash of DSKEK, but I'd be
carefull with that.

[1] DSKEK is probably not used for data encryption, but is a wrapping
key for per-dataset keys, but anyway.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: 
<http://mail.opensolaris.org/pipermail/zfs-crypto-discuss/attachments/20070806/29a005db/attachment.bin>

Reply via email to