ianleeclark / paseto Goto Github PK

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.

Let's say I generate a token with a footer:

token = Paseto.generate_token("v2", "local", payload, secret, "key_id")

I'm using the footer to carry the id of the key used to sign the message, so I need to be able to read the footer before I attempt to use parse_token/2.

At the moment I'm using this code:

{:ok, %Paseto.Token{footer: footer}} = Paseto.Utils.parse_token(token)
key_id = Paseto.Utils.b64_decode!(footer)

And it works fine, but I'm wondering if I'm doing the right thing since I have to base64-decode the foote rmyself? I'm also worried that Paseto.Util might be considered private?

This is due to us needing crypto:sign/5 so that the library can use pkcs1 pss padding

PasetoPlug & guardian_paseto

It looks like the libsalty dependency is incompatible with Erlang 23.0.

ld: library not found for -lerl_interface
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [priv/salty_nif.so] Error 1

Unless I've totally misconfigured something, the example from the README for generating a token does not work:

iex(3)> {:ok, pk, sk} = Salty.Sign.Ed25519.keypair()
iex(4)> keypair = {pk, sk}
iex(5)> token = generate_token("v2", "public", "This is a test message", keypair)
** (CompileError) iex:5: undefined function generate_token/4

Expected: a valid string token.
Actual: CompileError.

I think the line should be:

 token = Paseto.generate_token("v2", "public", "This is a test message", keypair)

It would also be nice if you included how to convert the pk and sk to a regular old copy-and-pasteable string so we could easily use it in a config file.

Apologies for opening an issue just for a question.

When using parse_token inside a Plug, I'm wondering whether I need to match on the message returned in an {:error, message} tuple, or is it safe to just forward the message as part of the HTTP response? Would I be giving away too much in this case?

Full list is here https://erlang.org/documentation/doc-12.0-rc2/doc/general_info/removed.html#functions-removed-in-otp-24

Warnings on OTP24:

==> paseto
Compiling 7 files (.ex)
warning: :crypto.hmac/3 is undefined or private, use crypto:mac/4 instead
  lib/paseto/utils/crypto.ex:73: Paseto.Utils.Crypto.hmac_sha384/2

warning: :crypto.hmac/4 is undefined or private, use crypto:macN/5 instead
  lib/paseto/utils/crypto.ex:81: Paseto.Utils.Crypto.hmac_sha384/3

warning: :crypto.stream_decrypt/2 is undefined or private, use crypto:crypto_update/2 instead
  lib/paseto/utils/crypto.ex:25: Paseto.Utils.Crypto.aes_256_ctr_decrypt/3

warning: :crypto.stream_encrypt/2 is undefined or private, use crypto:crypto_update/2 instead
  lib/paseto/utils/crypto.ex:13: Paseto.Utils.Crypto.aes_256_ctr_encrypt/3

warning: :crypto.stream_init/3 is undefined or private, use crypto:crypto_init/3 + crypto:crypto_update/2 + crypto:crypto_final/1 or crypto:crypto_one_time/4 instead
Found at 2 locations:
  lib/paseto/utils/crypto.ex:12: Paseto.Utils.Crypto.aes_256_ctr_encrypt/3
  lib/paseto/utils/crypto.ex:24: Paseto.Utils.Crypto.aes_256_ctr_decrypt/3

It seems that only V1 is affected by this.

Not an issue but a question.

A PHP app communicating with our Elixir app wants to upgrade to paseto V3.
Due to some dependency updates they need to update their PHP paseto package which includes compatible dependencies but is dropping support for V1 and V2.

Are there any intentions to bring V3 and V4 support into this package?