It sounds like the hardware-locked key is a step in the right directon when it comes to key management, though. I'd say that's the big deal compared to the cypher used.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple's 'Unbreakable' iOS Device Encryption Highlighted
- Thread starter MacRumors
- Start date
- Sort by reaction score
It sounds like the hardware-locked key is a step in the right directon when it comes to key management, though. I'd say that's the big deal compared to the cypher used.
That's a totally different. Cryptography provides the math for a particular protocol (idea, method of encryption). The math doesn't talk about how idiotic one can be to use a particular method of encryption in a totally unsanctioned manner.
If the stupidity is taken into account, everything can be compromised. I can release my private key and cry all day that I was hacked to the core. It doesn't help anything.
Exactly. As Ferguson points out in Cryptographic Engineering
Cryptography is Hard
Cryptography is the Easy Part
Sure, but I know this software is used by local police stations for iOS forensics, so I guess it seems to work.
http://www.homelandsecuritynewswire...c-toolkit-circumvents-ios-5-security-measures
Yes you do need the key. Data itself are not encrypted with your password but with (much bigger) AES key which is encrypted with your password and stored in AES chip.
Let's assume I can make a snapshot of all data on the iOS device, using e.g. elcoms software. Then I also have the encrypted AES key (encrypted using my passphrase).
Now I can bruteforce the passphrase on a fast computer, without worring about the wiping after 10 tries etc.
This is what the elcom software does it bruteforces IMO.
I wouldn't trust any important information to an iOS device. Sadly, because I really would like to have my VPN access certs stored on my iPad.
This is no different from other encryption methods; if you know nothing about the contents of encrypted data then you have no way of knowing if what you've decrypted is usable. As I said earlier, if you are encrypting a file-system, then unless the attacker knows this then it becomes difficult for them to know when they've actually found the correct key anyway. You can sort of work around that with statistical analysis but it's the same basic problem; if someone hands you a lump of encrypted data and asks you to decrypt it with no information as to what it is, or how it was encoded, then that's a far more "unbreakable" case than anything else described, as you could guess the key on your first attempt but if it doesn't produce anything recognisably decrypted then it's just as secure as ever
Likewise with a one-time pad, you don't need to know what the message says, only have some method for determining whether it's been decrypted or is still entirely or partly gibberish. For example, if you're hoping the data contains co-ordinates or credit-card details then you can do pattern matching after each guess to see if you've found anything that looks correct.
It's also still very much to do with key length; if, for example, you've only encrypted 16-bits of data, then the key that an attacker needs to guess is only 16-bits long; so as long as you have some way of verifying the data after each guess then a computer can churn through that pretty quickly without knowing what the exact details of the message may be. For example, a credit card number wouldn't take that long as you can guess the key in stages using information about what you're looking for; if you know the card number is in string form then you can discount any guess at a key, or key segment, that won't produce digits as it's either data you don't need, or an invalid guess.
Indeed, the fact that one-time pads aren't applied in stages is actually a weakness, as while AES should always be as strong as the key length, a one-time pad is actually only as strong as the smallest unit of data you can verify. So if you can verify individual bytes that have been decoded then you could break the key simply by making a series of guess at each byte; it'd still take a while but it'd be much faster and easy to do in parallel. Meanwhile AES data with block chaining can't be guessed in segments, as the best you could do would be to confirm what the previous block of was; in CBC that'd be just be a block of ciphertext you already know and would still need to decode anyway.
Applying a one-time pad "properly" is also a huge caveat that means you lose almost all of the advantages of the method (speed/simplicity) and still end up having to somehow secretly store a key at least as long as the data. That's also on top of the assumption of using a cryptographically random key, which you'd probably end up having to use AES or some other encryption method to generate, and which actually reduces the range of possible key segments you can use since you need to avoid any significant repeating sections as you could could otherwise end up making it easier to break.
I will show you WHY the single use pad is unbreakable by using the simplest possible example. My "pad" or key is always of the form 11111... or 2222... in other words a digit "n" that s repeated as many times as required. This is a trivial to break code.
The encryption algorithm is "add n" So if I let n=1 my pain text messages has the letter "A" I change it to a "B" and "Z is changed to "A". If n=2 then A becomes C and so on. The key is the value of n that I choose.
Next I will tell you the plain text you should be looking for. I it is the combo from my lock I use at the gym. It is the common combo lock my "Master" and I use letter from a telephone key pad to encode the combo. Either A, B or C for "1" and so on. All combos are composed of tree two digit numbers. leading zeroes are used for numbers less than ten.
So I have made this as easy is it gets. You know exactly what to look for and the search space is tiny. I bet you a buck you can't break it. (don't bother trying you can't.)
OK here is the message: "DFIUNB".
You can "brute force" this in 10 minutes just by counting on your fingers but you will never know which key I used.
I think this proves that encryption can be truly unbreakable. I have just done about the dumbest possible things, telling you the algorithm, using a tiny key and saying what the plain text is but it is still unbreakable unless you have my lock and can test all ten answers
The problem is that with one time pad, as in this example you get as many answers as there are keys and you have no way to know which of the typically trillions of answers is the right one
The encryption algorithm is "add n" So if I let n=1 my pain text messages has the letter "A" I change it to a "B" and "Z is changed to "A". If n=2 then A becomes C and so on. The key is the value of n that I choose.
Next I will tell you the plain text you should be looking for. I it is the combo from my lock I use at the gym. It is the common combo lock my "Master" and I use letter from a telephone key pad to encode the combo. Either A, B or C for "1" and so on. All combos are composed of tree two digit numbers. leading zeroes are used for numbers less than ten.
So I have made this as easy is it gets. You know exactly what to look for and the search space is tiny. I bet you a buck you can't break it. (don't bother trying you can't.)
OK here is the message: "DFIUNB".
You can "brute force" this in 10 minutes just by counting on your fingers but you will never know which key I used.
I think this proves that encryption can be truly unbreakable. I have just done about the dumbest possible things, telling you the algorithm, using a tiny key and saying what the plain text is but it is still unbreakable unless you have my lock and can test all ten answers
The problem is that with one time pad, as in this example you get as many answers as there are keys and you have no way to know which of the typically trillions of answers is the right one
You're wrong, again.This is no different from other encryption methods; if you know nothing about the contents of encrypted data then you have no way of knowing if what you've decrypted is usable. As I said earlier, if you are encrypting a file-system, then unless the attacker knows this then it becomes difficult for them to know when they've actually found the correct key anyway. You can sort of work around that with statistical analysis but it's the same basic problem; if someone hands you a lump of encrypted data and asks you to decrypt it with no information as to what it is, or how it was encoded, then that's a far more "unbreakable" case than anything else described, as you could guess the key on your first attempt but if it doesn't produce anything recognisably decrypted then it's just as secure as ever
Simple maths and probability can tell you that it is easy to to determine whether you have decrypted a message or not. Since the data have encrypted is usually many, many times bigger than the key, it is mathematically highly improbable that any other key from all the possible keys in the key space will render a valid result, e.g. if we have encrypted a harddrive, it is highly improbable that any key different to the key used for encryption will give us a harddrive with a valid file system header. Likewise with text messages, a decrypted message should have a dominance of roman characters, which again is highly improbable for any other key other than our secret key. If you've ever worked with decryption software or ever wrote any brute-force algorithms you would have known that.
However even if we know what was encrypted using OTP, we still wouldn't be able to decrypt it. If we have an encrypted message that has 1000 characters, any message that consists of 1000 characters can be found during our "brute force" process. Do you get it, finally? We are guessing the whole message. Every byte in the original message has a unique byte in the pad that manipulates it. If we don't have the pad, we can't decrypt the message. It's as simple as that. It's impossible to crack OTP. No buts. It's impossible, stop arguing. So:
is also wrong and just shows you still don't understand how OTP works ("Indeed, the fact that one-time pads aren't applied in stages is actually a weakness" - what are you talking about? One stage is enough for OTP for it to be unbreakable. "A one-time pad is actually only as strong as the smallest unit of data you can verify" - what, what, what? The smallest unit of data you can verify is the whole freaking piece of data, but the problem is YOU CANNOT VERIFY IT. That's the whole point. You seem to know nothing about what you're talking about.). No pattern-matching bollocks will help you since every single byte needs to be guessed. Get it? Get it? Or do I have to explain it to you once more?
Please just simply learn about OTP before you continue this discussion.
OTP is unbreakable. I gave you facts, I gave you sources, I gave you explanations.
Why are you trying so hard to disprove something that is obvious to every cryptologist? Can't you just admit you're wrong?
----------
I will give him an even simpler example.
I am thinking of a single digit number (data that will be encrypted).
I have either added or subtracted a digit from my digit (the pad/key).
My result is 7 (the encrypted message).
What number was I thinking of? Try cracking OTP - it should be fast, the are only 10 keys.
Answer: You cannot tell which number I was thinking of thus you cannot crack OTP! That is the whole point. Now imagine I do this for every single byte in my encrypted data. The same thing applies - you cannot guess every single byte. You simply can't. It doesn't matter if I think of one number or a million numbers. You can't argue that you can break OTP because that defies logic!
Last edited:
Huh!? In case you didn't notice, you are replying to a thread that's almost 4 years old.
This has been already discussed above. Nothing more to say.
