Cryptologie

Go has an excellent standard library for cryptography primitives with well-established best practices. It was designed and is maintained in a principled way that likely appeals to more cryptography engineers. Also see this answer by one of its maintainers: https://www.reddit.com/r/crypto/comments/zukgfq/comment/j1l29um/ Some additional reasoning why having a strong standard library is important: https://www.cryptologie.net/article/505/why-not-rust-for-security/

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.

It’s done, but I have a lot of work to revise chapters. I’m also actively collecting feedback[1] if you are interested :) [1]: https://cryptologie.net/#article_510

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.

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…

On the one hand, I am glad it finally got the proper funding. On the other hand, I would prefer more effort going into more modern implementations [1] or protocols[2][3]. [1] https://sequoia-pgp.org/ [2] https://www.cryptologie.net/article/502/alternatives-to-pgp/ [3] https://blog.gtank.cc/modern-alternatives-to-pgp/

I'm again talking out of my depth, so take this with salt, but my understanding is the small public exponent is for the sterotyped message version of that attack not the partial key recovery variant. Looking at this page https://www.cryptologie.net/article/222/implementation-of-coppersmith-… it looks like the exponent isn't even an input to the algorithm when doing key recovery

[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/

TIL https://cryptologie.net/article/222/implementation-of-coppersmith-atta… There is also: https://simons.berkeley.edu/sites/default/files/docs/14975/cryptanalys…

The point of the article is that mature and well-vetted libraries have repeatedly been shown to have vulnerabilities in their RSA implementations. See [1] for just one recent example, but there have been many. [1]: https://www.cryptologie.net/article/461/the-9-lives-of-bleichenbachers…

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/

are you sure that the padding is not zeroed by memset? [1] says that memset_s exists because it is not optimized away if it just clears a variable that will not be used after the call (unlike memset) On the other end: people who do this for security reasons say not to trust memset_s is 'an optional feature of c11 and not really portable' [2] [1] https://en.cppreference.com/w/c/string/byte/memset [2] https://www.cryptologie.net/article/419/zeroing-memory-compiler-optimi…

You immediately lose your integrity protections, which allows you to launch attacks against AES-CTR as if it had no authentication tag. https://cryptologie.net/article/361/breaking-https-aes-gcm-or-a-part-o…

Coincidentally, there was a post yesterday on HN about how to communicate to developers. Sounds like they didn't read it. https://www.cryptologie.net/article/466/developers-are-not-idiots/

More details here: https://www.cryptologie.net/article/432/disco/

I thought it was a mirror of 4chan or something, but it's apparently a (4chan inspired) imageboard. Title is confusing. Blog link at the bottom of the page is interesting: https://cryptologie.net/article/424/writing-a-dapp-for-the-ethereum-bl…

https://www.cryptologie.net/article/274/lets-encrypt-overview/ They should use HSTS and redirects, though.

> 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.