Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Encryption Google

Google Starts Upgrading Its SSL Certificates To 2048-bit Keys 118

Posted by Soulskill from the go-big-or-go-home dept.
An anonymous reader writes "Google today announced it has already started upgrading all of its SSL certificates to 2048-bit keys. The goal is to beef up the encryption on the connections made to its services. Google says the upgrade, which includes the root certificate that the company uses to sign all of its SSL certificates, will be completed 'in the next few months.' Previously, however, Google was more specific and said it was aiming to finish the process by the end of 2013."
This discussion has been archived. No new comments can be posted.

Google Starts Upgrading Its SSL Certificates To 2048-bit Keys More

Google Starts Upgrading Its SSL Certificates To 2048-bit Keys

Comments Filter:

  • Completely useless... (Score:3, Informative)

    by Anonymous Coward on Tuesday July 30, 2013 @05:25PM (#44428685)

    If the NSA has the master key...

    • Re: (Score:1)

      by Anonymous Coward

      I'm going to be an iconoclast here. If the NSA had a root key, I would actually go as far as to trust it. So far, except for one assclown that had access to too much, the NSA hasn't had any real failures (unlike Diginotar or other CAs), nor hacks (like Comodo.)

      I'd trust the NSA's root key in an instant, provided they actually had a standard for vetting that was above and beyond "click this checkbox to swear that you are whom you claim to be", or paying a bit more for a special root key that gives your web

    • beat me to it. .. and gives the keys to the NSA...film at 11

  • Older PCs (Score:4, Insightful)

    by MightyMait ( 787428 ) on Tuesday July 30, 2013 @05:29PM (#44428733) Journal
    I wonder how this'll affect older PCs? Aren't SSL communications with larger keys more processor-intensive than when using a smaller key?

    • Re: (Score:3, Funny)

      by Anonymous Coward

      If you really worry about SSL key lengths affecting your system performance. You probably should buy a new one.

    • Not really. (Score:5, Informative)

      by Anonymous Coward on Tuesday July 30, 2013 @05:37PM (#44428827)

      The initial connection setup will be more processor intensive (4x?) but the actual communications isn't done with public/private key encryption. The public/private keys are only used to verify the identity of the server and to exchange a symmetric (AES128 often) key. After the setup, the rest of the transfer will be no more complex and so shouldn't load your PC any more than before.

    • Re:Older PCs (Score:5, Informative)

      by tlhIngan ( 30335 ) <slashdot.worf@net> on Tuesday July 30, 2013 @05:58PM (#44429007)

      I wonder how this'll affect older PCs? Aren't SSL communications with larger keys more processor-intensive than when using a smaller key?

      Hardly anything, actually. The actual amount of encryption and decryption done using the RSA2048 key is quite small - really only about 128 to 256 bits or so.

      Public key encryption is horrendously slow, too slow for modern usage, so what happens is the bulk encryption is done via a symmetric cipher, typically AES these days (previously it was 3DES or DES). Of course, for symmetric ciphers to work, you need to share a key. So what happens is the client generates a key for AES, encrypts it with the RSA2048 public key, and sends it to the server. The server decrypts the key using its RSA2048 private key and then communications take place via AES and that shared key.

      The change from RSA1024 to RSA2048 should have minimal impact since it's only done on session setup while the actual communications use the far faster and more secure AES algorithm.

      (Yes, public key encryption is weaker - you need more bits for the key to have the same level of protection as a symmetric cipher using way less bits.).

    • I wonder how this'll affect older PCs? Aren't SSL communications with larger keys more processor-intensive than when using a smaller key?

      It is just in initial RSA operations and does not effect cost to encrypt underlying data itself. Most everyone else had already upgraded to 2048 years ago.

  • Try to buy an SSL certificate with 1024 bit keys. I dare you. Double dare you. Yeah, you won't be able to.

    What will be news is the myriad of devices that have crappy firmware which relies on the old keys for all the wrong reasons.

    • Re: (Score:2)

      by xatr0z ( 633279 )
      Yes, but unlike almost all other certificates and big websites Google uses elliptic curve diffie hellman, which means something like every user having their own key. That key also changes every day. So after breaking one they would only be able to intercept traffic form that user for 1 day.

      So google's certificates give much more security than other ones, even if they use 4096 bit keys.

      • Yes, but unlike almost all other certificates and big websites Google uses elliptic curve diffie hellman

        I can't tell if you are making up ironic bullshit or being informative. Maybe using cute names in IT wasn't that good an idea anyway. But I guess if it was a joke there would have been at least 5 nonsequitor names after each other to describe a security tem and not only four.

        • Re: (Score:2)

          by sFurbo ( 1361249 )
          How else would you describe applying the Diffie Hellman* key exchange method to elliptic curve** cryptography? As opposed to marketing terms, scientific jargon is a way to describe the properties of what is being described, not a way to make it sound sexy.

          *Named after the people who invented it the second time, as is traditional with cryptographic algorithms.
          **The name came because a certain class of integrals arose in connection with the problem of giving the arc length of an ellipse.

  • Key size not the flaw... (Score:5, Insightful)

    by sabt-pestnu ( 967671 ) on Tuesday July 30, 2013 @05:30PM (#44428755)

    The largest risk isn't during transmission, it is at the user's end... and Google's end. 2 million bit encryption wouldn't be enough if you had a keylogger, or if google got served a National Security Letter that it decided to honor.

    • Re: (Score:2)

      by gl4ss ( 559668 )

      The largest risk isn't during transmission, it is at the user's end... and Google's end. 2 million bit encryption wouldn't be enough if you had a keylogger, or if google got served a National Security Letter that it decided to honor.

      well they figured out that if they lock the root in a safe that can be only opened by putting in 100000 100 dollar bills they can write another bill to NSA for retrieving it for them, as logistical cost of accessing the key.

      • The root key is in an HSM, and can't be extracted. I think I can say that without compromising anything confidential.

        • The root key is in an HSM, and can't be extracted.

          For disaster recovery purposes it must also exist elsewhere.

          • Re: (Score:2)

            by gmueckl ( 950314 )

            A key that is only used for communication and never for storage does not need to be recoverable, does it?

          • The root key is in an HSM, and can't be extracted.

            For disaster recovery purposes it must also exist elsewhere.

            Other HSMs. There is a secure mechanism for syncing keys between devices that ensures that it is still impossible to ever extract them in cleartext. All major HSM devices can do this.

        • WIth physical access and knowledge of the hardware sure it's extractable ... this is assuming there's no backdoor in the HSM, always a large assumption.

          • WIth physical access and knowledge of the hardware sure it's extractable

            With good tamper-reactive hardware? Well... in theory, sure, anything is possible. In practice, good luck getting in without triggering the tamper response, which zeros the master key. Note that freezing attacks don't work, because getting the device outside of a certain temperature range triggers the tamper response, as does physical penetration, exposure to radiation, improper input voltage or loss of battery power or... good FIPS 140-2 level 4 hardware is very touchy.

            ... this is assuming there's no backdoor in the HSM, always a large assumption.

            Actually, I worked a bit on the IBM

    • It can frustrate 3rd world oppressive governments with sniffing capabilities (there's a few) thats about it.

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      The largest risk isn't during transmission, it is at the user's end... and Google's end. 2 million bit encryption wouldn't be enough if you had a keylogger, or if google got served a National Security Letter that it decided to honor.

      Hush now, the NSA wants you to believe that they capture data in flight, therefore you are more protected using bigger keys.

      More bits is always better and more unbreakable! Google's working hard to protect your privacy!

    • The largest risk isn't during transmission, it is at the user's end... and Google's end. 2 million bit encryption wouldn't be enough if you had a keylogger, or if google got served a National Security Letter that it decided to honor.

      Yeah, but the NIST recommendations suggest that 1024-bit keys aren't adequate any more, so it's just good security hygiene to upgrade, even if they're not actually the current weak point, which I agree is almost certainly at the user's end.

  • I think the people who wield the root certs were hoping that ECC would come around before they had to switch to 2048, but it didn't. The crushing effect of certicom's obvious patents and the lateness of the NSAs RFC6090 meant that RSA won again.

    I don't see anything improving on the ECC front. All the structural problems remain. We'll be messing with 4096 RSA before long and your smart cards will all have to be replaced.

    • What structural problems?

      • 1) Over conservative corporate lawyers who think ECC is a no-go land
        2) Fear, uncertainty and doubt about whether certicom will come after you with their lawyers
        3) Suspicion by tin foil hat bearers that the NSA are promoting elliptic curve algorithms (in RFC6090) they know how to break
        4) Engineers who don't know how to avoid stepping on patented parts of elliptic curve cryptography implementations.
        5) Obsolete operating systems that don't understand ECC certs
        6) Anything else I haven't thought of

  • WTF? (Score:2, Insightful)

    by bloodhawk ( 813939 )
    How the fuck is "by the end of 2013" more specific than "in the next few months"? First is a 5 month range, the second "generally" refers to a 2-4 month range. At worst there timeline response hasn't changed.

    • Re:WTF? (Score:5, Insightful)

      by hawguy ( 1600213 ) on Tuesday July 30, 2013 @05:59PM (#44429013)

      How the fuck is "by the end of 2013" more specific than "in the next few months"? First is a 5 month range, the second "generally" refers to a 2-4 month range. At worst there timeline response hasn't changed.

      "By the end of 2013" specifies an exact point in time at which the project will be done - Dec 31st, 2013, if they slip past that date, then they are late. However, "in the next few months" is very non specific, with no universally accepted definition of what it means and can depend on the range being considered -- If I have big bag of M&M's and someone asks me for a "few", they'd probably be disappointed if I gave them 2 - 4. Since "few" is so non-specific, they could stretch it out to 5 months and still claim they are within a "few".


    • How the fuck is "by the end of 2013" more specific than "in the next few months"?

      Linus?

  • Big deal. (Score:4, Insightful)

    by magic maverick ( 2615475 ) on Tuesday July 30, 2013 @05:39PM (#44428839) Homepage Journal

    I've been using 4096 bit keys for over two years. Now if only /. would get into the act (I don't want freaks and weirdos at where ever I use the 'net to know a. what stories I read. b. whether I'm logged in or not. c. if I'm logged in, what my user name and password are).

    Also, the moderators are all insufficiently like the "ideal" for their gender (whatever gender that is). E.g. the male identifying mods all have small penis'.

    • Google uses ECDHE [blogspot.com] which makes their encryption dramatically more secure than the vast majority of others.

    • E.g. the male identifying mods all have small penis'.

      Penises. They have small penises.

      I am obviously a grammar Nazi, with a large penis - not a mod with a small penis. Or giant clitoris, for that matter.

      Also, no one cares what you read - you're probably looking for the typos, logical fallacies, incomprehensible summaries, sensationalism, broken links, incomplete headlines, and overall mediocrity in order to make your average self feel above average.

      Oh wait, that's me. Based on your browsing history, you

      • You're a stupid nazi. Like all nazis really. First, "penis ' " is perfectly acceptable in that context. The apostrophe (') indicates that a letter or letters have been left out. Like in words such as "don't" and "'ouse"; in the first an "o" is missing, in the second the "h". Often missing letters are used to indicate pronunciation (as in "don't"), even though strictly, you shouldn't write like that in formal documents (where grammar and spelling matter more).

        And I think you probably have a small penis anywa

  • 2048 bytes? Pure blinkered American-centric bias.. (Score:4, Funny)

    by Dogtanian ( 588974 ) on Tuesday July 30, 2013 @05:50PM (#44428921) Homepage
    The Yanks are so used to accessing Google on their bloated 2K TS-1000s [wikipedia.org], that they seem to have forgetten that those of us with the original British 1K ZX81 [wikipedia.org] won't be able to access their website securely any more.

    I bet those tossers are so spoiled they have blackjack and hookers, and 16K rampacks on their servers. Hope someone wobbles them (*) and they lose all their data. Gits.

    (*) The rampacks, I mean. I've no idea what wobbling a hooker would do to your data.
  • how is "by the end of 2013" more specific then "in the next few months". Last time I checked, 2 or 3 months is more specific then 1-5 months

  • Yeah guys (Score:3)

    by Meshugga ( 581651 ) on Tuesday July 30, 2013 @06:20PM (#44429171)

    until you disclose how much data *exactly* of how many users on average you're handing over to LEOs per request, I'ma not gonna trust you ever again.

  • Google should have done this years ago! They have all the resources to have their own structure without having their security outsourced to certification authority company like Symantec. They can even have it for free.

Slashdot Top Deals

It is easier to write an incorrect program than understand a correct one.

Close