I don’t see having access to iCloud changes anything. There’s a lot of stuff not backed up to iCloud that the FBI wants.
AES is not vulnerable to this type of attack. If you have a method that eliminates any keys (as in even going from 2^128 to 2^127 possible keys) write it up in a paper. It would be the biggest paper of the decade in cryptography and the start of a extraordinarily lucrative career.
Doesn’t anyone find it curious how one guy’s phone becomes the precursor to economic collapse, Internet-wide privacy forfeiture and the collapse of worldwide security?
It’s not a big disagreement, but one nevertheless. A backdoor implies intent. As an example: Apple would include two public keys in the download code, each one permitting a correctly signed code to be loaded. One of the keys would be prepared by the FBI, and they would hold the corresponding private key. It is most probable that such an arrangement will be discovered by hackers (although it would not be exploitable) and Apple might need to explain that away.
The other tomato is just a bug. Specifically, in this case it is a conceptual bug. I guess that Apple did not believe to be forced to sign a hack.
By the way, a perfectly legal way FBI has, is to subpoena the private key Apple is using and the source code of the software. This is available on the shelf information, but even the FBI do not have the cojones to ask for it.
Regarding the cite you asked for: Please read this NY Times article. It contains a wealth of information:
If these morons didn’t use one guy’s phone as an excuse for every corrupt government everywhere to have the tools to sabotage every phone, we wouldn’t be talking about this.
Let’s get real. You think corrupt governments are just waiting for the FBI to do something first so they can get away with the same thing? Get real. The Chinese government sends people to work camps for criminal without a trial. I laugh if you’re going to posit that they wouldn’t dare conduct searches that are a million kinds of illegal here.
doubleminus, thanks for the cite. I’ll read that tonight.
The order is to create a new OS for the iPhone that bypasses these security measures. There is no question that they could do so. In the same vein they could also create software that tells them if the currently installed OS has the auto-erase feature enabled. I’m not a software engineer so I can’t really say how specifically, but it is 100% guaranteed that they can do this. You’re not a software engineer either but I would be curious why you think that they couldn’t.
This order comes on the heels of many other attempts to force Apple to create a backdoor to the iPhone. Apple is a business, not a privacy activist. If it was in their best interest as a business they would comply. Clearly it isn’t, and they won’t. It will be interesting to see how this all unfolds, but as written the order is obviously an attempt to open the door to create a backdoor to the iOS. The precendent set if they did would open the door to countless other investigations that demand the same action.
Scylla, you’re just flat wrong here. If you do a distribution of input values and output values like you’re suggesting, that takes billions and billions of years! There are two to the 256 power different keys to try out! How do you think they could do a distribution of the outputs of each of these keys, when there are almost as many keys as there are subatomic particles in the universe?
That says nothing like what you’ve described.
I think at this point you just need to admit that you know nothing about cryptography and stick to your conspiracy theory ideas about how we know they’ve cracked it is that they say they haven’t.
I’m not a software engineer either, but I think the answer is they can’t since the phone is encrypted and by definition there is no plain data like that to be extracted.
But which ones do you do? There are 10^77 possibilities, and it does you no good to look at just a trillion of them. If one of those trillion isn’t it, then you’re no closer to figuring out which one IS it.
Our encoding method will be to have a two number key using the numbers 1 - 100, the algorithm will be to multiply our input by the first number in the key and then add the second number.
(I know, it’s a devastatingly complex and diabolical encryption method, but bear with me, this only a conceptual example)
Now let’s say the output is “85.”
Now even though we don’t know what the key is, we know certain things about the key. We know that the first number in the key can’t be greater than 6 since anything more than that would produce a Number higher than our output.
Right off the bat we’ve eliminated 9400 of 10,000 possible combinations.
We also know that the second number must be small enough to possibly give us our output, so if we are testing 6 as the first number of the key, the only possible combinations would be the numbers 1-7, we can exclude 8-100. We can do the same for the remaining possibilities for the first number of the key, and now we’ve reduced the possible keys from 10,000 to about 100 (I haven’t bothered to work it out exactly.). That’s about a 99% reduction in possible keys to test.
The AES code is of course just slightly more complex than this, but knowing the formula used and knowing what unencrypted output looks like necessarily tells us something about what the keys must be.
So let’s say for the sake of argument that the above appears somewhat reasonable to you. You say “Very impressive Scylla! Congratulations, by applying your method you have now reduced the time needed to crack the code from 100 billion years, to only 1 billion years! We better get started on this right away.”
That’s a good point except for the fact that the more complex the algorithm and keys used the greater the constraint upon the output, and the more unencrypted data you have to work with the more you able to eliminate keys.
Going back to my example let’s say that the next piece of unencrypted data is “5.” And the output is “37.” We can now reduce the remaining keys again, and I believe that’s enough to solve it and guess the keys right there.
Again, the problem is that we do not know what the “13” is, much less what the key is. You assume that the iPhone encrypts every byte on its SSD; I believe that is an unfounded assumption. Show me where it says that literally all of the phone’s content is encrypted, because it would make a lot more sense from a security perspective to not encrypt the standard data and object code (which is nicely segregated form user data).
As I explained earlier when I discussed the keybag.
They could determine the setting only by disabling it in their new OS, loading the new OS, brute-forcing the passcode, using the passcode, and then checking the setting.
Scylla, if you really believe that a plaintext attack on AES-256 is plausible, you need to go apply to the NSA and explain your technique. You will also likely get a Fields medal. There are few techniques that have shown enough effectiveness to reduce the key-length by two bits. Anything beyond that is fantasy at this point (or at least a very well kept secret).