Hacker News Reader

Comment by modeless | Hacker News Reader

I'm glad ADP exists now, but you have to make sure everyone you message has it enabled too, or your messages are still Apple's to read whenever they choose. Meanwhile Google's equivalent backup feature (whatever other faults it may have) has been end-to-end encrypted by default for everyone since long before ADP was even available at all. The risk of losing access is practically nonexistent because the password is your screen lock code, the same one you enter on your lock screen literally every day.

Also, is government spying the only reason Apple decrypts messages? We don't know. They don't disclose that they do it for the government, but we know they do from other sources. What other purposes might they not be disclosing?

View on HN

The concern is if you lose your devices with E2EE enabled then you are locked out permanently. Grandma won't know how to use a Yubikey (which is the alternative Apple provides for this eventuality with ADP enabled) and will be out of luck.

This is not a requirement with Google's solution. After losing all your devices you only need your lock screen code to decrypt your backup, as I said. This is achieved using a secure element on the datacenter side to protect against brute-force attacks on the screen lock code.

> the password is your screen lock code

You mean the one that by default is a 4 digit number and therefore trivially brute forcable?

And neither android hardware nor the google servers have any kind of secure element enforcing brute force protections like '3 tries then we wipe the keys'.

> neither android hardware nor the google servers have any kind of secure element enforcing brute force protections

I don't know why you would say this when it is obviously false. https://security.googleblog.com/2018/10/google-and-android-h...

do they actually enforce these limits? I couldn't find any google UI which says "2 tries left or your data will be permanently erased".

One can't implement brute force protections without such a UI...

"You need to wait 5 minutes" isn't sufficient for a 4 digit pin...

The waiting time increases after failed attempts.

In general that isn't secure unless the security chip has access to a secure time server to know that the required amount of time has passed.

Otherwise you can simply say "yeah, we power cycled you and now the year is 100,000, can I have another guess?"

I don't see any mention of that functionality in any public documentation.

So now you just need to fake a cell tower and a GPS constellation so that the phone gets a new time on power cycle. Which would be about 60s minimum, to boot and acquire.

And that’s with a power cycle, so 14,000 a day? I’ll not going to assume the button will last more than 100,000 presses, so I don’t see many combinations being tried.

You can spoof GPS with a hackrf so this is not actually that crazy, I wouldn’t be surprised if certain 3 letter agencies have tried this already.

I'm not sure how different devices implement it, but the security chip can simply count the time it was powered on, it doesn't have to rely on wall clock time.

(Relying on wall clock time caused a bug in an early iOS version of this feature, where it would show a really long delay when the clock was reset, and there was no way to set the clock correctly)

I can't speak to Pixels personally but every Samsung phone I've owned that I can remember has exactly that.

https://www.reddit.com/r/samsung/comments/13nnphc/delete_pho...

> And neither android hardware nor the google servers have any kind of secure element enforcing brute force protections

The Titan M chip is present on all Pixel devices:

https://grapheneos.org/faq#encryption

I don’t believe that on Android or iOS it defaults to 4-Digits anymore, does it?

Reply on news.ycombinator.com