Security audit on this approach

[jonnycrunch]

Just curious who will be auditing this approach. Looking at the crate on BBS+ and Ursa, this appears to be an algorithmic association of the blinded attributes to the pair-wise curve, which seems like a layer on top of the BBS+ cryptography. If this becomes a work item, how will the approach be audited for vulnerabilities?

[tplooker]

@mikelodder7 are you able to respond to this query?

[mikelodder7]

Auditing in what way?
The cryptography or the higher layer?

[mikelodder7]

The cryptography has been audited by the hyperledger maintainers which include cryptographers and crypto engineers. I don’t know who will audit the Json LD layer

[tplooker]

@jonnycrunch are you able to stipulate what additional layer you are referring to? If it is about the BLS to BBS+ public key conversion where we derive the generators for the signed messages from the BLS public key, then we have already had this approach reviewed by multiple cryptographers including the team responsible for the latest publications around BBS+ signatures

[jonnycrunch]

BBS+ by itself seem perfectly fine to be audited under ursa, I'm concerned about the selecting points on the pair-friendly curve representing values derived from the JSON-LD layer. Are those truly random or can a pattern emerge such that I can infer the values based on distancing and patterns like in Ulam's spiral. So..... JSON-LD layer.

[tplooker]

@jonnycrunch thanks for clarifying, there is no point selection occurring at the JSON-LD layer, take for instance the blsSign() interface this takes in a key pair for the issuer and an array of messages (N-Quads when the input is a linked data proof). If there was say 5 messages then 5 generator points are derived from the issuers public key + an incrementing counter in a deterministic manner (on purpose) as this information is intended to be public. This approach has been audited by multiple cryptographers including the original author of BBS+ @mikelodder7 perhaps you can clarify this further.

[tplooker]

Each message is then committed to its respective generator point when creating a BBS signature.

[tplooker]

@jonnycrunch this is the definition in our current draft of the scheme https://mattrglobal.github.io/bbs-signatures-spec/#name-dpktopk

[wyc]

Hey, could be useful to reach some further clarification here.

1. @tplooker By "original author" of BBS+, do you mean the implementor of the bbs crate? It seems that the the authors of this paper would have a claim to origin authorship of the term. Was it them?
2. @jonnycrunch Are you referring to the somewhat arbitrary selection of the pairing-friendly curve BLS12-381, which originated from the ZCash project?

[tplooker]

@wyc good idea, by authors I mean those that are responsible for one of the most recent academic revisions of BBS+ signatures, see here https://www.researchgate.net/publication/306347781_Anonymous_Attestation_Using_the_Strong_Diffie_Hellman_Assumption_Revisited section 4.3. @mikelodder7 can provide more detail on this.

[mikelodder7]

The original authors of the BBS+ signature are Boneh, Boyen, and Shachum and has been improved many times but the cryptographers that @tplooker is referring are Jan Camenisch, Manu Drijvers, and Greg Niven, formerly at IBM Zurich, now at Dfinity. Manu Drijvers is one of the maintainers on the Ursa project.

The BLS12-381 curve is quick becoming the pairing curve of choice. For example, it's going to be used for the Eth2.0 deployment. Its been endorsed by Dan Boneh and his group. Algorand is using it for their code. ZCash has deployed it on their main net. QED-IT is using on their blockchain. Dmitry Khovratovich has recommended it many times for use with Sovrin. Each of these groups or individuals are very well respected cryptographers. Thus I have no problem suggesting its use. Some rust implementations of the curve have been audited.

As for our approach for deriving points, Hash to curve is being used with the public key and incremented counters as inputs. BLS12-381 operates in a prime field, and thus any generator in a prime is considered safe for use. By hashing to points in this way, we are effectively choosing values that are "nothing up our sleeve" and we couldn't possibly know the discrete log.

Hope this helps.

[OR13]

Seems like this is actually a request for an audit of URDNA2015.... Which seems to finally getting some attention...

• URDNA2015 Support multiformats/multicodec#149
• Codec proposal: N-Quads (RDF format) multiformats/multicodec#180

We might want to make this dependency a little clearer, but from a security perspective... it relies on sha256...

https://json-ld.github.io/normalization/spec/#dfn-hash-algorithm

and its defined, and implemented in a number of languages...

Worth noting that if IPLD and JSON-LD both supported URDNA2015 they would both get the same level of "out of the box" support from this suite...

[jonnycrunch]

@mikelodder7 @tplooker I'm not worried about the selection of the BLS12-381 nor the hash to curve, I'm wondering about the conversion of the JSON-LD into a block of messages and whether that leaks data. At first, I thought this was a numerical off-set from the incremented counters. But, looking at the spec this seems like a BBS+ signature over a group of Pedersen Commitments derived from the LD-signature which is the array statement from the n-quads and the counter is the position in the array. To be clear, I am NOT a cryptographer but I'm less worried about something up your sleeve as I am that we have a good understanding on the governance of adapting new approaches, or in this case combining them and not fully understanding them. I really, really like this approach. I just want a reason to like it even more.

[mikelodder7]

Right now, messages are Blake2b hashed which has stronger properties than sha256. In addition, a random nonce is added to signatures of high entropy. With that knowledge, I’m failing to see any leaks In Patterns or anywhere else

[OR13]

@jonnycrunch are you volunteering to do an audit? I don't know how to make this issue actionable.

[OR13]

This issue is stale, the base crypto is going through CFRG, and we will be documenting the relevant privacy and security issues associated with JSON-LD.