NIST SP800-38F specifies key wrapping algorithms. An important distinction between KW (without padding) and KWP (with padding) seems to be that KW cannot be used to wrap keys of length 8 bytes i.e. 1 semiblock in the NIST specification. On the other hand, KWP is allowed to wrap keys of size less than 16 bytes. Is there a catastrophic failure if a (broken) KW implementation supports wrapping 8 byte keys?
2
-
$\begingroup$ Without padding (or other related size metadata) you can't define the exact plaintext length in the decrypted plaintext block when it's not equal to a multiple of the block size. The decryption function won't know how long the key is. $\endgroup$– NatanaelJan 22, 2020 at 19:05
-
$\begingroup$ Assume that the mechanism is known to be KW (no padding, default ICV A6A6A6A6A6A6A6A6, custom ICV may be set by user) and that the wrapped key is of length 8 bytes (decrypt yields 16 bytes, ICV is checked to be default ICV1 or custom ICV set by user). In this situation, KW can be simply viewed as AES_ECB(wrapping_key, 8_byte_key_being_wrapped). This behavior of breaking down to AES_ECB for 8 byte keys is identical to that of KWP. My question is how bad is this? Ignoring the obvious issue with using 8 byte keys for anything, is there any scope for information leakage of larger wrapped blobs? $\endgroup$– sceJan 22, 2020 at 20:32
Add a comment
|