4 ms·

I don't get it. Full end-to-end encryption means you can validate the identity of the sender. Once you can do that blacklisting bad actors or whitelisting kno

by zzalpha 12y ago

I don't get it. Full end-to-end encryption means you can validate the identity of the sender. Once you can do that blacklisting bad actors or whitelisting known-good actors is trivial. Even hijacking accounts in this model for the purpose of sending spam doesn't work unless you can also gain access to the private key, which itself would be non-trivial. Encrypt that private key with a strong passphrase and you're in even better shape. What am I missing?

dredmorbius 12y ago
you can validate the identity of the sender No you cannot. Encrypting and authenticating are two separate acts. Mutt with GPG/PGP support makes this clear -- your options are to sign (authenticate + integrity) and/or encrypt a message (you can do either, both, or none). It's possible that you'll still be able to do header checks, though if people move increasingly to onion routing their Internet traffic, a lot of source-based validation (IP checks) will fail. A great deal of spam detection works on noting the origin and contents of messages, and yes, absolutely, encryption makes that harder. It does, however, also increase the costs for the spammer. And there might be other ways to improve protocols. But it's a challenge.
- zzalpha 12y ago
  I'm quite aware that encryption and authentication are separable elements in a PKI cryptosystem. But I don't believe that invalidates my point. Assuming a PKI cryptosystem, I can (and I contend should) greylist all emails that aren't signed by senders in my whitelist. Again, I accept I could be missing something here. Maybe that model doesn't scale effectively or something. I don't know, I admit I haven't thought the use cases through that thoroughly. It certainly adds a burden on the receiver side, but it works (unlike today where whitelists can be defeated by forging the sender address in the email header). Of course, it's true that the original comment is fundamentally correct: encryption basically obsoletes existing anti-spam technologies if the payload is encrypted. It just seems to me that e2e crypto provides the tools for a whole different range of anti-spam options that aren't possible today.
  - deegles 12y ago
    There's a thorough overview of current techniques and how they would be invalidated by encryption in the post I linked to. I agree that e2e crypto would enable new techniques, but that wasn't my point.
    - zzalpha 12y ago
      Heh, fair enough. I think I was caught up by the word "all" in the phrase "would break basically all anti-spam technologies". I read that as implying that e2e encryption makes managing spam impossible. Seems clear that wasn't the intent, so... yeah, have a happy new year!
      - deegles 12y ago
        Maybe I was a bit hyperbolic :)
  - jcrites 12y ago
    End-to-end encryption does not invalidate most existing anti-spam technologies. However, these technologies will need to run after decrypting the content, which may mean on the end user's machine(s). Less processing horsepower will be available than with server-side techniques, but the same techniques can still apply. If your mobile device and desktop PC both possess your decryption key, then your desktop PC could act as the anti-spam engine and transmit a list of good messages to your mobile device. A bigger problem would be ISPs who wish to keep their anti-spam techniques confidential and evaluate them only on their own servers. Allowing the end-users to download the scanning logic and run it locally would create a risk of divulging their proprietary techniques. The ability to keep software truly confidential and under its creator's control is one of the motivating factors behind the rise of software as a service. Whitelisting can also go a long way toward allowing only preapproved authorized senders to communicate with you using end-to-end encryption. The remaining senders might communicate with messages that are encrypted to your ISP instead. The DIME protocol anticipates this sort of layered encryption: https://news.ycombinator.com/item?id=8816806 https://news.ycombinator.com/item?id=8816806 When someone wishes to communicate with you using end-to-end encryption, they might first send an "introduction" message encrypted to your ISP, which can be scanned. Then the receiver can decide to authorize the sender for E2E or not.

by zzalpha 12y ago

dredmorbius 12y ago

you can validate the identity of the sender No you cannot. Encrypting and authenticating are two separate acts. Mutt with GPG/PGP support makes this clear -- your options are to sign (authenticate + integrity) and/or encrypt a message (you can do either, both, or none). It's possible that you'll still be able to do header checks, though if people move increasingly to onion routing their Internet traffic, a lot of source-based validation (IP checks) will fail. A great deal of spam detection works on noting the origin and contents of messages, and yes, absolutely, encryption makes that harder. It does, however, also increase the costs for the spammer. And there might be other ways to improve protocols. But it's a challenge.

zzalpha 12y ago
I'm quite aware that encryption and authentication are separable elements in a PKI cryptosystem. But I don't believe that invalidates my point. Assuming a PKI cryptosystem, I can (and I contend should) greylist all emails that aren't signed by senders in my whitelist. Again, I accept I could be missing something here. Maybe that model doesn't scale effectively or something. I don't know, I admit I haven't thought the use cases through that thoroughly. It certainly adds a burden on the receiver side, but it works (unlike today where whitelists can be defeated by forging the sender address in the email header). Of course, it's true that the original comment is fundamentally correct: encryption basically obsoletes existing anti-spam technologies if the payload is encrypted. It just seems to me that e2e crypto provides the tools for a whole different range of anti-spam options that aren't possible today.
- deegles 12y ago
  There's a thorough overview of current techniques and how they would be invalidated by encryption in the post I linked to. I agree that e2e crypto would enable new techniques, but that wasn't my point.
  - zzalpha 12y ago
    Heh, fair enough. I think I was caught up by the word "all" in the phrase "would break basically all anti-spam technologies". I read that as implying that e2e encryption makes managing spam impossible. Seems clear that wasn't the intent, so... yeah, have a happy new year!
    - deegles 12y ago
      Maybe I was a bit hyperbolic :)
- jcrites 12y ago
  End-to-end encryption does not invalidate most existing anti-spam technologies. However, these technologies will need to run after decrypting the content, which may mean on the end user's machine(s). Less processing horsepower will be available than with server-side techniques, but the same techniques can still apply. If your mobile device and desktop PC both possess your decryption key, then your desktop PC could act as the anti-spam engine and transmit a list of good messages to your mobile device. A bigger problem would be ISPs who wish to keep their anti-spam techniques confidential and evaluate them only on their own servers. Allowing the end-users to download the scanning logic and run it locally would create a risk of divulging their proprietary techniques. The ability to keep software truly confidential and under its creator's control is one of the motivating factors behind the rise of software as a service. Whitelisting can also go a long way toward allowing only preapproved authorized senders to communicate with you using end-to-end encryption. The remaining senders might communicate with messages that are encrypted to your ISP instead. The DIME protocol anticipates this sort of layered encryption: https://news.ycombinator.com/item?id=8816806 https://news.ycombinator.com/item?id=8816806 When someone wishes to communicate with you using end-to-end encryption, they might first send an "introduction" message encrypted to your ISP, which can be scanned. Then the receiver can decide to authorize the sender for E2E or not.