Hacker News new | past | comments | ask | show | jobs | submit login

> E-mail is fundamentally terribly positioned to do secure messaging

E-mail is fundamentally a way to send a sequence of bytes somewhere (untrusted) so they can be picked up later by someone (trusted).

That’s also literally what Signal is built on so I think you’re overstating the difference.




Secure messaging is much more complex, but here’s a simple example of how that’s not true: TCP is bidirectional and email is one message, fire and forget. That immediately affects your ability to have forward and backward secrecy.


I do not think the OSI model is very useful but you seem to, so let me put it this way: E-mail is bidirectional too just at layer 4 instead of layer 3 (I hope I remembered my layers right!)

E-mail is store-and-forward just like TCP is; how do you think an IP router works? TCP is fully duplex; a tx doesn’t wait behind an rx, exactly like an e-mail reply not waiting behind an e-mail receive. The only difference is that a router will typically use volatile memory to store messages before they are sent but e-mail will typically use disk.

If your security model relies on this difference then your security model is broken. It’s worth noting that Signal does NOT rely on this difference. It relies on participants being mostly online to permit frequent rekeys and not having to retain old keys indefinitely.


No, email is not bidirectional. You send an email, the recipient later opens it. Sure, the recipient's SMTP server might respond right away with an ephemeral key you can use to enjoy forward secrecy, but that server has to store the message for the recipient to retrieve later.

You can't have full forward secrecy with email as it is used today. If you want forward secrecy with email, you need three emails sent in rapid succession: Alice sends a request to Bob, Bob sends a response to accept the request, and Alice sends the actual encrypted email. That would work. But you basically need Bob to be online.


> you need three emails sent in rapid succession

This is partially correct, but they do not need to be in rapid succession, and therefore Bob does not need to be online.


Alice's ephemeral private key must be kept as long as the whole handshake. Bob's is a bit shorter (between the last two messages).

If the messages are slow to come, those ephemeral keys become less and less ephemeral, and could actually be stolen.


That is exactly correct. As I'm sure you know, it is Alice that retains her DH key not the email server or anyone else. As I said:

> If your security model relies on this difference then your security model is broken. It’s worth noting that Signal does NOT rely on this difference. It relies on participants being mostly online to permit frequent rekeys and not having to retain old keys indefinitely.

Signal does not depend on TCP being "bidirectional" as lvh said, it depends on participants being mostly online. This has nothing to do with the transport properties of e-mail vs. TCP.


“Bidirectional”. So peers can mostly talk to each other. Do you really want to die on that particular semantic hill? “These Ethernet frames have source and destination addresses eventually”?


> Do you really want to die on that particular semantic hill?

Sure. The world of cryptography software is already muddled by misinformation, poor practices and misguided appeals to authority. We shouldn't need to spread misinformation about technologies such as e-mail to get people to stop using it.




Applications are open for YC Winter 2020

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

Search: