Testing Boneh Franklin IBE on BN curve

[Geal]

This PR implements the Boneh Franklin "BasicIdent" IBE scheme with BN curves. I'll update the PR with the FullIdent scheme once I write it.

From what I've read, the original scheme works on bilinear pairings, but with G1 x G2 -> Gt, it only requires that CDH holds in G1 and G2, and DDH holds in Gt, so it should work on BN curves (could anyone confirm this?).

This PR uses the two previous ones, the first to fix compilation, the second to reuse the sighash module. I'll rebase when those are merged.

What I currently need to move this forward, is a way to serialize a point in compressed form, to generate a hash from it. The way I do it for this test is very ugly: using format! and the Debug implementation for g_idto generate a string, and hashing it with sha256.

A way to serialize and deserialize arbitrary points from G1, G2 and Gt would be useful as well, to transport ciphertexts or signatures.

The hash derived from the shared g_id point is used to generate a Chacha20 key instead of XOR-ing it directly with the plaintext. I think it is ok, assuming that Chacha20 is a PRF, but I have not verified it yet. It keeps the malleability from the original scheme, but it would not be hard to derive more data, to do a Chacha20+Poly1305 authenticated encryption (or any other algorithm combination).

[zmanian]

I suggest we break out a point_to_symmetric_key function that does sha256(serialized point)

[ebfull]

I've made a number of changes to the API which affect this PR:

1. Scalar has been renamed to Fr.
2. G1, G2 and Fr now implement serialization with rustc-serialize. Points are serialized uncompressed in the format described by IEEE 1363.
3. G1, G2, Fr and Gt are now Copy and operator overloading over those objects does not currently use references.
4. Fr now has an interpret(&[u8; 64]) static method. It interprets the input as a 512-bit big-endian number, divides it by the modulus, and uses the remainder as the element in Fr, for a solid uniform distribution. You can interpret a message as an Fr by hashing it (with BLAKE2b, for example, which produces 512-bit digests) and calling Fr::interpret with the hash. I don't intend to add BLAKE2b to this library, but the blake2-rfc crate should give you what you want.
5. Exponentiation of Gt elements does not overload ^ anymore, instead you must use the pow method.