Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: x/crypto: add support for AES Key Wrap #27599

Closed
bdhess opened this issue Sep 10, 2018 · 10 comments
Closed

proposal: x/crypto: add support for AES Key Wrap #27599

bdhess opened this issue Sep 10, 2018 · 10 comments

Comments

@bdhess
Copy link

@bdhess bdhess commented Sep 10, 2018

AES Key Wrap is defined in RFC 3394 (plain) and RFC 5649 (with padding).

The implementation is straightforward and the relevant RFCs come with test vectors. I have an implementation complete that I'd be happy to submit. I'd suggest adding it to a package named x/crypto/aeswrap to avoid confusion with the AES data encryption functionality in crypto/aes.

@jefferai
Copy link

@jefferai jefferai commented Jun 10, 2019

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

@bdhess
Copy link
Author

@bdhess bdhess commented Jun 10, 2019

We released the variant with padding in google/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.

@jefferai
Copy link

@jefferai jefferai commented Jun 10, 2019

Awesome, thanks!

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Jan 6, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Jan 13, 2021

@rsc rsc moved this from Incoming to Active in Proposals Jan 13, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Jan 13, 2021

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

@rsc
Copy link
Contributor

@rsc rsc commented Jan 20, 2021

1 similar comment
@rsc
Copy link
Contributor

@rsc rsc commented Feb 17, 2021

@FiloSottile
Copy link
Contributor

@FiloSottile FiloSottile commented Mar 15, 2021

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.

@rsc rsc moved this from Active to Likely Decline in Proposals Mar 24, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Mar 24, 2021

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

@rsc rsc moved this from Likely Decline to Declined in Proposals Apr 1, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Apr 1, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Declined
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants