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.

[Brian Warner]

Note that the extensible-tubid structure was established in #60, and first released in 0.2.6.

[Brian Warner]

dup of #219