4 ms·

PGP isn’t architecturally well-equipped to provide forward secrecy i have no insight into the development, but i suppose that swapping out PGP for something en

by em-bee 1y ago

PGP isn’t architecturally well-equipped to provide forward secrecy i have no insight into the development, but i suppose that swapping out PGP for something entirely different should technically be possible. they did develop a peer to peer protocol with forward security for real-time messages that sidesteps SMTP entirely. seems a bit wierd given the premise, but the devs are at least not limiting themselves to SMTP and PGP.

woodruffw 1y ago
> but i suppose that swapping out PGP for something entirely different should technically be possible. That would probably be good, but email is still a terrible substrate for secure messaging. Clear metadata is security poison; you want as little of it revealed to participant servers as possible. > they did develop a peer to peer protocol with forward security for real-time messages that sidesteps SMTP entirely. That’s great, but in that case: what’s the value proposition relative to Signal or even Matrix?
- em-bee 1y ago
  the peer to peer protocol at this point is only for realtime communication at which both parties have to be present. like IRC, those messages are not saved. it does not replace regular messaging which is stored. i was merely trying to point out that the developers are capable of thinking outside of the box that they started from and that deltachat may develop in a different direction. as someone else stated, deltachat's value is that it is able to reuse existing infrastructure and does not require (but allow) a new set of servers to be able to work.
  - woodruffw 1y ago
    > i was merely trying to point out that the developers are capable of thinking outside of the box that they started from and that deltachat may develop in a different direction. I mean this kindly: I wish they would think a little bit more inside the box, and converge onto a proven design. (It’s worth noting that your “existing infrastructure” argument is exactly why Signal uses phone numbers. Using existing infrastructure is a great idea, so long as it doesn’t compromise the security expectations any reasonable user has. That isn’t currently true for Delta Chat.)
    - em-bee 1y ago
      exactly why Signal uses phone numbers the reason may be the same, but the effect is entirely different. until recently signal did not allow hiding the phone number, failing my privacy expectations. a public phone number is something entirely different than a public email address. signal is also centralized with its own servers. deltachat works completely without dedicated servers. and emails easily allow multiple accounts. and what are reasonable security expectations? what you and i consider reasonable does not at all match what the general population expects. for most people sending encrypted emails would already be a win. (autocrypt also works with regular email clients, not just deltachat) the goal here is to raise the general use of encryption in messages. if that is not sufficient then deltachat is not the right tool. but i have friends on telegram and whatsapp. getting them to use deltachat would be an improvement.
      - woodruffw 1y ago
        Centralization is not a security property in the context of E2EE. You can want decentralization (I often do), but it’s essentially an ideological demand rather than a security preference when the server provably has no access to your messages or metadata. > and what are reasonable security expectations? End-to-end encryption that the user can’t accidentally downgrade from and that doesn’t spray valuable metadata across the Internet. That’s table stakes; I’m not interested in lowering my standards below that. > for most people sending encrypted emails would already be a win. I don’t think this is even remotely true. I think the average person doesn’t know what an encrypted email is. We’re now in at least the third decade of encrypted email techniques, and adoption outside of corporate S/MIME (another can of worms) is marginal. There’s almost too much to even say here; it’s a disservice to even accept the implicit assumption that users would use encrypted email correctly if they could be made to: the single most common breakage point for all of this stuff is still people replying or forwarding previously encrypted messages in the clear! > the goal here is to raise the general use of encryption in messages. No. The goal is security. “General use of encryption” goes back to putting ideology before security. The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people. The US famously kills people based on metadata[1], and we’re the “strict” ones in terms of evidentiary standards. [1]: https://www.nybooks.com/online/2014/05/10/we-kill-people-based-metadata/ https://www.nybooks.com/online/2014/05/10/we-kill-people-bas...

by em-bee 1y ago

woodruffw 1y ago

> but i suppose that swapping out PGP for something entirely different should technically be possible. That would probably be good, but email is still a terrible substrate for secure messaging. Clear metadata is security poison; you want as little of it revealed to participant servers as possible. > they did develop a peer to peer protocol with forward security for real-time messages that sidesteps SMTP entirely. That’s great, but in that case: what’s the value proposition relative to Signal or even Matrix?

em-bee 1y ago
the peer to peer protocol at this point is only for realtime communication at which both parties have to be present. like IRC, those messages are not saved. it does not replace regular messaging which is stored. i was merely trying to point out that the developers are capable of thinking outside of the box that they started from and that deltachat may develop in a different direction. as someone else stated, deltachat's value is that it is able to reuse existing infrastructure and does not require (but allow) a new set of servers to be able to work.
- woodruffw 1y ago
  > i was merely trying to point out that the developers are capable of thinking outside of the box that they started from and that deltachat may develop in a different direction. I mean this kindly: I wish they would think a little bit more inside the box, and converge onto a proven design. (It’s worth noting that your “existing infrastructure” argument is exactly why Signal uses phone numbers. Using existing infrastructure is a great idea, so long as it doesn’t compromise the security expectations any reasonable user has. That isn’t currently true for Delta Chat.)
  - em-bee 1y ago
    exactly why Signal uses phone numbers the reason may be the same, but the effect is entirely different. until recently signal did not allow hiding the phone number, failing my privacy expectations. a public phone number is something entirely different than a public email address. signal is also centralized with its own servers. deltachat works completely without dedicated servers. and emails easily allow multiple accounts. and what are reasonable security expectations? what you and i consider reasonable does not at all match what the general population expects. for most people sending encrypted emails would already be a win. (autocrypt also works with regular email clients, not just deltachat) the goal here is to raise the general use of encryption in messages. if that is not sufficient then deltachat is not the right tool. but i have friends on telegram and whatsapp. getting them to use deltachat would be an improvement.
    - woodruffw 1y ago
      Centralization is not a security property in the context of E2EE. You can want decentralization (I often do), but it’s essentially an ideological demand rather than a security preference when the server provably has no access to your messages or metadata. > and what are reasonable security expectations? End-to-end encryption that the user can’t accidentally downgrade from and that doesn’t spray valuable metadata across the Internet. That’s table stakes; I’m not interested in lowering my standards below that. > for most people sending encrypted emails would already be a win. I don’t think this is even remotely true. I think the average person doesn’t know what an encrypted email is. We’re now in at least the third decade of encrypted email techniques, and adoption outside of corporate S/MIME (another can of worms) is marginal. There’s almost too much to even say here; it’s a disservice to even accept the implicit assumption that users would use encrypted email correctly if they could be made to: the single most common breakage point for all of this stuff is still people replying or forwarding previously encrypted messages in the clear! > the goal here is to raise the general use of encryption in messages. No. The goal is security. “General use of encryption” goes back to putting ideology before security. The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people. The US famously kills people based on metadata[1], and we’re the “strict” ones in terms of evidentiary standards. [1]: https://www.nybooks.com/online/2014/05/10/we-kill-people-based-metadata/ https://www.nybooks.com/online/2014/05/10/we-kill-people-bas...