Google Starts Upgrading Its SSL Certificates To 2048-bit Keys 118
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."
Completely useless... (Score:3, Informative)
If the NSA has the master key...
Re: (Score:1)
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
Re: (Score:2)
Re:Completely useless... (Score:5, Funny)
It's called private key, you cretin. Now, go smoke some weed and don't bother the grown-ups will you?
Let me draw you a picture...
Me <---- (SSL) ----> Google ---- (SSL) ----> NSA
Re: (Score:1)
It's called private key, you cretin. Now, go smoke some weed and don't bother the grown-ups will you?
Let me draw you a picture...
Me <---- (SSL) ----> Google ---- (SSL) ----> NSA
I thought it was
Me NSA Google. isn't that why they call it MITM?
Re: (Score:3)
Me NSA Google. isn't that why they call it MITM?
Actually, it's AITM, or Agency In The Middle.
But overall, the whole thread represents the wrong approach: If it's the SSL keys in TFA that are being borkified for NSA access, then the NSA would have to stick something between you and Google (and would have to host the SSL key itself, as well as the domain name), so you would be correct if that were the case.
However? Not really sure that Google would want anyone else controlling their domain name/LBs/firewalls/etc, especially when it's easier for some govern
Re:Completely useless... (Score:5, Insightful)
Re: (Score:1)
Re: (Score:2, Interesting)
The nice story about working hard and helping find contraband....
ie nobody in the West is going to let an East Germany forget about what happens on the Wall.
We now all know the truth about the US brands and their legal positions wrt your plaintext.
Re: (Score:2)
I have no idea what you're trying to say.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
I love how this is an article about how goog is increasing security, yet 95% of the posts are about NSA snooping. This is the flip side of the PRISM stuff - a company will never be able to prove that NSA is NOT snooping. Once the public loses faith, it will be really hard for a company to regain it. maybe this has already happened...
Why should the company have to regain any trust anyway? The fact is the US government is currently mandating that they do all of this crap and issuing them with gag orders so Google can't tell anyone.
The only way Google can get out of this is relocate their HQ to russia, exactly where the Brin family escaped from. Even if they did this it would probably be no better as Putin is not exactly Mr Privacy.
The truth is that companies cannot do a damn thing providing congress and the supreme court keeps saying thi
Re: (Score:1)
Why should the company have to regain any trust anyway?
it needs to regain my trust because currently i dont' trust it to keep my data confidential. instead of "teh cloudz" I'll use desktop services where I own my data. because I don't trust goog.
Re: (Score:2)
Why should the company have to regain any trust anyway?
it needs to regain my trust because currently i dont' trust it to keep my data confidential. instead of "teh cloudz" I'll use desktop services where I own my data. because I don't trust goog.
Do you trust anyone else not to share your data with the NSA? If you do I have a bridge to sell you.
Re: (Score:1)
Do you trust anyone else not to share your data with the NSA? If you do I have a bridge to sell you.
Not gonna lie, I wrote a pretty strident diatribe about how I'm cutting myself out of their loops, but I'm deleting it because I'm sure NSA is reading this thread. even if I post AC they would connect it with my account. I'm not going to do anything out of the ordinary so all my data will be available through existing channels: goog, MS, apple, verizon. also, why is it so cold in here? oh yeah, because of the chilling effect to the first amendment.
Re: (Score:2)
That means the envelope Google sends to the NSA will be twice as heavy. ;-)
Re: (Score:2, Informative)
Actually...
Me ----> (SSL) ----> Verisign ----> NSA ----> (SSL) ----> Google
Re: (Score:2)
Verisign or any other signing authority don't have Google private key nor anybody else private key for that matter.
Re: (Score:2)
Re: (Score:2)
Well, I wouldn't use fake certs, it seems like a nice way to leave traces and evidences. There must be a better way but this is just my MHO.
Re: (Score:2)
Actually that won't work since Google is enabling forward secrecy [blogspot.com.es] Knowing the key will not be enough. The NSA would need to have an actual proxy server between you and Google to monitor the traffic.
Re: (Score:2)
Verisign or any other signing authority don't have Google private key nor anybody else private key for that matter.
They do have the ability to provide a second key for a common name that end users will trust, allowing a man in the middle attack. Having the CA private key would allow someone to do this at their leisure.
Re: (Score:2)
Normally the PKI on certificates is just used for authentication, and then encrypting the exchange of the symmetric key; symmetric key encryption is used to transfer the actual documents. My guess would be those companies collaborating with NSA on snooping have a server side SSL library that shares the negotiated symmetric keys with the NSA and after the connections are setup simply duplicates all the packets; which the NSA can now decrypt the payloads of.
I doubt the NSA is actually MITM.
Re: (Score:1)
In practice most SSL sessions use the public/private key pairs to generate the session key in a rather trivial manner. That means if you know the server's private key, you can derive the session key after the fact.
What you're thinking of is a property called "perfect forward secrecy". Unfortunately, in reality the negotiated parameters of real-world SSL sessions rarely have the property of forward secrecy. Because of the way SSL has evolved, and because of bugs discovered over the years, and for other vario
Re: (Score:2)
Don't forget the symmetric may change several times in a course of an TLS session. It is called renegotiation. It was made to make things more secure than a single symmetric key but funnily enough, it got exploited...
https://tools.ietf.org/html/rfc5746 [ietf.org]
http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html [educatedguesswork.org]
http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION [openssl.org]
http://tools.ietf.org/html/rfc5746 [ietf.org]
Re: (Score:1)
Right... because google signs their own certs and you magically make your browser trust them tool.
Why don't you do some reading:
http://www-01.ibm.com/software/webservers/httpservers/doc/v2047/manual/ibm/en_US/9atssl.htm [ibm.com]
and let intelligent people talk.
Re: (Score:2)
This are America so no.
Re: (Score:2)
D wave doesn't appear to do factoring.
Doesn't need to... (Score:1)
It does the lower bounds of a limit problem, so you can (sort of) figure out where you're looking for the values for the key, and then along with regular cpus/gpus only bruteforce it above that point/within that range.
Taking a few factors off a crypto key's seed values can certainly make cracking the key/certificate easier to do.
Re: (Score:2)
Even if you can use the D-Wave to take off say 128 bits of uncertainty, that still leaves a pretty big problem in a 512 bit system, never mind a 1024 or 2084 bit system.
Re: (Score:2, Interesting)
A 768-bit RSA key was factored in late 2009. 1024-bit should be trivial for the NSA, although not trivial in the sense that they don't need to be selective about their target.
Just because there's no known algorithm to factor primes easily doesn't mean that there aren't practical optimizations to help improve performance. Most of the time when you hear that it takes "thousands of years" to factor a prime number, the speaker is only taking into consideration the most brain dead methods. Cryptographers are con
Re:Doesn't need to... (Score:5, Funny)
Most of the time when you hear that it takes "thousands of years" to factor a prime number
Really? I can factor most primes in my head.. Semiprimes would be a different story...
Re: (Score:2)
Older PCs (Score:4, Insightful)
Re: (Score:3, Funny)
If you really worry about SSL key lengths affecting your system performance. You probably should buy a new one.
Not really. (Score:5, Informative)
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)
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.).
Re: (Score:2)
Re: (Score:2)
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.
Why is this news? (Score:2)
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)
So google's certificates give much more security than other ones, even if they use 4096 bit keys.
Re: (Score:1)
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)
*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)
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)
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.
Re: (Score:3)
Re: (Score:2)
The root key is in an HSM, and can't be extracted.
For disaster recovery purposes it must also exist elsewhere.
Re: (Score:2)
A key that is only used for communication and never for storage does not need to be recoverable, does it?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
It can frustrate 3rd world oppressive governments with sniffing capabilities (there's a few) thats about it.
Re: (Score:2)
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!
Re: (Score:2)
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.
So ECC missed the boat (Score:2)
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.
Re: (Score:2)
Re: (Score:3)
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)
Re:WTF? (Score:5, Insightful)
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".
Re: (Score:2)
It may provide a definite endpoint, but it is definitely LESS specific in this example as it means anytime in the next 5 months. Whereas in the next few months in the vast majority of terms means at worst in the next 4 months and usually within the next 3.
Unless, by a "few" they meant 5 months. Or maybe 6.
Anytime a project manager tells you "Oh, it'll be done within a few months", you know that he doesn't really know when it's going to be done and it probably means no one has it on their schedule, it might be done tomorrow or it might be done in 6 months. If he really had a good idea when it would be done, he would have told you.
Re: (Score:2)
How the fuck is "by the end of 2013" more specific than "in the next few months"?
Linus?
Big deal. (Score:4, Insightful)
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'.
Re: (Score:3)
Google uses ECDHE [blogspot.com] which makes their encryption dramatically more secure than the vast majority of others.
Re: (Score:2)
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
Re: (Score:1)
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
Re: (Score:2)
You can't compare symmetric key lengths (based on AES) with RSA modulus sizes. An extra bit in a symetric key gives you alot more security than an extra bit in the RSA key..
Re: (Score:2)
But when it's so easy and cheap, why not? They have to renew keys anyway...
2048 bytes? Pure blinkered American-centric bias.. (Score:4, Funny)
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.
more specific? (Score:2)
Yeah guys (Score:3)
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.
2048 standard (Score:1)
Re: (Score:2, Insightful)
Not really. There are good reasons to encrypt, you just have to understand them.
The main thing you need to realize is that encrypting something only delays the disclosure of the data. It may take a LONG time to try all the available keys, but eventually a brute force attack will be successful. Of course, if it's going to average 100 years of effort, it may not be worth it to the attacker, or it may not matter what you bank account balance was by then.
Re: (Score:2)
Don't know, but as I've said before, Google seems to have been doing things to make harder work for the NSA over the last few years. This would support the rumors of the NSA being able to efficiently brute-force some lower-length keys used in SSL.