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
It is quite common to derive a Nonce from the HKDF family of transformations, as outlined in RFC8188 for instance. This came up in the open source slack.
Importance:
Currently, this is possible by deriving a symmetric key, then accessing its unsafeBytes before converting the type to a Nonce. Implementing the above referenced RFC for an implementation of WebPush, this would ultimately look like:
However, this sticks out quite a bit against the semantically pleasant deriveKey APIs.
Proposed Improvements
We could either add conversions between SymmetricKey and Nonce, but this feels like the wrong approach. Alternatively, we could define deriveNonce alternatives to the above to directly return a Nonce. Either way, a non-unsafe way to get a nonce suitable for sealing a payload with a given algorithm would be welcome (even better if we could use the new generic integer parameters to correctly determine things like sizing 😍).
The text was updated successfully, but these errors were encountered:
New API Proposal: Nonce from
HKDF
Key DerivationMotivation:
It is quite common to derive a Nonce from the
HKDF
family of transformations, as outlined in RFC8188 for instance. This came up in the open source slack.Importance:
Currently, this is possible by deriving a symmetric key, then accessing its unsafeBytes before converting the type to a Nonce. Implementing the above referenced RFC for an implementation of WebPush, this would ultimately look like:
However, this sticks out quite a bit against the semantically pleasant
deriveKey
APIs.Proposed Improvements
We could either add conversions between SymmetricKey and Nonce, but this feels like the wrong approach. Alternatively, we could define
deriveNonce
alternatives to the above to directly return a Nonce. Either way, a non-unsafe way to get a nonce suitable for sealing a payload with a given algorithm would be welcome (even better if we could use the new generic integer parameters to correctly determine things like sizing 😍).The text was updated successfully, but these errors were encountered: