brycx / pasetors Goto Github PK

In order to use Paseto for my application I need cross-language interoperability. However the only two Paseto v4 implementations for Python enforce Algorithm Lucidity, meaning they currently cannot be easily used in conjunction with pasetors, since it doesn't support Paserk.

So it would be great if pasetors could support importing/exporting keys from/to Paserk :)

What works perfectly and correctly

Adding "kid" (Wrapped PASERK) field to footer through footer.add_aditional("kid", ...) is not allowed.
Adding "wpk" (Wrapped PASERK) field to footer through footer.add_aditional("wpk", ...) is not allowed.

Adding "kid" (Wrapped PASERK) field to footer possible with footer.key_id(...).

Missing feature

Adding "wpk" (Wrapped PASERK) field to footer not possible footer.wrapped_paserk(...).

See also chronotope/chrono#602

Maybe we need to switch to time, using the version that has a fix.

As suggested herein:

• https://github.com/paseto-standard/paseto-spec/blob/master/docs/02-Implementation-Guide/02-Validators.md
• https://github.com/paseto-standard/paseto-spec/blob/master/docs/02-Implementation-Guide/04-Claims.md
• https://github.com/paseto-standard/paseto-spec/blob/master/docs/02-Implementation-Guide/05-API-UX.md

Hello, @brycx . Your library is awesome. I hope I can use pasetors in my web app.

Although there are libraries which already implement PASETO using javascript programming language, unfortunately those aren't running well in browser environment. Those libraries can be used in node.js environment (run javascript inside server). Converting existing library which can be used in browser is not an easy task.

Nowadays, rust can be compiled into WebAssembly (or WASM for short), and then can be used in browser. If you don't mind, could you add WASM support for this library?

See #25 and #24

I was surprised to discover that AsymmetricPublicKey does not implement clone. I was wondering if there's a reason?
If not we should audit all types for clone impls.

Thanks for your hard work, it's a very good crate.

it's all works perfectly, expect when i trying to change the expiration time.
for example, using Claims::new() will create a claims expired in one hours, it's works fine.
but when i trying to change this, there is no easy way to do that, i had to write a helper function, like

fn helper_change_exp(claims: &mut Claims, duration: &Duration) {
  if let Some(Value::String(iat) = claims.get_claim("iat") {
    let iat = OffsetDateTime::parse(&iat, &Rfc3999).unwrap();
    let exp = (iat + *duration).format(&Rfc3999).unwrap();
    claims.expiration(&exp).unwrap();
}

or

fn helper_change_exp(claims: &mut Claims, duration: &Duration) {
  let iat = OffsetDateTime::now_utc();
  let nbf = iat;
  let mut exp = iat;
  exp += *duration;
 
  claims.issued_at(&iat.format(&Rfc3339).unwrap()).unwrap();
  claims.not_before(&nbf.format(&Rfc3339).unwrap()).unwrap();
  claims.expiration(&exp.format(&Rfc3339).unwrap()).unwrap();
}

if the Claims::new() can accept a Duration, it's will be more user friendly, like

pub fn new(duration: &Duration) -> Result<Self, Error> {
        let iat = OffsetDateTime:now:now_utc();
        let nbf = iat;
        let mut exp = iat;
        exp += *duration;

        let mut claims = Self {
            list_of: HashMap::new(),
        };

        claims.issued_at(&iat.format(&Rfc3339).map_err(|_| Error::InvalidClaim)?)?;
        claims.not_before(&nbf.format(&Rfc3339).map_err(|_| Error::InvalidClaim)?)?;
        claims.expiration(&exp.format(&Rfc3339).map_err(|_| Error::InvalidClaim)?)?;

        Ok(claims)
    }

then we can use Claims::new(&Duration::hours(3)), less code and easy to use.
could you please considering add this?
or maybe add a new new() function with another name for compatibility?

They seem to be have been updated in: https://github.com/paseto-standard/test-vectors/releases/tag/v1.3.0

The latter is more self-contained, has fewer dependencies which are also up to date. The dalek crate has been behind on rand versions for some time and the ed2559-compact uses fiat's formally-verified arithmetic for Ed25519. Additionally, the latter has all the functionality required by this crate as well.

As per discussion in #98, the function signatures for above two types should define message to be &str to correctly capture the spec requirement of payloads being valid UTF-8 data. As is currently the case for Claims.

This constitutes a SemVer breaking change.

They have been updated upstream since #15

Please let me know if this is not the right place to open this issue.

I've got a cloudflare worker running and I'm trying to create and verify pasetos, however there is a panic which seems to only happen on attempting to create a token. I'll include the code and behavior here.

use core::convert::TryFrom;
use pasetors::claims::{Claims, ClaimsValidationRules};
use pasetors::keys::SymmetricKey;
use pasetors::token::UntrustedToken;
use pasetors::{local, version4::V4, Local};
use std::error::Error;

pub fn mint(email: &str, key: &str) -> Result<String, Box<dyn Error>> {
    let mut claims = Claims::new()?;
    claims.subject(email)?;

    let sk = SymmetricKey::<V4>::from(key.as_bytes())?;
    let token = local::encrypt(&sk, &claims, None, Some(b"implicit assertion"))?;

    Ok(token)
}

pub fn verify(token: &str, key: &str) -> Result<Option<Claims>, Box<dyn Error>> {
    let validation_rules = ClaimsValidationRules::new();
    let untrusted_token = UntrustedToken::<Local, V4>::try_from(token)?;
    let sk = SymmetricKey::<V4>::from(key.as_bytes())?;
    let trusted_token = local::decrypt(&sk, &untrusted_token, &validation_rules, None, None)?;

    let claims = match trusted_token.payload_claims() {
        Some(c) => Some(c.to_owned()),
        None => None,
    };

    Ok(claims)
}

Observed behavior when calling mint:

panicked at 'time not implemented on this platform', library/std/src/sys/wasm/../unsupported/time.rs:31:9

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.

Use cargo-semver-checks as part of CI, so we don't accidentally introduce breaking changes.

What is your plans re v3.public will you be supporting it? If so do you have an ETA?

A user should be able to compute the public key from a given private key of the current versions v2, v3 and v4.

This should be straight forward with v2 and v4 since the ed25519 crates support the needed operations as part of their public API. In terms of v3, it seems this will require a dependency on fiat-crypto and implementing scalar multiplication with the curve base/generator. ring does not support computing a public key from the private and does not even have a type to represent a private key.

Based on discussion starting here: #40 (comment)

I am currently using an implementation of paseto but it is currently not being maintained again. This crate, implementation, was recommended but I have issues implementing what I want. In the previous crate, I have these two functions:

...
pub fn issue_confirmation_token(user_id: uuid::Uuid) -> String {
    let settings = crate::settings::get_settings().expect("Cannot load settings.");
    let current_date_time = chrono::Utc::now();
    let dt = current_date_time + chrono::Duration::minutes(settings.secret.token_expiration);
    paseto::tokens::PasetoBuilder::new()
        .set_encryption_key(&Vec::from(settings.secret.secret_key.as_bytes()))
        .set_expiration(&dt)
        .set_not_before(&chrono::Utc::now())
        .set_claim("user_id", serde_json::json!(user_id))
        .build()
        .expect("Failed to construct paseto token w/ builder!")
}

pub async fn verify_confirmation_token(
    token: String,
) -> Result<crate::types::ConfirmationToken, String> {
    let settings = crate::settings::get_settings().expect("Cannot load settings.");
    let token = paseto::tokens::validate_local_token(
        &token,
        None,
        &settings.secret.secret_key.as_bytes(),
        &paseto::tokens::TimeBackend::Chrono,
    )
    .map_err(|e| format!("Paseto: {}", e))?;

    serde_json::from_value::<crate::types::ConfirmationToken>(token)
        .map_err(|e| format!("Serde_json: {}", e))
}
...

How can I achieve these with this crate. The examples in the docs ain't helping much and I had spent ample time trying to get this to work but all to no avail.

Add test for --no-default-features to CI as well.

I think allowing the keys to be serialized to and deserialized from PASERK strings would make sense.

This would be a follow up to #23.

time-rs/time#693

The fix is to update the crate version.

Some applications might only need Paseto local, while some applicaitons might only need Paseto public. In either case they might want to avoid an unnecessary dependency on ed25519-dalek or orion respectively.

So I think the following would make sense:

[features]
default = [ "std", "local", "public" ]
std = [ "serde_json", "chrono" ]
local = [ "orion" ]
public = [ "ed25519-dalek" ]

The current dependency on orion::util::secure_cmp would need to be dropped (we can just directly depend on subtle).

To make docs.rs render feature badges we can employ this trick.

Why do keys not implement clone? There are other ways to write clone for this type in the public interface like AsymmetricSecretKey::from(key.as_bytes()).expect("roundtrip"). So this mostly seems like syntactic salt. Thoughts?

Why TryFrom<String> not TryFrom<&str>?
For example here https://docs.rs/pasetors/0.5.0-alpha.5/src/pasetors/paserk.rs.html#129-141
Why do we need to own the string in order to convert it into a pasetors type?

These are the things remaining before 0.5.0 can be released:

• Add test that test the version features enabled individually not just all at the same time
• Audit error-variants for usage and clarity in context
• Run test-suite on 32-bit target using cross
• Switch to RustCrypto p384 crate once 0.11.0 has been released thereof, which will include P384 support (#55). RFC 6979 support still seems experimental, so we need to add an issue to switch to this in the future.
• Update PASERK test vectors (#59)
• Ensure fuzzing targets are up-to-date

We'd also want to update the listing on paseto.io to indicate we support v3.public.

cc @Eh2406

A minor suggestion

It would be nice if the payload could be relaxed to a non-valid utf-8 encoding, currently it restricts binary encodings. I know binary encoding, is not compliant with the PASETO RFC. As a suggestion, it could be hidden behind a feature flag to allow binary encodings and since the function signature for payload is &[u8], and a valid footer does not need a valid utf-8 encoding.

https://github.com/brycx/pasetors/blob/807d3ad3660158bac25be0f66768d84ee259323d/src/token.rs#L119C21-L119C21

A user should be able to easily generate an asymmetric keypair for v2, v3 and v4.

This should be straight forward with v2 and v4 since the ed25519 crates support the needed operations as part of their public API. In terms of v3, this will probably require pulling in the pkcs8 because this is the only format ring supports the keypair to be exported as. We can get the public key from ring with .public_key().as_ref() but need PKCS8 parsing for the private key.

Based on discussion starting here: #40 (comment)

In #65, we removed the public key as a parameter in sign() operations, re https://github.com/MystenLabs/ed25519-unsafe-libs. What wasn't caught back then and remains now, is the possibility to construct two different AsymmetricSecretKey's, with the same secret seed but different public keys, as the format is seed || pk. This is relevant in settings where the keys can come from to-some-degree untrusted sources.

Therefor, I wish to introduce a check that recomputes the public key from the seed and compares it to the provided. Whether or not this should be an optional check I'm not sure of yet. But at first glance, it seems as if this would be best added in Version::validate_secret_key() impl for V2 and V4, and simply fail if the public keys do not match. It does add some overhead, but increases misuse-resistance.

Edit: InVersion::validate_secret_key() is where the check will be and remain for now.

Instead of using version numbers for the different actions used, it would be better to reference by git commit SHA value.

Also strip "Error" from variant names. See #27

A user should be able to extract the footer and message part of a untrusted token. We can realize this by introducing two new types: UntrustedToken and TrustedToken.

Previous discussion in #40 stated the use case of not knowing what the footer contains, but still wanting to verify it. So a user should be able to get the untrusted footer value and pass it to verify()/decrypt() in order for it to be validated. Note that the footer is both compared in constant time AND is part of the signature for public tokens and the authenticated additional data for the AAD for local tokens. This means, that even if the footer has been tampered with, the signature/tag validtion should fail. Sufficient warnings should be part of the documentation of the UntrustedToken and it's risks.

let untrsuted_token = UntrsutedToken::try_from(untrsuted_input)
// untrsuted_token.footer() -> returns Option(&'a [ u8])
let verify([..], [..], untrsuted_token.footer())?;

verify()/decrypt() functions could then return a TrustedToken with the ability to return the same individual parts of the verified token.

Based on discussion starting here: #40 (comment)

New test vectors have been added that include failures.

See paseto-standard/test-vectors#21

See RustCrypto/elliptic-curves#565

I'm assuming once this is done, the p384 crate will be the one that is maintained going forward.