Bind Keys to Version and Purpose

[paragonie-security]

https://github.com/atholbro/paseto/blob/ed9567b4b1c8644ddda495c9e869278ac5ee38e1/paseto-core/src/main/java/net/aholbrook/paseto/PasetoV2.java#L55

https://github.com/atholbro/paseto/blob/ed9567b4b1c8644ddda495c9e869278ac5ee38e1/paseto-core/src/main/java/net/aholbrook/paseto/PasetoV2.java#L113

See https://github.com/paseto-standard/paseto-spec/blob/master/docs/02-Implementation-Guide/03-Algorithm-Lucidity.md

Right now, byte arrays are accepted by this API. There's no mechanism to prevent a user from using a v2 public key as a v2 local key.

[atholbro]

I'm in favor of this and was thinking of adding something similar myself but just never got around to it.

The purpose could probably be omitted if you require the type directly on the Pasteo functions, for example:

public abstract String encrypt(Object payload, SymmetricKey key, String footer);
public abstract String sign(Object payload, AsymmetricSecretKey sk);
public abstract <_Payload> _Payload verify(String token, AsymmetricPublicKey pk, Class<_Payload> payloadClass)

Seems to be effectively the same as taking a base Key class and checking the purpose at runtime. Actually might be cleaner since the function signature then becomes self documenting on the expected type.

Do you foresee any issues with this? Perhaps I'm missing something obvious here as I just started looking at it.

Regardless, I will update the library with the changes, likely with my suggestion above unless there is a reason for the alternative.

[atholbro]

Did the initial work on this in the associated PR.

[paragonie-security]

I'm in favor of this and was thinking of adding something similar myself but just never got around to it.

The purpose could probably be omitted if you require the type directly on the Pasteo functions, for example:

public abstract String encrypt(Object payload, SymmetricKey key, String footer);
public abstract String sign(Object payload, AsymmetricSecretKey sk);
public abstract <_Payload> _Payload verify(String token, AsymmetricPublicKey pk, Class<_Payload> payloadClass)

Yes!

Seems to be effectively the same as taking a base Key class and checking the purpose at runtime. Actually might be cleaner since the function signature then becomes self documenting on the expected type.

Do you foresee any issues with this? Perhaps I'm missing something obvious here as I just started looking at it.

We're less worried about vulnerabilities and more about accidental misuse.

Regardless, I will update the library with the changes, likely with my suggestion above unless there is a reason for the alternative.

Awesome! Let us know if you need a review.