[HN Gopher] D(HE)at: A Practical DoS Attack on the Finite Field ...
       ___________________________________________________________________
        
       D(HE)at: A Practical DoS Attack on the Finite Field Diffie-Hellman
       Key Exchange
        
       Author : c0r0n3r
       Score  : 30 points
       Date   : 2024-03-07 12:00 UTC (11 hours ago)
        
 (HTM) web link (ieeexplore.ieee.org)
 (TXT) w3m dump (ieeexplore.ieee.org)
        
       | probablyrobots wrote:
       | The 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.
        
       | glitchc wrote:
       | Discussing 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.
        
         | Retr0id wrote:
         | This attack doesn't require MitM, though.
        
         | anonymous-panda wrote:
         | 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.
        
           | dboreham wrote:
           | 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.
        
           | tptacek wrote:
           | 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).
        
             | wolf550e wrote:
             | Looks like google won't: https://www.ssllabs.com/ssltest/an
             | alyze.html?d=www.google.co...
        
       | tptacek wrote:
       | Seems 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?
        
         | mike_d wrote:
         | This reads like a "I got funding but my original research
         | didn't pan out and I need to publish something."
        
       | thadt wrote:
       | This specifically (CPU exhaustion attack) is called out as a
       | rationale for why Wireguard implements cookie reply packets[1].
       | If a verified source is DOSing you with bad handshakes, maybe its
       | time for their IP to be put in timeout in an upstream routing
       | table.
       | 
       | [1] https://www.wireguard.com/protocol/#dos-mitigation
        
       ___________________________________________________________________
       (page generated 2024-03-07 23:01 UTC)