Cryptologie is a blog by a cryptography engineer covering TLS attacks, PGP alternatives, protocol design, and security tooling choices.
HN links it for its cryptography posts, and commenters engage with its security topics. One mentions the author's book revisions and collecting feedback.
This is a lot more interesting than I thought it would be from the title.
Obviously, anyone can trivially generate "backdoored" Diffie-Hellman parameters; for instance, just use a bogus generator that locks the algorithm into a tiny subgroup. No matter what private keys Alice or Bob generate, the DH computation will be predictable.
This writer wants to do something cooler: generate NOBUS parameters, in the fashion of Dual_EC DRBG, so that the parameter's authors can predict DH computations but (without Significant effort) nobody else can.
Several of the methods the writer is playing with involve DH parameters for which they can use Pohlig-Hellman to recover secrets. Pohlig-Hellman breaks DH when its victims are unfortunate enough to be in a group with a smooth order --- that is (I'm butchering this), when the group order factors into small primes. It works by collecting samples from the target for each factor of the group; each leaks a bit of the key modulo that factor. You knit the samples together with CRT.
David wrote this up well here: https://www.cryptologie.net/article/196/pohlig-hellman-algorithm/
Obligatory plug: a fun version of this attack is the kick-off problem on Sean Devlin's very excellent Set 8 of the Cryptopals challenges. Set 8 isn't on the website, but you can mail him (finding him is an exercise for the reader) to get a copy (on the honor system, like the other challenges were before we published). Set 8 builds this attack to an extremely useful…
I don't buy the theory that the Web PKI or some equivalent is "unnecessary for non-Web things". If anything I think there have been a few places where there's a nasty security gap because somebody didn't just stuff the Web PKI in there, even though it wasn't necessarily a perfect fit, because what we got instead was nothing ie no security.
An example of that first: Does your phone try to connect to SomeBrand WiFi networks? How does it know if this is a "real" SomeBrand WiFi network? It doesn't. In some scenarios this means you leak valid credentials for the "real" SomeBrand to bad guys. In most cases you at least leak identity information. That's not great news. If the WiFi network was named example.com the WiFi AP could of course present a certificate for example.com, leveraging the Web PKI.
Now, there are people who want to do QUIC without TLS, mostly what they want to do is NOISE. Like this: https://www.cryptologie.net/article/467/quic-noise-nquic/ But again, I think something like SSH is the exception and the Web PKI is more applicable to most uses for QUIC.
> The reason why I still like C is that it is a simple language. Simple in a sense that it is easy to express ideas and what to expect from it. For example, if you want to retrieve an array value with two offsets, one of which can be negative, in C you write arr[off1 + off2] while in Rust it would be arr[((off1 as isize) + off2) as usize].
There's an argument to be made that C is a simple language compared to some, I'll grant that. But implicit casts and the integer promotion rules really aren't a good example of simplicity. Terseness, sure, but not simplicity. For example, from https://www.cryptologie.net/article/418/integer-promotion-in-c
uint8_t start = -1;
printf("%x\n", start); // prints 0xff
uint64_t result = start << 24;
printf("%llx\n", result); // should print 00000000ff000000, but will print ffffffffff000000
result = (uint64_t)start << 24;
printf("%llx\n", result); // prints 00000000ff000000
There are good reasons why e.g. Go, which prioritizes simplicity very highly, does not allow implicit integer casts.
[1] Tanya Khovanova, Soviet-American mathematician who became the second female gold medalist at the International Mathematical Olympiads.
https://www.tanyakhovanova.com/
[2] Filippo Valsorda (cryptography)
https://filippo.io/
[3] David Wong (cryptography)
https://www.cryptologie.net/
[4] OpenBSD everything
https://www.undeadly.org/
[5] blog with some funny articles
https://idlewords.com/
[6] Might need a proxy/VPN to access this site
https://www.otherhand.org/
[7] Not a blog but something nice
https://thenicestplace.net/
Edit:
[8] weekly useful/curious datasets
https://www.data-is-plural.com/archive/
[9] documenting startups getting swallowed by the big fish
https://ourincrediblejourney.tumblr.com/
That's one of them, and the least interesting of both. I remember that the other one was way more concealed and involved a global variable or something like that and it didn't seemed that the code was doing what was actually doing.
There was an amazing blog entry which explained it, but can't find it right now.
Edit: I don't think this was the one I read, but it's similar.
https://cryptologie.net/article/316/junipers-backdoor/
Basically, Dual EC was chained to another PRNG, so the output should have been robust to crypto vulnerabilities discovered in any of both. The thing is: the second one was never called, because the for's index(a global variable) was set to 32 inside a function call, so the loop never run.
This is a bit pointless, since it does not say on which platform the comparison is made.
In any case, KangarooTwelve [1][2] (on AVX-512) is also 10x faster than SHA-256.
KangarooTwelve is a fast hash function of the Keccak family (from which the SHA-3 derives from), and it is clearly what BLAKE3 tries to catch up with.
However, KangarooTwelve probably benefits from the more extensive scrutiny that SHA-3 has received and will receive, and (from a performance standpoint) from future HW extensions that will speed it up even more (the first one appeared on ARMv8.2).
[1] https://keccak.team/files/KangarooTwelve.pdf
[2] https://www.cryptologie.net/article/393/kangarootwelve/