Is your feature request related to a problem? Please describe.
As of now, the builder accepts only chrono types for set_issued_at, and so on, but in my application i only use the time crate on don't want to pull in chrono as a dependency just for the builder.

Describe the solution you'd like
A feature flag to choose between chrono and time would be really great.

Describe alternatives you've considered
An alternative would be to pass a UNIX timestamp, but that is not really feasible, as it would need a conversion to ISO8601 time, which i guess would end up in using chrono for the conversion.
Something else would be to accept a String, but then all type safety and guaranties that a correctly ISO8601 was passed in would be gone. So i think this is not an option.

So...would be open to such a feature flag? Then i could open a PR.

I evaluated 3 PASETO implementations in Rust and found the API on this one to be most ergonomic and featureful.

But I see there has not been any update in 2 years, the Cargo.toml shows a 3.0.0 release but that's not what's on Crates.io, and 'cargo deny' is complaining about EOL on the failure crate brought in as a dep for 2.0.0.

I also see a few automatic PRs in the queue here, unmerged.

I guess I'm wondering if there's a plan on this project. I'd offer to help out a bit, but I'm no PASETO (or auth/security) expert.

Describe the bug
When I try to build the latest trunk branch, I get the following error.

error[E0308]: mismatched types
  --> src/v2/local.rs:48:48
   |
48 |   if let Ok(mut state) = GenericHashState::new(24, Some(nonce_key)) {
   |                                                ^^
   |                                                |
   |                                                expected enum `Option`, found integer
   |                                                help: try using a variant of the expected enum: `Some(24)`
   |
   = note: expected enum `Option<usize>`
              found type `{integer}`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
error: could not compile `paseto`

To Reproduce
Steps to reproduce the behavior:

1. Check our a fresh copy of the trunk branch or checkout the latest release
2. Run cargo update to update compatible dependencies
3. Run cargo check

Expected behavior
The crate should compile without error.

Versions (please complete the following information):

• OS: Fedora release 34 (Thirty Four) 5.12.11-300.fc34.x86_64
• Rustc version rustc 1.53.0 (53cb7b09b 2021-06-17)
• Version 2.0.1+

Additional context

It would appear that sodiumoxide updated their API which caused a breaking change in this library.

I've forked the repo and will look to provide a PR.

Describe the bug
validate_public_token requires PasetoPublicKey. Which in turn wraps Ed25519KeyPair. It is not possible to create Ed25519KeyPair when only in possession of an &[u8] public key.
For comparison paseto::v2::public::verify_paseto takes the public key as an &[u8], which is what I would expect from validate_public_token also.

Expected behavior
I would expect validate_public_token to take argument public_key: &[u8], instead of the current public_key: PasetoPublicKey (which actually requires a private key to be present). Maybe split the method into separate implementations for V1 and V2?

Description

This project seems to use untrusted = 0.5.1 as I can see from the cargo.toml file on master branch. Recently a security issue was fixed as part of 0.6.2 release. Please refer to rustsec/advisory-db@3c0458d . You can also consider adding cargo audit as part of the build step to get notified in the future.

Kindly ignore if this is irrelevant or fixed on another branch.

Thanks.

Description

Steps to reproduce:

git clone [email protected]:instructure/paseto.git
cargo test

Error message:

running 15 tests
test pae::unit_tests::test_le64 ... ok
test pae::unit_tests::test_pae ... ok
error: process didn't exit successfully: `/Users/kau/Development/paseto/target/debug/deps/paseto-597deab10fb2334f` (signal: 11, SIGSEGV: invalid memory reference)

Hello! I just happened to do a rustup update right after 1.32 was stabilized and found my app was segfaulting. I traced it here and found the tests were doing the same thing. Hopefully you are able to reproduce. Thank you.

Additional Information

• Rust Version
  rustc 1.32.0 (9fda7c223 2019-01-16)

• Platform:
  Mac 10.14.2 (Mojave)

Description

Steps to reproduce

1. Clone this repo
2. cp examples/local-using-builders.rs src/main.rs
3. cargo run

This should verify the token, but it fails with this error mesage.

    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/paseto`
"v2.local.DTpWpnjY9TKfl_pe4i86IEyY4a01zVBjjyFH9abs-xhIBSRKjNXK_W621g9Au0Q08iGo_q5n9qv7aSGaA8hEKau_GqrZXlX4jBSZdPBGBc_OYSdeQbCchl5PWlo8e9LCiq7AUR65P3T-x3evnJhiJ3caPw7RLPwGPeUZMIIPuRzI5qonZ0_aJn0Yr4H6pCgauVl1yvCOrM9H19kW6OEH4MyOv9ULBJFKOhAXO34C73F6x575XSOPrOQeBMKlpdDZMfB9LqhxHMpaWKIy29olMyiO8a7clTJ9MWWfADLNZ-2nUVLl0ba4_d0N.a2V5LWlkOmdhbmRhbGYw"
thread 'main' panicked at 'Failed to validate token!: Error(JsonError, State { next_error: None, backtrace: InternalBacktrace { backtrace: Some(stack backtrace:
   0: error_chain::backtrace::imp::InternalBacktrace::new::h648878bdcff53f4e (0x55687391c0f2)
             at /home/mrceperka/.cargo/registry/src/github.com-1ecc6299db9ec823/error-chain-0.12.0/src/backtrace.rs:56
   1: <error_chain::State as core::default::Default>::default::hf3814f6738a31558 (0x55687391a782)
             at /home/mrceperka/.cargo/registry/src/github.com-1ecc6299db9ec823/error-chain-0.12.0/src/lib.rs:666
   2: paseto::errors::Error::from_kind::h6f1c9a1a05350852 (0x55687386910a)
             at /tmp/paseto/<::error_chain::error_chain::impl_error_chain_processed macros>:53
   3: <paseto::errors::Error as core::convert::From<paseto::errors::ErrorKind>>::from::hb93eaa51c87f0c64 (0x556873869308)
             at src/errors.rs:15
   4: <T as core::convert::Into<U>>::into::h5ee9fb1abfa3f2b5 (0x55687387ae18)
             at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libcore/convert.rs:455
   5: paseto::tokens::validate_potential_json_blob::h769b5ab34b7d3ca5 (0x556873859f90)
             at src/tokens/mod.rs:41
   6: paseto::tokens::validate_local_token::hb51002e1b8109a1b (0x55687385b351)
             at src/tokens/mod.rs:119
   7: paseto::main::h7be5630e7543d4e7 (0x55687384f415)
             at src/main.rs:27
   8: std::rt::lang_start::{{closure}}::h192db9481c263cb7 (0x55687384ebef)
             at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libstd/rt.rs:74
   9: std::rt::lang_start_internal::{{closure}}::h6eb089a6fc5de4c9 (0x556873985872)
             at src/libstd/rt.rs:59
      std::panicking::try::do_call::haa8c3812c8ee3dac
             at src/libstd/panicking.rs:310
  10: __rust_maybe_catch_panic (0x556873993769)
             at src/libpanic_unwind/lib.rs:102
  11: std::panicking::try::hb30f4e80d31f57ea (0x556873986243)
             at src/libstd/panicking.rs:289
      std::panic::catch_unwind::h2d2435e0a6c5ec4e
             at src/libstd/panic.rs:398
      std::rt::lang_start_internal::h209b9d62a82d0a63
             at src/libstd/rt.rs:58
  12: std::rt::lang_start::h1e7ba43d3fbb373f (0x55687384ebc8)
             at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libstd/rt.rs:74
  13: main (0x55687384f809)
  14: __libc_start_main (0x7fb6e4117b96)
  15: _start (0x55687384dd69)
  16: <unknown> (0x0)) } })', src/libcore/result.rs:1009:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:211
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:476
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:390
   6: rust_begin_unwind
             at src/libstd/panicking.rs:325
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:77
   8: core::result::unwrap_failed
             at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libcore/macros.rs:26
   9: <core::result::Result<T, E>>::expect
             at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libcore/result.rs:835
  10: paseto::main
             at src/main.rs:27
  11: std::rt::lang_start::{{closure}}
             at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libstd/rt.rs:74
  12: std::panicking::try::do_call
             at src/libstd/rt.rs:59
             at src/libstd/panicking.rs:310
  13: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:102
  14: std::rt::lang_start_internal
             at src/libstd/panicking.rs:289
             at src/libstd/panic.rs:398
             at src/libstd/rt.rs:58
  15: std::rt::lang_start
             at /rustc/6bfb46e4ac9a2704f06de1a2ff7a4612cd70c8cb/src/libstd/rt.rs:74
  16: main
  17: __libc_start_main
  18: _start

Additional Information

• Rust Version: rustc 1.32.0-nightly (6bfb46e4a 2018-11-26)
• Platform: Ubuntu 18.04.1 LTS

Is your feature request related to a problem? Please describe.
I have a project I am currently using paseto for. I have implemented all other endpoints required for authentication and authorization but left with logging out users. But I can't seem to figure out how to invalidate tokens.

Describe the solution you'd like
I want a method to invalidate the tokens generated.

Describe alternatives you've considered
I have not tried out any other alternatives yet.

Additional context
N/A

Issue creation requested here: #23 (comment)

There are currently 3 features that can be disabled and all possible combinations should be checked that they build & pass test during CI.

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

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

Is your feature request related to a problem? Please describe.
I have the following bit of toy code:

let state = paseto::tokens::PasetoBuilder::new()
  .set_encryption_key(Vec::from("FISHYLAKEBLACKMAGIC".as_bytes()))
  .set_expiration(Utc::now() + Duration::minutes(15))
  .set_not_before(Utc::now())
  .build()
  .expect("failed to construct paseto token");

and I'm getting a nasty error:

thread 'main' panicked at 'failed to construct paseto token: InvalidKey

Looking at the documentation however, I don't see any rules regarding what makes a key valid or invalid.

Describe the solution you'd like
Some explanation of the requirements for set_encryption_key in the docs.

Describe alternatives you've considered
n/a

Additional context
n/a

Describe the bug
Building and validating a local token does not work.

To Reproduce

#[cfg(test)]
mod tests {
  use chrono::prelude::Utc;
  use chrono::Duration;

  #[test]
  fn paseto_build_validate() {
    let key = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
    let state = paseto::tokens::PasetoBuilder::new()
      .set_encryption_key(key.as_bytes())
      .set_expiration(&(Utc::now() + Duration::minutes(1)))
      .set_not_before(&Utc::now())
      .build()
      .expect("failed to construct paseto token");
    println!("{}", state);

    let validation = paseto::tokens::validate_local_token(
      &state,
      None,
      key.as_bytes(),
      &paseto::tokens::TimeBackend::Chrono,
    );
    println!("{:?}", validation);
    assert!(validation.is_ok());
  }
}

I'm getting

running 1 test
v2.local.c4IpI4S4kU-sb-wNW7mTmreWGhOLsO42SF0PDUuidfBGKmYiI6jQKqqa2RUnxzqK75moe8IjfNOROBw9c1QaYDzD1lGatPiEeoqt-D36Mw89wPlsB3dA3OwXako0Cu3Nrnc5svohjTRREiDDZOu3bPbYIxzlT58
Err(UnparseableTokenDate { claim_name: "iat" }

   0: failure::backtrace::internal::InternalBacktrace::new
             at /home/skainswo/.cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.8/src/backtrace/internal.rs:46:44
   1: failure::backtrace::Backtrace::new
             at /home/skainswo/.cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.8/src/backtrace/mod.rs:121:35
   2: <failure::error::error_impl::ErrorImpl as core::convert::From<F>>::from
             at /home/skainswo/.cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.8/src/error/error_impl.rs:19:17
   3: <failure::error::Error as core::convert::From<F>>::from
             at /home/skainswo/.cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.8/src/error/mod.rs:36:18
   4: paseto::tokens::validate_potential_json_blob
             at /home/skainswo/.cargo/registry/src/github.com-1ecc6299db9ec823/paseto-2.0.0+1.0.3/src/tokens/mod.rs:74:11
   5: paseto::tokens::validate_local_token
             at /home/skainswo/.cargo/registry/src/github.com-1ecc6299db9ec823/paseto-2.0.0+1.0.3/src/tokens/mod.rs:181:14
   6: api::auth::tests::paseto_build_validate
             at src/auth.rs:383:22
   7: api::auth::tests::paseto_build_validate::{{closure}}
             at src/auth.rs:373:3
   8: core::ops::function::FnOnce::call_once
             at /build/rustc-1.49.0-src/library/core/src/ops/function.rs:227:5
   9: test::__rust_begin_short_backtrace
  10: test::run_test::run_test_inner::{{closure}}
  11: std::sys_common::backtrace::__rust_begin_short_backtrace
  12: core::ops::function::FnOnce::call_once{{vtable.shim}}
  13: std::sys::unix::thread::Thread::new::thread_start
  14: start_thread
  15: __GI___clone
)
thread 'auth::tests::paseto_build_validate' panicked at 'assertion failed: validation.is_ok()', src/auth.rs:390:5
stack backtrace:
   0: std::panicking::begin_panic
             at /build/rustc-1.49.0-src/library/std/src/panicking.rs:521:12
   1: api::auth::tests::paseto_build_validate
             at ./src/auth.rs:390:5
   2: api::auth::tests::paseto_build_validate::{{closure}}
             at ./src/auth.rs:373:3
   3: core::ops::function::FnOnce::call_once
             at /build/rustc-1.49.0-src/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
test auth::tests::paseto_build_validate ... FAILED

failures:

failures:
    auth::tests::paseto_build_validate

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

Versions (please complete the following information):

• OS: NixOS 20.09
• Rustc version [rustc --version]: 1.49.0
• Version 2.0.0+1.0.3

Additional context
I can confirm this was working on paseto 1.0.7.