pqshield / nist-sigs-zoo Goto Github PK

There is a lot of code repeated between the plain and widescreen versions...

Would it make sense to add a total latency column that, for a given Mbit/s and GHz, computes the total time required for:

1. compute signature
2. send (public key +) signature over the network
3. verify signature

?

Kind regards,
ambiso

I initially intended to allow scrolling and zooming on the scatter plot, but I couldn't get the d3.js zoomable plot examples working. I'm currently using Observable's Plot library, but that one does not support zooming yet (observablehq/plot#1590).

The page currently lists EdDSA (specifically, Ed25519) for comparison purposes, with 32-byte public keys and 32-byte signatures, but Ed25519 signatures really are 64 bytes in length, not 32 (hence 32+64 = 96 for sig+pk).

(EC-based Schnorr signatures with 128-bit security can be achieved with pk=32 and sig=48, if we want to further nitpick, but Ed25519 was defined and specified with the less optimal 64-byte signature size, so that it may support batch verification, which decreases the per-signature verification cost, in situation where you have hundreds of signatures to check and can batch them.)

A feature that lets us filter by algorithms that are broken would be really fun.

Dear All,

I hope this message finds you well. I am pleased to announce that the latest optimized code for the SNOVA post-quantum cryptography digital signature scheme has been updated on GitHub. This update brings some significant improvements and optimizations, which we believe will enhance the security and performance of our signature scheme.

You can find the latest code at the following link: https://github.com/PQCLAB-SNOVA/SNOVA

Here are the latest benchmarks for efficiency:

            name   generate_keys_ssk   generate_keys_esk   sign_digest_ssk   sign_digest_esk   verify_signture
SNOVA(37, 17, 2)             801,339             828,048           690,663           338,723           146,738
 SNOVA(25, 8, 3)             433,186             442,031           713,438           370,046           218,801
 SNOVA(24, 5, 4)             202,843             212,256           444,236           306,736           163,805
SNOVA(56, 25, 2)           4,207,799           4,302,330         3,332,244           964,716           507,009
SNOVA(49, 11, 3)           2,758,759           2,808,062         3,702,911         1,365,463         1,004,519
 SNOVA(37, 8, 4)             891,056             933,377         1,795,054         1,188,690           544,395
SNOVA(75, 33, 2)          11,844,511          12,109,075         8,871,223         2,304,920         1,165,161
SNOVA(66, 15, 3)           8,635,966           8,779,555        10,685,501         3,546,746         2,460,059
SNOVA(60, 10, 4)           3,877,397           4,013,756         6,206,765         3,110,898         1,504,945

Our team remains committed to continuously improving and optimizing our digital signature scheme to provide better security in the post-quantum era. If you have any questions or suggestions, please feel free to contact us anytime.

Thank you once again for your attention and support to our work!

Best Regards,
SNOVA TEAM

Regarding the markers for the "Public key size/signature size" graph, instead of differentiating the schemes by "pre-quantum / standardized / broken candidate / not broken candidate", one alternative solution would be to have one shape of marker per family of post-quantum signatures. Since most people at this point want to know "is scheme X more efficient than scheme Y?", perhaps this could work better. You could then use the colors to differentiate between standardized / broken / not broken / pre-quantum

The anchors currently jump to not exactly the right spot (the <h3> jumps out of view), and when the contents of tables changes due to selecting filters, you also lose your place on the page. Not sure how to fix this, though.

It looks like AIMer is currently being left of the comparison chart. The easiest way to see this is to disable all other schemes. The comparison is then empty instead of including the AIMer schemes. My best guess for problem is that the scheme is called AIMer in schemes.csv, but it's called AIMER in parametersets.csv.

Thanks for making this cool tool!

Our group used some of your team's data last year to make a website tool for internal use, if you are interested we can consider collaborating on maintenance.

https://pqclab.org/nist/SigParmsView

It would be informative to have the category column in the second (Parameters) table.

For the now renamed NIST-selected schemes (ML-DSA/Dilithium, ML-KEM/Kyber, SLH-DSA/SPHINCS+) the markers in the graph are currently incorrect. They show as a black + instead of a purple star.