id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
227	new crypto: curve25519	Brian Warner		"Given the frustrations of TLS (especially interacting with pyOpenSSL to override certificate validation), it might be better to bail on it and go with a Curve25519-based message-based wire protocol. The basic ideas:

* TubID would be the Curve25519 public key (or maybe Ed25519 verifying key)
* clients create ephemeral keypairs for each connection
* connection-scoped forward security: new server ephemeral keypair is created during negotiation
* maybe use Axolotl, Noise, or one of the SIGMA key-exchange protocols for setup
* each top-level Banana message gets its own box. Easier to do if we remove streaming.

Foolscap-0.6.5 (at least) accepts any tubid where the first 32 characters are all legal base32 (`a-z A-Z 2-7`), and rejects anything else (`BadFURLError`). These will be treated as an old-style cert hash: the connection will be accepted if `base32(SHA1(cert))` matches the first 32 characters of the claimed tubid. Note that `base32()` always emits lowercase, so uppercase tubids can never match. Ignoring things past the first 32 characters was added to leave room for future extensions, although naturally making extensions of a security-critical discriminator must be done very carefully.

A new kind of tubid should be easy to visually distinguish from the old ones, and guaranteed to never be mistaken for the old type. In particular it should trigger the `BadFURLError` when processed by an old implementation. Given the regexp in 0.6.5, this means one of:

* use one of (0,1,8,9) in the first 32 characters
* use a non-alphanumeric prefix, maybe ""v2-"" (where the hyphen is what matters)

Note that using a capital letter is not enough to trigger `BadFURLError`, but would be safe against accidental/intentional overlap.
"	defect	closed	major	undecided	negotiation	0.6.5	duplicate