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?

  • $\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$
    – Natanael
    Jan 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$
    – sce
    Jan 22, 2020 at 20:32


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.