There Is No Diffie-Hellman but Elliptic Curve Diffie-Hellman • Hacker News Board

Re: There Is No Diffie-Hellman but Elliptic Curve Diffie-Hellman

#61

Post by aleph_minus_one » Wed, May 28, 2025, 7:54 PM UTC

newpavlov wrote: post #51

oleganza wrote: post #25

Earlier quoted context omitted.

When I learned crypto 5-10 years ago, it turned out that a lot of "building blocks" are mostly hacks. Looking back from 2020s we see that some of the standards that we use for the last 20-30 years can in principle be thrown out of the window (they can't for compatibility reasons, though) and replaced with much cleaner and more universal replacements. If we do not talk about modern exotic stuff (post-quantum crypto, z…

>Keccak for all of symmetric crypto: it is suited both for encryption, hashing, duplex transcripts for ZK protocols etc. Unfortunately, Keccak and sponge constructions in general are inherently sequential. Even with hardware acceleration it heavily restricts possible performance. For example, AES-CBC encryption is 4-8 times slower than AES-CTR on high-end CPUs with AES-NI available. VAES makes the difference even big…

> Unfortunately, Keccak and sponge constructions in general are inherently sequential.

Couldn't you simply using BLAKE3 instead? To my knowledge BLAKE3 exactly was designed to solve this "parallelism problem" by combining the "cryptographic ideas" of BLAKE2 with the binary tree structure of Bao (the latter was designed to make the hash construction easy to parallelize).

Re: There Is No Diffie-Hellman but Elliptic Curve Diffie-Hellman

#62

Post by thaumasiotes » Wed, May 28, 2025, 9:40 PM UTC

red_trumpet wrote: post #41

thaumasiotes wrote: post #19

Earlier quoted context omitted.

What would that help with? I know KaTeX supposedly lets you copy-and-paste the text, but that won't get you text that is fit for any purpose.

Better typography helps with reading. The same reason someone would complain if this was typed in Comic Sans. Also the images don't scale well, so if you look at this with a high resolution display, either the images are too small or not sharp.

Well, having gone and looked at the website, I'd have to agree that KaTeX would be an improvement, but not for reasons that relate to whether the math is rendered as an image.

Rather:

- The background of the math images is white, which doesn't match the background of the website;

- The baseline of the text in the images is not aligned with the baseline of the surrounding text.

I was imagining a more-competently-put-together website.

Re: There Is No Diffie-Hellman but Elliptic Curve Diffie-Hellman

#63

Post by rainsford » Wed, May 28, 2025, 9:50 PM UTC

newpavlov wrote: post #51

oleganza wrote: post #25

Earlier quoted context omitted.

When I learned crypto 5-10 years ago, it turned out that a lot of "building blocks" are mostly hacks. Looking back from 2020s we see that some of the standards that we use for the last 20-30 years can in principle be thrown out of the window (they can't for compatibility reasons, though) and replaced with much cleaner and more universal replacements. If we do not talk about modern exotic stuff (post-quantum crypto, z…

>Keccak for all of symmetric crypto: it is suited both for encryption, hashing, duplex transcripts for ZK protocols etc. Unfortunately, Keccak and sponge constructions in general are inherently sequential. Even with hardware acceleration it heavily restricts possible performance. For example, AES-CBC encryption is 4-8 times slower than AES-CTR on high-end CPUs with AES-NI available. VAES makes the difference even big…

How much does the lack of parallelization matter in practice though? Sure, AES-CTR can be parallelized, but the authentication function you're probably pairing it with likely can't. And in a lot of cases I'm aware of where encryption parallelism is important for performance (e.g. line-rate VPN encryption), you can achieve parallelism for the operation as a whole without achieving stream based parallelism. In the VPN example, even if you can't encrypt all the blocks in a single packet in parallel, you can probably achieve just as much parallelism speedup by encrypting multiple packets in parallel.

Re: There Is No Diffie-Hellman but Elliptic Curve Diffie-Hellman

#64

Post by nioj » Thu, May 29, 2025, 12:20 AM UTC

cmrx64 wrote: post #23

vitalnodo wrote: post #16

Just wondering — has anyone come across a course or resource that explores how cryptographic systems are built up from smaller building blocks? Like, using something like SageMath for algebraic structures, a prover like Lean to verify properties — to get a feel for how things actually fit together. There's something cool about trying to reimplement known standards just to understand them better (with the usual "don’t…

the types of arguments and proofs used in cryptography are notoriously difficult to mechanize, a little bit of lean isn’t going to go get anywhere close to stating a security property. eg CryptHOL needs a ton of infrastructure, and in still very limited: https://eprint.iacr.org/2017/753.pdf

There is also SSProve which has similar goal to CryptHOL:

https://dl.acm.org/doi/full/10.1145/3594735

https://github.com/SSProve/ssprove

Re: There Is No Diffie-Hellman but Elliptic Curve Diffie-Hellman

#65

Post by Tadpole9181 » Thu, May 29, 2025, 5:56 AM UTC

gary_0 wrote: post #60

AnotherGoodName wrote: post #57

Earlier quoted context omitted.

Just to add to the above for clarity a proof that key based encryption isn't reversible requires a proof of P!=NP which hasn't been done. That may surprise people but we have no proof of the robustness of the encryption we use. In fact it might not work! Consider a one time pad for really extreme security needs. One time pads do have a proof (see the work of Shannon).

Shor's algorithm suggests that a lot of encryption doesn't actually work, but of course it requires a quantum computer that hasn't yet been built, and may not be practical to build, so fingers crossed. At least there are quantum-resistant encryption algorithms, and OTPs are still provably secure like you say.

On "finger's crossed" - I think it's important to say that the majority of web traffic has switched over to PQC algorithms for key exchange that are not susceptible (thanks Cloudflare). We're not close to building a machine suitable for running Shor's in a practical sense, so even potential "store now, break later" attacks are now kinda pointless. Things like SSH keys are trivially revokable and often have enforced expirations, so they're not really a viable attack vector anyway.

The symmetric encryption used for the vast majority of actual encryption has always been safe. Grover's algorithm does not scale appropriately (exponential on key length) unlike Shor's and cannot be parallelized. Worst case, AES-128 becomes as week as AES-64. So we bump it to AES-256 and we're back at the same difficulty as before (impossible). There's a degree of confidence this will always hold true.

Re: There Is No Diffie-Hellman but Elliptic Curve Diffie-Hellman

#66

Post by vendiddy » Thu, May 29, 2025, 6:15 AM UTC

cvwright wrote: post #40

vitalnodo wrote: post #16

Just wondering — has anyone come across a course or resource that explores how cryptographic systems are built up from smaller building blocks? Like, using something like SageMath for algebraic structures, a prover like Lean to verify properties — to get a feel for how things actually fit together. There's something cool about trying to reimplement known standards just to understand them better (with the usual "don’t…

There are no proofs of the hardness of DDH or RSA etc. That’s why they’re called assumptions. OTOH if you want to win a Turing Award…

Can't someone learn this stuff with the assumption that certain functions are hard to invert?

Like assuming f(x) is hard, let us try to prove these other properties of security.

Re: There Is No Diffie-Hellman but Elliptic Curve Diffie-Hellman

#67

Post by tgma » Thu, May 29, 2025, 4:17 PM UTC

vendiddy wrote: post #66

cvwright wrote: post #40

Earlier quoted context omitted.

There are no proofs of the hardness of DDH or RSA etc. That’s why they’re called assumptions. OTOH if you want to win a Turing Award…

Can't someone learn this stuff with the assumption that certain functions are hard to invert? Like assuming f(x) is hard, let us try to prove these other properties of security.

What you described is pretty much exactly how modern provable cryptography field works today. Reduction to assumptions about certain primitives and constructing the boundaries of security given such assumptions.

E.g. "Assuming AES block cipher is a perfect pseudorandom function, prove AES-GCM construction is secure up to certain number of messages"