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

[Bernd Paysan]

Am Montag, 18. Mai 2015, 22:50:21 schrieb 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.

I'm aware of that, associated data is e.g. needed if you want to include an 
envelope (which e.g. contains routing data) in the authentication.  That's 
fine for other purposes, but for key wrapping, better not.

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

This mode is IMHO not really an integrated AEAD cipher.  It consists of a 
block encryption using AES CTR mode, and a checksum on the decrypted data.  
The checksum is secured by a second key, the checksum algorithm itself is not 
secure, and it uses a primitive that is not well suited for checksums (AES).

When you use a cryptographic hash (e.g. HMAC construction) for that second 
phase, the checksum would be secure without requiring an additional key.

Whether that allows an attack vector depends on the situation.  E.g. assume 
you have an ordinary, secure HMAC on your key, and you have signatures for 
your key - the obvious way is to just sign the HMAC.  You cannot change 
anything in the key without breaking the signature; nobody can.

With AES-SIV, the creator of the original key wrapping can, he can change the 
auxiliar data in such a way that a signature using the SIV can't detect that.  
You could argue that you shouldn't use the SIV for that, you should use 
another checksum; but with other AEAD algorithms like Keccak in duplex mode, 
this usage is secure.

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

Well, there are algorithms, which don't have this problem.  I just say: You 
should not use encryption to harden algorithms which can't do their job 
without, even though other algorithms can do that.

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

Well, Keccak in duplex mode as AEAD-encryption has no such problem.

You seed Keccak with the key.  You absorb the associated data and a non-
synthetic IV (if your key or associated isn't unique anyways), if any (for key 
wrapping, you shouldn't have any associated data, but a unique IV).  You 
encrypt the rest in duplex mode.  You get a secure cryptographic hash out as 
checksum.  That's general purpose, not restricted to key wrapping.

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

Keccak Duplex mode is certainly state-of-the-art.

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

Yes.  But using AES for hashing is not using a trusted primitive: AES is not 
particularly good at hashing.  It's ok for encryption, but its block size is 
way too small for a general-purpose hash primitive, and then, you need an 
additional key to protect your less-than-perfect hash.

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

Indeed.

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

Yes, fully agreed.

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

No, double-encryption with two different algorithms and two different keys, 
e.g. what Truecrypt does, is fine.  Even using one weak cipher multiple times 
with different keys (like Triple-DES) is much much better than only one (DES 
is broken).

If you have doubts about the viability of one algorithm, you should replace 
it.  If you have a general doubt, but don't know which algorithm is broken, do 
multiple encryption.  A lot of attacks base on known plaintext, and with 
multiple encryption, you stop that attack from working.

If you use the same key for both, you risk that a known attack on one 
algorithm can be used to recover the key.  But at least you have a better 
security margin if you use the same algorithm twice (more rounds).  In case of 
AES, where the security margin is relatively low, double-AES (i.e. 20 rounds 
for AES-128) is already stronger than AES alone (at least it provides better 
security margin).

If you have double-encryption with two independent algorithms and keys of a 
high-entropy data, and your checksum is just one encrpyt-then-mac (i.e. you 
feed in both keys and the encrypted message into a secure hash), checking that 
your brute-forced attack was actually working without using the wrapped key 
itself might be completely impossible (e.g. if you have a 128 bit checksum of 
256 bit key+data), and then, you really get the 256 bit strenght, because your 
really have to break both algorithms to get any hint that you were successful.

-- 
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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cryptech.is/archives/tech/attachments/20150519/c4e28975/attachment.sig>