[mnet-devel] Re: [web-calculus] YURLs

[Trevor Perrin]

At 07:22 PM 7/20/2003 -0400, Zooko wrote:


>[Removing Cc:'s except Trevor Perrin and mnet-devel.]
>
>  Trevor Perrin wrote:
> >
> > it looks like a bad symmetric key will cause the inode to decrypt
> > improperly, so the code that parses the inode will probably complain that
> > it's gibberish.
>
>I agree.  This is doubly true for inodes which contain blockIds -- for the
>file to finish reconstruction would require that the inode decrypt into
>something containing real blockIds that map to real blocks!
>
> > It might be better to catch this error before parsing - if
> > the inodeId was an HMAC-SHA1 of the encrypted inode and the encryption 
> key,
> > I think that would work.
>
>Hm.  The problem with that is that servers store the encrypted inode block,
>indexed by the inodeId (== SHA1(encryptedinode)), and the servers are not
>allowed to know the encryption key.

ah!  That's an interesting model, I should read more about this.


>Therefore, we need the mapping between encryptedinode and inodeId to be
>verifiable without knowledge of the key (so that servers can verify the
>validity of blockId->block mappings for the blocks they store).
>
>I agree that it would be better to explicitly include some information to
>double-check the encryption key.  Then I could say "If the file reconstructs
>without an error, then either the result is the original file or an attacker
>has found a collision in SHA1.".
>
>As it is, I can only say "If the file reconstructs without an error, then
>either the result is the original file, or an attacker has found a collision
>in SHA1, or an attacker has found an AES key which decrypts this ciphertext
>into some plaintext which has at least 64 bits of his choosing.".
>
>I really don't know how plausible is that last threat (the funny AES key).
>
>So here is a proposal -- the last 20 bytes of the inode are the HMAC of the
>rest of the inode with the symmetric key.  This is the simplest solution
>I can think of which preserves our requirements for mnet URIs and which 
>allows
>us once again to say "Either the resulting file is the original file or an
>attacker has found a collision in SHA1.".

What if the key stored in the mnet URI is used as input to a Key Derivation 
Function that outputs separate Authentication and Encryption keys.  Then 
you use the Authentication key for hmac'ing.  The server is allowed to know 
the Authentication key but not the Encryption key.

The nice thing about having an Authentication key, is that in addition to 
doing:
inodeId = HMAC-SHA1(AuthKey,inode)

you might want to do:
shareId = HMAC-SHA1(AuthKey, share)

Otherwise, I could possibly take a shareId and use the length-extension 
property of SHA1 to calcluate the shareId of this share with additional 
data appended to it.  Whether this actually works and what it accomplishes 
depends on all sorts of things, like what the data format of the share is, 
what cipher mode you're using, how the SHA-1 padding interacts with these 
things..  But if you're HMAC'ing everything you don't have to worry about it.

For the KDF, all you'd have to do is run the cipher in counter mode until 
you've got enough output, or something similar.

Trevor 



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel