Open Geal opened 8 years ago
I've made a number of changes to the API which affect this PR:
Scalar
has been renamed to Fr
.G1
, G2
and Fr
now implement serialization with rustc-serialize
. Points are serialized uncompressed in the format described by IEEE 1363.G1
, G2
, Fr
and Gt
are now Copy
and operator overloading over those objects does not currently use references.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.Gt
elements does not overload ^
anymore, instead you must use the pow
method.
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 theDebug
implementation forg_id
to 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).