back to article A simple SSL tweak could protect you from GCHQ/NSA snooping

An obscure feature of SSL/TLS called Forward Secrecy may offer greater privacy, according to security experts who have begun promoting the technology in the wake of revelations about mass surveillance by the NSA and GCHQ. Every SSL connection begins with a handshake, during which the two parties in an encrypted message …

COMMENTS

This topic is closed for new posts.
  1. David Hicks
    Stop

    Was this news?

    I've written stuff to extract data from SSL/TLS streams after the fact, assuming access to the server's private key. Doesn't work with DH. DH/DHE/ECDHE are specifically disallowed in FIPS 140-2 and other federal/government standards for a reason - you can't audit them.

    So if you care about securing your SSL/TLS comms against future snooping then enable the cipher-suites that use these keygen mechanisms.

    Of course if it's anything important and you really don't want the government agencies to look, then you'll be needing to run your own certificate authority too (no, not just a self-signed server cert), in order to thwart MITM attacks. What, you thought the cert authorities wouldn't just issue any cert the government agencies feel like? LOL.

    1. JeevesMkII
      Holmes

      Re: Was this news?

      That's not how certificate issuance works. You generate they key and send them a certificate signing request with your public key parameters. The cert. auth. never knows your private key, for obvious reasons.

      1. Justicesays
        Unhappy

        Re: Was this news?

        But all you know is that this certificate for "www.mysite.com" was signed by Verisign.

        Verisign can sign any number of certificates for the same site for whatever private key they like, as you don't know it either.

        Sure, its fine for securing stuff when you control both ends of the connection (like a vpn back to your company) where you can keep track of the public key as well.

        Otherwise you'll have to use something else, like something that keeps track of public keys and tells you if they change. Then how do you know the change isn't normal? Go on the internet...Kind of chicken and egg there? Use a third party validator like Convergence (which uses the internet to check...dunno if they build in fixed public keys)?

        In any case, the public/private key mechanism breaks down when the adversary not only has access to your communications, but also controls the courier system, address book and your third party verification service you use to set up the exchange in the first place.

        1. Pet Peeve
          WTF?

          Re: Was this news?

          "In any case, the public/private key mechanism breaks down when the adversary not only has access to your communications, but also controls the courier system, address book and your third party verification service you use to set up the exchange in the first place".

          Bullfood. The only weaknesses in PKI are a) losing control of your private key, don't do that, or b) asking for someone's public key which you don't have yet. This is only done once and saved (until it expires or is revoked), for exactly this reason.

          IN ANY EVENT, PKI is not used for session key negotiation in SSL, it's used for authentication.

          1. Pet Peeve
            Big Brother

            Re: Was this news?

            Well, you do have one point. If the NSA does a man in the middle, and they have a way of creating certificates signed by a recognized root CA for the site you're connecting to, they can see everything going on. Of course, in that situation, they can fake each side of the DH (if effect wiring themselves into the conversation), and you're boned.

            Do the three letter agencies do that? I sincerely doubt it as a matter of routine. But I wouldn't be surprised if they had malware that plants false root CAs on a target's cert store, and can have your ISP route your traffic through servers they control if they want to eavesdrop. But it would be hard to do without leaving footprints that th target could find if they had any brains at all.

            1. John Deeb
              Boffin

              Re: Was this news?

              Pet Peeve: "Do the three letter agencies do that [man in the middle]?"

              The context here was the stored traffic and not the live flow. Therefore man in the middle would not be feasible unless the tap can also redirect (not split) specific traffic through their own infrastructure on request. But technically this would modify active routing tables: highly unlikely. The tap at the main exchange has to be passive. That said, there are other possibly access points up or downstream for block and insert which could help to achieve this if such target was to be selected.

            2. Fazal Majid

              Re: Was this news?

              If a tinpot dictatorship like Iran does this regularly (google "comodo iran" for more details), you can rest assured our benevolent voyeurs do so as well.

          2. David Hicks
            FAIL

            Re: Was this news?

            >> Bullfood. The only weaknesses in PKI are a) losing control of your private key, don't do that, or b) asking for someone's public key which you don't have yet.

            Bullshit.

            The weakness with the PUBLIC authority structure is you have to trust the public authorities, and sometimes you can't. You can request a key for www.example.com because you own it, but if any of the authorities trusted by your browser issue another certificate to someone else for www.example.com, then they are enabled to perform MITM attacks. Or if they allow a signing certificate then whoever gets that can sign a cert for any server they like, and MITM anything.

            >> IN ANY EVENT, PKI is not used for session key negotiation in SSL, it's used for authentication.

            Well, that rather depends on the cipher suite you use, which is rather the point of this article.

          3. Justicesays
            Thumb Down

            Re: Was this news?

            "Bullfood. The only weaknesses in PKI are a) losing control of your private key, don't do that, or b) asking for someone's public key which you don't have yet. This is only done once and saved (until it expires or is revoked), for exactly this reason.

            IN ANY EVENT, PKI is not used for session key negotiation in SSL, it's used for authentication."

            So, yeah, the weakness is when you ask for a public key, that's when the MITM attack works. In a standard internet situation you ask for the public key each time, you don't store it unless you use one of the secondary controls I detailed. Once the MITM attacker has pointed you at their server instead, using their public key, you can start up whatever encryption negotiation with them you want,. Turns out as they provided the session negotiation they can read the traffic, so whatever mechanism you use it doesn't help you against a live MITM attack.

      2. David Hicks
        FAIL

        @ JeevesMkII

        "That's not how certificate issuance works. You generate they key and send them a certificate signing request with your public key parameters. The cert. auth. never knows your private key, for obvious reasons."

        Hi again.

        I know exactly how certificate issuance works because I've done it. And I know very well that if the likes of Verisign issued a certificate to the NSA with the signing bit switched on then they could sign any certificate for any server they felt like and perform man-in-the-middle attacks against any system that had (for instance) verisign's root certificate installed. The certification authority never knows your private key because it's irrelevant to a MITM attack. You only need to get the client to accept that your cert is signed by a trusted root.

        I know this because I've written software to do this (successfully) and familiarised myself with the SSL and TLS RFCs. Perhaps you should do the same and investigate the role of the authorities in the chain of trust before you hold forth on issuance procedures.

      3. Steve I
        WTF?

        Re: Was this news?

        Great - another "Why is this news? (*sniff*) I've known this obscure technical fact for years. sure everyone knows it?"

        I'm just waiting for the El Reg article on how the convert-to-decimal instruction on the IBM Mainframe oddly has the usual order of source and destination operands reversed. then I can say "Why is this news? *sniff*. Doesn't everyone know IBM Assembler?". If this happens, please feel free to reply "No they don't and f#ck off".

  2. DavCrav Silver badge

    "In recent years, we've seen DHE fall out of fashion. Internet Explorer 9 and 10, for example, support DHE only in combination with obsolete DSA keys,"

    Well, given recent revelations, perhaps it was that the NSA didn't want DH as standard, and leaned on Microsoft.

    1. Pet Peeve
      FAIL

      That statement is a big pile of bullfood. DHE out of fashion? Internet Explorer having anything to do with establishing the connection? What the heck is this guy talking about?

  3. Pet Peeve
    Boffin

    This sounds bogus. Asymmetric crpyto is used for authentication (to verify the site you're going to isn't spoofed), but the session keys are negotiated by a Diffie-Hellman key exchange, which as far as I know has always been perfect forward security, since you can eavesdrop on the entire exchange and not learn a thing about what key was negotiated.

    Are there SSL modes that don't use DH? I didn't think so.

    1. Anonymous Coward
      Anonymous Coward

      Well

      There are ssl modes that don't use DH but they're not favoured. "openssl ciphers -v" will give you a list of ciphers in preference order and the top ones for both 0.9.8x (mac) and 1.0.1e (fedora) use DH.

      I can understand IE trading security for performance though...

      1. Pet Peeve
        Facepalm

        Re: Well

        IE has its own ssl implementation built into it? Really? That seems like a really, really bad idea.

        1. Henry Wertz 1 Gold badge

          Re: Well

          "IE has its own ssl implementation built into it? Really? That seems like a really, really bad idea."

          It sure is, but this is the Microsoft way. This really is one reason Microsoft has had so many security problems over the years -- the lack of code reuse where it makes sense. I mean, they'll fix some JPEG handling flaw -- in 5 different places in the code -- then find out they missed another 3, and that these other few locations have a *different* JPEG handler with different bugs.

          Of course, in the case of IE, they will not of course use OpenSSL... Microsoft probably (despite being required by EU decree to keep IE seperate from Windows) expects IE to have the definitive SSL implementation for Windows, and people wanting to use SSL to call the SSL support in IE.

          1. Bronek Kozicki Silver badge
            Holmes

            Re: Well

            Actually, it is not IE which implements cryptographic operations, it is core of the operating system (i.e. Windows). Although IE, like any other user program, gets to choose how to use this cryptography, and unlike any other user program, gets to influence the OS team what's available and how it's implemented.

      2. Anonymous Coward
        Anonymous Coward

        Re: Well

        >> There are ssl modes that don't use DH but they're not favoured.

        Actually they are, particularly by government agencies.

    2. Eugene Crosser
      Boffin

      Asymmetric crpyto is used for authentication (to verify the site you're going to isn't spoofed), but the session keys are negotiated by a Diffie-Hellman key exchange

      When you do PK authentication you can establish the session key "for free" as a side effect. I guess this is usually done because it somewhat simplifies the handshake.

      1. Pet Peeve
        Holmes

        It's NOT usually done. The most common SSL modes use DH for key exchange. I have no idea where this "out of fashion" thing comes from. DH is vital for forward security, that's why it was developed.

        1. Eugene Crosser

          Indeed, my Apache with default configuration handshakes with DHE. However, this article explains the performance problem with DH, and solution that is apparently adopted by Google now: they handshake with ECDHE at the moment.

  4. amanfromMars 1 Silver badge

    It is a lot more involved and complicated than you think or have not yet been told

    This feature has become a serious liability in the era of mass surveillance.

    Surely it be better used as added exciting features in these eras of mass surveillance …… SMARTR Mentoring and AIMonitoring.

    Sharing ESPecial Knowledge for the Way Out Into the Wild and Open.

    And that's NEUKlearer HyperRadioProActive IT Systems Testing for GCHQ Compatibility/SWIFT Responses.

    And you may like to consider that CyberSpace is long ago a Private Pirate Place and has its Super Space Travellers Exchanging Gifts of Luscious Awe Ware.

    Home Territory to the Nymph and Satyr, who are both pleasurably satisfying but insatiable. :-)

    To Control and Power Love …… Now that would be a Heavenly Opportunity with Perks not to be Denied to Love Power Controllers.

    The very nature of love ensures and guarantees it be so, and it is only natural and to be fully expected of intelligence which has passionate insatiable drivers in search of the Perfect KISS for Climactic Union with Others of the Species.

    And if you want to know what has happened there, El Reg, you can tell everyone and/or anyone who asks, a node was docked and locked to our servers.

  5. FordPrefect

    Good luck trying to secure your traffic against US government snooping. US companies supply most network kit, most pc's are running windows and US companies run most of the trusted root certificate authorities.

    1. Anonymous Coward
      Anonymous Coward

      US companies run most of the trusted root certificate authorities

      Yup - that's your starting point for security. Avoid like the plague.

    2. btrower

      The devil you know is still the devil

      Re: "US companies run most of the trusted root certificate authorities."

      Most of holders of root certificates are among the entities I trust the *least* to protect me.

  6. Anomalous Cowshed

    A couple of drops...

    1878: A couple of drops of this here snake oil will protect you against any illness, the IRS and bankruptcy, boy!

    1968: Just hold this crystal in your right hand, it will protect you against the FBI and bad karma, man!

    2013: All you need to do is implement this SSL handshake and it will protect your computer against any acronym which tries to collect your data, mate.

  7. Anonymous Coward
    Anonymous Coward

    Any expectation of privacy in today's communications on the Internet are gone. Governments have access to your emails, phone calls, bank records, travel itineraries, family history's, lists of your friends, what they do, where they go and what you talk about. Your phone and car carry GPS history of your travels. And that is what we KNOW about.

    The time to secure communications was twenty years ago. Instead, nothing was done and state sponsored keys, algorithms and protocols were introduced. Commerce laws were enacted to outlaw the schemes that would have guaranteed privacy and now here we are. Besides, they don't NEED to break your encryption when companies you trusted, ISP's and telecoms hand over the plain text regardless.

    The only thing we can do is revamp the entire standards we use on a daily basis. The cost would be exorbitantly expensive and in the end any "official" replacement will be just as flawed and easy to crack / track.

    Welcome to the world of secret laws and star chamber justice. Go ahead and vote for someone else next time. See how fast the system changes. Once governments get power, they seldom walk away from it.

    1. Gavin King

      Star Chamber

      You over malign the Star Chamber. In some ways its biggest problem was that it was efficient. Everything was done "on the papers", so that come judgement time, there could be a rapid number of judgements that seemed to be rather arbitrary, but were in fact reasonably well considered.

      I remember a historian looking through the cases within the last fifty years or so and coming to the conclusion that the decisions of the star chamber were not particularly unfair, considering the times. I forget which book it was in, alas.

      Secret laws on the other hand: not such a nice thing.

  8. Anonymous Coward
    Anonymous Coward

    So simple!

    That the Reg doesn't even tell us how to do it.

    1. Anonymous Coward
      Anonymous Coward

      Re: the Reg doesn't even tell us how to do it.

      Well I'm certainly still in the dark about how to tell whether my browser is/isnot likely to be trying to run sessions with DH rather than falling back to the less secure sort.

      Lets pick e.g. firefox: what does it usually try to do? while ssl'ing, can I check so see what sort of ssl is being used? can I get it to warn me about certain ssl schemes being used/demanded by the server? Perhaps there's a plugin that would help?

      I'm certainly no wiser about the user end, i.e what my browser is doing.

  9. Anonymous Coward
    Anonymous Coward

    willing participant

    "Although the use of Diffie-Hellman key exchange eliminates the main attack vector, there are other actions a powerful adversary could take," Ristic warns. "For example, they could convince the server operator to simply record all session keys."

    Well if the adversary was able to obtain the cooperation of the server operator, why wouldn't they simply have the server operator log the desired unencrypted info?

  10. ZanzibarRastapopulous

    Key exchange for dummies.

    Let me get this straight because I always just guessed at how SSL works and am obviously wrong...

    - Computer A contacts computer B sending A's public key.

    - B sends A a randomly generated session key encrypted using A's public key.

    - A decrypts key using it's private key and now both machines have the secret session key.

    - A and B communicate using the secret session key.

    - A and B disconnect.

    - A and B destroy the secret session key.

    - Future connections use a different randomly generated session key.

    How do you get the secret session key after the connection has terminated?

    1. phr0g
      Angel

      Re: Key exchange for dummies.

      http://www.theregister.co.uk/2013/06/03/quantum_boffins_get_spooky_with_time/

    2. Anonymous Coward
      Anonymous Coward

      Re: Key exchange for dummies.

      No, the MITM attack happens during the first exchange. If Computer A only THINKS it talks to B but it's in reality N(SA) who then in turn talks to B, A will never know that the comms was basically cleartext to N. For N to pretend it's B it needs a cert that the browser will accept during session setup, and it's there the support from root CAs comes i play. If they issue a cert that confirms a valid "B entity your session is compromised.

      You are right insofar that it's a lot harder post event, but all you need is a DNS tweak and a cert and you're in (the intercept) business. This is partly because the SSL cert was never meat to act as a site identifier, that's something that was dreamt up later.

      BTW, this is also why you should not have your DNS reg and management in the US.

    3. Tomato42
      Boffin

      Re: Key exchange for dummies.

      if you have access to private key (a search warrant, 15 minutes if work for a TLA and can say PATRIOT) you can do exactly the same the A computer does in step 3 even years after the original communication took place

      there's no need for esoteric software, even wireshark can do this

      but it's impossible to do if you use DH (either log based or EC based) since the key is never sent over the link and both server side and client side random variable used to derive the key is single use and not tied to certificate or private key in any way

    4. David Hicks
      Happy

      Re: Key exchange for dummies.

      >> B sends A a randomly generated session key encrypted using A's public key.

      >> How do you get the secret session key after the connection has terminated?

      'C' takes a length of pipe and a couple of hard men, retrieves A's private key and decrypts the session key message, therefore unlocking all the rest of the data with the session key.

      Diffie-Hellman gets around this by using clever maths to allow two sides of a conversation to derive the same key *without exchanging enough information over the wire to rebuild the key later*. It's a work of genius and I highly recommend reading about it on Wikipedia.

      1. This post has been deleted by its author

      2. Jamie Jones Silver badge

        Re: Key exchange for dummies.

        ">> B sends A a randomly generated session key encrypted using A's public key.

        >> How do you get the secret session key after the connection has terminated?

        'C' takes a length of pipe and a couple of hard men, retrieves A's private key and decrypts the session key message, therefore unlocking all the rest of the data with the session key."

        I'm probably going to make a fool of myself here, but I'll say it anyway :-)

        In the above, why doesn't "A" create a new private/public key for each session (well, not A-the-person, but A-the-software) -- never storing the private key on permanent store? Then there is no private key for "C"'s thugs to beat out of "A"

        1. ZanzibarRastapopulous

          Re: Key exchange for dummies.

          In the above, why doesn't "A" create a new private/public key for each session (well, not A-the-person, but A-the-software) -- never storing the private key on permanent store? Then there is no private key for "C"'s thugs to beat out of "A"

          Exactly what I was thinking, why are these keys kept beyond the life of the session?

          Also, the article refers to getting the key off the server, B in my example, however I never give B the private key, unless it means the session key, which should be deleted after the session ends.

          1. David Hicks
            Stop

            Re: Key exchange for dummies.

            >> Exactly what I was thinking, why are these keys kept beyond the life of the session?

            OK, so the RSA keys need to be kept because they are used for authenticating who you're talking to. Without them you're vulnerable to MITM attacks.

            >> Also, the article refers to getting the key off the server, B in my example, however I never give B the private key, unless it means the session key, which should be deleted after the session ends.

            I think the point is that the server may be forced by non-technological means to give up their private key. Or they may be hacked. Without (EC)DH(E) you could use this to decrypt any previous traffic dumps you happen to have of comms between that server and any clients.

            1. ZanzibarRastapopulous

              Re: Key exchange for dummies.

              OK, so the RSA keys need to be kept because they are used for authenticating who you're talking to. Without them you're vulnerable to MITM attacks.

              That's true for authenticated keys, but that should be done after an encrypted channel has been formed and over the encrypted channel. Otherwise you're revealing who is conversing in plain-text (the signatures themselves).

              Besides if we're talking web communication then the client (A) isn't verified. The login process is presumed to achieve that.

              I think the point is that the server may be forced by non-technological means to give up their private key.

              But in my example the session key isn't encrypted with B's key, it's encrypted with A's public key, and as A's key isn't verified it can be temporary. If A uses a permanent key then yes, A could be strong-armed, but A is the client.

              Actually, B doesn't need a public/private key at all in that example.

              I'm assuming A has a public/private key pair, and the session key is a randomly generated symmetric key.

              I'm sure there's a stack of crypto-geeks cringing at my inability to understand why this is an issue. If so, my apologies.

              1. David Hicks

                Re: Key exchange for dummies.

                "That's true for authenticated keys, but that should be done after an encrypted channel has been formed and over the encrypted channel. Otherwise you're revealing who is conversing in plain-text (the signatures themselves)."

                This is not how SSL works, nor is it a problem it tries to solve. It's perfectly obvious who is conversing because (over the public internet) you can see the endpoints anyway. And signed certificates will be passed to anyone that connects to the server, so it's pretty irrelevant to this domain (though probably not all domains) who gets to see it and we don't care if it's secret or not.

                But in my example the session key isn't encrypted with B's key, it's encrypted with A's public key, and as A's key isn't verified it can be temporary. If A uses a permanent key then yes, A could be strong-armed, but A is the client.

                I think I became confused over who A and B were. OK, lets flesh out your example a bit -

                The client is A and the server is B. It's not mentioned but we'll assume that RSA authentication is used to rule out MITM attacks (right?) at the start of the connection in the usual way. The Key pair used here will be Kb0 (private) and Kb1 (public) and Kb1 is signed. So now we know who is talking to who and we're left with the problem of establishing a session key in a way that cannot be decoded from a traffic dump afterwards.

                The 'pure' RSA method is for A to use Kb1 to encrypt a session key, Ks, and send it to B which decrypts using Kb0. If Kb0 is ever discovered then Ks can be recovered and the whole session can be decrypted.

                Your proposal is that the client generates a new Public/Private key pair (Ka0 and Ka1) and sends the public part (Ka1) to the server. The server uses this to encrypt a random session key Ks, sends it back to the client which decrypts using the private key (Ka0), so now encrypted comms can commence. Ka0 and Ka1 are immediately erased so Ks can't be decrypted in future. Correct?

                The method used in the article and in practice is to use DH, send some parameters over the wire, and come up with Ks in a way that never exchanges Ks or enough information to derive Ks over the wire.

                I can see no reason your solution wouldn't work (this doesn't mean it's perfect, there may be good reasons it isn't, I'm an amateur crypto-geek not a pro). It does send Ks over the wire so if RSA factorisation ever gets 'solved' you may have the same issue. This seems unlikely, though you'd want to use a long key to be sure.

                The reason you might not deploy it in practice is that generating RSA key pair Ka0 and Ka1 is a non-trivial computational expense for the client and can take a number of seconds even on a relatively modern machine, greatly extending the TLS handshake period. Encrypting with them is also somewhat expensive for the server. DH is comparatively trivial and fast for both sides.

                So AFAICT there's no cringeing needed, your scheme would work but is slow. AFAICT.

                1. ZanzibarRastapopulous

                  Re: Key exchange for dummies.

                  Your proposal is that the client generates a new Public/Private key pair (Ka0 and Ka1) and sends the public part (Ka1) to the server.

                  Yes, although I wasn't going to worry too much about destroying the client's private key.

                  I see the problem here is simply that the key chosen, is long term, and the server's key rather than the client's.

                  The advantage of using a client key is that you increase the number of keys in the system.

                  1. David Hicks

                    Re: Key exchange for dummies.

                    OK so with a non-ephemeral client key pair, you would make life a lot more tricky for a potential eavesdropper because they'd have to obtain the client private key Ka0 for each client they were interested in. However if Ka0 can be obtained then potentially all the Ks used by that client to encrypt comms to multiple servers could be exposed. By changing the client key pair every so often (daily?) you could mitigate this risk somewhat.

                    It does rely on client security rather than server security, and where you put your trust there probably depends on your politics.

                    That said, I think the DH kex scheme is superior because there is no key information retained between connections, and Ks is never broadcast at all.

                    1. ZanzibarRastapopulous

                      Re: Key exchange for dummies.

                      That said, I think the DH kex scheme is superior because there is no key information retained between connections, and Ks is never broadcast at all.

                      Yes, except in effect a public/private key pair is created at each connection. Which we feel is computationally expensive, and if it's not lends itself to being brute forced.

                      If you look at wikipedia's explanation of DH (it has a useful analogy: http://en.wikipedia.org/wiki/File:Diffie-Hellman_Key_Exchange.svg) then you can view the colours passed to the other person as being public keys and Alice and Bob's secret colours as private keys and you have the same problem don't you? All you need is one of the "secret colours" and you're in.

                      So it only works if the secret is regularly changed doesn't it? If one of the secrets is stored then it too will break in exactly the same way. Which is fine where the key generation is computationally light.

                      1. David Hicks

                        Re: Key exchange for dummies.

                        >> Yes, except in effect a public/private key pair is created at each connection.

                        Kind of. It's key material rather than actual keys.

                        >>Which we feel is computationally expensive, and if it's not lends itself to being brute forced.

                        This is not true of DH, no, it's computationally very cheap and is not really prone to brute force. RSA keys are computationally expensive to create because (IIRC) of the fact they are very long co-primes in a modular number space. If you want to understand what that means, I recommend a crypto mathematics course. I'm a bit shaky on it myself.

                        >> All you need is one of the "secret colours" and you're in

                        >> So it only works if the secret is regularly changed doesn't it?

                        Yup, and in the case of DHE (I'm unsure with plain DH) the 'secret' (or its parameters) are changed and then discarded with every connection. As discussed, with RSA this isn't really practical due to the computational cost.

        2. David Hicks
          Happy

          Re: Key exchange for dummies.

          >> In the above, why doesn't "A" create a new private/public key for each session (well, not A-the-person, but A-the-software) -- never storing the private key on permanent store? Then there is no private key for "C"'s thugs to beat out of "A"

          OK, so the public/private key pair are used for authentication. We don't generate new ones each time, as a rule, because A's public key needs to be accepted as secure and trusted by B. This can be achieved by sharing it in some secure way ahead of time or by having a mutually trusted authority sign it. If you don't do this B can't be sure they are talking to A, B might be talking to M who is running a man-in-the-middle attack.

          You could certainly reduce the lifetime of private keys and securely delete them after a while, that might be good practice, but it's not really practical to make a new one each connection.

          And this is basically what Diffie Hellman is for, to make session keys that can't ever be regenerated when the connection is dead, so C has no recourse to pipe and gorillas :)

  11. PyLETS
    Boffin

    If they have the private key they can MITM diffie hellman too

    Perfect forward secrecy using DH key exchange and throwing the session key away afterwards can only be authenticated to stop Eve who works for the NSA doing a MITM attack with both Alice and Bob (who think they have a direct connection) using either RSA or a pre-shared secret for authentication. If Eve has the secrets involved she can do a MITM here and subvert the session. Perfect forward secrecy only works in respect of session which occurred previously to Eve obtaining the long-term secrets used by Alice and Bob to authenticate each other. There may also be some advantage to using Diffie Hellman keys if Eve wants to do some fishing after the event using her vast session recording database and isn't actively monitoring Alice and Bob's communications with each other in real time.

    1. David Hicks

      Re: If they have the private key they can MITM diffie hellman too

      Yes, the attack requires active participation in the data stream, whereas without Diffie Hellman you can decode it at your leisure later.

  12. Anonymous Coward
    Anonymous Coward

    How many of the acres of computers the NSA have...

    ... do you all think it'll take for the NSA to brute force the key exchange session?

    In fact why do you think they have so many acres of compute power?

    The only safe way to encrypt something the NSA can't break, is to use your very own private encryption algorithm, and most of us aren't capable of producing one of them.

    Just accept that the NSA can read anything and everything you put out here, and adapt to those circumstances.

    1. Anonymous Coward
      Anonymous Coward

      Re: How many of the acres of computers the NSA have...

      Maybe they just have those computer farms to play Pong. I've worked with people that were so bad at coding they managed to create webpages that could bring a Sun E10k to its knees with just 200 users :)

    2. Tomato42
      FAIL

      Re: How many of the acres of computers the NSA have...

      protip: both authors of AES have never worked for NSA, in fact, they live and work in europe

      and so is the case for the few dozen of other cryptographers that tried to break AES during the competition

      to believe that there are backdoors in AES is bigger tinfoil hattery than the "we never went to moon" bollocks

      also, using "crypto of your own design", that's exactly what you *don't* do, and it's written in every crypto textbook on first page.

      1. Anonymous Coward
        FAIL

        Re: How many of the acres of computers the NSA have...

        protip: both authors of AES have never worked for NSA, in fact, they live and work in europe

        and so is the case for the few dozen of other cryptographers that tried to break AES during the competition

        to believe that there are backdoors in AES is bigger tinfoil hattery than the "we never went to moon" bollocks

        "backdoors"? Where did I mention "backdoors"?

        protip: WIth enough compute power EVERY encryption method can be brute forced.

        also, using "crypto of your own design", that's exactly what you *don't* do, and it's written in every crypto textbook on first page.

        Which I believe was precisely the point I was making.

        1. David Hicks
          FAIL

          Re: How many of the acres of computers the NSA have...

          >> protip: WIth enough compute power EVERY encryption method can be brute forced.

          Do the math. AES-256, if you check 1 billion keys per second, would take in the region of 1.5 times 10 to the power 60 years to brute force.

          For comparison, the earth will likely be devoid of life (due to the sun getting hotter) in around 10 to the power 8 years.

          Hell, let's say we can check a key every clock cycle in a modern 4 GHz machine, you're still looking at 9 time 10 to the 59. If everyone on earth had a quad core version of that, dedicated only to the problem of decoding an AES-256 message, it would STILL take almost 10 to the power 40 (that's 10 with 40 zeroes after) times the expected lifetime of the planet to decode.

          1. Anonymous Coward
            Anonymous Coward

            Re: How many of the acres of computers the NSA have...

            Do the math. AES-256, if you check 1 billion keys per second, would take in the region of 1.5 times 10 to the power 60 years to brute force.

            For comparison, the earth will likely be devoid of life (due to the sun getting hotter) in around 10 to the power 8 years.

            Hell, let's say we can check a key every clock cycle in a modern 4 GHz machine, you're still looking at 9 time 10 to the 59. If everyone on earth had a quad core version of that, dedicated only to the problem of decoding an AES-256 message, it would STILL take almost 10 to the power 40 (that's 10 with 40 zeroes after) times the expected lifetime of the planet to decode.

            Which only overlooks two simple known facts.

            1). The NSA are retaining encrypted data for breaking.

            (If they can't break it (and know they can't break it, as per your analysis) why waste resources retaining it?)

            2). They ARE using all that compute power they have for something.

            (And here we are back at my original point)

            1. David Hicks
              Stop

              Re: How many of the acres of computers the NSA have...

              >> 1). The NSA are retaining encrypted data for breaking.

              >> (If they can't break it (and know they can't break it, as per your analysis) why waste resources retaining it?)

              It's possible that quantum computing may render much of our current crypto irrelevant in the future.

              It's possible they may be able to get keys by physical or legal coercion or just by hacking.

              It's not possible to brute force AES 256 in a reasonable amount of time, even with their resources.

              >> 2). They ARE using all that compute power they have for something.

              Well, it's not brute-forcing AES-256 keys because that's a waste of time and energy. A lot of crypto that's actually in use is far less secure than AES, or is used in constructions which leak information and may be vulnerable to various attacks, perhaps their attentions are on that.

              >> (And here we are back at my original point)

              Which doesn't really hold up to scrutiny. Private encryption schemes are almost always flawed, and if you do it right you can encrypt data in a way that holds up to all known attackers. Of course it's possible the eggheads at the NSA are ahead of the game here and have got attacks on AES the rest of the world don't know about, but that's speculative.

              1. Anonymous Coward
                Anonymous Coward

                Re: How many of the acres of computers the NSA have...

                Well, it's not brute-forcing AES-256 keys because that's a waste of time and energy. A lot of crypto that's actually in use is far less secure than AES, or is used in constructions which leak information and may be vulnerable to various attacks, perhaps their attentions are on that.

                In your opinion it's not brute forcing AES, because you are sure AES cannot be brute forced. You can't actually tell us all definitively that the NSA don't have a way of doing it, but you believe they don't, because if they did they'd be shouting about it from the rooftops (for the glory of being able to do it (this being the same organisation who are behaving so secretively, and are MASSIVELY upset that you even know they're capturing the data in the first place, but we'll just ignore the contradiction about how they can be upset about you just knowing they're capturing data, but that they'd definietly want you to know they could break AES)).

                Personally I'll go with assuming they have a way of breaking it, all the evidence suggests it's the only safe assumption, no matter what the theories about how much time it would take to brute force it say. Simply because if they couldn't brute force it (and they knew they coudn't brute force it, they wouldn't piss away time and resources capturing it for analysis). I think it's a quite well established precedent that intelligent people don't piss away time doing something, that they know they cannot do (according to you and the theories about AES) over and over again to no end.

                Which doesn't really hold up to scrutiny.

                Which was entirely the point I was making, you really do seem to have missed the point of the statement I made about using a private encryption algorithm. I've repeated more than once already that I wasn't putting the suggestion forward as any kind of serious suggestion, as shown by my original statement pointing out that "most of us aren't capable of that".

                1. David Hicks

                  Re: How many of the acres of computers the NSA have...

                  >> In your opinion it's not brute forcing AES, because you are sure AES cannot be brute forced.

                  It can't. See calculation.

                  >> You can't actually tell us all definitively that the NSA don't have a way of doing it

                  Then it wouldn't be brute force.

                  >> Personally I'll go with assuming they have a way of breaking it

                  Good for you.

                  >> Which was entirely the point I was making...

                  You said a bunch of things about brute forcing key exchange (which would be DHE, and is another very hard crypto challenge to try and break), you said something about a private encryption algo that was flat out wrong, and now you're speculating that the NSA have a way of breaking all known crypto.

                  Basically all you've got is "I think the NSA is really clever".

                  1. Anonymous Coward
                    Anonymous Coward

                    Re: How many of the acres of computers the NSA have...

                    Basically all you've got is "I think the NSA is really clever".

                    And for some reason you think I have some interest in attempting to discuss it with someone like yourself who has more than once now completely ignored the fact that I have pointed out that my initial statement about the use of private algorithms was NOT that anyone should attempt to use them.

                    You've obviously got some kind of mental problem which refuses to even acknowledge that the points you keep chanting over and over again, aren't facts in anything otyher than your own head. Do please feel free to keep your disorder to yourself, and stop repeatedly claiming over and over again that I have said something which I haven't said.

          2. Anonymous Coward
            Anonymous Coward

            Re: How many of the acres of computers the NSA have...

            "If everyone on earth had a quad core version of that, dedicated only to the problem of decoding an AES-256 message, it would STILL take almost 10 to the power 40 (that's 10 with 40 zeroes after) times the expected lifetime of the planet to decode."

            And moreover, the earth would become uninhabitable due to overheating MUCH sooner.

    3. PyLETS
      Boffin

      Re: How many of the acres of computers the NSA have...

      "In fact why do you think they have so many acres of compute power?"

      Because very many of their targets are careless and use weak passwords or outdated standards like WEP and because the NSA has very many surveillance targets at any one time I would deduce. A possibility is that the NSA have discovered unpublished solutions to how to factor products of 2 very large primes other people don't know about or have a similarly unpublished solution to the discrete logarithm problem needed to crack RSA or Diffie Hellman even with acres of compute power. But they'd have to give whoever knows these secrets better incentive to keep these secrets than could be obtained through publication of this knowledge - see below.

      "The only safe way to encrypt something the NSA can't break, is to use your very own private encryption algorithm, and most of us aren't capable of producing one of them."

      Most such algorithms will prove remarkably easy for the NSA to break, because they won't benefit from expert peer review, as such algorithms have proved breakable almost invariably in the past. The best algorithms are the ones where there is a large enough prize for breaking them, and objective knowledge exists that many highly expert cryptanalysts have spent years unsuccessfully trying to break them with no break having been published. Do you think a security academic like me wouldn't love to be able to make my currently local reputation go international by knowing and publishing how to factorise the product of 2 very large primes or solve the discrete logarithm problem in a reasonable period of time on any feasible collection of compute power ? As to breaking home made algorithms, that's a first year's undergraduate exercise for students of cryptanalysis.

      1. Anonymous Coward
        Anonymous Coward

        Re: How many of the acres of computers the NSA have...

        As to breaking home made algorithms, that's a first year's undergraduate exercise for students of cryptanalysis.

        I did think everyone reading here would easily see I wasn't actually suggesting this was in any way viable, by stating that "most of us aren't capable of that".

  13. Anonymous Coward
    Boffin

    Tor Browser Bundle

    Tor Browser Bundle works pretty well. It's slower than normal browsing, but if all you are doing is reading news sites or something simple, it will do the job.

  14. Charles Manning
    WTF?

    Why can't servers change their keys frequently?

    The bit I don't understand is that hoarding data for future decryption assumes that the server never changes its keys and thus, once the key is obtained, all the history can be read.

    Why can't the server just set up new keys every hour, minute, second, session or whatever? That would mean the hoarded data would surely be useless before the last key change.

    I don't know enough about this, hence the question. Perhaps someone knowledgable can explain....

    1. Pet Peeve
      Headmaster

      Re: Why can't servers change their keys frequently?

      They do. Every browser session has its own key, and if you're using the proper encryption method (any with KX=DH) the session key is never in the data stream, and can't be extracted by simply listening to both ends of the conversation - an attacker would have to actively man-in-the-middle, which is nontrivial.

      Every server I've looked at always has the DH methods first, so DH isn't out of favor anywhere sane (inside the internals of IE isn't considered sane). The only way to get a conversation to use RSA for key exchange (which wraps the session key in a packet encrypted by the server's private key, which is NOT perfect forward) would be to actively mess with the protocol handshake, which is also nontrivial.

      I don't see that happening except for a very motivated eavesdropper, and the risks of detection would be very high if the people being snooped on are paying any attention at all. SSL is going to continue to be an annoyance for the three-letter agencies as it is currently used, and DH will be disabled over the cold dead hands of most netizens.

      The article has the basic idea right (don't be an idiot and use RSA for key exchange), but it's not very well written.

  15. Anonymous Coward
    Anonymous Coward

    No matter what you do

    Always remember to sign off all email/web correspondence with a friendly acknowledgement to the NSA and GCHQ bods.

    They appreciate the love.

  16. Anonymous Coward
    Anonymous Coward

    Getting up to speed

    Here is an article from Netcraft from yesterday with lots of technical detail on PFS

    http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html

    And, here is an introductory article on the subject from a few days ago

    http://blogs.computerworld.com/encryption/22366/can-nsa-see-through-encrypted-web-pages-maybe-so

  17. samaiorca
    Pint

    XKCD Speaks to the Truth of the Matter

    I think we should all just take a gander at the well-published XKCD toon below and drink in the truth.

    https://xkcd.com/538/

    http://www.theregister.co.uk/Design/graphics/icons/comment/pint_32.png

  18. Anonymous Coward
    Anonymous Coward

    RE. Re. Acres of computers

    I propose that the unit of NSA or other computer acreage be called the "Obamanation".

    :-)

    But the most secure method is a onetime key stored in volatile memory at both ends and deleted bytewise as the messages are sent.

    1. Steve I
      WTF?

      Re: RE. Re. Acres of computers

      "But the most secure method is a onetime key stored in volatile memory at both ends and deleted bytewise as the messages are sent."

      Wouldn't you have to post each other the keys.

  19. Anonymous Coward
    Anonymous Coward

    I suggest...

    ... a simple substitution code (or would it be a cipher?) would suffice. If the terrorists used the words 'holiday' for 'Jihad' and 'sister' for 'b0mb'...

    I haven't gone so far as to think this through (this is The Reg, after all) but I think this would work:

    "Hi Tariq. Fancy going on *holiday* (wink) to the Great Sat... I mean, America?"

    "Sure thing Iqbal. I'll bring your *sister* (wink, wink) and she can blow everyone."

  20. MarkJ
    Black Helicopters

    Fairly obviously, the NSA aren't trying to brute force AES because it's inefficient. A keen student of history will note that Station X didn't try to brute force either Enigma or Lorenz, their methods were much more efficient.

    The whole thing is irrelevant if you are tapping the server side backhaul as that won't be encrypted.

  21. Scurvy
    Devil

    I think the author and experts....

    I think the author and "experts" quoted in the article should know the difference between DH and DHE.....and stop using the terms interchangeably. They offer *very* different levels of session key security.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2020