Re: [PROPOSED WORK ITEM] W3C-VC-QP - Verifiable Credential Quantum Proof #247

re KEMs - to clarify, I was noting that to note that that is where
attention currently is (and related problems), so getting serious eyes in
for review would be hard at the moment for a composite / hybrid signature
scheme.

Size and signing time is definitely a concern, and I am interested in the
results you see, especially with larger credentials (say supply chain
oriented, or genetic testing).

Mike Prorock
Founder
https://mesur.io/



On Wed, Mar 27, 2024 at 1:51 PM Andrea D'Intino <andrea@dyne.org> wrote:

> Mike:
>
> This statement:
> > Currently no QP signature offers zero-knowledge proof or unlinkability
> features, so part of the task of the WG might involve combining QP
> signatures with more privacy-enhancing signining algorithms (such as BBS or
> ECDSA-SD).
>
> Is somewhat concerning - combinations / hybrid schemes are non-trivial and
> I would personally recommend following CFRG, and also SAAG / PQUIP (and
> also JOSE / COSE) for challenges that are arising in that area and avoid
> defining any hybrids in a group that does not have the expertise to review
> the side effects of that combination.
>
> No comment from me on this (maybe Manu knows more?)
>
> Also, bear in mind that from a review standpoint, more focus is being put
> on review of KEMs and providing protection around store now, decrypt later
> attacks in relation to hybrids than on the signature side (since you can
> sign multiple times with different algorithms).
>
> About KEMs: with Zenroom we also support Kyber512 (also from PQClean) and
> NTRUP761 (the one implemented in openssh). We discussed the topic (in a
> private thread) only to come to the conclusion that we can't see an
> immediate application of KEMs in the VC space. If you have ideas on how use
> KEMs in VCs, I'm all ears!
>
>
> If you mean multiple signatures - e.g. one BBS+ for selective disclosure,
> etc, and one for post quantum support then i think that is ok to note.
>
> this is in fact a topic for discussion. Dilihium2 sigs are very fate (some
> 3KB per sig) so you can't fit many inside a VC. I was thinking it could
> make sense to wrap the whole VC (including BBS/ECDSA sigs) into a
> Dilithium2 sig... but again we've just opened the topic so it's all green
> field here.
>
> Cheers,
>
> | Andrea D'Intino | +45  21 62 79 18 | Project Manager
> | https://Dyne.org think &do tank  | software to empower communities
> | ⚷ crypto κρυπτο крипто गुप्त् 加密הצפנה المشفره
>
>
>
>
>
> On Wed, Mar 27, 2024 at 12:41 PM Andrea D'Intino <andrea@dyne.org> wrote:
>
>> Hi everyone,
>>
>> we are seeking feedback on a new CCG Work Item proposal regarding the
>> quantum-prooof signatures for Verifiable Credentials across devices and
>> websites. Please leave your support or concerns here:
>>
>> https://github.com/w3c-ccg/community/issues/247
>>
>> # New Work Item Proposal
>>
>> The proposal is about defining a new specification to define the
>> associated Data Integrity cryptosuite that can be used to construct digital
>> signatures and proofs using quantum-proof (QP) signing algorithms, starting
>> with [Dilithium](https://pq-crystals.org/dilithium/index.shtml).
>>
>> The notable feature of this family of signature schemes is the
>> quantum-resistance, according to the [NIST competition results](
>> https://csrc.nist.gov/Projects/post-quantum-cryptography/selected-algorithms-2022).
>>
>>
>> Currently no QP signature offers zero-knowledge proof or unlinkability
>> features, so part of the task of the WG might involve combining QP
>> signatures with more privacy-enhancing signining algorithms (such as BBS or
>> ECDSA-SD).
>>
>> We aim to initially focus on Dilithium2 (as apparently there is the only
>> signature scheme readily available) and progressively extend the specs to
>> accomodate more signature schemes.
>>
>>
>> ## Include Link to Abstract or Draft
>>
>> https://msporny.github.io/di-quantum-safe/#abstract
>>
>> * Dilithium signature implementations (C language): [pq-crystals](
>> https://github.com/pq-crystals/dilithium.git), [pq-clean](
>> https://github.com/PQClean/PQClean)
>> * Zenroom implementation of the [Dilithium signatures](
>> https://dev.zenroom.org/#/pages/zencode-scenarios-qp?id=dilithium)
>> * Specification of _did:dyne_ W3C-DID method supporting [Dilithium
>> pubkey](https://dyne.org/W3C-DID/#dilithium2verificationkey)
>> * Curl POST to test W3C-VC-QP signing [API](https://pastebin.com/h1vWd8eP
>> )
>> * Preliminary W3C-VC-QP proof structure:
>>
>> ```
>> "proof": {
>>       "created":
>> "1710861739438",                                           //epoch
>>       "cryptosuite":
>> "experimental-dilithium2-2024",                         //proposed
>> cryptosuite name
>>       "id":
>> "H+4899Oefjch3wmRTfczR08jSNdJ+Jr67kadQO7/7uc=",                 //hash of
>> the W3C-VC
>>       "proofPurpose": "assertionMethod",
>>       "proofValue": "...Dilithium2signature...",
>>       "type": "DataIntegrityProof",
>>       "verificationMethod": "did:dyne:..#dilithium_public_key"
>> // Dilithium2 pubkey of the issuer
>>     }
>>
>> ```
>>
>> ## List Owners
>>
>> > Identify 1 lead (person responsible for advancing the work item) and at
>> least 1 other owner. Ideally, include their github usernames
>>
>> @andrea-dintino @msporny, @jaromil, @wip-abramson
>>
>> ## Work Item Questions
>>
>> 1. Explain what you are trying to do using no jargon or acronyms.
>>
>> Draft a standard for a W3C-VC proof format, that supports Dilithium (and
>> potentially further QP algorithms) signatures
>>
>> 2. How is it done today, and what are the limits of the current practice?
>>
>> First experiment of Dilithium signed W3C-VC formats.
>>
>> 4. What is new in your approach and why do you think it will be
>> successful?
>>
>> Building on top of extending w3C-VC cryptosuite standards, aiming to be
>> as little invasive and disruptive as possible.
>>
>> 5. How are you involving participants from multiple skill sets and global
>> locations in this work item? (Skill sets: technical, design, product,
>> marketing, anthropological, and UX. Global locations: the Americas, APAC,
>> Europe, Middle East.)
>>
>> Initial participant group includes cryptographers and developers from
>> Dyne.org (Netherlands), DigitalBazaar (US) and Will Abramson (US)
>>
>> 6. What actions are you taking to make this work item accessible to a
>> non-technical audience?
>>
>> While the topic is deeply technical, the specification should attempt to
>> provide a gentle introduction to the topic via a non-technical introduction
>> as well as non-technical use cases with imagery that is accessible to the
>> general population.
>>
>>
>> Cheers,
>>
>> | Andrea D'Intino | +45  21 62 79 18 | Project Manager
>> | https://Dyne.org think &do tank  | software to empower communities
>> | ⚷ crypto κρυπτο крипто गुप्त् 加密הצפנה المشفره
>>
>>