PAKEs icon indicating copy to clipboard operation
PAKEs copied to clipboard

spake2: transcript does not appear to be encoded as shown in RFC 9382

Open potto216 opened this issue 1 year ago • 6 comments

The SPAKE2 transcript does not appear to be encoded as shown in RFC 9382 section 3.3 because the order of the transcript elements and what is being hashed for those elements is different.

It looks like in the SPAKE2 code the transcript is computed in finish which calls either hash_ab or hash_symmetric and they are forming the transcript from first the hash of the password and then the hash of the identities (below).

    let mut transcript = [0u8; 6 * 32];

    let mut pw_hash = Sha256::new();
    pw_hash.update(password_vec);
    transcript[0..32].copy_from_slice(&pw_hash.finalize());

    let mut ida_hash = Sha256::new();
    ida_hash.update(id_a);
    transcript[32..64].copy_from_slice(&ida_hash.finalize());

    let mut idb_hash = Sha256::new();
    idb_hash.update(id_b);
    transcript[64..96].copy_from_slice(&idb_hash.finalize());
...

But this differs from section 3.3 of the RFC because the transcript TT is encoded as:

        TT = len(A)  || A
          || len(B)  || B
          || len(pA) || pA
          || len(pB) || pB
          || len(K)  || K
          || len(w)  || w

where A and B are the identities and the pA and pB are hashes of the password hash multiplied by a point on the elliptic curve and added to another random point on the elliptic curve.

I'm happy to continue the analysis and write a fix, but I want to make sure this is a valid issue first

potto216 avatar Dec 28 '24 17:12 potto216

If you can help make our implementation RFC9382 compliant, great

tarcieri avatar Jan 03 '25 18:01 tarcieri

Okay great, I'll work on a PR with potential changes to discuss.

potto216 avatar Jan 05 '25 02:01 potto216