Add aes-kwp (Key Wrap with Padding) mode

[jvdsn]

Apart from AES-KW, NIST SP 800-38F also defines the AES Key Wrap with Padding mode (KWP), which allows input keys that are not a multiple of 8 bytes. This mode is also described in rfc5649.

The actual algorithm itself is very similar to the AES-KW algorithm, however there are some major differences:

• obviously, the input is padded (with zeroes), to align to 8 bytes
• the IV is composed of a fixed IV prefix and a variable MLI (message length indicator)
• when the input is <= 8 bytes long, it is simply (padded and) appended to the IV and one AES-ECB encryption is performed on the resulting 16 byte block
• otherwise, the same wrapping algorithm as for AES-KW is performed

Because of the many similarities, the implementation code was directly adapted from the AES-KW implementation. One of the differences here is the return type of unwrap. Because the plaintext length is unknown to the caller when unwrap is called, the caller needs to provide an output buffer which is large enough to hold all 8 possible message lengths. The unwrap function then returns the actual output size, and it is the responsibility of the caller to truncate the output buffer to the appropriate length (i.e. remove the padding applied by wrap). This is done automatically in unwrap_vec.

Finally, I took the liberty to update the descriptions of the AES-KW mode. I know this is quite pedantic, but the actual name of the mode is AES Key Wrap, not AES Key Wrapping. Key Wrapping refers to the general method of wrapping keys, but there are multiple implementations of this, AES Key Wrap (KW) being one of them, but also AES Key Wrap with Padding (KWP) or even Triple DEA Key Wrap (TKW) (as described in SP 800-38F).

[tarcieri]

Given the large amount of duplication with aes-kw, particularly around things like the Kek types, I'm wondering if this should just be an additional construction provided by the aes-kw crate, rather than its own crate.

[jvdsn]

Given the large amount of duplication with aes-kw, particularly around things like the Kek types, I'm wondering if this should just be an additional construction provided by the aes-kw crate, rather than its own crate.

A potential solution would be adding some kind of wrap_with_padding and unwrap_with_padding methods (and associated vec methods) to the aes-kw create?

Of course, we'd have to make it clear in the descriptions of the crate that AES-KWP is also included then, because generally aes-kw refers to the mode of operation without padding.

[tarcieri]

The (un)wrap_with_padding names sound fine to me.

And yeah, just add information about AES-KWP to the crate description in Cargo.toml and the README.md and I think we should be good to go.

[tarcieri]

Merging this.

@jvdsn if you'd like to submit a followup PR to address the error types, potentially with breaking changes, we can discuss those separately

[jvdsn]

Right, I'll have to think about the best way to represent it. If I come up with something, I'll follow up.

One more thing: I didn't update the CHANGELOG file in this PR. I'll leave that up to you when you feel like releasing a new crate version.