4 ms·

If I remember correctly from their statement on this issue before they were baaically unaffected by the new laws as they do not off end-to-end encryption, so th

by Jedi72 8y ago

If I remember correctly from their statement on this issue before they were baaically unaffected by the new laws as they do not off end-to-end encryption, so they were already open to lawful intercept requests.

bad_user 8y ago
Email services claiming e2e encryption are snake oil. It’s interesting to me how a demographics like that of HN can fall for it.
- isostatic 8y ago
  So when I send my gpg mail, it’s not encrypted?
  - ownagefool 8y ago
    Yes, it is. But if this is a feature of a mail service rather than a mail client, then the service has the keys and, given GPG has no perfect forward secrecy, they have the ability to decrypt all emails you send and recieve. If you go down the road of the mail service owning a mail client that promises e2e, then the issue moves to worrying about the code that runs on your device. If it's webmail, the JavaScript can easily be changed, so you really want a thick client. Then you need to worry about the thick client sending data that it's really not supposed to i.e. can it read your key and send it to $vendor? Even then, GPG without Perfect Forward Secrecy means that when your key is brute forced or side channel attacked, which we assume will happen, you lose all your secrecy, so you need to think about this as a temporary state.
    - bad_user 8y ago
      Note that the key could be client side and the email service could encrypt the email in a way as to not find out your private key. However, and this is key, a majority of email is sent and received unencrypted via their servers, because that's just how email works. In other words, email at rest might be encrypted, but most of the email in transit is not. This means that a man in the middle (e.g. the NSA) can still intercept all your communications. And even with PGP encryption, which is e2e, the meta data is still unencrypted because that's what the email protocol demands. Having the ability to see whom you're communicating with, that's enough in many cases. Email is simply not a good solution for e2e encryption. If you have secrets to protect, there are now other solutions available, like Signal and even Signal has some issues (like its reliance on phone numbers for identification).
- eeeeeeeeeeeee 8y ago
  Agreed. But having encryption at rest on your stored email would be a decent feature. Now it looks like if FastMail added that, they could be compelled by the government to break it anyway, without notifying the user.
  - cyphar 8y ago
    Mailbox.org has a feature like that, where all incoming messages are PGP encrypted to your public key when they're received so there's only a small window where they have the plaintext (and the plaintext isn't stored long-term nor is it stored in a way where they can decrypt it). The problem is that fundamentally email still provides them the plaintext -- so they wouldn't need to add a new capability or break the design of their at-rest crypto, they would simply have to stash away emails that were requested by a warrant. The problem is that e2e messaging applications, where there is no way for the server to do this, are going to be in quite serious trouble. They would need to re-design their crypto so they can add additional "backdoor" device keys that let them access the messages, or provide backdoored binaries to the relevant target. And that's what TCNs will be used for -- to compel those kinds of backdoors.

by Jedi72 8y ago

bad_user 8y ago

Email services claiming e2e encryption are snake oil. It’s interesting to me how a demographics like that of HN can fall for it.

isostatic 8y ago
So when I send my gpg mail, it’s not encrypted?
- ownagefool 8y ago
  Yes, it is. But if this is a feature of a mail service rather than a mail client, then the service has the keys and, given GPG has no perfect forward secrecy, they have the ability to decrypt all emails you send and recieve. If you go down the road of the mail service owning a mail client that promises e2e, then the issue moves to worrying about the code that runs on your device. If it's webmail, the JavaScript can easily be changed, so you really want a thick client. Then you need to worry about the thick client sending data that it's really not supposed to i.e. can it read your key and send it to $vendor? Even then, GPG without Perfect Forward Secrecy means that when your key is brute forced or side channel attacked, which we assume will happen, you lose all your secrecy, so you need to think about this as a temporary state.
  - bad_user 8y ago
    Note that the key could be client side and the email service could encrypt the email in a way as to not find out your private key. However, and this is key, a majority of email is sent and received unencrypted via their servers, because that's just how email works. In other words, email at rest might be encrypted, but most of the email in transit is not. This means that a man in the middle (e.g. the NSA) can still intercept all your communications. And even with PGP encryption, which is e2e, the meta data is still unencrypted because that's what the email protocol demands. Having the ability to see whom you're communicating with, that's enough in many cases. Email is simply not a good solution for e2e encryption. If you have secrets to protect, there are now other solutions available, like Signal and even Signal has some issues (like its reliance on phone numbers for identification).
eeeeeeeeeeeee 8y ago
Agreed. But having encryption at rest on your stored email would be a decent feature. Now it looks like if FastMail added that, they could be compelled by the government to break it anyway, without notifying the user.
- cyphar 8y ago
  Mailbox.org has a feature like that, where all incoming messages are PGP encrypted to your public key when they're received so there's only a small window where they have the plaintext (and the plaintext isn't stored long-term nor is it stored in a way where they can decrypt it). The problem is that fundamentally email still provides them the plaintext -- so they wouldn't need to add a new capability or break the design of their at-rest crypto, they would simply have to stash away emails that were requested by a warrant. The problem is that e2e messaging applications, where there is no way for the server to do this, are going to be in quite serious trouble. They would need to re-design their crypto so they can add additional "backdoor" device keys that let them access the messages, or provide backdoored binaries to the relevant target. And that's what TCNs will be used for -- to compel those kinds of backdoors.