Re: Demonstration of Support for NIST-Compliant Selective Disclosure for Data Integrity Cryptosuites in VCWG

Re ephemeral keys on ecdsa-sd. this means an issuer cannot use a boring old
HSM to protect the signatures, correct? It wouldn’t be viable imo. To many
keys (at least a new keypair for each VC) and also the ephemeral nature
doesn’t seem to fit if one uses an HSM.

On Sat 29. Jul 2023 at 17:13, Manu Sporny <msporny@digitalbazaar.com> wrote:

> Hey Christopher and Sam, apologies for the delay in response, last
> week was hectic.
>
> On Fri, Jul 21, 2023 at 10:31 PM Christopher Allen
> <ChristopherA@lifewithalacrity.com> wrote:
> > Is this fundamentally selective disclosure using hash-based ‘elision’?
>
> You'd have to define "hash-based elision" for me to give you a
> definitive answer, but I'll try anyway. :)
>
> From what I understand of Gordian Envelope and ACDC, no it's not
> hash-based elision. I say that with a huge caveat that my
> understanding of both is almost certainly not tracking the latest
> developments, and they differ in important ways. I believe ecdsa-sd is
> a different approach. The approach is outlined in this slide deck:
>
>
> https://docs.google.com/presentation/d/1d-04kIWhPuNscsAyUuRH3pduqrNerhigCWahKe6SNos/edit#slide=id.g2174b6c9183_0_1364
>
> There are detailed examples of how it works on slides 18-25. Perhaps
> you could take a look and let me know if you agree that it's not an
> elision-based approach?
>
> Sam smith wrote:
> > The ACDC spec for some time has included  similar mechanisms 1) nested
> partial disclosure and/or 2) arrays of blinded hashes for selective
> disclosure.
>
> To be clear, ecdsa-sd does neither due to information leakage
> concerns. We use a flat list of statements that only reveals structure
> when a selective disclosure is made and not before, and only then with
> the information revealed (which is not true for other mechanisms like
> SD-JWT). So, with ecdsa-sd, you don't accidentally discover the
> structure of information that is not disclosed. From what I remember,
> ACDC can do this for some structures (but not for sets/lists). I don't
> know where Gordian is on this particular item.
>
> We don't encode arrays of blinded hashes because that can leak
> information (which is further elaborated upon, below).
>
> > So apparently, there is some convergence to using collections of blinded
> hashes as standard cypto enabled selective disclosure mechanisms.
>
> I wouldn't say that, there are drawbacks to using collections of
> blinded hashes, which I touch upon above and elaborate upon below.
>
> > I wasn’t aware of anything possible other than that which is NIST
> compliant as BBS+ & CL sigs both requires pairing cryptography.
>
> Yes, the ecdsa-sd approach does not require pairing-based
> cryptography... it uses boring old NIST-compliant cryptography. The
> steps are roughly:
>
> 1. Convert the input document into canonical statements (RDF
> canonicalized quads).
> 2. Split the quads into one "mandatory disclosure set" and multiple
> "selective disclosure statements".
> 3. Generate an ephemeral NIST-compliant keypair.
> 4. Sign the "mandatory disclosure set" and the public component of the
> ephemeral key using your public DID (or whatever public NIST key you
> want to use).
> 5. Individually sign each "selective disclosure statement" with the
> ephemeral private key, and then throw the private key away.
> 6. Bundle all the signatures together; that's your initial proof.
> Attach the signature to the document using the generalized Data
> Integrity "add proof" algorithm, and hand it over to the holder.
>
> The holder can then take that document, with the attached initial
> ecdsa-sd proof, and generate derived proofs (selectively disclosed
> VCs) to give to verifiers.
>
> > The link to the PR wasn’t that helpful, no details or docs in it.
>
> The PR contains links to the slide deck, the specification text, and
> one complete implementation, which has a lot of documentation related
> to the usage of the library. I'll re-produce those links below:
>
> Presentation on Selective Disclosure for W3C Data Integrity
>
> https://docs.google.com/presentation/d/1d-04kIWhPuNscsAyUuRH3pduqrNerhigCWahKe6SNos/edit#
>
> ecdsa-sd specification text:
>
> https://pr-preview.s3.amazonaws.com/w3c/vc-di-ecdsa/pull/20.html#ecdsa-sd-2023
>
> ecdsa-sd-2023-cryptosuite library usage:
>
> https://github.com/digitalbazaar/ecdsa-sd-2023-cryptosuite/blob/main/README.md
>
> > Is this proposal a hash of an LD quad list (aka a “quin”) or some other
> technique?
>
> The "mandatory disclosure set" is a single hash and signature of a set
> of quads. Each "selective disclosure statement" is individually hashed
> and signed. There is also an HMAC that is used as a randomization
> function to prevent leaking information via bnode identifiers. This
> information leakage prevention mechanism is a feature that is missing
> from other selective disclosure techniques when dealing with arrays of
> data (such as the number of employees in a company, or children in a
> family, or items in a shipping manifest, or other types of information
> leakage that you don't want when doing a selective disclosure).
>
> > Does it use a single salt ( i.e. like mDL) or can individual items be
> salted or unsalted depending on correlation requirements?
>
> There is no single salt value, as described above. The signatures
> themselves are correlatable because we're not using pairing-based
> cryptography. That said, it's possible to have multiple  per-signature
> hashes and salts. We're looking for feedback on the current
> specification to see if we should add that functionality or not. It
> would provide some level of correlability protection as long as we can
> find the right NIST-approved primitives to do it. The challenge with
> this cryptography suite has been using only NIST-approved primitives,
> which limits the options we have wrt. anti-correlation primitives.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
> --
*Oliver Terbu*
Director Identity Standards, Spruce ID <https://spruceid.com/credible>