search

decentralized-identity / bbs-signature

The BBS Signature Scheme
https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html
Apache License 2.0
79 stars 26 forks source link

Crypto agility #8

Closed schanzen closed 2 years ago

schanzen commented 3 years ago

The current draft is partially agnostic to the cryptographic details and in other parts very specific. For example, the choice of curve is left open: https://github.com/schanzen/bbs-signature/blob/main/spec.md#choice-of-signature-primitive But, the curve is implicitly enforced in https://github.com/schanzen/bbs-signature/blob/main/spec.md#terminology along with other primitives such as the hash functions. This will make #7 a bit awkward to fix.

I guess the specification could be very specific to only define a concrete instantiation or abstract to allow crypto agility. The latter may require additional metadata in the objects.

Related to #5 as well. Maybe hashfunctions should be harmonized for the initial recommendation/instantiation?

tplooker commented 3 years ago

Thanks for raising, I agree along side the hashing algorithm as we discussed on the most recent call the underlying curve used should be left open. Could you elaborate on where in the terminology section this is currently not the case?

schanzen commented 3 years ago

Under https://github.com/schanzen/bbs-signature/blob/main/spec.md#terminology you are defining dst, hash_to_curve_g1, and hash_to_curve_g2 with a parameter which is tied to BLS12-381: BLS12381G1_XMD:BLAKE2B_SSWU_RO_BBS_SIGNATURES:1_0_0 and BLS12381G1_XMD:BLAKE2B_SSWU_RO, respectively.

The dst parameter should probably be different depending on the used hash and curve and so should the algo for the hash_to_curve.

schanzen commented 3 years ago

I guess the question is if the "BBS+ Signature Scheme" is supposed look like https://datatracker.ietf.org/doc/html/rfc6979 where you then have specific instantiations in the test vectors: https://datatracker.ietf.org/doc/html/rfc6979#appendix-A.2.5 Or if it should be more like https://www.rfc-editor.org/rfc/rfc8032 where the choice of primitives is taken away (on purpose). One could make the argument that the approach of EdDSA is more sensible as implementors will make less errors, but maybe the scheme itself should then also be qualified. Ex: "The BLS12-381-SHAKE-BBS+ signature scheme" or similar.

dlongley commented 3 years ago

One could make the argument that the approach of EdDSA is more sensible as implementors will make less errors...

+1 to this approach.

tplooker commented 2 years ago

Yeah +1 being overly cryptographically agile is a security and implementation risk, I would suggest the best middle ground is to position the draft with a single definition of DIGEST_ALGORITHM / HASH_ALGORITHM rather than having the concrete algorithm repeated throughout as it is currently.

dlongley commented 2 years ago

Yeah, it's one thing to make sure your core design is flexible and pluggable. It's another thing to surface that flexibility all the way up your stack to implementers/users that can make bad mistakes with the wrong choices. Eliminate choice at those top layers to help protect implementers/users.

schanzen commented 2 years ago

The other point I was trying to make is that the "name" of the draft is currently very generic "BBS Signature Scheme" while what is proposed is actually much more specific. It may be time to give the proposed scheme a dedicated (new) name? My reasoning is that it basically squats the concept of "BBS+ Signature Schemes" which may lead to confusion in the future especially of schemes based on other curves pop up.

tplooker commented 2 years ago

My reasoning is that it basically squats the concept of "BBS+ Signature Schemes" which may lead to confusion in the future especially of schemes based on other curves pop up

I think this is asking another cryptographic agility question here seperate from the selection of the digest algorithm, which is should the draft couple itself to a particular pairing based curve (e.g BLS 12-381). The decision to mandate a particular digest algorithm does not necessarily mean we have to do the same in regards to the curve. Leaving the draft open to new curves makes it more like ECDSA rather than EdDSA in this respect.

schanzen commented 2 years ago

My reasoning is that it basically squats the concept of "BBS+ Signature Schemes" which may lead to confusion in the future especially of schemes based on other curves pop up

I think this is asking another cryptographic agility question here seperate from the selection of the digest algorithm, which is should the draft couple itself to a particular pairing based curve (e.g BLS 12-381). The decision to mandate a particular digest algorithm does not necessarily mean we have to do the same in regards to the curve. Leaving the draft open to new curves makes it more like ECDSA rather than EdDSA in this respect.

The (albeit theoretical) issue I have with "BBS Signature Scheme" is that this specifier existed before this (more specific) draft. So if anybody ever writes down "We are using the BBS Signature Scheme" it is ambiguous if this refers to any implementation of the proposed scheme from a paper or this specific proposal. On the other hand is is 100% unambiguous if somebody writes ECDSA or EdDSA, respectively. There is only one way to do those, and they can be found in RFCs. The issue is that the draft is using a name which is, essentially, already "taken" and that may lead to issues unless this becomes the de-facto standard and "overtaking" the meaning of "BBS Signatures" which cannot be guaranteed.

To be more specific:

  1. "BBS Signature" is defined here: D. Boneh, X. Boyen, and H. Shacham. Short Group Signatures.
  2. "BBS+ Signature" is defined here: Man Ho Au, Willy Susilo, and Yi Mu. Constant-Size Dynamic k-TAA.

What is written in the draft/specification in this repos is "XYZ Signature Scheme" which is based on a BBS (1) or BBS+ (2) signature.

schanzen commented 2 years ago

Just adding here a point raised by @tplooker in today's meeting: The wip draft (#3) conceptually deviates from the one proposed in the papers with respect to the deterministic generation of message commitments. Which makes the draft even more a variation of BBS which uses/proposes the use of nonce values.

tplooker commented 2 years ago

During the delayed call today we discussed taking this draft in the direction of supporting several key cryptographic extension points, e.g "agile". And then defining profiles on top which promote interoperable implementations.

Some of the rational for this was noted through how elliptic curve cryptography was developed, essentially ECDSA when it was developed preceded formal standardisation of particular elliptic curves, hence the need to remain agnostic. Within the sub-field of pairing cryptography we find a similar situation where by multiple curves are showing promise and adoption however innovation and development continue to occur here. Therefore rather than the draft picking one winner, a set of security criteria could be defined that allows different pairing friendly curves to be used.

Going in this direction with the draft would mean the follow elements would be abstractly defined

tplooker commented 2 years ago

@schanzen the direction this draft has taken is to define ciphersuites, the exact format is still a W.I.P, but do you feel this is addressing this issue?

tplooker commented 2 years ago

Assuming this issue has now been addressed given an approach has been agreed by the working group as described above, please re-open if you do not feel it has been.