Keys with associated versions #34
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Rather than accepting bytes we accept a generalised key type associated with its function. Keys are a natural place for encrypt implementations associated with that particular key to live. This also allows us to gate the unitTestNonce behind a non-exported method.
Key splitting should be a method of the key in particular. This particularly relevant for PASETO v3 and v4 implementations, which have different key splitting logic to v1.
Implement v1 in terms of specific key types
Implement v2 in terms of versions specific keys
aidantwoods
commented
Oct 5, 2021
| // slice of 32 bytes, regardless of whether PASETO v1 or v2 is being used. | ||
| Encrypt(key []byte, payload interface{}, footer interface{}) (string, error) | ||
| // Encrypt encrypts a token with a symmetric key | ||
| Encrypt(key SymmetricKey, payload interface{}, footer interface{}) (string, error) |
Author
There was a problem hiding this comment.
Something perhaps to consider here is how to handle the implicit param added the encrypt, decrypt, sign, and verify in v3 and v4. It probably isn't ideal to add an implicit arg to the existing methods in v1 and v2, as it may falsely give the impression that the implicit param is being validated (when it would be ignored for those versions). Perhaps a reasonable middle ground would be to add the param everywhere, but error if implicit is non-empty in v1 and v2. An alternative would be to specify separate methods altogether e.g. EncryptImplicit(key SymmetricKey, payload interface{}, footer interface{}, implicit interface{}) (string, error), where these implicit methods always throw for v1 and v2.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As alluded to in #32, keys should to be strongly bound to their parameter choices to prevent algorithm confusion attacks (so byte arrays or similar shouldn't be accepted). From the PASETO spec:
I've opted to refactor the core PASETO operations into methods associated with each specific key (e.g.
V2SymmetricKeyhas implementations forencrypt,decryptinvolving its raw material). This means that the version level methods just need to do a type assertion checking that the given key matches the version, before deferring down to the key specific implementation.Fixes #32