Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In this case both ends are you. You could back up on one phone and restore on another.

You're right that "E2E" is slightly ambiguous. But "encryption at rest" is even worse in my opinion, since it could just mean that Apple/Google's datacenters have disk encryption with a key they can access.



I am neither the authority to define "encryption at rest", nor am i saying "encryption at rest" is good wording in this case.

But from my understanding, "encryption at rest" is not disk encryption.

If you have a database with disk encryption, once the disk crypto key is entered an attacker could try to "do hacker stuff" and exfiltrate the WAL files.

If you have "encryption at rest", the WAL files are written encrypted and are decrypted on read. An attacker may get your WAL files, but they are still encrypted.


There are likely multiple definitions. This Azure definition disagrees with you:

>Encryption at rest is designed to prevent the attacker from accessing the unencrypted data by ensuring the data is encrypted when on disk. If an attacker obtains a hard drive with encrypted data but not the encryption keys, the attacker must defeat the encryption to read the data.

https://docs.microsoft.com/en-us/azure/security/fundamentals...

So with this definition encryption at rest has the threat model of an attacker who can physically steal a hard drive but not the hard drive's encryption key.


Well if Facebook is encrypting I'm hoping Apple/Google can't decrypt on their datacenters. That would be really weird. Just with the key that I hold (aka my app account). I've always understood E2EE as an in transit thing or public/private key where it is encrypted till the other end. I definitely want my backups sitting at rest on some server where I have no ends and it is just a loop.


>Well if Facebook is encrypting I'm hoping Apple/Google can't decrypt on their datacenters.

I was referring to the prior backup scheme where Facebook wasn't encrypting. It could accurately be described as encrypted at rest I think, but yet Google and Apple could read the contents I think.

>no ends and it is just a loop.

The terminology is getting pretty confusing at this point. I usually think of the ends as the intended parties to look at the data. If there are no ends, then no one will look at the data, meaning the data is useless. Actually if there's no beginning end, there's no one to create the data, so thus the data doesn't even exist.


Next step is who owns the key, if it is FB that kills E2E story. If it is user, they'll forget/lose it, so it doesn't scale to 2B users. Currently Apple/Google are set as the custodians of the key.


From the pdf, it sounds like the HSM owns the key, and will only give it up if the correct password is provided.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: