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

[Simon Josefsson]

Bernd Paysan <bernd at net2o.de> writes:

> 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).

Having unencrypted data is optional.  It is there so that it is a
complete AEAD cipher -- the 'AD' part in 'AEAD' is for Associated Data'
which is unencrypted data.

> 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.

I'm aware of the traditional arguments for encrypt-then-authenticate
when combining a traditional a cipher with a traditional MAC, but as far
as I am aware, that argument is not applicable to AEAD ciphers.  To
clarify: What cryptographic security guarantees are violated?

> 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.

Well, yes, if the attacker has your keys, your security will be reduced.

> 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.

I think you are asking for too much here -- I don't recall seeing
analysis of other key wrapping mechanisms wrt security level when parts
of the key is leaked.  This is interesting considering side channel
attacks which may lead to partial key discovery -- but that is (as far
as I can recall) alas still beyond what state-of-the-art solutions
protect against.

> 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.

I believe we are in agreement.  The general recommendation is to use a
general-purpose AEAD encryption mode based on some trusted primitive.

SIV isn't the perfect AEAD mode, but it is certainly better than RFC
3394 in this regard, and it is actually analyzed for the use-case of key
wrapping.

I don't care for or against SIV, I just believe the choice of RFC 3394
key wrapping is ill-adviced and I'm concerned that you are going down
the wrong path.  If people here don't like SIV, then pick another AEAD
mode but please demand from it that it has a security proof and
preferrably has been analyzed for the key-wrapping use-case.

> 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.

Cryptographers typically frown upon such constructs.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/tech/attachments/20150518/2e38e1be/attachment.sig>