A couple minor spelling/grammar corrections.

micahrequested to merge
micah/torspec:pq_edits into main

Hi @nickm - I was reading over your new prop355, really interesting and impressive effort! I enjoyed reading about the handshake design choices for a PQ tor and I like the transitional vs. "next-generation environment" distinction. The performance tables and the short round trip examples are really helpful to see also!

While reading, I found a couple of minor typos that are addressed in this MR.

NB: one of these changes, I am not certain about, specifically this one:

- * R2->Client: "Extra data reply", "EXTENDED2 (from R23."

+ * R2->Client: "Extra data reply", "EXTENDED2 (from R3)."

I had a couple notes that I made while reading that aren't necessarily actionable items, but I provide them here because I wasn't sure where else it would make sense to do so, feel free to ignore if I've got anything fundamentally wrong that would require substantial explanation to educate me in what I am missing, as that is likely the case due to my limited depth in both the PQ and lower-level tor fundamentals.

  • You mention the the NIST standardized algorithms by calling them "ML-KEM, ML-DSA, SLH-DSA," but I kept mentally translating them to what I think are the 'standard' names from NIST (although I'm having trouble confirming this). From what I can tell, NIST's official standardization documents and most cryptographic libraries refer to CRYSTALS-Kyber (the 'module-lattice' KEM), CRYSTALS-Dilithium (the 'module-lattice' digital signature), SPHINCS+ (the stateless hash-based signature), and possibly FALCON (another lattice-based signature). So I was mentally substituting 'ML-KEM' with 'Kyber,' and 'ML-DSA,' with 'Dilithium', and I was presuming that SLH-DSA was SPHINCS. I fully understand why you would want to use the short acronyms. Maybe a footnote, 'These are references to NIST’s CRYSTALS-Kyber and CRYSTALS-Dilithium, plus SPHINCS-like.' to help future readers who do not recall the older(?) naming might help.

  • For large KEM parameters would we need to split or fragment handshakes due to payload size? It seems the largest parameter sets in the table (e.g., ML-KEM-1024) are already in the ballpark of 1–1.5 KB for the pubkey or ciphertext.

  • I was wondering how older Tor relays/clients would handle these new handshake message types, maybe its out of scope for an exploration like this, but some kind of version negotiation approach, including a fall-back might be necessary for deployment transitions.

  • If the extra data in ntor v3 is not forward-secure would that mean that in transitional handshakes, an attacker with a future CRQC can potentially decrypt those fields? <aybe that is acceptable for transitions, unless other data that should have forward secrecy is included in extension data.

  • Really interesting to see the numbers in your tables! I was thinking about large relays that build thousands/tens of thousands of circuits/second and if adding 40–60 microseconds per handshake might be significant. Some of the approaches (PQ-KEM-DSA) are comparatively quite large which seems out of scope for typical relays.

  • You mention that next‐generation "will require relays to have PQ identity keys", and that is out of scope (which makes sense) - I was just wondering if this requirement is because a CRQC could forge the relay identity as the circuit handshake alone can't provide that property, and that would be required to resolve MiTMs? That wasn't obvious to me, but probably would be to other readers who are more knowledgeable in this space.

  • In implementation, should we be considering "KEM agility" so there is a generalized KEM-based approaach that allows for future PQ KEM standardization?

Merge request reports