Closed ksivask closed 1 year ago
The issue is in how src/jwe.c:_r_jwe_ecdh_decrypt()
separates _r_concat_kdf()
and gnutls_hash_fast()
functionality. per the spec, 'n' rounds needs to performed. refer: https://www.rfc-editor.org/rfc/rfc7518.html#section-4.6.2
Since I am using this tool for cross functional testing, I have patched the source to follow the spec.
Hello,
I'm not sure I'm following, can you quote the part in the specs where it specifies the number of rounds required to get the key?
https://www.rfc-editor.org/rfc/rfc7518.html#section-4.6.2 section references the NIST spec for KDF.
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf 5.8.1.1 The Single-Step KDF Specification
Also check https://www.rfc-editor.org/rfc/rfc7518.html#section-5.2 for specs on various AES_XXX_CBC_HMAC_SHA_XXX.
The gnutls_hash_fast(GNUTLS_DIG_SHA256, kdf.data, kdf.size, derived_key)
only generates 32 byte hash, thus only R_JWA_ENC_A128CBC
works as expected. Both R_JWA_ENC_A192CBC
and R_JWA_ENC_A256CBC
dont have the full input key "K"
So if I follow you, I should use gnutls_hash_fast with GNUTLS_DIG_SHA384
on R_JWA_ENC_A192CBC
and GNUTLS_DIG_SHA512
on R_JWA_ENC_A256CBC
?
I may have misread the RFC where it states:
It uses the HMAC message
authentication code [[RFC2104](https://www.rfc-editor.org/rfc/rfc2104)]
with the SHA-256 hash function [[SHS](https://www.rfc-editor.org/rfc/rfc7518.html#ref-SHS)] to
provide message authentication, with the HMAC output truncated to 128
bits, corresponding to the HMAC-SHA-256-128 algorithm defined in
[[RFC4868](https://www.rfc-editor.org/rfc/rfc4868)].
But you mentioned the number of rounds to hash the key, I don't see anything in the specs that would suggest other number of round than 1, did I misread that too?
no, thats not what I meant.
Per https://www.rfc-editor.org/rfc/rfc7518.html#section-4.6.2, the "Digest Method is SHA-256" for "Key Derivation for ECDH Key Agreement". Per the NIST, the reps = ceil(keydatalen / hashlen)
. please review the 5.8.1.1 section "Process".
for example: for A256CBC, you have to do 2 rounds of KDF. K is derived_key. 1st round: sha256(1, ZKey, OtherInfo) = 1st 32 bytes of K 2nd round: sha256(2, ZKey, OtherInfo) = 2nd 32 bytes of K.
For A192CBC, same as above, but K truncated to 48 bytes. thus MAC_KEY and ENC_KEY each get 24 bytes.
The above is roughly my patch in plaintext. I can send a PR after running the test cases.
The above is roughly my patch in plaintext. I can send a PR after running the test cases.
Yes please, that would be appreciated
Sample EC256 Key & Data:
rhonabwy:
NOTE: both encrypt and decrypt use {0} as key (last 32 bytes)
go-jose:
Using another JWE tool
Patched rnbyc:
NOTE: the key is now correct
Cross verify with go-jose/jose-util: