back to article Big data busts crypto: 'Sweet32' captures collisions in old ciphers

Researchers with France's INRIA are warning that 64-bit ciphers – which endure in TLS configurations and OpenVPN – need to go for the walk behind the shed. The research institute's Karthikeyan Bhargavan and Gaëtan Leurent have demonstrated that a man-in-the-middle on a long-lived encrypted session can gather enough data for a …

  1. Pascal Monett Silver badge

    How is that counted ?

    "2,000 requests per second in a single TLS connection. In our experiment, we were lucky to detect the first collision after only 25 minutes (220.1 requests)"

    2,000 requests per second is 120,000 per minute, meaning 3 million in 25 minutes.

    Could someone explain what 220.1 requests is supposed to be ?

    Because if they managed to get their collision in only 220 requests, or even 220 100 requests, then this thing is more dangerous than they say.

    1. Richard 26

      Optional

      Could someone explain what 220.1 requests is supposed to be ?

      2 ^ 20.1

      1. Pascal Monett Silver badge

        By my calculator that gives 1,123,835.93.

        Still not comprehensible.

        1. BJC

          Yep, there's a transcription error from the original article and 2^20.1 got changed to "200.1" and 2^36.6 got changed to "236.6".

          You are correct that 2^20.1 (1123835) would still be too low at 2000 requests per second for 25 minutes (3000000) but the original article did say "up to" 200 requests per second. I don't see anything to note whether 2000 requests per second could be sustained.

          It would seem to be something that might have been better clarified in the original article and definitely better transcribed by The Reg.

  2. frank ly Silver badge

    "Decrypt the login cookie."

    So, they get the login cookie for the malicious site that they control, after it's had lots of cyber chat with another site that they control. This is about the connection and login to their malicious site. I don't understand how that helps them to break the encryption of the user's VPN link, because I always assumed that the VPN was 'transparent' and its encryption was between the user and the end point operator (who must be trusted).

    1. Roq D. Kasba

      Re: "Decrypt the login cookie."

      I think it's similar to the Enigma break, the end sites are about creating enough repeated cleartext that observing the encrypted traffic yields some clues.

  3. Voland's right hand Silver badge

    a majority of OpenVPN connections

    Not so sure about that, mine have been AES ever since via released AES acceleration (and long after moving off via hardware). Most sites I know have gone AES long ago too.

    1. Preston Munchensonton

      Re: a majority of OpenVPN connections

      Agreed. I haven't used a 64-bit cipher in a VPN configuration since 2006.

      1. Lee D Silver badge

        Re: a majority of OpenVPN connections

        It's not inconceivable, however, that there are a lot of places with VPN installed a long time ago that haven't ever been reconfigured ("because it works") or upgraded.

        But then, the problem is that, rather than anything to do with a weakness in the ciphers used.

    2. Anonymous Coward
      Anonymous Coward

      Re: a majority of OpenVPN connections

      One of our customers last week, complaining about an error they were getting in their logs

      "well the old VPNs worked so why don't we go back to using DES?".

      (Old VPNS used 3DES, new VPNS are using AES and connecting just fine from our end, the error seems to be an IP routing error rather than encryption algorithm problem. Oh, and it's re-keying every hour)

      Anon to protect the guilty.

  4. Ken Hagan Gold badge

    How does it scale?

    The half-terabyte of raw data looks like a very unlikely pre-requisite. The average punter would have to max out their allowance for several months to exchange that much. Is the attack still feasible for (say) 100 times less raw data, which would seem to me to be a more reasonable amount to pull over in a single session. (Even that, of course, is 100 times more data than might appear in a truly interesting SSL session, such as a visit to a bank.)

    Or am I thinking of the wrong target here?

  5. steamnut

    I'm safe, I'm in the UK...

    If 785 GB is required then I'm safe and they need to be very patient.

    With a rural broadband connection it would take many weeks to get enough data from my link.

    As I reboot all my systems routinely at midnight then I guess the connection would be broken anyway.

    1. Doctor_Wibble
      Devil

      Re: I'm safe, I'm in the UK...

      Not just the monumental patience required, 2000 requests per second (even split across 'a few dozen') on top of everything else would definitely get noticed, even the crappiest ad scripts don't dare to dream of burning that much CPU/bandwidth. On the other hand this may well turn out to be their true purpose, with banners just being a handy sideline.

      Also, if your HTTP connection is open for long enough for 785GB then security isn't your problem, it's chafing, blisters and RSI...

  6. Anonymous Coward
    Anonymous Coward

    It's not heartbleed is it...

    ... not saying it shouldn't be obsoleted but it's not the issue I thought it'd be.

  7. Crazy Operations Guy Silver badge

    " set up your client to force frequent re-keying "

    If you design a client for an encrypted connection that doesn't re-key for 750 GB, you should have your birth certificate revoked...

    At 785 GB and a 64-bit key, that would be a payload-to-key use factor of 13,170,114,560. Any reasonable security engineer would expect their encryption to be broken at a hundredth of that...

  8. G.Y.

    112

    NIST retired 80-bit crypto 12/31/2010, said 112 is the minimum

    1. Anonymous Coward
      Anonymous Coward

      Re: 112

      This is block size not key size. Blowfish can have pretty big keys but operates on 64-bit blocks. 3DES is just DES (64-bit block; 56-bit key) run 3 times (usually with different keys each time).

  9. John Smith 19 Gold badge
    Unhappy

    So who are the biggest users of VPN's?

    People wanting remote access to "stuff."

    And the people most likely to be running short code length connections?

    Large businesses who got it running a long time ago and don't want to fix what's not broken.

    Yes, I think quite a lot of people should be worrying.

  10. Anonymous Coward
    Anonymous Coward

    HTTPS shouldn't be an issue to fix, but OpenVPN gets the encryption mode defined at both ends, and both must match. Unlike HTTPS, you can't define several ciphers and just have the other end pick one.

    However, in the settings there's this:

    --reneg-pkts n

    Renegotiate data channel key after n packets sent and received (disabled by default).

    --reneg-sec n

    Renegotiate data channel key after n seconds (default=3600).

    When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour.

    Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set --reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds.

    The solution is to increase --reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side.

    I would advise that if people are unable to migrate from Blowfish in their OpenVPN configurations, they make use of these two settings to at least ensure the keys are re-negotiated in time. The default of 1 hour sounds safe unless you have very busy VPN links. --reneg-pkts would make doubly sure that the keys are negotiated often enough to make this attack nearly impossible unless the attackers were very lucky indeed.

    New installations should probably look at other ciphers, I tend to stick to the AES ciphers. (See openvpn --show-ciphers for a list)

  11. a_yank_lurker Silver badge

    Volume of data

    To break a code one needs enough data to give clues to the key. This has always been true. The only difference between now and the Enigma machines is the amount of data needed.

    Encryption will never be perfect and will be broken with enough time and effort. It just has to be good enough so the plain text is useless one obtained.

  12. Mage Silver badge

    Need bigger ...

    With more data capture and maybe quantum cell assisted computing, if you are changing, then change to biggest key and best cipher available.

  13. druck Silver badge

    Change keys

    Just make sure you negotiate a new session key after transferring significantly less than 2^64 bytes of data (say 2^30 bits).

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019