- From: Oliver Terbu <oliver.terbu@spruceid.com>
- Date: Sun, 13 Aug 2023 07:06:04 +0200
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Christopher Allen <ChristopherA@lifewithalacrity.com>, W3C Verifiable Credentials Working Group <public-vc-wg@w3.org>
- Message-ID: <CAP7TzjBjr_Q_1jeSsaXf+ph0REqRHGO9EPo6eB2CBRhtyDbQdQ@mail.gmail.com>
I guess if one can throw away the esk then HSM could be viable. On Sun 13. Aug 2023 at 06:36, Oliver Terbu <oliver.terbu@spruceid.com> wrote: > 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> > -- *Oliver Terbu* Director Identity Standards, Spruce ID <https://spruceid.com/credible>
Received on Sunday, 13 August 2023 05:06:47 UTC