- From: Orie Steele <orie@transmute.industries>
- Date: Sat, 29 Jul 2023 10:59:50 -0700
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Christopher Allen <ChristopherA@lifewithalacrity.com>, W3C Verifiable Credentials Working Group <public-vc-wg@w3.org>
- Message-ID: <CAN8C-_+PDV66yTY8Oykt7+iOPWGKy_RRKVmqgf4XeAGvJ5JD5w@mail.gmail.com>
https://www.nist.gov/blogs/manufacturing-innovation-blog/commonly-misused-terms-cybersecurity On Sat, Jul 29, 2023, 10:13 AM 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/ > >
Received on Saturday, 29 July 2023 18:00:08 UTC