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

Feature request: AES Key Wrap/Unwrap (RFC 3394) #1455

Closed
KirkLandTrip opened this issue Oct 31, 2022 · 1 comment · Fixed by #1456
Closed

Feature request: AES Key Wrap/Unwrap (RFC 3394) #1455

KirkLandTrip opened this issue Oct 31, 2022 · 1 comment · Fixed by #1456
Labels

Comments

@KirkLandTrip
Copy link

The problem
Some applications use Key Wrapping to store a key (that is used to decrypt some user data) in a "non-trusted" location, usually together with the data it encrypted.
The key isn't stored in plain-text and instead it is stored in an encrypted form, called the "wrapped" form.
This is done by encrypting using a secondary key, called a KEK. This secondary key is usually not stored in the same place.
A common way to implement it is to generate the KEK in memory based on a password/PIN code that a user enters, then decrypt the wrapped key and then use the results to decrypt the user's data.

"AES Key Wrapping" defined in RFC 3394 is a popular way to wrap keys.
It uses the raw AES function but does some arithmetic/shifting around the input/output.
So this is NOT the same as just Running AES-ECB with the input=key_to_wrap and the encryption key=KEK.

The solution I'd like to have
New modules in Cyberchef that work like this:

  1. AES Key Wrapping: Works on the input data as the "Key Data" (Key to wrap)
    With 2 parameters:
    * KEK - The Key to encrypt with
    * IV - As defined in RFC 3394, It's prepended to the "Key Data" before encrypting/wrapping it. (It is NOT used as the IV to the AES method. The abused the name "IV" here)
  2. AES Key Unwrapping: Works on the input data as the "Wrapped Key"
    With 2 parameters:
    * KEK - The Key to decrypt with
    * IV - As defined in RFC 3394, The first 8 bytes of the decrypted blob should equal to this IV (this is used to verify that unwrapping succeeded).

For both IV parameters, RFC 3394 suggests these 8 bytes:
a6a6a6a6a6a6a6a6
So using it as the default value will probably cover most use cases.

Alternatives I've considered
I've tried using "AES Decrypt"/"AES Encrypt" modules directly before I realized that the usage of AES in the wrapping/unwrapping is not just a simple call to AES, there are several additional shifting and XORing involved.

** Links: **
RFC 3394 - https://www.rfc-editor.org/rfc/rfc3394
Key Wrap in Wikipedia - https://en.wikipedia.org/wiki/Key_wrap

@mikecat
Copy link
Contributor

mikecat commented Oct 31, 2022

Implemented! I hope you like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants