Bind Keys to Specific PASETO Versions

[paragonie-security]

https://github.com/aidantwoods/swift-paseto/blob/297a9e3506c8ad5d6404800157b129fa3c49cee6/Sources/Paseto/Keys/Key.swift#L10-L22

This should also indicate what version of PASETO the key is intended to be used with. See https://github.com/paseto-standard/paseto-spec/blob/master/docs/02-Implementation-Guide/03-Algorithm-Lucidity.md for more information.

(This should also be checked at runtime by the encryption/etc. routines.)

[aidantwoods]

Are you saying you've found a place where keys can be misused? Or is this more checking this is being done?

Each concrete key type is bound to a specific version (and symmetry) as part of the type system. The Key type here is a generalised template that the more specific keys use (and isn't itself instancible).

Largely the enforcement of using the correct key type to perform decryption/verification of a PASETO is done though the type system so that this class of error is caught as early as possible (i.e. if you have a version2 local PASETO that you want to decrypt, you can't use anything other than a version 2 symmetric key without hitting a compile error). There is of course some runtime checking when parsing a PASETO and returning the correct type (since parsing happens at runtime).

If you want some more info on how this all works there is a fairly verbose document here: https://github.com/aidantwoods/swift-paseto/blob/master/Documentation/README.md#the-paseto-message :)

[paragonie-security]

Are you saying you've found a place where keys can be misused?

No, we've just quickly scanned through the known PASETO implementations and filed issues with the ones that accepted strings or byte arrays rather than distinct types in their API.

Our line of reasoning was:

• Can you distinguish between a 256-bit symmetric key and an Ed25519 public key?
• If not, could someone accidentally pass a key meant for v2.public tokens to the decrypt API (intended for v2.local tokens)?
• If so, then there's a risk of algorithm confusion, but only if the library is misused.

We're not Swift experts, so it's totally possible we missed something important.

Largely the enforcement of using the correct key type to perform decryption/verification of a PASETO is done though the type system so that this class of error is caught as early as possible (i.e. if you have a version2 local PASETO that you want to decrypt, you can't use anything other than a version 2 symmetric key without hitting a compile error). There is of course some runtime checking when parsing a PASETO and returning the correct type (since parsing happens at runtime).

Perfect, then you've solved Algorithm Lucidity through compile-time type-safety. That is not only an acceptable answer, but a good one. There's nothing that needs to be done from a security perspective. 👍