3 ms·

That's really useful, thanks. I barely understood a word of the OP.

couchand 3y ago
The link is a specification of the protocol, not a tutorial. It is intended to unambiguously state the operations, and requires significant background knowledge to be able to read correctly.
- drcongo 3y ago
  I know, that's why I thanked this poster for adding some links that are easier to understand.
  - ylk 3y ago
    Signal also created an easier to understand blog post in case you haven’t seen it, yet: https://signal.org/blog/pqxdh/ https://signal.org/blog/pqxdh/
ignoramous 3y ago
I guess if you're not already familiar with the Signal protocol specs, the current documentation might feel a little incomplete. TLDR is, SS (shared secret) derived rom Kyber is mixed in to make the handshake, which outputs SessionKey (SK), pq safe. Note though, offline authentication (of identities) itself isn't pq safe (the authors plan to address this in the near future, however). // CipherText (CT) and SharedSecret (SS) as outputs from Kyber (CT, SS) = Kyber(PostQuantumOneTimePublicPreKeyBob) // DH1, DH2, DH3, and optionally DH4 are Diffie-Hellman-Merkel outputs SecretKey = HKDF-Signal(DH1 || DH2 || DH3 || *SS*) // or StrongSecretKey = HKDF-Signal(DH1 || DH2 || DH3 || DH4 || *SS*) From Signal's PQ-XDH spec (section 4.11): > Kyber hashes Bob's public (pre)key with Alice's random bits to generate the shared secret, making Bob's key contributory, as it is with a Diffie-Hellman key exchange. This does not reduce the dependence on Alice's entropy source but it does limit Alice's ability to control the post-quantum shared secret (SS). Not all KEMs make Bob's key contributory and this is a property to consider when selecting pqkem. The pqkem (Kyber) happens 2 phases (1a & 1b below): ---------- Alice: xx. recv(publickey) 0a. msg <- prng(256bits) 0b. random1, random2 = sha3-512(msg || sha3-256(publickey)) 1a. ct = encrypt(publickey, msg, random2) 1b. ss = shake256(random1 || sha3-256(ct)) xx. send(ct); store(ss) ---------- Bob: yy. recv(ct) 0a. msg' = decrypt(ct, privatekey) 0b. random1', random2' = sha3-512(msg' || sha3-256(publickey)) 1a. ct' = encrypt(publickey, msg', random2') yy. assert(ct == ct') 1b. ss = shake256(random1' || sha3-256(ct)) yy. store(ss) ---------- Both: zz. sk = ss mixed with X3DH zz. AEAD verify sk ---------- Refs: - Crystal-Kyber: https://pq-crystals.org/kyber/data/kyber-specification-round3-20210804.pdf https://pq-crystals.org/kyber/data/kyber-specification-round... (pg 10 - 11; algorithms 8 & 9) - NIST ML-KEM: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf (pg 30 - 32; algorithms 16 & 17)

The link is a specification of the protocol, not a tutorial. It is intended to unambiguously state the operations, and requires significant background knowledge to be able to read correctly.

drcongo 3y ago
I know, that's why I thanked this poster for adding some links that are easier to understand.
- ylk 3y ago
  Signal also created an easier to understand blog post in case you haven’t seen it, yet: https://signal.org/blog/pqxdh/ https://signal.org/blog/pqxdh/

ignoramous 3y ago

I guess if you're not already familiar with the Signal protocol specs, the current documentation might feel a little incomplete. TLDR is, SS (shared secret) derived rom Kyber is mixed in to make the handshake, which outputs SessionKey (SK), pq safe. Note though, offline authentication (of identities) itself isn't pq safe (the authors plan to address this in the near future, however). // CipherText (CT) and SharedSecret (SS) as outputs from Kyber (CT, SS) = Kyber(PostQuantumOneTimePublicPreKeyBob) // DH1, DH2, DH3, and optionally DH4 are Diffie-Hellman-Merkel outputs SecretKey = HKDF-Signal(DH1 || DH2 || DH3 || *SS*) // or StrongSecretKey = HKDF-Signal(DH1 || DH2 || DH3 || DH4 || *SS*) From Signal's PQ-XDH spec (section 4.11): > Kyber hashes Bob's public (pre)key with Alice's random bits to generate the shared secret, making Bob's key contributory, as it is with a Diffie-Hellman key exchange. This does not reduce the dependence on Alice's entropy source but it does limit Alice's ability to control the post-quantum shared secret (SS). Not all KEMs make Bob's key contributory and this is a property to consider when selecting pqkem. The pqkem (Kyber) happens 2 phases (1a & 1b below): ---------- Alice: xx. recv(publickey) 0a. msg <- prng(256bits) 0b. random1, random2 = sha3-512(msg || sha3-256(publickey)) 1a. ct = encrypt(publickey, msg, random2) 1b. ss = shake256(random1 || sha3-256(ct)) xx. send(ct); store(ss) ---------- Bob: yy. recv(ct) 0a. msg' = decrypt(ct, privatekey) 0b. random1', random2' = sha3-512(msg' || sha3-256(publickey)) 1a. ct' = encrypt(publickey, msg', random2') yy. assert(ct == ct') 1b. ss = shake256(random1' || sha3-256(ct)) yy. store(ss) ---------- Both: zz. sk = ss mixed with X3DH zz. AEAD verify sk ---------- Refs: - Crystal-Kyber: https://pq-crystals.org/kyber/data/kyber-specification-round3-20210804.pdf https://pq-crystals.org/kyber/data/kyber-specification-round... (pg 10 - 11; algorithms 8 & 9) - NIST ML-KEM: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf (pg 30 - 32; algorithms 16 & 17)