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

I'm happy they are catching criminals, but now I wonder how many of my encryption and privacy software is actually an FBI front.


That is why effective end to end encryption is so important. It doesn't matter who is behind it. That is the whole point. No trust required.


The app can just leak your keys to a central database? Using code other people wrote/compiled always requires trust.


The three requirements for effective end to end encryption:

1. All cryptographic keys controlled by the users.

2. Some way to confirm you are actually connected to who you think you are connected to.

3. A way to confirm that the code you are running is not leaking keys/content.


Could the OS lock down the app's permissions to prevent that?

Like, this app can ONLY send/recv e2e encrypted messages, and not log anything or talk to other apps.


The app could still send your keys _as_ an e2e message (to the app author). OS enforcement would need to be pretty intrusive to stop this (e.g. a pop-up for every message sent, displaying the actual destination of the message). I bet users would get pretty blind to such pop-ups, and it would be easy to trick them into accepting the leaking of their private keys.


If you trust the OS, it could hypothetically be built into the OS such that the app only gives what needs to be encrypted to the OS and gets back an encrypted payload to send, then the app wouldn't need to access your keys?

Of course at that point the OS has to either provide good key management itself, or a good API so that the apps can still make things seamless while still not accessing the keys directly.. and probably other problems I haven't thought of.


Makes sense. OS already does key storage (eg, secure enclave [1]) so its not hard to imagine en/decrypt without the key leaving storage.

[1] https://developer.apple.com/documentation/security/certifica...


Yeah good point, for that matter you need to trust the app isn't cc'ing the FBI on every message you send.




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

Search: