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, -- Yawning Angel