Re: New Work Item Proposal: Revocation List 2020

BBS+ actually originated in 2002 right as Elliptic Curve Cryptography (ECC)
was starting to become more formalized. It was just CL signatures which
were RSA based then immediately adapted to ECC. Dan Boneh and many others
including Jan Camenisch have either been involved in improving upon it or
reviewing it over the years. The BBS+ is the same cryptography that's used
in TPMs in the Direct Anonymous Attestation protocol. Intel expanded it to
include revocation with EPID. The cryptography is based on Diffie-Hellman
and EDDSA. Nothing new that hasn't been around for decades. From my
perspective, no weaknesses or vulnerabilities have been found in it for
almost 20 years. The security proofs have been greatly increased as more
use cases have been found.

"New and unproven" is the wrong way to describe it. I know you probably
didn't mean it badly, but unproven cryptography means one of a few things:

1- Its new math
2- Applying existing math in a new context
3- No formal security proofs have been made or reviewed.

So to clarify, when you say unproven, I believe you meant to say NIST
hasn't given it the rubber stamp.  Otherwise, it's like saying JSON-LD is
unproven. We know that's not the case. There's lots of cryptography that is
widely used even in Govt, for example, that isn't NIST approved like
Ed25519 and Secp256k1. I know Govt is using the Ethereum blockchain.
OpenSSH has included Ed25519 for decades. I was using libsodium when I
worked in Govt and we know that's not NIST approved. There have been papers
written about the weaknesses in ECDSA and how the proofs for those are not
solid or broken yet we still use them every day. NIST isn't a gold
standard, it just makes the red tape process go easier. In fact, most of
the cryptography we used wasn't NIST approved. Look at the signal messenger
app. Nothing in that app is NIST approved but it's used heavily in Govt and
somewhat in Healthcare.
As we know, NIST is very slow to adopt and approve new things, but that
doesn't mean they aren't or can't be used in Govt, Healthcare, or academia,
it just means more red tape. RSA, for example, wasn't formalized by NIST
until the patent expired in 2000. Now, I have had many conversations with
NIST in person at conferences like Real World Crypto, ZKProof, and by email
about getting BBS+ and the BLS curves approved. They are very interested in
it. However, no one has shepherded it yet through the process which takes
lots of $$$$$ or lots of adoption.

Another point, Tobias and I want to submit an IETF standard for the BBS+
signatures, and if all of you start using it, then that will help increase
interest. I hope that helps to add to your assurance that we plan to push
this forward.

Another point to clear up. BBS+ doesn't directly handle revocation. You
would use a set membership proof with cryptographic accumulators and
Schnorr proof to show the revocation claim in the VC is the same one in the
accumulator and it's not revoked. I'm actively working on making this as
simple as the BBS+ nodejs wrapper that was demo'd at IIW. Cryptographic
accumulators can be RSA, ECC, or Merkle tree based.

I hope that helps clear up some things. I would ask this community to be
more careful about how they use the terms "unproven" or
"privacy-preserving" and try to be a little specific like the math is
unproven or not NIST approved or the privacy is enhanced by the issuer not
seeing who the query is about in revocation. It can be misleading for those
who are not cryptographically informed.



On Sat, May 2, 2020 at 2:51 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 5/2/20 11:53 AM, Mike Lodder wrote:
> > To answer your question Orie, we absolutely can do Jon revocation
> > with BBS+ in ZKP fashion.
>
> Yes, accumulator-based mechanisms are neat and have a high potential to
> be useful. That's where we started too.
>
> BBS+ originated around 2006, formalized in 2008 (if memory serves),
> seems to have survived academic peer review... and has yet to make it
> through any IETF Crypto Forum Research Group gauntlet or federal
> information security standard (that I know of).
>
> For example, FIPS 186-5 doesn't mention it (nor do many of the other
> NIST publications).
>
> My point being that BBS+ Signatures are crypto that has yet to go
> through any of those processes, which can take 5-10 years from the
> moment you decide to take the task on (which costs millions of dollars).
>
> That's not to say that it shouldn't be attempted. As I mentioned in the
> previous thread, Digital Bazaar is very supportive of getting this BBS+
> Signature stuff moving. Getting it deployed into a production
> government, healthcare, or high security system is a whole other matter.
>
> I want folks to keep that in mind when comparing RevocationList2020
> (which can be deployed into production very soon now -- because it uses
> known and approved crypto and processes) and this
> BBSRevocationAccumulator202X proposal (which may take up to a decade,
> because it uses relatively new and "unproven" crypto).
>
> That said, we started standardizing JSON-LD over a decade ago for this
> very reason, this stuff takes time. So, it looks like we want to do
> this, so let's do this... but be aware of the time lines and that we
> have companies that need to ship product today.
>
> The conversation jumped at some point to where we're not making an
> apples to apples comparison. One of the apples you can eat today, the
> other one you'll have to wait 5+ years for.
>
> It's possible I missed an IETF RFC or NIST (or equivalent) publication
> that makes BBS+ Signatures something we can use immediately... and I
> hope I did, because that'd be great.
>
> What's the status and timeline of BBS+ Signatures on the IETF CFRG
> standards track or adoption by NIST?
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>
>

-- 
Mike Lodder
Security Maven