71–80 of 92 posts
Really though? This mostly-untrue statement is the line that warrants adding hashtag #post-quantum-cryptography to the blogpost?
Earlier quoted context omitted.
Off topic - is Firedancer going to survive Jump winding down its crypto arm? Kanav left, they liquidated a huge staked ETH position a few months ago (+ a bunch of other coins), and the SEC/CFTC is all over them for the Terra Luna fiasco.
Rumors of Jump’s demise are greatly exaggerated. Check the torrent of firedancer talks at Solana Breakpoint literally next week and decide yourself. Folks have said jump is gonna die for 20+ years. They’ve been around 30ish…
> The x25519 algorithm also plays a role in post-quantum safe cryptographic solutions, having been included as the classical algorithm in the TLS 1.3 and SSH hybrid scheme specifications for post-quantum key agreement. Really though? This mostly-untrue statement is the line that warrants adding hashtag #post-quantum-cryptography to the blogpost?
/?q X25519Kyber768Draft00: https://www.google.com/search?q=X25519Kyber768Draft00
Earlier quoted context omitted.
I'm not sure if you're reading more into what I said than I intended, but I'm not convinced by this argument. You might have missed that this course was on security in general, not cryptography; not everything in the course was cryptographic related. That said, I'd argue that for the vast majority of software engineers the type of stuff they're dealing with can be dealt with without needing to know the math. For exam…
Sure. It's a failing of the ecosystem. That observation, a cup of coffee, and 1-3 years will get you a Kenny Paterson paper stunt-breaking your system. I feel where you're coming from, but, respectfully: it does not matter. My thing here is just: learn the math! Or do something else. I did! There is so much to do in our industry.
I'm not sure I understand what you mean here by "something else in our industry". Are you arguing that I'm not qualified to be a software engineer due to not understanding the math behind elliptic curves, or did you miss my repeated use of phrases like "the vast majority of software engineers" rather than some specialty where cryptography implementation details details are more important? If the latter, I can reassure you that I don't work in cryptography, work on any cryptographic libraries, or have any specific responsibilities related to security beyond the general idea that all software being written should be secure. If the former, I'll have to respectfully disagree, and suggest that maybe even if you aren't willing to consider that you're wrong about the math being a hard requirement for someone being qualified as a software engineer, it's worth considering that you almost certainly don't have enough information to conclude whether a stranger on the internet is qualified based on reading some of their comments.
> The x25519 algorithm also plays a role in post-quantum safe cryptographic solutions, having been included as the classical algorithm in the TLS 1.3 and SSH hybrid scheme specifications for post-quantum key agreement. Really though? This mostly-untrue statement is the line that warrants adding hashtag #post-quantum-cryptography to the blogpost?
Actually, e.g. rustls added X25519Kyber768Draft00 support this year: https://news.ycombinator.com/item?id=41534500 /?q X25519Kyber768Draft00: https://www.google.com/search?q=X25519Kyber768Draft00
Does 25519 suffer from key/data-dependant execution time? Is this implementation resistant to that? If it isn't, it's kinda a footgun which shouldn't be published for general use.
That doesn't mean that this implementation doesn't have timing attacks, but the implementors claim they chose mechanisms which should be constant-time.
Earlier quoted context omitted.
> anecdotally, generating 2048-bit or larger RSA keys for me tends to be a lot slower than ed25519 That’s not really anecdotal. Generating an ed25519 key is barely more than generating a random 256-bit value. Generating an RSA key is significantly more work.
I did say my understanding was probably naive; I didn't know the details to be able to assert anything beyond my own observation!
Earlier quoted context omitted.
Actually, e.g. rustls added X25519Kyber768Draft00 support this year: https://news.ycombinator.com/item?id=41534500 /?q X25519Kyber768Draft00: https://www.google.com/search?q=X25519Kyber768Draft00
Kyber768 is the post-quantum algorithm in that example, not x25519.
> Someday there will probably be a TLS1.4/2.0 with PQ, and also FIPS-140 -4?
> Are there additional ways to implement NIST PQ finalist algos with openssl?
- open-quantum-safe/oqs-provider [implements mlkem512 through mlkem1024 and x25519_mlkem768]
Earlier quoted context omitted.
Rumors of Jump’s demise are greatly exaggerated. Check the torrent of firedancer talks at Solana Breakpoint literally next week and decide yourself. Folks have said jump is gonna die for 20+ years. They’ve been around 30ish…
Parent asked a specific question about the survival of Firedancer and winding down of the crypto arm though. No demise of Jump mentioned.
You can make the determination on your own, but there will be an obvious large showing of firedancer folks and some exciting updates for the project.
The firedancer team at one of the better HFT firms wrote an AVX512 optimized implementation of ed25519 and X25519 that’s significantly faster than OpenSSL. https://github.com/firedancer-io/firedancer/pull/716 Ditto for sha256: https://github.com/firedancer-io/firedancer/pull/778 And sha512: https://github.com/firedancer-io/firedancer/pull/760 If you’re an optimization nerd, this codebase is wild.
I see they learned clang’s dirty little secret over intrinsics viz. that in producing the IR it deviates (sometimes dramatically when AVX-512 is concerned) from the documented opcodes and the results are inevitably detrimental.
nb those abstractions do make sense when you can only afford to write a single implementation of the algorithm; then you're just talking about a high level programming language. But they frequently fail to achieve their goal when you're writing a second implementation for the sole purpose of being faster.