search

w3f / schnorrkel

Schnorr VRFs and signatures on the Ristretto group
BSD 3-Clause "New" or "Revised" License
309 stars 93 forks source link

Double check adaptor implicit certificates #4

Open burdges opened 5 years ago

burdges commented 5 years ago

We include an implicit certificate scheme similar to ECQV implicit certificates, as described in "Standards for efficient cryptography, SEC 4: Elliptic Curve Qu-Vanstone Implicit Certificate Scheme (ECQV)".

We also hash the issuer's public key when creating the challenge e, mostly because it sounds wise, but also since that helped with the MQV vs HMQV issues. Ristretto handles most point validation issues here, but anything like the identity, etc. needs checking.

I'll read through the security proof somewhat closer eventually. See:

Daniel R. L. Brown, Robert P. Gallant, Scott A. Vanstone. "Provably Secure Implicit Certificate Schemes". Financial Cryptography 2001. Lecture Notes in Computer Science. Springer Berlin Heidelberg. 2339 (1): 156–165. doi:10.1007/3-540-46088-8_15.

burdges commented 5 years ago

Also we need more tests if we're actually going to use these anywhere.

burdges commented 5 years ago

I wonder if ring implicit certificates make sense.. I could imagine these being useful in peer-to-peer networking, if either schnorrkel were also being used for a key exchange at the transport layer, or else if we standardized a mapping from Ristretto to Ed25519. #38

burdges commented 4 years ago

We killed ECQV in favor of an adaptor signature based implicit certificate scheme that can be abstracted better. We should still explore the MQV vs HMQV issues and do security arguments for this adaptor signature based implicit certificate scheme.

burdges commented 3 years ago

It's possible ECQV implicit certificates chain better than adaptor ones, not sure yet.