jws.Sign does not support a custom signer with an algorithm that does not exist in allSignatureAlgorithms. about jwx HOT 7 CLOSED

@ilya-korotya @decentralgabe I've merged #911, but as usual I would like to hold off making a release until the dust settles, so please point your go.mod to the appropriate commit id for the time being.

from jwx.

As a result, there should be no issues with automatically selecting a signature or verification algorithm.

Quite possibly. I just don't want to promise anything unless I know what exactly the problem is: I didn't when you first posted, I now have a bit more idea.

Also, it's not like I have the code and its history memorized.,, I need to figure out why I have allSignatureAlgorithms and signerDB separately, if they can be merged, etc by combing through what I did.

In short, yes, I know you can make that portion work by adding it to one map, but I need to figure out if that makes sense for the whole package, and if there are pros and cons I can only weigh in after I know what your use case.

Anyways, your code is most helpful, let me ponder for a bit.

from jwx.

@ilya-korotya Okay, you can check PR #911. It's something I whipped out in a short period of time, so I don't promise that it's perfect or stable (nor that I'm going to keep this exact implementation), but I think you can try it and let me know if it works for you.

from jwx.

Ah, that looks like an unfortunate side-effect of 2aa98ce. It went unnoticed because we didn't expect people to make up new algorithm families.

Basically, we introduced a new type absctraction over jwa.SignatureAlgorithm / jwa.ContentEncryptionAlgorithm, and that introduced a wee bit more complexity that we should have thought about.

I think I have the choice of a) only allow overriding existing algorithm implementations, or b) allow arbitrary algorithms for signer/verifiers. But I'd like to know your use case, and if possible, a failing test. Currently I'm slightly inclined for (a) because this may tie into changing how we automatically select the appropriate signer/verifier for a given algorithm, but I may be wrong.

Please let me know

from jwx.

I am currently working on integrating BJJ into my project to generate JWS tokens using the BJJ signature algorithm. While I can manually construct a JWT token and then separately add the BJJ signature, I have found that utilizing your library provides a valuable abstraction layer for building JWX with ease.

Test for reproduce the issue:

1. BJJ provider for registration BJJ sign algorithm (bjj_provider.go):

package jwxsignissue

import (
	"errors"
	"fmt"

	"github.com/iden3/go-iden3-crypto/poseidon"
	"github.com/lestrrat-go/jwx/v2/jwa"
	"github.com/lestrrat-go/jwx/v2/jws"
)

const BJJAlg jwa.SignatureAlgorithm = "BJJ"

func init() {
	bjjp := &BjjProvider{}
	jws.RegisterSigner(
		bjjp.Algorithm(),
		jws.SignerFactoryFn(
			func() (jws.Signer, error) {
				return bjjp, nil
			},
		))
}

type BjjProvider struct{}

func (b *BjjProvider) Algorithm() jwa.SignatureAlgorithm {
	return BJJAlg
}

func (b *BjjProvider) Sign(payload []byte, opts interface{}) ([]byte, error) {
	signer, ok := opts.(jws.Signer)
	if !ok {
		return nil, errors.New("bjj signer opts support only signer interface")
	}

	digest, err := poseidon.HashBytes(payload)
	if err != nil {
		return nil, fmt.Errorf("failed get poseidon hash for payload: %v", err)
	}

	return signer.Sign(digest.Bytes(), opts)
}

2. bjj_kms storage for bjj private keys (bjj_kms.go):

package jwxsignissue

import (
	"crypto"
	"io"
	"math/big"

	bjj "github.com/iden3/go-iden3-crypto/babyjub"
)

type BjjKMS struct {
	pk *bjj.PrivateKey
}

func (s *BjjKMS) Public() crypto.PublicKey {
	return nil
}

func (s *BjjKMS) Sign(_ io.Reader, buf []byte, _ crypto.SignerOpts) ([]byte, error) {
	digest := big.NewInt(0).SetBytes(buf)
	sig, err := s.pk.SignPoseidon(digest).Compress().MarshalText()
	if err != nil {
		return nil, err
	}
	return sig, nil
}

3. Test file (bjj_test.go):

package jwxsignissue

import (
	"testing"

	"github.com/lestrrat-go/jwx/v2/jwa"
	"github.com/lestrrat-go/jwx/v2/jws"
	"github.com/stretchr/testify/require"
)

func TestBJJSing(t *testing.T) {
	payload := []byte("hello world")

	signer := &BjjKMS{}

	_, err := jws.Sign(
		payload,
		jws.WithKey(
			jwa.KeyAlgorithmFrom(BJJAlg),
			signer,
		),
	)
	require.ErrorContains(t, err,
		`failed to set "alg" header: invalid value for alg key: invalid jwa.SignatureAlgorithm value`)
}

I believe that it would be beneficial to have the ability to add custom signature algorithms to the current list of supported algorithms. This could be achieved by expanding the allSignatureAlgorithms list during the algorithm registration process. As a result, there should be no issues with automatically selecting a signature or verification algorithm.

from jwx.

It's worth noting that JWT protected headers include an alg header, which specifies the supported algorithm for verifying the token's signature. This allows for the correct verification algorithm to be selected automatically during the validation process.

from jwx.

Yes, this pull request is working for me. I had some errors during implementation, but the pull request above fixed the main issue with the 'unknown signature algorithm'. Now, I am able to sign messages with my BJJ private key.

from jwx.