You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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)
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.
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:
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)
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
The text was updated successfully, but these errors were encountered: