ED25519_NONDETERMINISTIC #1495
-
|
In the voice of minisign's README.md:
Is this the correct way to build it non-deterministically? (for testing I want both deterministic and non
Is this sufficient indication of success: Size is a poor indicator, I didn't want to risk installing the custom build before trying against a package maintainer version: The output of the signatures looks identical in length. Which is probably expected since the randomness is consumed and an Ed25519 sig is always same size in output? I cannot see a string with readelf. Perhaps an info in How can I check if my build is non-deterministic? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
|
This is usually not a practical concern, unless you expect an adversary to shoot lasers on a microcontroller while signing, in the right location, at the right time, and repeat the process a bazillion times while doing measurements. But if this is the case, the easiest way is to build minisign using Zig, without libsodium with |
Beta Was this translation helpful? Give feedback.
-
|
Thank you a lot for your work and advice! Zig looks like a fun new language and I will try this. In 5 years people might sign with Falcon already, smallest sigs of all pq-lattice based ones whilst supporting level 5 (FIPS 206). https://github.com/algorandfoundation/falcon-signatures But right now minisign is the best tested and most secure tool! I am glad Ed25519 is considered safe up until ~2035. |
Beta Was this translation helpful? Give feedback.
-
|
Falcon (FN-DSA) and ML-DSA public keys are too large for this use case, and they would require a hybrid signature scheme for which no standard construction has been defined yet. The landscape of post-quantum signature schemes is still evolving, and NIST is currently selecting additional candidates. With its small public keys and reasonable performance, CROSS would be nice. In the meantime, I'm considering adding optional support for SLH-DSA signatures to Minisign (at least in the Zig implementation, since I already have an SLH-DSA implementation ready). These signatures are slow but already standardized; their public keys are small, and they are among the most reassuring from a security perspective. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for adding more input! You probably saw that age added PQ support for encryption with mlkem768 and Cv25519. The keys are exactly as you say: "gigantic/too large". Despite this being an encryption and not signature scheme of course.
I don't understand code based well. https://www.wolfssl.com/dilithium-vs-falcon/ Maybe an Ed25519 + Falcon-1 hybrid could be favoured simply because it is tiny compared to Dilithium, once draft and final standard are released by NIST. Since this is all a lot of work, I refrained from asking you for a timeline. 5-10 years safety on classic Ed25519 is enough time, but I'm very excited that you take interest and consider any scheme that may suit you. Hash based SPHINCS+ also may be interesting. Given that I can only donate little, I don't want to ask for anything, my money wouldn't even cover 1 hour of your work. Thanks for your replies and great FLOSS tools, they mean a lot to me! |
Beta Was this translation helpful? Give feedback.
This is usually not a practical concern, unless you expect an adversary to shoot lasers on a microcontroller while signing, in the right location, at the right time, and repeat the process a bazillion times while doing measurements.
But if this is the case, the easiest way is to build minisign using Zig, without libsodium with
zig build -Doptimize=ReleaseSmall -Dwithout-libsodium. You'll get a nice, small, static binary. And non-deterministic signatures.