11 ms·
Show HN: filippo.io/mlkem768 – Post-Quantum Cryptography for the Go Ecosystem
- mooreds 3y agoAnyone aware of such implementations for other languages (java, c#, etc)?
- elliewithcolor 3y agoGeneral implementation or a „from scratch“? For general here is a list: https://pq-crystals.org/kyber/software.shtml https://pq-crystals.org/kyber/software.shtml
- cipherboy 3y agoNote that there may be incompatibilities (as noted in the article) until NIST has published the final revisions. Some specifications are on Round 3 kyber, others are on FIPS 203. This one will interoperate with Bouncy Castle (both Java and C#) as we both use FIPS 203 draft, but it won't interoperate with OQS simultaneously (three-way interop) as that is still on the Round 3 submission. See also: https://github.com/bcgit/bc-java/issues/1578 https://github.com/bcgit/bc-java/issues/1578 (Disclosure: BC is my employer)
- elliewithcolor 3y agoFair point.
- glitchc 3y agoHow about liboqs from OpenQuantumSafe? It includes an implementation of most PQC primitives proposed to date: https://github.com/open-quantum-safe/liboqs https://github.com/open-quantum-safe/liboqs
- dorianmariefr 3y agoSpec: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf (linked from the article)
- deleted 3y ago[deleted]
- tux3 3y agoNeat that it can also work as draft00/kyber v3 =) How hard would it be to support a fast Kyber 90's mode, without SHA-3? (I suppose you would have to break the abstraction for that one).
- FiloSottile 3y agoYeah, replacing the hash would take a fork. Note that this implementation spends only about 20% of CPU time in SHA-3, so the gain wouldn't be massive. That proportion would probably grow after optimizing the field implementation, but almost certainly not enough to make it worth using a non-standardized, less-tested mode.
- tux3 3y agoThat's fair. Thanks.
- bennettnate5 3y agoCorrect me if I'm wrong, but if it's written in pure Go, wouldn't that make it susceptible to timing/power side channel attacks?
- bennettnate5 3y ago> All critical operations are performed in constant time. Should have clicked all the way through links to the project docs--looks like they're keeping this in mind.
- e1g 3y agoJust for context, the OP (FiloSottile) was in charge of cryptography and security on the Go team until recently.
- FiloSottile 3y agoGo is as susceptible to timing side channels as C, if not less. (The difference being that while there is one major Go compiler, which usually does not go overboard with optimizations, when writing C you have to do increasingly complex tricks to defend against the compiler realizing what you are trying to do and replacing it with a more efficient variable-time branch.) This implementation was written to avoid any secret dependent code path. Power side channels, which require physical access, are indeed outside the threat model of Go.
- l33t7332273 3y agoIs there a language that is invulnerable to power side channel attacks? The idea seems nonsensical to me. As far timing attacks, what about Go makes it more susceptible to timing side channels than any other language?
- gnfargbl 3y agoI have no ability to judge the quality of this algorithm or implementation, but I do thoroughly approve of the usage of unicode in variable names: ρ, σ := G[:32], G[32:] Somehow much better than seeing "rho", "sigma".
- clktmr 3y agoI must say, I don't like it at all. As with all characters that aren't part of my keyboard, the extra steps to type these add so much friction. Also, I would probably misread ρ as p, giving me the weirdest compile errors. How would you feel about adding acutes and cedilles to characters? It just adds complexity. Let's stick to the smallest common denominator.
- eviks 3y agothe smallest common denominator for math is math symbols, full ascii notation instead of those is the extra complexity in reading comprehension, which, as the saying goes, is a more frequent occurence
- Philip-J-Fry 3y agoGotta disagree. It's neat, but I don't like to see it in the real world. For a start, I don't know how to type these on a keyboard. Secondly, most people wouldn't know what these symbols are called. Granted, those looking at the code probably have a greater chance of knowing. But it isn't friendly code in my opinion. I think clarity is key, and "rho" or "sigma" are pretty clear. Also, add in that there's a constant "n" and a constant "η". Just begging for confusion.
- curiousgal 3y ago[flagged]
- zare_st 3y ago[flagged]
- hattmall 3y agoSo what is the actual state of Quantum computing in regards to the level that would make something like this necessary? Is it become like AI where instead of actually coming into existence the definition is mostly just changing to bring forth a new product under a previously existing name?
- jjice 3y agoWithin the last two-ish years, the NIST settled on some post quantum crypto algorithms and there's been some implementation of them more and more since. Quantum computing is still far off, but I think the mindset is "why not start now?" I don't know for certain, but I'd assume things like elliptic curve were implemented a good bit before it garnered mainstream usage. I'd love for someone who was around that when it was happening to correct me if I'm wrong though.
- KMag 3y agoYou're correct. For a while, elliptic curves were avoided by most for 2 reasons (1) worry about interpretation of some of the now-expired patents and (2) there were some known "gotchas" for constructing curves, and there were some fears that there were still some "gotchas" to be found. (And, perhaps, the NSA knew some of the gotchas and were keeping them in their back pockets.) Side note: arithmetic/range coding had similar slow adoption due to patents. Depending on your interpretation, IBM's range coding was prior art for the arithmetic coding patents, but nobody really wanted to test it in court. For instance, bzip2 is the original bzip with the arithmetic coding step replaced by a Huffman code. Nobody wanted a repeat of the debacle with GIF images being widely adopted before many realized the use of the patented LZW compression might be a problem.
- Avicebron 3y agoI'm just barely scratching the surface of quantum computing mostly out of curiosity after almost a decade of traditional software work. So I mostly have done things like qiskit tutorials, but other than reading about the theory I have yet to see a coherent explanation as to how the devices actually implement the theory. Again. I'd love to be enlightened
- vbezhenar 3y agoThe same guy that brought us https://github.com/FiloSottile/age https://github.com/FiloSottile/age I really like this tool.
- candiddevmike 3y agoAge is nice but seems to have stagnated--last release is from 2022, and it's not using a more modern PBKDF like argon. If you're looking for something designed for secret storage/sharing, checkout rot: https://github.com/candiddev/rot https://github.com/candiddev/rot
- tptacek 3y agoNot changing since 2022 is a feature, not a bug. It's an exchange format, so it was never going to switch KDFs just for funsies, and scrypt is fine.
- dpatterbee 3y agoI wouldn't describe age as having stagnated, it's simply stable. It has a well defined spec which it fully implements (seemingly correctly), so there isn't any need for more recent releases. Also I think it's a bit sly to not mention that you're the creator of the alternative you suggest.
- FiloSottile 3y agoage is intentionally stable as a format and as a core tool. There is a lot of activity in the integration and plugin ecosystem, which I am very happy about. https://github.com/FiloSottile/awesome-age https://github.com/FiloSottile/awesome-age I have a wishlist for v2 changes, and I am considering slowly and carefully making such a release this year, but the difference in security between scrypt and Argon2 doesn't really justify making a change there.
- varispeed 3y agoShame it doesn't have plausible deniability built in. That is you could encrypt at least two files and decrypt one of them based on which key you provide. This seems to be a security flaw of most of these kind of tools. That is there is only one possible key, so someone with a hammer can make you disclose it. But if the number of keys is unknown, you can give up some keys and hope attacker will leave you alone, without revealing the actual protected file.
- tgkudelski 3y agoHello from Kudelski Security. This is super timely, because we recently had to discontinue one of the other only existing Go libraries for quantum-resistant cryptography in Go! Full story at https://research.kudelskisecurity.com/2024/02/01/the-kyberslash-vulnerability-and-the-crystals-go-library-a-retrospective-story/ https://research.kudelskisecurity.com/2024/02/01/the-kybersl...
- client4 3y agoWasn't kyber-512 intentionally weakened by the NSA members of NIST?
- tptacek 3y agoNo.
- less_less 3y agoTo expand on this: Daniel J Bernstein (of Curve25519 etc fame) has alleged that NIST and/or NSA knows a secret weakness in Kyber and therefore pushed it instead of NTRU. While the allegations are vaguely plausible -- NSA employs some very clever people, and of course they would like to interfere -- the evidence DJB put forth hasn't convinced very many other cryptographers. There was also an incident a few months back when someone with an NSA email address suggested significant last-minute changes to Kyber on the PQC forum mailing list. These changes had a security flaw, and they were rejected. NSA might still know a different weakness, of course. Note also that DJB's allegations focus on Kyber-512 being too weak, and this post is about Kyber-768.
- tptacek 3y agoI don't think there's a single PQC cryptography researcher other than Bernstein himself (corrections welcome) that takes the claims he made seriously, and one of the basic mathematical arguments he made may have been refuted, two messages down in the mailing list thread, by Chris Peikert.
- Kurd 3y ago[flagged]
- lopkeny12ko 3y agoWhatever happened to "don't roll your own crypto"? Isn't this work best left to OpenSSL for example.
- sackfield 3y agoThis is a good point, most of Go's crypto library seems to be written in go: https://cs.opensource.google/go/go/+/master:src/crypto/crypto.go https://cs.opensource.google/go/go/+/master:src/crypto/crypt... Go can link to C but the process is a bit horrible. I wonder if Go's memory safety in comparison to C and the security implications reverses this a bit.
- ecnahc515 3y agoNone of that is an actual implementation of the cryptography, that's just the interfaces. The actual implementations are elsewhere and use architecture specific assembly for anything that needs constant time properties.
- FiloSottile 3y agoNo, we use assembly for access to specialized (e.g. AES-NI) or vector instructions, and we do so reluctantly. We much prefer writing cross-platform constant time Go. https://go.dev/wiki/AssemblyPolicy https://go.dev/wiki/AssemblyPolicy The actual implementations are in that tree, too: https://cs.opensource.google/go/go/+/master:src/crypto/ https://cs.opensource.google/go/go/+/master:src/crypto/
- wfn 3y agoGolang has its own native crypto implementations where possible. Having used openssl extensively and having read some of its source code[1], I would personally like good alternatives. The developer (Filippo Valsorda) is a cryptographer and Go maintainer (incl. of some well known Go crypto packages in its std lib). In this particular instance he seems to have implemented this (ML-KEM-768) as an exercise (incl. educational), but still, just some context! [1] openssl is a gift that keeps on giving (CVEs). Just look at all those nice (incl. recent) issues, incl. RCEs iirc. Also, very anecdotal, but I find it funny that they haven't updated this page for the last I don't know 15 years? https://wiki.openssl.org/index.php/Code_Quality https://wiki.openssl.org/index.php/Code_Quality
- mauricesvp 3y agoUnrelated, but c'mon Filo, the 32 bit syscall table is still 'coming soon' :')
- FiloSottile 3y agoHah, touché my friend. It's just that every time I think about touching that page it scope creeps into making it autogenerated from the kernel sources via CI etc. etc. :)
- teleforce 3y agoPerhaps relevant to the discussions is this friendly book on crypto systems implementation in the latest version of Go by John Arundel. Inside the last section there is a passing mention on post quantum crypto. Perhaps if John can update the book later with this library once the NIST PQ is standardized. Explore Go: Cryptography (Go 1.22 edition): https://bitfieldconsulting.com/books/crypto https://bitfieldconsulting.com/books/crypto