@bdhess Any chance you've open-sourced your implementation in the mean time?

We released the variant with padding in tink-crypto/tink@22467ef

Note that the Tink implementation is fairly opinionated: no 192-bit wrapping keys, and wrapped keys must be between 16 and 8192 bytes inclusive.

Awesome, thanks!

/cc @FiloSottile

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

ping @FiloSottile

AES Key Wrap is a weird legacy mode. It had completely undefined requirements, and when Rogaway looked at formalizing some he came up with SIV, a much better alternative. https://web.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf

Practically, KW is slow and bizarre: two rounds of it would be a SIV mode with not-fantastic bounds due to the 64-bit blocks. For some reason, KW runs six rounds, because why not. This works out to twelve AES compressions per 128-bit block, which is going to be at least ten times slower than any reasonable alternative.

In terms of things I'd like to steer users who want deterministic encryption towards, I'd much rather have a real SIV mode like AES-GCM-SIV. In terms of compatibility, this issue only got seven 👍 in two years, and the two third-party implementations github.com/NickBall/go-aes-key-wrap@v0.0.0-20170929221519-1c3aa3e4dfc5 (unpadded) and github.com/google/tink/go/kwp/subtle@v1.5.0 (padded) have three and one importer, respectively.

It's also a very very simple mode to implement, so I am not concerned about the quality of third-party implementations.

I think this is a good fit for a third-party module, not x/crypto.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group

Curiously enough, CryptoKit just added KeyWrap support. It's not enough to reconsider the decision, but I wonder why.

https://developer.apple.com/documentation/cryptokit/aes/keywrap

@FiloSottile while AES KW may be "weird legacy", it is one of the algorithms in JWA (https://www.rfc-editor.org/rfc/rfc7518.html#section-4.4) which is used to make encrypted JWTs (i.e. JWEs)... and I am taking a wild guess here but that is probably why its now in cryptokit.

Also, the two third-party implementations you mention above are not quite identical. NickBall/go-aes-key-wrap does Key Wrapping per RFC 3394 / KW from NIST 800-38F whereas google/tink/go/kwp/subtle does KWP from NIST 800-38F. That unpadded/padded distinction is very subtle and quite unobvious if coming from the RFC instead of the NIST document.