Live data from Hacker News

Apple Reportedly Storing over 8M Terabytes of iCloud Data on Google Servers

macrumors.com

221–229 of 229 posts

Re: Apple Reportedly Storing over 8M Terabytes of iCloud Data on Google Servers

#221
post #159

Earlier quoted context omitted.

Of course there is no guarantee: AES256 could be broken tomorrow, or maybe it has already been. What we know is that, extrapolating compute speed from the past decades and even assuming quantum computers become useable in practice, the best algorithms we currently have cannot be brute-forced within the next 50 years.

> AES256 could be broken tomorrow, or maybe it has already been. This is extremely unlikely. > What we know is that, extrapolating compute speed from the past decades and even assuming quantum computers become useable in practice, the best algorithms we currently have cannot be brute-forced within the next 50 years. Quantum computers only offer a quadratic speedup against symmetric ciphers. AES 256 will survive much…

> This is extremely unlikely.

AES-256 was broken in 2011.[1] While only four times faster than brute force and thus not a practical attack, it suggests that compromise is possible. The Snowden documents indicated that the NSA was working on breaking AES-256. It seems unlikely they would waste effort on a task they considered impossible. Whatever they achieve will be achievable by others eventually.

On top of that, no implementation is perfect. Bugs are discovered in cryptographic APIs on a regular basis. Even if your API is perfect, the application calling the API can have bugs that allow compromise.

[1] https://web.archive.org/web/20120905154705/http://research.m...

Re: Apple Reportedly Storing over 8M Terabytes of iCloud Data on Google Servers

#222
post #8

All the data is encrypted so it doesn’t matter where they are storing it. Using multiple service providers (Google, Amazon, their own servers, etc) might actually be beneficial because it eliminates one point of failure, especially if they replicate data in a smart way to take advantage of it. It might also speed up access to data.

Unless you have encryption that is guaranteed to never be obsolete it ALWAYS matters where you store the data.

Not just that, but also a guarantee of no compromising bugs in either the cryptographic API or the application code that calls it.

Yes. If you want your data protected, it always matters where you store it.

Re: Apple Reportedly Storing over 8M Terabytes of iCloud Data on Google Servers

#223
post #84

Earlier quoted context omitted.

pretty sure it was a joke

Not a joke, the AU is a pretty common unit of measurement when talking about distances too large for metres and too small for light-years, especially since it's based on one of the most widely understood astronomical distances. Of course using it to describe the distance it's derived from is more than a little tautological, but that wasn't too important in the context of discussing magnitude prefixes. It's roughly th…

...thus making it tautological and extremely pertinent given the context

Re: Apple Reportedly Storing over 8M Terabytes of iCloud Data on Google Servers

#224
post #176

Earlier quoted context omitted.

If your model is "even encryption isn't good enough" then you might as well not care because there is nothing you can do to protect it.

That is a strawman. Apple could just not host at Google.

No it isn’t, wether Apple stores its data in a contract data center or one it owns doesn’t change the fact that if you don’t believe encryption is effective then it’s a lost cause to worry about the privacy of your data.

Re: Apple Reportedly Storing over 8M Terabytes of iCloud Data on Google Servers

#225
post #8

All the data is encrypted so it doesn’t matter where they are storing it. Using multiple service providers (Google, Amazon, their own servers, etc) might actually be beneficial because it eliminates one point of failure, especially if they replicate data in a smart way to take advantage of it. It might also speed up access to data.

Unless you have encryption that is guaranteed to never be obsolete it ALWAYS matters where you store the data.

> Unless you have encryption that is guaranteed to never be obsolete it ALWAYS matters where you store the data.

Well, while there is truth to that, it isn't the whole story. There is a time value to all information that must be factored in. If nothing else, think of one overbroad* classification example: Battle plans, SECRET; Intelligence; TOP SECRET.

* By which I mean there are subtleties and exceptions too numerous to go into here, but the example remains largely illustrative.

The higher the classification, the higher the long term time value, the greater robustness required in one's controls.

In this case, information about/for large numbers of private individuals, today's strong enough symmetric encryption may be strong enough for quite some time.

Or it might not be. I'd love to see a detailed risk assessment....

Re: Apple Reportedly Storing over 8M Terabytes of iCloud Data on Google Servers

#226
post #194

Earlier quoted context omitted.

Is the assumption that google is going to store, then attempt to decrypt the data at some point in the future? Or is the claim that google's services are less secure than Apple's would be? If not, then I'm not sure that this is worse at all. Sure, if you believe google to be actually malicious, then this would be a problem, but I don't think there's a reasonable argument to say that google would go to this length of…

Google -is- a malicious and exploitative surveillance capitalism company preying on people that don't feel like they have a choice. Inch by inch "don't be evil" has been replaced with "maximize profit". I have no doubt that if in 20 years decrypting "historical" Apple user data for "training purposes" is legal and will make Google leadership more money, they will pressure ethically flexible engineers to do it for the…

Well, you may be right, but then if you are, I’m not sure you can justify leaving your data with Apple either, which is a public company that has the same underlying market incentives. In fact, if that’s what I believed, I doubt I would put any of my data anywhere, and rather just go live in the woods, or more likely, just give up and stop caring. I’m not convinced that Apple will be any more or less malicious than google is/was/will be when considering a 20 year time frame.

Re: Apple Reportedly Storing over 8M Terabytes of iCloud Data on Google Servers

#227

Earlier quoted context omitted.

> iterating through every possible value of a 256 bit key It's my understanding that when encryption gets "broken", it usually refers to something other than a simple brute force attack. Like, something that would make it so you don't need to run as many iterations or whatever. I assume this because a brute force attack is something that is always possible from day 1, whereas an encryption scheme being broken is some…

My understanding is that encryption is "broken" any time it becomes feasible for someone to decrypt your data without the key. Brute force attacks are always hypothetically possible, but the encryption isn't broken unless such an attack is feasible. As a counter-example, DES would count as "unbroken" under your definition. The EFF built a machine in 1998 for under $250,000 that could crack a DES key in under 24 hours…

I think you're mixing "weak" and "broken". Out of interest I looked at the Known attacks section of wikipedias AES article and it says as the first sentence "For cryptographers, a cryptographic "break" is anything faster than a brute-force attack".

DES is both weak and broken, but it could be either without the other.

Re: Apple Reportedly Storing over 8M Terabytes of iCloud Data on Google Servers

#229

Earlier quoted context omitted.

They are using AES-128. https://support.apple.com/en-us/HT202303

A minimum of AES-128, which could mean 100% AES-128 or 1% AES-128 from old iOS devices that haven't been updated in years. And even AES-128 would require doing a 2^64 exhaust on a quantum computer, which would be quite a remarkable feat.

More likely it’s all AES-128 since that is natively supported by energy-efficient TPM chips, while -256 isn’t.
Post reply on HN