> Wait, what? So many articles and journals I read on the topic just talk about prime fields, modular reduction and blah blah blah like it’s asking someone to buy milk and eggs at the grocery store.<p>No kidding, it's so frustrating! I have to read some articles/ papers like 20x and open a bunch of wikipedia tabs to understand wtf they're talking about. If they gave a simple, high level explanation it would save tons of time - while a wikipedia article is going to be very in depth, it's not tailored to the context of what I'm reading, so I often have to look at a whole bunch of things to start to build a good model in my head for wtf they're trying to convey.<p>This post, on the other hand, is perfect for me. Thank you so much for writing it I'm learning a ton.
This work is associated with Precursor (<a href="https://www.bunniestudios.com/blog/?p=5921" rel="nofollow">https://www.bunniestudios.com/blog/?p=5921</a>), which is Bunnie's project to build a mobile hardware platform from the ground up.
> It’s a weird thing about academics — they like to write papers and “share ideas”, but it’s very hard to get source code from them.<p>I suppose at least part of the reason, especially for things like crypto and statistics, is that they don't want to get bogged down in plausibly-correct claims of fatal flaws, and be perhaps repeatedly (over years hence) put in a defensive position of having to prove the criticism <i>in</i>correct or have everyone assume the work was wrong?<p>I can sort of understand that. The same's true for the papers themselves of course, but I can see it being more annoying for code. ('But it's never going to actually be in that state', etc.)
>The “double ratchet” algorithm is integral to modern end-to-end-encrypted chat apps, such as Signal, WhatsApp, and Matrix.<p>Signal protocol uses a hash ratchet for the message to message forward secrecy. So you don't need to do the expensive key agreement stuff unless that hash ratchet falls out of synchronization.<p>It isn't really clear if any messaging application really needs message to message forward secrecy in the first place. You really only need to do that expensive key agreement operation when you want to get rid of some old messages that someone has captured off the wire. That can be reasonably done at the end of a session or even weekly. Very few people need messages that have not even scrolled off the screen to be forward secret, assuming they need it at all.
This is an excellent read[1]. It reminded me of the process I went through putting together an FFT engine in an FPGA although I think the small execution engine is just stellar, and not something I had considered.<p>[1] To be fair I find most of the stuff Bunnie writes about to be worth reading! :-)
I learned Montgomery multiplication from the Handbook of Applied Cryptography (Menezes, Oorschot and Vanstone), and coded it directly from the pseudocode therein. Not to mention lots of other crypto algorithms. This book is a gold mine.
Excellent deep dive on this beast that had me similarly question my intelligence in the past.<p>As a former academic: the reason sharing source code is/was rare is that it tends to be extremely ugly, and that you don’t get any credit for publishing it where it matters (I. e. tenure committees). To go from something that works to something that you would allow people to see takes about as much time as the original work.<p>(As a side note: I feared for the worst when I saw, among tags like “hacking” and “open source”, the tag “feminism” in the side bar. I enjoyed being wrong.)
This is neat. The ever-present admonition against rolling one's own crypto lurks in the back of my mind, though. It is not my intent here to impugn Bunnie's competence, though I do wonder if he's run the design or implementation past any cryptographers to try to verify that the design or implementation are sound, and don't subtly break critical assumptions vital to the security of the algorithm.