Hey Neil : ) On Sat, Jan 13, 2024 at 8:33 AM Neil Madden <[email protected]> wrote:
> I’m still catching up with JOSE activity from the last year or so, so > apologies if this has already been discussed. > > If I’m reading the specs right, the smallest signature for ML-DSA is > almost 2.5KB on its own — about 10x the size of RSA-2048, which is already > pushing it, size-wise, for many applications. Compared to Ed25519 we’re > looking at an almost 40-fold increase in size. For SPHINCS+ the smallest > appears to be about 8KB — ie on its own it is double the maximum total size > for cookie storage in a web browser, and that’s before base64-encoding. > > Given that the quantum threat for signatures is less pressing than it is > for encryption (where you need to worry about collection happening now), > maybe it might be worth waiting to see if the ongoing NIST process throws > up some candidates that might be more suitable in a JOSE/COSE scenario? (I > only have limited experience with COSE, but surely if anything these > concerns are even more acute in that case?) > Here is a blog post summarizing the NIST candidates: https://blog.cloudflare.com/nist-post-quantum-surprise Falcon was the smallest, but seems to have not been chosen: "Unfortunately, NIST stated on several occasions that it would choose only two signature schemes, but not both Falcon and Dilithium" This is the reason we (cose wg draft authors) have not revised the falcon draft which was adopted by the cose wg. I agree with your comments, but given the trends we see in LAMPS / TLS, I feel it's important that when post quantum signatures roll out elsewhere, JOSE and COSE have support for them to the same degree that other protocols do. In case you are more interested in post quantum alignment, I highly recommend: https://datatracker.ietf.org/wg/pquip/about/ In particular, since we have just discussed signatures, keys and params, I was planning to follow the advice we got regarding limiting registrations for SLH-DSA in JOSE and COSE: - https://mailarchive.ietf.org/arch/msg/pqc/bi3fNCDk4upbxnxeVNLUp-5EgEE/ We could even limit further from 12 to 8 to 6 perhaps (3 levels, and 2 hash functions). Regards, OS > > — Neil > > On 12 Jan 2024, at 22:03, Orie Steele <[email protected]> wrote: > > > Hello Post Quantum Enthusiasts, > > We apologize for allowing the drafts to expire, that has now been > corrected. > > We've published new versions and done a tooling migration to the COSE WG > GitHub repository: > > - https://github.com/cose-wg/draft-ietf-cose-dilithium > - https://github.com/cose-wg/draft-ietf-cose-sphincs-plus > > Here is a quick summary of what changed, but of course you can see the > full diff in the datatracker. > > 1. We adjusted the names to reflect FIPS.204 (IPD) and FIPS.205 (IPD) > 2. We removed extraneous text on the details of the algorithms, which is > better covered in the references noted above. > 3. We provided skeletons for examples > > We are seeking implementations of ML-DSA and SLH-DSA in order to update > the examples sections, with closer to real world data. > > We have opted not to migrate Falcon, the parameter sets for sphincs will > probably keep us busy for a while. > > I'd like to take this opportunity to complain a bit about this part of the > FIPS 205 IPD: > > " This standard approves 12 parameter sets for use with SLH-DSA. " > > I feel this is a mistake, and wonder if there is any opportunity to reduce > this to something less than 4x the number defined by ML-DSA. > > Even if NIST preserves all 12, we don't have to register all 12 in > draft-ietf-cose-sphincs-plus. > > ... I really don't want to have to generate 12 key pairs and signature > examples, especially because a single key pair with the required line > breaks is likely to be longer than the entire draft. > > Of course, we will do whatever the working group thinks is correct here... > what should we do? > > Regards, > > OS > > -- > > > ORIE STEELE > Chief Technology Officer > www.transmute.industries > > <https://transmute.industries> > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
