Invalid Signature

[digitalrbnz]

I am creating a client assertion signed JWT using RSA and PS512. The token seems to be fine if decoded and all the signatures verify in JWT IO and state the correct algorithm.

"Invalid token signature"

However when I attempt to use this as part of a client credential auth, I get an invalid signature error.

If I use exactly the same key kid, claims etc using KJUR library in js or postman, it works fine.

One thing I noticed is that the token size using KJUR us much smaller than using this library, even though the header, payment and and signing are all the same.

final jwt = JWT(
      header: Map.from(<String, String>{
        'kid': '1231231231',
        'typ': 'JWT',
      }),
      // Payload
      {
        'iss': clientID,
        'exp': (expiration_time.millisecondsSinceEpoch ~/ 1000) + 3590,
        'iat': (current_time.millisecondsSinceEpoch ~/ 1000) - 120,
        'jti': uuid.v4(),
      },
      audience: Audience(
          ['https://idpprovider.com/oauth/v2.0/token']),
      subject: clientID,
    );

    final token = jwt.sign(RSAPrivateKey(privateKey),
        algorithm: JWTAlgorithm.PS512,
        expiresIn: Duration(minutes: 50),
        noIssueAt: true);

Are there any known issues here or something obvious I might be missing?

[user163]

The problem is that the dart library for PSS uses a fixed salt length of 32 bytes (s. here), while RFC 7518, sec. 3.5 defines that the salt length must correspond to the digest output size, i.e. 32 bytes for PS256, 48 bytes for PS384 and 64 bytes for PS512. Therefore, the current implementation only generates RFC7518 compliant signatures for PS256, but neither for PS384 nor for PS512.

[digitalrbnz]

The problem is that the dart library for PSS uses a fixed salt length of 32 bytes (s. here), while RFC 7518, sec. 3.5 defines that the salt length must correspond to the digest output size, i.e. 32 bytes for PS256, 48 bytes for PS384 and 64 bytes for PS512. Therefore, the current implementation only generates RFC7518 compliant signatures for PS256, but neither for PS384 nor for PS512.

Thanks for your response. I have just confirmed this is the issue. I updated the following from 32 > 64 and it is now working. I will add a switch statement for the version and submit a PR.

  @override
  Uint8List sign(JWTKey key, Uint8List body) {
    assert(key is RSAPrivateKey, 'key must be a RSAPrivateKey');
    final privateKey = key as RSAPrivateKey;

    final algorithm = _getAlgorithm(name);

    final signer = pc.Signer('${_getHash(name)}/${algorithm}');
    pc.CipherParameters params = pc.PrivateKeyParameter<pc.RSAPrivateKey>(
      privateKey.key,
    );

    if (algorithm == 'PSS') {
      final random = _random ?? Random.secure();
      final salt = Uint8List.fromList(
        List.generate(**64**, (_) => random.nextInt(256)),
      );

      params = pc.ParametersWithSalt(
        params,
        salt,
      );
    }

    signer.init(true, params);

    final signature = signer.generateSignature(Uint8List.fromList(body));

    if (signature is pc.PSSSignature) {
      return signature.bytes;
    } else {
      return (signature as pc.RSASignature).bytes;
    }
  }

[user163]

Be careful. If you hard-code 64 instead of 32, PS512 will work, but no longer PS256 and PS384. A possible working solution is e.g. to implement a function:

int _getDigestOutputSize(String name) {
    switch (name) {
      case 'PS256':
        return 32;
      case 'PS384':
        return 48;
      case 'PS512':
        return 64;
      default:
        throw ArgumentError.value(name, 'name', 'unknown hash name');
    }
}

(analogous to _getHash()) and to apply this function instead of the hard-coded 32 in sign() as follows:

final salt = Uint8List.fromList(
    List.generate(_getDigestOutputSize(name), (_) => random.nextInt(256)),
);

and in verify() as follows:

params = pc.ParametersWithSaltConfiguration(
    params,
    secureRandom,
    _getDigestOutputSize(name),
);

However, I have only tested this randomly.

[digitalrbnz]

@user163 Agreed. That was just for testing purposes. I have added a switch statement to the sign and verify functions and preliminary testing checks out. PR has been raised -> #59

Thanks again for identifying the issue. You have been credited in the PR.