1

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?

sce
  • 257
  • 2
  • 6
  • 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. – Natanael Jan 22 '20 at 19:05
  • 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? – sce Jan 22 '20 at 20:32

0 Answers0