[e12e]

> Apparently Android-encrypted phones are the safest though.

That's odd. I guess the implication is that iPhone hsm is broken (or they can get past a short pin via an exploit that allows brute forcing - typically an hsm should (be possible to configure to) permanently destroy the keys after N attempts).

I suppose it demonstrates that secure encryption requires the user to memorise something equivalent of 96-128 bits of entropy, that will be used for key derivation.

[ed: i suppose it's conceivable that there's an attack against how the iPhone generates symmetric encryption keys, but I would guess that's less likely]

[kop316]

Your intuition is correct on that.

The iPhone encryption from San Bernardino had a 4-digit pin + a long salt, and the long salt is in the iPhones secure enclave. However, the phone would erase itself (don't know if it's the salt or erase everything) after 10 tries. If they were able to image the phone and get the long salt, the keyspace is only 10000, which is trivla to do on a cheap computer today. I believe you can input a long passphrase for iPhone security, and them you'd be back to the problem of a complex passphrase.

Android gives you the option to input a secure passphrase for key derivation, but you can also use a 4 digit PIN/similar non-secure passphrase, and be just as vulnerable. I am not as familiar with additional security measures Android has (I think it does have a similar measure where too many incorrect passphrases will cause it to erase itself).

[Moter8]

As far as I remember, they were able to do copies of the iPhone. (I guess, similar to a nandroid backup on android devices. Explicitely asked if that needs root, and he said they don't need root or any modified bootloader stuff at all.)

They also had jailbreaks/exploits for 10.2 (or the latest version at ~2 months ago)

[rightos]

There's also a relatively low attack value and attack surface for encrypted Android phones vs encrypted iPhones. Everyone who runs an iPhone has it encrypted, while relatively few people running Android devices have them encrypted. In terms of attack surface, the SecureEnclave has many APIs, some of which have had vulnerabilities in the past and it's quite possible to envision a scenario in which others were found and they're able to dump keys from it. It's also quite common on iOS to have weak PINs and similar low security measures, even just bypassing the mitigations against bruteforce attacks could allow them in to a huge number of device. On the other hand, people turning on disk encryption on Android are likely paranoid people who'll set giant passwords. So in terms of a numbers game, even a more basic exploit against iOS would look much more valuable.

In the Android case, often times you need to power off the device to really be protected as the key is just sitting in RAM. But if you've got a powered off Android device that's been encrypted, chances are you have a good challenge on your hands - there's nothing but the encrypted data on disk to work with unless you were to go to an active attack.

[2close4comfort]

Also encryption by default and much larger user base mean there is more focus on iOS than Android (like the old windows versus mac virus argument) the difference I see is that you are much more likely to get compromised by an application on Android than iOS. And since Google has been very friendly with the USG I would find it much more likely that Enclave or not that it will be NSA weakened crypto that will be the demise of your Android rather than exotic exploits of your wifi. And if your paranoid you carry a Nokia 7715 and extra SIMs or you back something Debian based like Purism.

[rightos]

> weakened crypto that will be the demise of your Android rather than exotic exploits of your wifi.

I don't think there's any truth to this - if the crypto were weakened you'd see it broken by that quite quickly - but it's quite strong and follows well accepted stands in the cryptography community, have a look yourself if you like. It's using dm-crypt and dm-crypt is fairly heavily tested and reviewed. Debian and likely Purism use the exact same, so certainly wouldn't be any better in that way.