Hello,
There's been talk of moving to a wide block construct for cell crypto (#5460), and for adding PQ Forward Secrecy to traffic (#17272). To facilitate this, there needs to be a method for negotiating which primitives a given relay supports.
To that end, here's the begining of a proposal (tentatively #260) that adds a `CIPHERSUITES` cell to the version negotiation process which allows relays to advertise the link cryptography primitives that they are willing to accept.
TODOs/TBD:
* Should the new cell be variable length? Our development cycle and how often we switch handshakes/link crypto tells me "No", the existing "VERSIONS" cell format tells me "Yes".
* We need to revise prop. 249 to add a cell crypto method specifier to CREATE2V/EXTEND.
* Proposal 249 does not cover changing RELAY_EARLY behavior, which will potentially cause problems (Eg: Ring-LWE + ntor will require between 5 to 9 fragments depending on the exact primitives).
* The actual hybrid construct is deliberately left unspecified.
* With runtime negotiation of primitives on a per-circuit basis, we introduce the possibility of downgrade attacks. We do calculate the SHA256 digest of VERSIONS/CERTS/AUTH_CHALLENGE cells (which will become VERSIONS/CIPHERSUITES/CERTS/AUTH_CHALLENGE), so we could do something like:
auth_input = verify | ID | B | Y | X | SLOG | PROTOID | "Server"
Where SLOG is the digest without too much difficulty...
The alternative to all of this would be something like including handshake methods/supported link crypto in the descriptors, but that seems silly.
Regards,