D(HE)at: A Practical DoS Attack on the Finite Field Diffie–Hellman Key Exchange
1–10 of 14 posts
Re: D(HE)at: A Practical DoS Attack on the Finite Field Diffie–Hellman Key Exchange
#2The linked article really beats around the bush before describing the attack. This link is a bit better:
https://dheatattack.gitlab.io/dheater/
It honestly doesn't seem that impactful to me.
Re: D(HE)at: A Practical DoS Attack on the Finite Field Diffie–Hellman Key Exchange
#3Discussing cryptographic solutions to denial of service attacks always seem a tad disingenuous. In the MITM model, the attacker is in full control of the communications channel, and can always replace, corrupt or deny packets to either recipient. No amount/quality/degree of cryptography can change this possibility.
Re: D(HE)at: A Practical DoS Attack on the Finite Field Diffie–Hellman Key Exchange
#4Discussing cryptographic solutions to denial of service attacks always seem a tad disingenuous. In the MITM model, the attacker is in full control of the communications channel, and can always replace, corrupt or deny packets to either recipient. No amount/quality/degree of cryptography can change this possibility.
This attack doesn't require MitM, though.
Re: D(HE)at: A Practical DoS Attack on the Finite Field Diffie–Hellman Key Exchange
#5Discussing cryptographic solutions to denial of service attacks always seem a tad disingenuous. In the MITM model, the attacker is in full control of the communications channel, and can always replace, corrupt or deny packets to either recipient. No amount/quality/degree of cryptography can change this possibility.
You’re misunderstanding the DOS attack I think. This is a DOS on the server itself and can prevent all other clients from connecting or the server from doing any useful work as its time is spent computing keys instead of anything useful. It doesn’t require any MITM proxy to be installed. Basically imagine a client could connect to a random Google server and take it down.
Re: D(HE)at: A Practical DoS Attack on the Finite Field Diffie–Hellman Key Exchange
#6Discussing cryptographic solutions to denial of service attacks always seem a tad disingenuous. In the MITM model, the attacker is in full control of the communications channel, and can always replace, corrupt or deny packets to either recipient. No amount/quality/degree of cryptography can change this possibility.
You’re misunderstanding the DOS attack I think. This is a DOS on the server itself and can prevent all other clients from connecting or the server from doing any useful work as its time is spent computing keys instead of anything useful. It doesn’t require any MITM proxy to be installed. Basically imagine a client could connect to a random Google server and take it down.
Yes but this is nothing to do with cryptography per se. Most servers can be taken down by a client that finds some expensive operation it can get executed, then sends a bunch of same. The solution implies a generic per-client or per-request resource limit mechanism (which in my experience some systems have, but most do not). This is probably the only good thing about "serverless"/lambda type solutions.
Re: D(HE)at: A Practical DoS Attack on the Finite Field Diffie–Hellman Key Exchange
#7Seems pretty boring. It's an unbalanced computation issue: the server sends B=g^b to the client, expecting the client to generate and send A=g^a. Instead, the client sends a random A, "proving no work" so to speak. Repeat. I think that's the whole attack?
Re: D(HE)at: A Practical DoS Attack on the Finite Field Diffie–Hellman Key Exchange
#8Discussing cryptographic solutions to denial of service attacks always seem a tad disingenuous. In the MITM model, the attacker is in full control of the communications channel, and can always replace, corrupt or deny packets to either recipient. No amount/quality/degree of cryptography can change this possibility.
You’re misunderstanding the DOS attack I think. This is a DOS on the server itself and can prevent all other clients from connecting or the server from doing any useful work as its time is spent computing keys instead of anything useful. It doesn’t require any MITM proxy to be installed. Basically imagine a client could connect to a random Google server and take it down.
Will Google even do a straight FFDH TLS handshake? I tried with s_client and couldn't find a cipher string that would work (starting by taking the default and just chopping all the non-DH strings out).
Re: D(HE)at: A Practical DoS Attack on the Finite Field Diffie–Hellman Key Exchange
#9Seems pretty boring. It's an unbalanced computation issue: the server sends B=g^b to the client, expecting the client to generate and send A=g^a. Instead, the client sends a random A, "proving no work" so to speak. Repeat. I think that's the whole attack?
This reads like a "I got funding but my original research didn't pan out and I need to publish something."
Re: D(HE)at: A Practical DoS Attack on the Finite Field Diffie–Hellman Key Exchange
#10Earlier quoted context omitted.
You’re misunderstanding the DOS attack I think. This is a DOS on the server itself and can prevent all other clients from connecting or the server from doing any useful work as its time is spent computing keys instead of anything useful. It doesn’t require any MITM proxy to be installed. Basically imagine a client could connect to a random Google server and take it down.
Will Google even do a straight FFDH TLS handshake? I tried with s_client and couldn't find a cipher string that would work (starting by taking the default and just chopping all the non-DH strings out).
Looks like google won't: https://www.ssllabs.com/ssltest/analyze.html?d=www.google.co...