sevenoftwelve

Hi there,

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

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.

Was any of this generated using AI?

Hi @LoadingAlias,

Constant-time MAC, AEAD, and signature verification.

That sounds suspiciously incomplete to me.

Which cryptographic algorithms in the library are currently not implemented in constant time?

Where did the speedup come from? How where these optimizations achieved?

What motivated you to write the library? Why not contribute to existing rust crypto libraries instead? How is the work financed?

What peer review strategy are you following with the library? Who else but yourself has verified this code?

Look, you can't write stuff like that any more. It took me three minutes to figure out you where joking.

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.

[^0]: Pereira, Olivier. "Internet voting with Helios." Real-World Electronic Voting. Auerbach Publications, 2016. 293-324, https://www.realworldevoting.com/files/Chapter11.pdf

[^1]: Adida, Ben. "Helios: Web-based Open-Audit Voting." USENIX security symposium. Vol. 17. 2008, https://www.usenix.org/legacy/event/sec08/tech/full_papers/a...

I don't think so.

Using hash functions requires a minimum amount of entropy in the seed. So do the schemes put forward in the article. In particular, these schemes require a relatively high degree of certainty about the amount of entropy in the stream at low variation. For the entropy extractors, the amount of total entropy required scales linearly with the length of the output stream. If you are using a hash function, the entropy requirement is constant.

The fact remains, both the method put forward in the post and using hash functions have a minimum entropy requirement. Even if you have only a small amount of entropy, hash functions will still get you more bang for the buck.

If push really comes to shove, you can still use a key stretching function[^0] to make it as hard as possible for an attacker to brute force what little entropy you have, as is routinely done with passwords.

To illustrate the difference in entropy requirement, imagine running the Von Neumann generator for a while, achieving the needed entropy level. In this scenario, the output stream of randomness will be fine. If you then get a section from the stream with very little entropy – much lower than the required amount – you get a section with very little entropy in your output stream. The Von Neumann generator can degrade, hash functions won't (for all practical intents and purposes).

Fortuna is designed to approach the entropy estimation problem. It is eventually secure even in the face of a determined attacker; due to the construction using entropy pools used with exponentially decreasing frequency of use, it covers an extreme range of different entropy levels – around ten orders of magnitude with 32 pools.

Crucially, once a secure level of entropy is reached, the RNG stays secure.

Of course, if the amount of entropy is low, Fortuna will produce quite a bit of insecure entropy before, eventually, producing secure entropy. In practice, this issue can be solved by running Fortuna for a while without producing any output. In a factory producing secure hardware devices, you might just allow the device to be active for a day, and you might some extra, high-quality entropy from the device that flashes your hardware devices in the first place.

Fortuna also allows you to use different sources of entropy securely. Using a Von Neumann generator for instance, achieving this is much harder.

Entropy estimation is borderline impossible in practice; Fortuna deals with this head on, with von Neumann you are lost if your estimate is off.

[^0]: https://en.wikipedia.org/wiki/Key_stretching

The article is interesting, but it misses the most practical and unambiguously safe way to generate streams of random data: Use cryptography.

To generate a stream of random data, use a hash function with arbitrary-length output (XOF) such as blake2x[^0] or shake256[^1]. Make sure your key contains at least 256 bits of entropy. Absolutely never use a key with less than 128 bits of entropy.

Since it's impossible to know how much entropy there is in a key, you probably want to use something like the Fortuna RNG[^2]. Substitute the sha2/AES based construction for your XOF. Bruce Schneier designed Fortuna back when XOFs were harder to come by.

If you want more performance, you can use blake2 to compress your input seed into 256 bits and generate the random stream using chacha20[^3].

All of this is usually handled by the Linux kernel[^4], so it's best to just use the getrandom(2)[^5] system call or just read from /dev/urandom[^6]. If you are writing a Rust program, you can use the rand[^7] crate, which uses a mixed approach reading a seed from the operating system and expanding it in-process using chacha[^8]. This is a valid strategy.

I am omitting some subtleties[^10] about mathematical definitions of randomness extractors as used by the author of the article. When you are using a cryptographic approach, you are dealing with a complexity-theory based security notion[^9], which does not precisely equate to creating a stream with a specific amount of entropy. Everywhere – except for a physics or a math paper dealing with information theory – I would call this a technicality. For most intents and purposes, cryptographic security notions are the most real-world robust conceptions of randomness available.

[^0]: https://www.blake2.net/

[^1]: https://csrc.nist.gov/pubs/fips/202/final (shake256 is part of the SHA-3 standard)

[^2]: https://www.schneier.com/academic/fortuna/

[^3]: https://protonvpn.com/blog/chacha20

[^4]: https://lwn.net/Articles/884875/

[^5]: https://man.archlinux.org/man/getrandom.2

[^6]: https://man.archlinux.org/man/urandom.4

[^7]: https://crates.io/crates/rand

[^8]: https://docs.rs/rand/0.8.5/rand/rngs/struct.StdRng.html

[^9]: https://en.wikipedia.org/wiki/Security_of_cryptographic_hash...

[^10]: In particular, PRFs are not guaranteed to output tokens with a certain amount of entropy – if I recall correctly – because they can map two inputs to the same output.

---

I am the main author of the Rosenpass[^11] post-quantum secure key exchange for WireGuard. My expertise comes from developing this protocol, as well as a couple of years of engagement with the real-world cryptography community and from my own scientific research on cryptography and secure implementations of cryptography.

[^11]: https://rosenpass.eu/

I am researching formal methods systems to conduct cryptographic proofs; I think a big issue in that space is having syntax sugar in the core compiler, so I am pursuing ways to move syntactic sugar into a separate macro language.

Your post sounds like an interesting research project, but the examples given in the blog post seem somewhat discouraging to me. When I gaze at one of your examples, they seem obtuse and while I am sure I could understand the examples by not just skimming the article, this does tell me that the grammars you used are not very self-explanatory: Your syntax expresses meaning relative to the specific grammar as opposed to expressing meaning relative to the English language or pre-existing, well-established programming languages.

Is there some example of self-explanatory grammars and self-explanatory bootstrapping code in your language?

I am the Rosenpass author; Rosenpass is an add-on to make WireGuard even more secure. There are certain types of attacks (i.e. those from quantum computers) that could become possible to perform for governments and very large organizations.

To protect the infrastructure of smaller companies and to protect the data of private WireGuard users, Rosenpass makes WireGuard immune against these potential attacks from states and large organization.

Rosenpass author here;

Mate, you could just read the code…or give it a try ;)

the WG author seems like he doesn't care about PQC

This is plainly not true; WG supports post-quantum security with the use of the PSK mechanism as we do. PQ-crypto is high quality but it is also new and fairly inefficient; not a good thing to integrate into the kernel directly. Using the PSK mechanism is the best way to do this I know of at this point in time.

It's also not clear how the WG PSK change is coordinated, and whether that entails a brief loss of connectivity - packet loss, latency spike.

WireGuard establishes a session with the existing PSK; we replace the PSK every two minutes but WireGuard keeps its established session around until it renegotiates a session.

Both WG and RP rekey their session every two minutes; there is no interruption.

We are based on the work of Hülsing, Ning, Zimmermann, Weber and Schwabe and in contact with the group. I havn't heard about kuedlki; the slides seem to refer to a reimplementation of the 2020 paper and the go implementation has been stale for two years. They also seem to use a tweaked krystals implementation which I would not trust. The link to the blog post they refer to dis dead.

The Rosenpass protocol builds on the 2020 paper but also adds security against state disruption attacks (CVE-2021-46873). The implementation is actively maintained, written un Rust not in go. We use Classic McEliece and Kyber from the OQS library.

Rosenpass author here;

nope, that is not correct. NIST has elected Kyber as one of the algorithms to standardize and we are using that.

As other commenters mentioned (very good info there, thank you all!) the other algorithm we use – Classic McEliece – is one of the oldest algorithms and has been well studied. There is no known efficient attack against it.

Rosenpass author here;

There is a confusion about terminology here I think. Mathematical proofs including cryptography proofs use models simplifying reality; i.e. the real practical system might still be susceptible to attacks despite a proof of security.

For crypto primitives (classic mc eliece, curve25519, ed25519, RSA, etc etc) the standard for proofs is currently showing that they are as hard as some well studied mathematical problem. This is done by showing that an attack on the primitive leads to an attack on the underlying mathematical primitive. The proof for Diffie-Hellman shows that attacking DH leads to an efficient solution for the discrete log problem. I.e. the proof is a reduction to the underlying primitive.

No primitive is perfectly secure (at least a brute force – i.e. guessing each possibility is possible); there is some probability that the adversary can guess the right key. We call this probability the adversary's advantage. One task in cryptoanalysis is to find better attacks against primitives with a higher advantage; if an attack with a polynomial time average runtime is found, the primitive is broken. Finding a higher non-polynomial attack is still an interesting result.

The standard for protocols is proving that the protocol is secure assuming the primitives are secure; since multiple primitives are used you basically get a formula deriving an advantage for breaking the entire protocol. The proof is a reduction to a set of primitives.

We did not build a proof in that gold standard, although we are working on it. We built a proof in the symbolic model – known as a symbolic analysis. This uses the perfect cryptography assumption; i.e. we assumed that the advantages for each primitive are zero. Google "Dolev-Yao-Model".

This makes the proof much easier; a proof assistant such as ProVerif can basically find a proof automatically using logic programming methods (horn clauses).

The definitions of security are fairly well understood; unfortunately there is a lot to go into so I can't expand on that here. Looking up "IND-CPA" and "IND-CCA" might be a good start; these are the security games/models of security for asymmetric encryption; you could move on to the models for key exchange algorithms there. Reading the [noise protocol spec](https://noiseprotocol.org/) is also a good start.

Granted, writing things in Rust doesn't exclude the possibility of a buffer overflow entirely. It does help make it much less likely.

Author here;

We are :) Rosenpass is a fancy way of generating a PSK for WireGuard.

Rosenpass author here.

It does yes. But it is a mitigation, not a real fix.

An attacker could still just speed up time. Although not being able to produce a KillPacket for the year three thousand is a good thing :)

Rosenpass author here; I myself am independent, thus funding by NLNet. We have some project participants who are Freelancers; two of my co-authors are employed at research institutes. One of my co authors is employed at MPI-SP.

The cookie thing is a defense against WireGuard CVE-2021-46873; the attack is in my view not bad enough to get rid of the WireGuard protocol. WG is still the standard for pre-quantum VPN implementations. Rosenpass also needs to use post-quantum crypto-primitives that need a lot of cpu and memory resources.

Rosenpass and WireGuard work together; Rosenpass runs in userspace and gives keys to WireGuard so we do not plan to replace it any time.

It would be possible to apply the biscuit mechanism to classical WireGuard; unfortunately that would cause a protocol incompatibility. I am not sure if they are going to take that path.

Author of Rosenpass here;

Coq is fairly generic; it has a long history and made it possible to write some really cool proofs such as a proof of the four colors theorem, but writing crypto proofs is really hard using Coq.

For symbolic verification Tamarin and ProVerif are the tools of choice; I used ProVerif.

For proofs of security for protocols EasyCrypt and CryptoVerif can be used. CryptoVerif, ProVerif and Coq where developed at the same Institute by the way; at Inria Paris.

Author here: No, symbolic verification does not protect from buffer overflows. Writing the implementation in Rust does

We are investigating ways how to do more formal verification for the implementation itself.

Direct link to the project: https://github.com/adobe/ferrum

Maybe the author just lacks deep editing skills…

Is this AI-generated? And that's why it's called "Deep Literacy"?

Finally, that settles it: ∞ = 3

Alternate Links:

Version hosted outside medium: https://cupdev.net/blog/014_quantumhardening.html

Vortrag (Deutsch): https://media.ccc.de/v/DiVOC-19-quantum

Lecture (English): https://www.youtube.com/watch?v=pHR8DEqnVX

The post discusses the optimization of bin2c (https://github.com/adobe/bin2c/) – a tool to embed binary files in C or C++ applications that reduces compilation times up to thirty times!

Thanks for the tip!

Technically still on vocation so I added a ticket to update the Readme :)

I've taken a look at Ramda! It does look very nice; I think the goals of Ferrum and Rambda are a bit different: Rambda seems to aim at being a kind of FP standard library for JS so in that regard it is more comprehensive than Ferrum.

Ferrum on the other hand is primarily designed to introduce some new features for iteration libraries in JS: Reverse Currying, Objects as Sequences and Lazyness are not provided by Rambda. Both Rambda and Ferrum feature a `pipe()` function.

Also Ferrum provides a Traits and a standard library of traits like Eq, Rambda does not I think :)

So I would prefer using Ferrum/Sequence over the list transformation functions from rambda because of the above mentioned features, but that shouldn't stop anyone from using the rest of Rambda (or even underscore or lodash); you should be able to mix and match functions from rambda and ferrum without any issue; even in the pipe functions; so I would say use Ferrum/Trait and Ferrum/Sequence and keep using Rambda for the rest because it's great; I think I'll add another example for mixing Ferrum and Rambda and Lodash :)

I do get where you are coming from and I do have to admit that even to me the entire reverse currying seems kind of alien…especially as someone coming from a very functional style where functions stay very short…

Unfortunately most JS code I work with is not written in such a functional style, so function bodys very often become larger than a couple of lines and in these cases having to search the argument somewhere a couple lines down does break the flow for me a bit…

It's the least problematic trade off I could find so far, trying to marry FP and procedural JS dev styles :)