[Cryptech Tech] [Cryptech-Commits] [user/sra/aes-keywrap] 01/01: Initial commit of AES Key Wrap implementation.

[Bernd Paysan]

Am Dienstag, 12. Mai 2015, 16:59:01 schrieb Simon Josefsson:
> I suggest looking at SIV. It provides key wrapping, and it is (in
> contrast to the RFC 3394 construct) a proper AEAD mode.  It is specified
> by well-known crypto people, Phillip Rogaway and Thomas Shrimpton, in a
> paper with security proofs and was presented at an academic conference.
> 
> https://tools.ietf.org/html/rfc5297
> http://web.cecs.pdx.edu/~teshrim/keywrap.pdf
> 
> The burden shouldn't be on us to prove something is bad, it should be
> for designers to convince everyone else that their stuff is good.

I'm not very convinced with SIV.  I agree with you that you shouldn't need to 
prove that something is bad, you should know that you have a good feeling with 
it. I agree with you that I would dismiss RFC 3394 right away.  I wouldn't 
dismiss SIV right away...

The essential principle I like to use as selection guide for crypto algorithms 
is that they withstand the "once upon a time in the west" test (based on the 
scene where Frank doesn't trust the guy with belt and suspenders - "can you 
trust a guy who doesn't trust his trowsers?", which, from a crypto-paranoid 
point of view is exactly the wrong thing to do), so you shouldn't only 
distrust your trowsers, you should also distrust your belt and your 
suspenders, and wear a bullet proof west on top, so that Frank can't shoot 
through them.

So a good crypto algorithm builds on sane components and then adds secrets.  
It doesn't use secrets to harden components which on their own can't do the 
job.  So the only purpose of the secret is the encryption, not the rest.

Let's look at SIV that way.  What are the things I feel uncomfortable with 
SIV?

1. The idea of "unencrypted, but authenticated data" obviously tries to lead 
one to believe that parts of a key bundle isn't worth to encrypt.  Don't, 
always encrypt everything.  If you have wrap your key n times for n 
recipients, better make each recipient try to open all wrapped keys instead of 
giving hints who's the recipient (by sorting the wrapped keys e.g. with the 
per-recipient shared secret, you can reduce search time to O(sqrt(n)) on 
average).

2. Is it encrypt then authenticatet?  No, it's the other way round, and 
shouldn't.  Can't be fixed, that's broken by design, for the synthetic IV.  
You should not be forced to decrypt something to authenticate it.

3. Use a cryptographic hash for authentication, so that even an attacker with 
full knowledge of all secrets can't generate two different messages with the 
same digest.  That doesn't work here, if you know K1, the key for S2V, it is 
easy to generate whatever digest you want with just one of the blocks being 
under your control (the latter, the easier).  That means the only thing that 
protects the digest is K1.  That's enough for the security proof, but your 
trousers shouldn't fall off if you aren't wearing your belt and suspenders and 
the bullet proof vest.

IMHO that's enough for not being that comfortable with SIV.  Use a general-
purpose AEAD encryption which can be used for message passing as well as for 
key wrapping. Saving a few bytes with the synthetic IV is not worth the 
trouble.

Double/tripple-wrapping (using two or three different algorithms, each with 
its own authentication; possibly with the same IV - it just has to be unique, 
sharing it is ok) could add security if you don't like to trust just one 
crypto primitive.  Double-wrapping means you have to break them both.

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