[Cryptech Tech] AES SIV mode for key wrapping?

[Bernd Paysan]

Am Dienstag, 17. März 2015, 11:53:38 schrieb Dan Harkins:
>   As a key wrapping (deterministic authenticated encryption) solution
> AES-SIV is superior to AES KEY-WRAP but AES-SIV also has a mode
> to provide "probabilistic" authenticated encryption analogous to
> traditional AEAD schemes like CCM (or GCM). The advantages it has
> over these other schemes is that AES-SIV is misuse resistant: if the
> nonce is reused you do not lose all security in the same way you do
> with CCM (or GCM).

For comparison:

In net2o, for key wrapping, I currently use Keccak duplex mode.  This strongly 
requires unique nonces for the first 128 bytes of the wrapped key, but doesn't 
have that issue for the rest of the wrapped key; which is why I first store 
the public part of the key, the nickname, and a lifetime self-signature (signs 
only the public part), and then I'm past the 128 bytes and can store the 
secret part (knowledge of the public part does *not* leak the secret part even 
when the nonces are identical).

However, I'm thinking about going to use a block cipher mode for this, because 
that will work for shorter key wrapping where no pubkey is there to get past 
the first 128 bytes.

As I'm free of all FIPS/NSA/IETF/bla constraints, I certainly want to go for a 
block cipher that has more security margin than AES; I've chosen Threefish.  
Threefish however does not have an AEAD mode proposed, and the usual AEAD 
modes available in the wild require two operations per block; that's not 
something I want.  Threefish however does have a perfectly fine (possibly 
keyed) hash mode, as it is part of SKEIN, one of the SHA-3 finalists.

The hash mode works as follows:  Each block is encrypted with a key that is 
the xor of the previous block's plaintext and cipher text.  That works for 
hashing, but it can't work for AEAD - if you output the cipher text, and the 
adversary knows the plaintext, she knows the next key - and by knowing the 
next key, Eve can reconstruct all the rest of the message.

So I've changed that: for AEAD, you start with a non-zero secret key for the 
first block.  For all further blocks, you xor pain text, cipher text, and the 
previous key to be used as next key - xoring more pseudo-random stuff into a 
new value does not make it less secure, but more so.  For the MAC, at last, 
after encryption of the last block with padding, you encrypt a zeroed block.  
The receiver doesn't need to decrpyt this block, comparison is good enough, so 
you can shorten that checksum if you don't think you need the full 512 bits of 
a Threefish block.

This mode does work with AES, too, but AES rekeying is more expensive than two 
AES operations, so if performance is an issue (e.g. for AEAD messaging), AES 
SIV is a better idea.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy at X}1GWr!+0qqp_Cn176t4(dQ*