←back to thread

Cryptographic Issues in Cloudflare's Circl FourQ Implementation (CVE-2025-8556)

(www.botanica.software)
159 points botanica_labs | 4 comments | 22 Oct 25 14:22 UTC | HN request time: 0.004s | source
Show context
rdtsc ◴[22 Oct 25 17:06 UTC] No.45672098[source]▶
Does the “don’t implement your own cryptography” advice apply to multi-billion companies, or it’s just for regular, garden variety developers?

Some of the issues like validating input seem like should have been noticed. But of course one would need to understand how it works to notice it. And certainly, in a company like CF someone would know how this is supposed to work…

Surely the devs would have at least opened wikipedia to read

https://en.wikipedia.org/wiki/FourQ

> In order to avoid small subgroup attacks,[6] all points are verified to lie in an N-torsion subgroup of the elliptic curve, where N is specified as a 246-bit prime dividing the order of the group.

replies(2): >>45673910 #>>45676116 #
commandersaki ◴[22 Oct 25 19:22 UTC] No.45673910[source]▶
So should they have opted for an inexistent implementation of FourQ in Go so they don't have to roll their own (keeping in mind this is a library for experimental deployment of PQ and ECC)?
replies(1): >>45674651 #
1. rdtsc ◴[22 Oct 25 20:20 UTC] No.45674651[source]▶
They should have found someone who knows what they are doing or not implement it at all. We're talking about a company with a $1B+ yearly revenue here.

They put their name behind it https://blog.cloudflare.com/introducing-circl/ and it looks like whoever they hired to do the work couldn't even read the wikipedia page for the algorithm.

replies(1): >>45675196 #
2. wbl ◴[22 Oct 25 21:12 UTC] No.45675196[source]▶
Both Kris and Armando have PhDs in cryptography. The issues here are a lot more subtle than that wiki article makes it seem.
replies(1): >>45675408 #
3. rdtsc ◴[22 Oct 25 21:29 UTC] No.45675408[source]▶
> Both Kris and Armando have PhDs in cryptography. The issues here are a lot more subtle than that wiki article makes it seem.

That's sort of make it look worse then, doesn't it? The main issue isn't that subtle. Even the wikipedia mentions it:

> points should always be validated before being relied upon for any computation.

Moreover the paper https://eprint.iacr.org/2015/565.pdf also mentions a few times:

> Algorithm 2 assumes that the input point P is in E(Fp2)[N], i.e., has been validated according to Appendix A

Appendix A:

> The main scalar multiplication routine (in Algorithm 2) assumes that the input point lies in E(Fp2 )[N]. However, since we have #E(Fp2) = 392 · N, and in light of small subgroup attacks [39] that can be carried out in certain scenarios, here we briefly mention how our software enables the assertion...

replies(1): >>45675444 #
4. commandersaki ◴[22 Oct 25 21:33 UTC] No.45675444{3}[source]▶
You realise experts at cryptography, even implementation, are fallible right?

Case in point: https://www.daemonology.net/blog/2011-01-18-tarsnap-critical...

Not saying the same situation either; obviously Colin made a silly mistake while refactoring.

We don't actually know the issue with these implementors, but again I ask, with having actual professionals in the field, what should they have done instead of rolling their own for a primitive that doesn't exist in the language?