Dilithium (quantum proof) VCs

Dear all,

I'm posting this after some discussion with Manu.

We have implemented Dilithium signatures (from the NIST PQC 
https://csrc.nist.gov/Projects/post-quantum-cryptography/selected-algorithms-2022) 
in our Zenroom VM (https://dev.zenroom.org/#/pages/zencode-scenarios-qp) 
a while ago, along with it we have implemented:

- a DID method that includes Dilithium pk, specs: 
https://dyne.org/W3C-DID/#dilithium2verificationkey and DID: 
https://did.dyne.org/dids/did:dyne:sandbox.genericissuer:GPgX3sS1nNp7fgLWvvTSw4jUaEDLuBTNq5eJhvkVD9ER 


- a quick&rough API that produces a Dilithium signed W3C-VC (it still 
needs some work, this is a PoC!)


You can check the API here:

/curl -X 'POST' \
'https://apiroom.net/api/genericissuer/issuer-w3c-vc-dilithium.chain' \
   -H 'accept: application/json' \
   -H 'Content-Type: application/json' \
   -d '{
   "data": {
  "claims": {
   "@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
   ],
   "id": "http://example.edu/credentials/1872",
   "type": [
    "VerifiableCredential",
    "AlumniCredential"
   ],
   "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
     "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
     "name": [
      {
       "value": "Example University",
       "lang": "en"
      },
      {
       "value": "Exemple d'\''Université",
       "lang": "fr"
      }
     ]
    }
   }
  }
}
}'/


Basically:

- you pass the API a *"data" : {  "claims": {...} } * where "claims" is 
any json that you want to get signed (I didn't do any validation on the 
input)

- the Dilithium signature of "claims" is created and inserted in the 
"proof" as "proofValue" as url64 (our default is base64, I changed it 
based on Manu's input about Multibase).

- most of the proof is hard-coded, apart from the "created" (the epoch 
of the server), the "id" (the sha256 of the Dilithium signature).

- The code producing the signature and verification can also run in the 
browser/mobile

- Our implementation of the Dilithium signatures is tested against the 
vectors publish by NIST (we're using Dilithium2 see: 
https://github.com/dyne/Zenroom/blob/master/test/vectors/dilithium2.rsp )

The resulting Dilithium signature is 3227 bytes. The other two NIST PQC 
signatures are SPHINCS+ (signature is 30KB) and Falcon (signatures is 
666-1280 bytes, speed/RAM performances as similar to ECDSA).

If anyone is interested, we could work further on the the Dilihium 
W3C-VC to make it fully compliant, we may as well implement Falcon 
signatures.


Looking forward for your comments :-)


| Andrea D'Intino | +45  21 62 79 18 | Project Manager
|https://Dyne.org  think &do tank  | software to empower communities
| ⚷ crypto κρυπτο крипто गुप्त् 加密הצפנה المشفره

On 29/01/2024 23.24, John, Anil wrote:
>
> >We now have the first public technical demonstration of cryptographic 
> layering[1] (aka parallel signatures) on a Verifiable Credential that
>
> >uses government approved cryptographic algorithms (FIPS-140) for full 
> and selective disclosure of a VC, as well
>
> >as unlinkable signatures using BBS, to achieve advanced privacy 
> protections.
>
> >What this means is that a single Verifiable Credential can be issued 
> that meets all government requirements when it comes to cryptographic
>
> >algorithms as well as one that addresses privacy concerns highlighted 
> by civil society and existing government privacy regulations.
>
> This is excellent to finally see this working in practice! 
> Congratulations!
>
> I am particularly interested to note that this implementation can also 
> be used to demonstrate what is actually meant by unlinkable digital 
> signatures:
>
>   * Issue a ECDSA-SD protected credential and present to a Verifier
>     asking for ‘Country Only’ multiple times (and see that the
>     signature remains the same)
>   * Issue a BBS protected credential and present it to a Verifier
>     asking for ‘Country Only’ multiple times (and see that the
>     signatures do NOT remain the same)
>
> Manu – Three questions:
>
>  1. Does this approach allow for the support of quantum safe signature
>     schemes as another option down the line when those become more
>     specified?
>  2. Does this approach allow for the support of anoncred based
>     signatures in parallel with others?
>  3. It sounds like the wallet has a specific role here >> “I'll pick
>     the one that the Verifier will accept and that maximizes privacy
>     for the Holder: BBS”; which also implies that the wallet could
>     choose to be NOT select the most privacy preserving option <<
>     which then follows that this is an area that people who are making
>     choices between wallets need to be aware and be educated on what
>     the wallet could do behind the scenes. Is my understanding correct
>     here?
>
> Best Regards,
>
> Anil
>
> Anil John
>
> Technical Director, Silicon Valley Innovation Program
>
> Science and Technology Directorate
>
> US Department of Homeland Security
>
> Washington, DC, USA
>
> Schedule a meeting with me (30 minutes; non-DHS people only) 
> <https://outlook.office.com/bookwithme/user/6250c4b6cae94d549b6db87b72b0b6d5@hq.dhs.gov?anonymous&ep=plink>
>
> Time Zone: UTC-05:00 (US Eastern Time)
>
> Email Response Time – 24 Hours or more; I sometimes send emails 
> outside of business days/times because it works for me; please do not 
> feel any obligation to reply to them outside of your normal working 
> patterns.
>
> A picture containing graphical user interface Description 
> automatically generated 
> <https://www.dhs.gov/science-and-technology>/Users/holly.johnson/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_1972159395
>
> This document contains pre-decisional and/or deliberative process 
> information exempt from mandatory disclosure under the Freedom of 
> Information Act, 5 U.S.C. 552(b)(5). Do not release without prior 
> approval of the Department of Homeland Security.
>