I am Karolin Varner, the person who designed the Rosenpass Protocol, which secures WireGuard against quantum attacks, and I am the managing director of Rosenpass e. V. I am well connected in the real-world cryptography scientific community and do cryptography daily.
Based on the responses from the author in this thread, I would strongly advise anyone against using this library for the following reasons:
- Lack of third-party reviews/existing review processes
- Somewhat evasive/defensive answers about LLM usage in this thread
- Lack of complete constant-time cryptography support
- The author's own insistence that this pre-v1 code (if it's pre-v1 and thus not yet at quality, don't advertise it for use. This is cryptography.) This claim is especially alarming since it's not found in the README, which does beg users to employ this library.
- Publishing this and then forcing everyone else to review this is extracting free labor from cryptographers. Code duplication in the code base extracts extra labor from cryptographers checking this. It's simply not good neighborly behavior.
The author claims themselves that the library is not fully constant-time secure; constant-time security is a basic guarantee all cryptography code MUST follow.
AUTHOR QUOTE:
NO global constant-time claim for:
- parsers/importers/DER/PHC decoding
- algo/profile negotiation
- keygen and OS randomness paths
- public RSA verification/encryption work
- hashes/checksums/fast hashes as whole APIs
- length/shape rejection before a primitive boundary
- Argon2d/scrypt as blanket CT primitives
Honestly, I am having a hard time making sense of this comment. A lot of these clearly should be constant time; not making them constant time is by definition insecure.
Given that this code is partially LLM-generated, I am dubious about whether every line of the code that is claimed to be constant-time secure is actually so.
It is also very confusing that the author claims constant-time security for MACs but not for (cryptographic) hashes. MACs (message authentication codes) are implemented in terms of hash functions, so how can the MAC be constant-time secure if the hash function is not? It makes no sense.
I suspect that the speedup reported might be in part due to the lack of constant-time security. Constant-time code comes with a performance penalty; if you are not doing constant time and the other people are, then of course your code will be faster.
It is particularly troubling that the author talks about "algo/profile negotiation"; this type of feature was a frequent source of dangerous vulnerabilities in SSL/TLS implementations (look up downgrade attacks). Also, for a library providing primitives, why is algo/profile negotiation even needed?
In short: If you want your projects to be secure, please do not use this. And please, dear author, do not publish half-baked crates in this way. It's disrespectful and steals our time as cryptographers.
Why do the different sha2 variants not share code? This seems like a lot of opportunities for small mistakes/discrepancies; especially considering the many architectures.
Cryptographer and IACR member with a tiny bit of inside knowledge here.
To me, the entire matter is mostly amusing; the negative impact on IACR is pretty low. I now have to spend 10-15 minutes voting again. No big deal.
It saddens me that Moti Yung is stepping down from his position as an election trustee; in my opinion, this is unwarranted. We have been using Helios voting for some time; this was bound to happen at some point.
Don't forget that the IACR is not a large political body with a decent amount of staff; it's all overworked academics (in academia or corporate) administering IACR in their spare time. Many of them are likely having to review more Eurocrypt submissions than any human could reasonably manage right now. There are structural issues in cryptography, and this event might be a symptom of the structural pressure to work way more than any human should, which is pervasive not just in cryptography, but in all of science.
From what I heard on the grapevine, this scenario was discussed when Helios was adopted; people wanted threshold schemes to avoid this exact scenario from the start, but from the sources I can find, Helios does not support this, or at least it does not make threshold encryption easy. The book Real-World Electronic Voting (2016)[^0] mentions threshold encryption under "Helios Variants and Related Systems", and the original Helios paper (2008)[^1] mentions it as a future direction.
You don't have to tell these academics that usable security is important. Usable security is a vital and accepted aspect of academic cryptography, and pretty much everyone agrees that a system is only as secure as it is usable. The hard part is finding the resources—both financial and personnel-wise—to put this lesson into practice. Studying the security of cryptographic systems and building them are two vastly different skills. Building them is harder, and there are even fewer people doing this.
I am Karolin Varner, the person who designed the Rosenpass Protocol, which secures WireGuard against quantum attacks, and I am the managing director of Rosenpass e. V. I am well connected in the real-world cryptography scientific community and do cryptography daily.
Based on the responses from the author in this thread, I would strongly advise anyone against using this library for the following reasons:
- Lack of third-party reviews/existing review processes
- Somewhat evasive/defensive answers about LLM usage in this thread
- Lack of complete constant-time cryptography support
- The author's own insistence that this pre-v1 code (if it's pre-v1 and thus not yet at quality, don't advertise it for use. This is cryptography.) This claim is especially alarming since it's not found in the README, which does beg users to employ this library.
- Publishing this and then forcing everyone else to review this is extracting free labor from cryptographers. Code duplication in the code base extracts extra labor from cryptographers checking this. It's simply not good neighborly behavior.
The author claims themselves that the library is not fully constant-time secure; constant-time security is a basic guarantee all cryptography code MUST follow.
AUTHOR QUOTE:
Honestly, I am having a hard time making sense of this comment. A lot of these clearly should be constant time; not making them constant time is by definition insecure.
Given that this code is partially LLM-generated, I am dubious about whether every line of the code that is claimed to be constant-time secure is actually so.
It is also very confusing that the author claims constant-time security for MACs but not for (cryptographic) hashes. MACs (message authentication codes) are implemented in terms of hash functions, so how can the MAC be constant-time secure if the hash function is not? It makes no sense.
I suspect that the speedup reported might be in part due to the lack of constant-time security. Constant-time code comes with a performance penalty; if you are not doing constant time and the other people are, then of course your code will be faster.
It is particularly troubling that the author talks about "algo/profile negotiation"; this type of feature was a frequent source of dangerous vulnerabilities in SSL/TLS implementations (look up downgrade attacks). Also, for a library providing primitives, why is algo/profile negotiation even needed?
In short: If you want your projects to be secure, please do not use this. And please, dear author, do not publish half-baked crates in this way. It's disrespectful and steals our time as cryptographers.