This blog is reserved for more serious things, and ordinarily I wouldn’t spend time on questions like the above. But much as I’d like to spend my time writing about exciting topics, som…
True, device encryption should be up to the user. Mine is encrypted, and most smartphones have encrypted storage these days. I actually have mine reboot after a period of inactivity, which removes the encryption keys from memory.
That said, they should have an option for app data encryption, but that’s hardly a requirement IMO, because I care far more about data being encrypted in transit than at rest on my devices. I can encrypt data at rest on my machines, I can’t encrypt data in-transit unless that’s baked in to the service.
That said, they should have an option for app data encryption, but that’s hardly a requirement IMO
So Telegram is not an encrypted messenger because there are types of messages that are not E2E encrypted but Signal is a encrypted messenger because encrypting local storage is optional. Got it.
Yes, because the “encrypted messenger” metric is about sending and receiving messages, not storing messages. On the order of things I care about, E2EE is much more important than local storage. I can do something about local storage, I can’t realistically do anything about E2EE.
Sure, but what happens when my contacts forget to push it and send me confidential information? I can be the most careful person in the world and always press that button, but I cannot control what others do. That’s why it needs to be E2EE for everyone.
Law enforcement would require a warrant, and criminals would need to break into my device first (highly unlikely without it being a targeted attack, and that’s not in my threat model at all).
And if they can break the encryption on my devices, they can likely break the encryption of the data at rest. Most people would probably use the same key for both anyway (biometrics or a PIN). If I need it to be more secure, I can create a special encrypted container for that service to store its data in.
I’d like to see them try. I use GrapheneOS, and it reboots after a period of inactivity, so the decryption keys aren’t even loaded into memory unless I’ve used my phone recently. There are also constitutional protections so the government can’t take my data without my permission, or with a warrant (if they can break the encryption, that is).
Even your average smartphone w/o any special setup is encrypted by default, though a lot of people use pretty awful security (i.e. only biometrics, and police can unlock your device with your biometrics violating your right to not self-incriminate).
It would be nice if Signal stored my data encrypted, but my devices are already encrypted (phone, desktop, and laptop), are usually in my possession, and have extra layers of protection on top to prevent stealing my data. So I’m a lot more comfortable with “unencrypted” data at rest than the chance that a contact will send me an unencrypted, sensitive message. I can mitigate the former, I can’t do anything about the latter.
True, device encryption should be up to the user. Mine is encrypted, and most smartphones have encrypted storage these days. I actually have mine reboot after a period of inactivity, which removes the encryption keys from memory.
That said, they should have an option for app data encryption, but that’s hardly a requirement IMO, because I care far more about data being encrypted in transit than at rest on my devices. I can encrypt data at rest on my machines, I can’t encrypt data in-transit unless that’s baked in to the service.
So Telegram is not an encrypted messenger because there are types of messages that are not E2E encrypted but Signal is a encrypted messenger because encrypting local storage is optional. Got it.
Yes, because the “encrypted messenger” metric is about sending and receiving messages, not storing messages. On the order of things I care about, E2EE is much more important than local storage. I can do something about local storage, I can’t realistically do anything about E2EE.
You can enable secret chat. Like press the button. But that’s probably too difficult compared to encrypting you devices.
Sure, but what happens when my contacts forget to push it and send me confidential information? I can be the most careful person in the world and always press that button, but I cannot control what others do. That’s why it needs to be E2EE for everyone.
So whether or not the messages can be retrieved by criminals or law enforcement is not a metric. Got it!
Law enforcement would require a warrant, and criminals would need to break into my device first (highly unlikely without it being a targeted attack, and that’s not in my threat model at all).
And if they can break the encryption on my devices, they can likely break the encryption of the data at rest. Most people would probably use the same key for both anyway (biometrics or a PIN). If I need it to be more secure, I can create a special encrypted container for that service to store its data in.
Encrypted from your girlfriend or yourself if you forgot your gesture, but not from Google/Apple/Government or anyone who actually wants your data.
I’d like to see them try. I use GrapheneOS, and it reboots after a period of inactivity, so the decryption keys aren’t even loaded into memory unless I’ve used my phone recently. There are also constitutional protections so the government can’t take my data without my permission, or with a warrant (if they can break the encryption, that is).
Even your average smartphone w/o any special setup is encrypted by default, though a lot of people use pretty awful security (i.e. only biometrics, and police can unlock your device with your biometrics violating your right to not self-incriminate).
It would be nice if Signal stored my data encrypted, but my devices are already encrypted (phone, desktop, and laptop), are usually in my possession, and have extra layers of protection on top to prevent stealing my data. So I’m a lot more comfortable with “unencrypted” data at rest than the chance that a contact will send me an unencrypted, sensitive message. I can mitigate the former, I can’t do anything about the latter.