From what I could gather, it seems like that NIST's key wrap (publication) provides similar security like AES-GCM Authenticated encryption. If this is true, why did we need a separate specification for key wrap in the first place ?
$\begingroup$
$\endgroup$
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
3
You can find some info in section B.2. "Comparison of Functionality with Other Authentication Methods" in NIST SP 800-38F, where it said:
- Many authenticated encryption algorithms ... provide an efficient means of authenticating associated data that is not confidential ...
- Digital signatures on ciphertexts or MACs on ciphertext can be verified without decrypting the ciphertext. ...
So obviously, NIST KWs don't allow authentication without decryption or associated header data.
But apart from NIST, you may also be interested in the paper Deterministic Authenticated-Encryption, where it gave a treatment on what does it mean to be a "key-wrapping" mode. To summarize, we can look at the following quote from the introduction section:
We call the goal deterministic authenticated-encryption (DAE) ... In a DAE scheme, encryption deterministically turns a key, a header, and a message into a ciphertext.
Where as traditional AEAD as treated semi-conanically in RFC5116: An Interface and Algorithms for Authenticated Encryption, a nonce/IV needed to be provided so as to provide so called "semantic security".
As to
Q: why did we need a separate specification for key wrap in the first place?
Determinism decreases the likelihood that misuse of the schemes happens, as could with non-deterministic schemes running on top of broken RNGs or compromised state.
-
$\begingroup$ GCM doesn't require IV generated using RNG, but I don't know how to edit this fact into the answer body nicely, so here it's in the comment. $\endgroup$– DannyNiuNov 28, 2018 at 8:00
-
2$\begingroup$ I guess you could create an argument around the fact that key wrapping doesn't require a RNG or state to be kept. If the IV is non-random, it must be created using some kind of counter or pseudo-random scheme. Just thinking along here :) $\endgroup$– Maarten Bodewes ♦Nov 28, 2018 at 11:13
-
$\begingroup$ " If multiple invocations are necessary on the same data for a system, then one method for ensuring that the ciphertexts are different would be to prepend the data with a fixed-length nonce before invoking the authenticated-encryption function." This means that even these schemes need some sort of nonce if they're invoked multiple times, making it essentially similar to vanilla AES GCM. @DannyNiu $\endgroup$– AkashDec 18, 2018 at 6:10
$\begingroup$
$\endgroup$
One advantage is the recommended maximum number of invocations using a single key.
- No limit on the number of invocations with KWP-AE or KW-AE. Encryption is stateless. (NIST SP 800-38F, "5.4 Limits on the Number of Invocations")
- $2^{32}$ maximum invocations with AES-GCM using random nonces to avoid nonce collisions with a $2^{-32}$ security margin. Encryption is almost stateless - must be sure that keys are rotated before passing $2^{32}$ encryptions. (NIST SP 800-38D, "8.3 Constraints on the Number of Invocations")
- $2^{48}$ maximum blocks ($2^{47}$ maximum 256-bit keys) encrypted with AES-GCM using unique nonces to avoid a birthday collisions of encrypted blocks with a $2^{-32}$ security margin. Encryption is not stateless - synchronized persistent state is required over the lifetime of the key when encrypting.
Huge disadvantages vs AES-GCM and other modes and algorithms are:
- No security proofs
- Extremely slow
- Only 64 bits of authentication
- No modern conveniences such as AAD
To get practically limitless bounds - at least $2^{64}$ invocations using a single key with random nonces - you can use XChaCha20-Poly1305 or AES-GCM-SIV.
To use NIST-compliant algorithms and modes you may need to use longer nonces and add an explicit key-derivation step and then use AES-GCM - see Amazon KMS's approach for example.
