Symmetric/local keys work great, however...

        v2 := paseto.NewV2()
	_, privateKey, err := ed25519.GenerateKey(nil)

	jsonToken := paseto.JSONToken{
		Expiration: time.Now().Add(24 * time.Hour),
		Subject:    "Foo",
		Audience:   "Bar",
		Issuer:     "This guy",
		IssuedAt:   time.Now(),
	}

	// Add custom claim    to the token
	jsonToken.Set("data", "this is a signed message")
	footer := "some footer"

	// Sign data
	token, err := v2.Sign(privateKey, &jsonToken, &footer)

Gives a err of incorrect private key type. What am I doing wrong here?

When running the example in the README, the local mode decryption step fails with error "can't unmarshal token data to the given type of value". Right now the library seems unusable.

Removed dependency on github.com/pkg/errors. Updated golang.org/x/crypto/ed25519 to crypto/ed25519. Updated test files.

These are api breaking changes, error checking and ed25519 code dependent on this version of paseto will need to be updated.

I want to add my own claim to the JSONToken. I tried to use

type MyToken struct {
	paseto.JSONToken
	Groups []string `json:"groups"`
}

but it doesn't work (field does not appear in my token). There is JSONToken.Set, but it only works with strings.

In the Paseto documentation, there are two conflicting stances on how one should use the token's footer:

• The PHP implementation mandates that decryption and verification operations match an expected footer against the token's actual footer.
• The documentation suggests that the footer can be used to specify facts to the receiver, such as a key ID (here and here).

In the former case, the receiver knows and will tolerate only one footer. In the latter case, the receiver only knows the schema of the footer, but can't know its value; rather, the receiver needs to read the value to know how to proceed.

This library doesn't take either approach to heart: neither the decryption nor verification functions accept an expected footer value to match, nor is there a means to extract a footer first to guide the rest of the decryption or verification process.

What is the author's take on the role of the token footer?

Hi, try to install via command go get -u github.com/o1egl/paseto, but I can only get version 1.0.0, using go get -u github.com/o1egl/[email protected], it said invalid version: unknown revision v2.0.0. Am I the only one who run into this? Thanks.

How i can create private/public key like from README.md - "Create token using asymetric key (public mode)" and use like files (id_ed25519, id_ed25519.pub) b, _ := hex.DecodeString("b4cbfb43df4ce210727d953e4a713307fa19bb7d9f85041438d9e11b942a37741eb9dbbbbc047c03fd70604e0071f0987e16b28b757225c11f00415d0e20b1a2") privateKey := ed25519.PrivateKey(b)

b, _ = hex.DecodeString("1eb9dbbbbc047c03fd70604e0071f0987e16b28b757225c11f00415d0e20b1a2") publicKey := ed25519.PublicKey(b)

Hi,

Thanks for the package!

I believe I found a problem with custom claims, specifically when using a struct as custom claim with field named via json tags.

To reproduce:

package main

import (
	"encoding/base64"
	"encoding/json"
	"fmt"
	"log"

	"github.com/o1egl/paseto/v2"
)

type someClaim struct {
	Foo string `json:"foox"`
}

func main() {
	secret, _ := base64.StdEncoding.DecodeString("vQVOM5M6dUftMNhwkvjTX3ObFupqzRrYMSc/IM9hZ2M=")

	tokenIn := &paseto.JSONToken{}
	tokenIn.Set("someclaim", &someClaim{Foo: "nonempty"})

	tokenInStr, _ := paseto.Encrypt(secret, tokenIn, "")

	tokenOut := &paseto.JSONToken{}
	paseto.Decrypt(tokenInStr, secret, tokenOut, nil)

	var someClaim someClaim
	tokenOut.Get("someclaim", &someClaim)
	out, _ := json.Marshal(someClaim)
	fmt.Printf("claim: %s\n", out)
	
	tokenOutStr, _ := tokenOut.MarshalJSON()
	fmt.Printf("token: %s\n", tokenOutStr)
}

Expected:

claim: {"foox":"nonempty"}
token: {"someclaim":{"foox":"nonempty"}}

Got:

claim: {"foox":""}
token: {"someclaim":{"foox":"nonempty"}}

Removing the json:"foox" tag fixes the issue, but this is of course not ideal.

Cheers

Using go get retrieves version 1 of the library rather than version 2. Is version 2 available like other versioned packages? I tried adding the version number to the package, but no luck.

Thanks

Given that PASETO is designed for "Resistance to Implementation Error / Misuse", I'm surprised the examples don't cover calling JSONToken.Validate, nor does JSONToken.UnmarshalJSON do this on it's own.

The documentation does indicate that the standard claims are optional, which would mean that calling the default set of validation functions during JSONToken.Unmarshal might break the current usage patterns for some people. That said, the documented usage goes through the trouble of setting an Expiration that is never verified.

This isn't too hard to fix, but I was curious if the maintainers are open to something more intrusive (breaking use of JSONToken without an Expiration, and NotBefore date, and ensuring UnmarshalJSON checks this) to prevent mistakes, or if just updating the documentation would be preferable.

Wanted to open this issue for discussion.

I have my token, symmetric key and footer string passed

v2 := paseto.NewV2()
err := v2.Decrypt(token, symmetricKey, &newJSONToken, &newFooter)

But how do I verify data?

I found there is newJSONToken.Validate() function which basically returns an error if there is any.

I have a couple of question for this library:

1. Is verification done by verifying "key" and "value" set using "Set" method on JSONToken?
2. Can "token" generated be altered like "JWT" and pass modified or tampered data?
3. Can "token" generated using "paseto" be decrypted and viewed like "JWT"?

Thanks

We at awesome-go noticed that the project has been without commits for over 1 year, is the project active?

ref: https://github.com/avelino/awesome-go/issues/4016

As alluded to in #32, keys should to be strongly bound to their parameter choices to prevent algorithm confusion attacks (so byte arrays or similar shouldn't be accepted). From the PASETO spec:

PASETO Cryptography Key Requirements

Cryptography keys in PASETO are defined as both the raw key material and its parameter choices, not just the raw key material.

PASETO implementations MUST enforce some logical separation between different key types; especially when the raw key material is the same (i.e. a 256-bit opaque blob).

Arbitrary strings (or byte arrays, or equivalent language constructs) MUST NOT be accepted as a key in any PASETO library, [...]

I've opted to refactor the core PASETO operations into methods associated with each specific key (e.g. V2SymmetricKey has implementations for encrypt, decrypt involving its raw material). This means that the version level methods just need to do a type assertion checking that the given key matches the version, before deferring down to the key specific implementation.

Fixes #32

This changes the token_validator to return a ErrTokenExpiredError instead of ErrTokenValidationError. This allows us to check for token expiration which differs from a regular token error. (e.g. trigger a refresh).

https://github.com/o1egl/paseto/blob/f1000e3be0ce1d221c08cebbe13e184414a092f6/v2.go#L78

https://github.com/o1egl/paseto/blob/f1000e3be0ce1d221c08cebbe13e184414a092f6/v2.go#L138

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.