Open dgamidov opened 3 years ago
Same problem here.
~I dont know the minimum OTP version supported by this project (base on CI tests, its probably 22?) But for OTP 21+ we could rely on crypto native implementation for RSASSA-PS since 4.1~
Edit: we are already using it via public_key module
The reason here is because JOSE is not passing the saltlen options of the rsa pss padding. You can directly change that with an ultra unreliable code like this:
:ets.insert(:jose_jwa, {{:rsa_sign, :rsa_pkcs1_pss_padding}, {:public_key, [rsa_padding: :rsa_pkcs1_pss_padding, rsa_pss_saltlen: -1]}})
Then your case will pass.
This is because the "detection" algorithm used by JOSE needs to be updated. When booting up it tries to detect the available options by simply trying a few options and signing/verifying them here. That is sub-optimal because depending on the combination of OpenSSL version plus OTP you might have several more options than the ones that are tried. On my machine, for instance, I have this output for :crypto.supports()
:
[
hashs: [:sha, :sha224, :sha256, :sha384, :sha512, :sha3_224, :sha3_256,
:sha3_384, :sha3_512, :blake2b, :blake2s, :md4, :md5, :ripemd160],
ciphers: [:aes_cbc, :aes_ccm, :aes_cfb128, :aes_cfb8, :aes_ctr, :aes_ecb,
:aes_gcm, :chacha20, :blowfish_ecb, :blowfish_ofb64, :blowfish_cfb64,
:blowfish_cbc, :des_ede3_cfb, :des_ede3_cbc, :des_ecb, :des_cfb, :des_cbc,
:rc4, :rc2_cbc, :aes_128_cbc, :aes_192_cbc, :aes_256_cbc, :aes_128_cfb128,
:aes_192_cfb128, :aes_256_cfb128, :aes_128_cfb8, :aes_192_cfb8,
:aes_256_cfb8, :aes_128_ecb, :aes_192_ecb, :aes_256_ecb, :aes_256_ccm,
:aes_192_gcm, :aes_192_ccm, :aes_128_ccm, :aes_256_ctr, :aes_192_ctr,
:aes_128_ctr, :chacha20_poly1305, :aes_256_gcm, :aes_128_gcm],
public_keys: [:rsa, :dss, :dh, :ec_gf2m, :ecdsa, :ecdh, :eddsa, :eddh, :srp],
macs: [:cmac, :hmac, :poly1305],
curves: [:secp160k1, :secp160r1, :secp160r2, :secp192k1, :secp224k1,
:secp224r1, :secp256k1, :secp384r1, :secp521r1, :secp192r1, :prime192v1,
:prime192v2, :prime192v3, :prime239v1, :prime239v2, :prime239v3, :secp256r1,
:prime256v1, :wtls7, :wtls9, :wtls12, :brainpoolP160r1, :brainpoolP160t1,
:brainpoolP192r1, :brainpoolP192t1, :brainpoolP224r1, :brainpoolP224t1,
:brainpoolP256r1, :brainpoolP256t1, :brainpoolP320r1, :brainpoolP320t1,
:brainpoolP384r1, :brainpoolP384t1, :brainpoolP512r1, :brainpoolP512t1,
:sect163k1, :sect163r1, :sect163r2, :sect193r1, :sect193r2, :sect233k1,
:sect233r1, :sect239k1, :sect283k1, :sect283r1, ...],
rsa_opts: [:rsa_pkcs1_pss_padding, :rsa_pss_saltlen, :rsa_mgf1_md,
:rsa_pkcs1_oaep_padding, :rsa_oaep_label, :rsa_oaep_md, :signature_md,
:rsa_pkcs1_padding, :rsa_x931_padding, :rsa_sslv23_padding, :rsa_no_padding]
]
As you can see, we should add a lot more logic on this detection algorithm I think.
HI the issue is still alive :-) but the unreliable solution works fine
Erlang/OTP 24 [erts-12.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit] [dtrace]
IEx 1.13.3 (compiled with Erlang/OTP 24)
{:jose, "~> 1.11"}
Can confirm, same issue encountered, temp fix did resolve it.
{:jose, "~> 1.11.2"},
Erlang/OTP 24 [erts-12.1.5] [source] [64-bit] [smp:32:32] [ds:32:32:10] [async-threads:1] [jit]
Hello! I am trying to sign JWT with RSA-2048 key using PS256, but it seems that JOSE.JWT.sign generates invalid signature.
Jose version 1.11.2
For PS256 signature is invalid (checked on on https://jwt.io):
For RS256 signature (same private key) is valid: