Hashing.
This is the concept you are missing.
Hashing takes 13 and returns 3ACD78C55FAD063D01274563AE327.
And it takes 14 and returns A430643CB66800186AC76984BDBF8.
Your method does not work with modern cryptography.
That data is encrypted with a completely different class of key from the keybag.
Remember the keybag? Different keys encrypt different kinds of data.
How do you propose that matters?
Are you proposing that AES is susceptible to a plaintext attack? Because that seems to be what you are proposing.
With the very best minds in cryptanalysis all focused on doing that for the fame and fortune that would come with it, the very best techniques have reduced the time taken to extract the key from a known plaintext and the encrypted text by 2 bits.
Are you being deliberately obtuse? Do you really think we don’t know anything about the data we are trying to extract?
I was providing a conceptual example.
I don’t understand why anybody has any faith in this version of encryption on this version of the software on this version of the iPhone, when every other version on every other phone, has basically been hacked by some high school dropout eurotrash paparazzi.
How many nude pictures of Jennifer Lawrence will it take to convince you I’m right?
We have a whole department of government who’s job is to do nothing but try to intercept and decrypt the best efforts of other countries to shield their confidential data. Apparently they have had some success. Yet, you think they have been defeated by the iPhone?
We know a great deal about some of the plaintext data. But we don’t squat about others.
And because the parts we know are encrypted with a different key than the ones we don’t know, knowing the plaintext data isn’t helpful.
You seem to be picturing this as a Captain Crunch Decoder Ring.
It matters because it shreds your example.
Yes.
There are two arguments I have seen from you. One is, “The same techniques that have been successfully used in the past will work here!” And the second is, “We have loads of smart people who have worked on this. Surely they would have succeeded!”
If there is some flaw in how Apple has executed the cryptography, and if these smart people have found it, then I agree with you. But the existence of that flaw is utterly speculative on your part.
If there is no flaw, then – and here is where you struggle – the scheme is not vulnerable except to a truly prodigious breakthrough in computer architecture.
You’ve called my viewpoint “speculative.” Consider though the # of iPhones we have had. Consider the # of operating systems we have had. Consider the number of updates we have had to each. Put together it likely numbers more than 100.
Every single one of those previous versions had exploitable security holes. Every. single. one.
You tell me that this one is different, and unlike every other iPhone that has ever existed this one is impervious.
You, my friend are positing a unicorn, a Sasquatch, a mythical beast that has never been seen before.
When I tell you in fact that it is probably not a unicorn, or a Sasquatch, or an Invisible Pink Unicorn, you claim I am being “speculative?”
You are not arguing with a 13 year old child. You cannot simply spout Apple propaganda, wave a magic wand and say “hocus pocus, Aes 235 key bag hashing billion billion years, presto changeover uncrackable.”
That this version of this phone is uncrackable… Or even particularly difficult to crack compared to previous versions is the speculative stance. That’s the extraordinary claim.
Not true.
Most are bug fixes. Some are security holes that don’t relate to encryption.
Except that no one is stepping forward to actually demonstrate the crack. Why is that?
Fair enough, but you see my point.
In the case of the government, I believe I’ve already made my case in great detail as to why they might wish this terrorist’s compatriots to believe their data is secure. There are two rules to code breaking:
- Break the code
- Convince everybody that you didn’t break the code.
Not all hackers wear white hats. Are you seriously asking me to argue why it might be advantageous to have access to a security hole that is generally unknown?
I disagree. The phone has to be able to determine if someone enters the wrong password 10 times and obviously it has to be able to do this before it has received the correct password and opened up access to the file system. So somewhere in there it is working with the unencrypted equivalent of “nope, try again. 9 attempts remaining…”
Like I said I’m not an Apple engineer and only one of those could really answer this question with certainty, but I find it extremely likely that Apple would know how to find that. They aren’t limited to doing what the FBI suggests. They might be able sniff data going between the CPU and the keypad UI and know that some bit is changing each time they try an incorrect PW, where no bit should change if the correct PW was entered, even if they can’t directly see what the bit is set to. Or any number of other possibilities.
But even if you’re right it doesn’t take anything away from the larger point that I was only reinforcing with this theory about the wording of the order to disable the auto-erase feature: this is not intended by the government to just be done for one phone and only one phone. It is just the most recent move in a long battle they’re fighting to make Apple backdoor the phone. Apple made it no secret that with the changes in IOS 8 they would no longer be able to honor orders from the government to crack into people’s phones and they were quite happy about that.
The government isn’t happy about it. They are trying to set a precedent with this order and Apple is trying to set a precedent by refusing to comply with it. They are both thinking ahead to millions of other phones that are going to be affected by the outcome of this one way or the other.
No, I get that motive.
I just don’t agree that this shows the code is broken.
That count is happening regardless. The phone increases time between tries after several failed attempts even when the auto-erase is not enabled.
I take no position on this claim.
The iCloud was done via social engineering, not breaking encryption.
Scylla, what you’re proposing just plain doesn’t make sense. Even if we knew that Moby Dick was on this murderer’s phone, doesn’t mean we can encrypt Moby Dick on our own and somehow crack his passcode. Different keys yield totally different results, and even an imperceptible difference in the text (let’s say one of the thousands of commas in the book was mistakenly misprinted as a period) would also result in totally different results even if you were using the same key.
I think everyone in this thread acknowledges that there are ways to break into this particular iPhone, and other iPhones in the past, by using some pretty clever techniques that do not involve banging one’s head against a very, very strong encryption system that the government uses to protect Top Secret data. If comparing different encrypted versions of identical versions Moby Dick yielded clues to breaking AES wide open, then you can absolutely bet that neither NIST, which validates the security of AES, or the NSA, which is responsible for the US military’s cryptography, would use this system. It would be dumped faster than old fish sitting in your wastebasket.
In the news today: Tim Cook sent an email to Apple’s employees today about why the company is taking a stance against fulfilling the judge’s order. The full text of the email is reprinted here:
I strongly suggest that everyone engaging in this discussion read the Answers to your questions about Apple and security linked to in Bo’s post above. You may think it is full of lies (I don’t), but I think we should all be clear about what Apple is claiming publicly.
One thing that I found instructive is that Apple considers the OS requirement that all passcode entry be done via fingers is integral to their security scheme, so they strongly object to the part of the FBI request that would allow passcode entry via a port or Bluetooth.