Use NaCl/Curve25519 for Tub authentication

[str4d]

The current TubID system uses the .startTLS() method of the TCP for authenticating Tubs and securing connections. But with #203 on the horizon, foolscap will support endpoints that do not have (or need) .startTLS(), because they have their own encryption (I2P/Tor). Attempting to use the existing SSL TubIDs over these transports will require considerable heroics. Some FURLs may also contain multiple endpoints, and these should authenticate with the same TubID / public key regardless of transport.

At RWC2014 warner suggested moving to NaCl crypto instead of SSL. This has the advantage of making Tub authentication independent of the transport used.

Legacy SSL TubIDs would still be supported, but only tcp location hints would be considered. The following table shows how location hints would be supported.

	Location Hint
TubID	tcp	i2p	tor
SSL	yes	no (unless heroics)
NaCl	uniform auth, aware of which transport is being used

[Brian Warner]

Merging the redundant #227 into this one. The description was:

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.

The extensible-tubid structure was established in #60, and first released in 0.2.6.