3 ms·

Can someone correct me if I am wrong, but it seems relatively easy to make an encrypted peer-to-peer messaging system. I mean, simply use a public/private encr

Can someone correct me if I am wrong, but it seems relatively easy to make an encrypted peer-to-peer messaging system. I mean, simply use a public/private encryption algorithm that has proven to be highly secure: - Share your public key openly - Anyone can send a message to you using your public key to encrypt the message - You decrypt with your private key on device Do all the encryption/decryption on device and viola, secure messaging. (This is basically how https works.) Of course this only allows a single device the ability to decrypt the message. However, if you want to allow multiple devices to share a private key, they can simple send each other their own private keys using the same encrypted protocol. In addition, for super paranoid use, a master password could be used to salt the private key so that would be required with the private key to enable decryption. (Which is similar to how password keepers basically work.) What am I missing?

closeparen 9y ago
Who do you trust to distribute the keys? This person is empowered to MITM. Who do you trust to know the metadata about how encrypted messages are flowing? Who do you trust to get the crypto implementation details right? How will you support use of multiple devices? People generally expect seamless switching between phone and laptop these days.
- ricksharp 9y ago
  Public keys are open, they can be distributed any way (they could be published to a hosted directory a shared wherever). Only the device that owns the private key could decrypt the message. In fact encrypted messages could be stored publically anywhere and only the intended recipient could read them. The flow of messages is not encrypted, the system only encrypts message contents. (However, there are options to make it very difficult to trace, but that is a different issue.) Trust is up to the user to decide and is always necessary. Multiple devices is easy enough, a device can encrypt its own private key and send it to another device (using the target devices public key). The target device would now have 2 private keys for decryption.
  - JetSpiegel 9y ago
    Public keys are open, but the hard part is mapping real people to their public keys. How do you know that the public key they send is the real one, and wasn't modified en route? For people you know IRL, this is easy, but for strangers?
    - snakeanus 9y ago
      You could use OpenPGP public keys so you can use the web of trust that comes with them.
adrianN 9y ago
For example you're missing forward secrecy: Do old messages stay secure or not if a key is leaked?
- ricksharp 9y ago
  The public/private keys could be changed periodically. Old private keys could be deleted. Once lost, access to the messages they decrypt would be permanently lost (no searching of message history).
sipos 9y ago
One thing missing is that most users cannot be trusted not to lose their key and still want a way to recover it. LastPass, for example, provides ways to do that, for example by using devices they have used recently but, I don't think it is particularly secure. Spreading the key to multiple devices so that you have a copy of it on another device helps obviously, as does allowing an unencrypted backup of the key, for example on a USB key you store securely. The other problem is paying for it. To deliver messages quickly to all devices, even when they are offline, the messages obviously have to be stored serverside, which takes up space and bandwidth. A federated system, where a user is on a particular server and, you deliver messages to that server, which delivers to their devices (possibly when they come back online) makes managing paying for it easier - you can get other people to host it or, people who can can host it themselves. It also removes the single central point of failure.
- ricksharp 9y ago
  Yes, if you lose your private key, it is gone forever. Otherwise there is no security. (Backup options would depend on the use case.) Yes, payment is a separate issue. It would be assumed that there is value in having this system available to the users that would be outside their messaging needs.
tptacek 9y ago
Which public key algorithm? In what mode of operation? What are you going to use to actually encrypt messages? You don't want to directly use the public key primitives to do this. In what mode of operation are you going to use that second, bulk encryption algorithm? How are you going to authenticate messages? What will you do to validate the public keys of your peers? When you close the application, will it forget everyone's keys? How do you prevent MITM on first contact? What happens when your peers change devices, and thus public keys? How do you authenticate those changes? If you get any of this wrong, remote attackers can MITM messages. How will you handle file transfers (and images and videos and voice, which will probably need yet another cryptosystem)? How will you cryptographically bind those transactions to the (presumably, somehow) authenticated chat session you set up? What happens when someone's device is compromised? Is every chat they've ever sent also compromised? What happens if someone is briefly compromised? Is every message they send in the future also necessarily compromised? How will you handle updating your software when, inevitably, someone finds a vulnerability in it? What happens if you have to upgrade the whole protocol? None of this is easy. Most of these problems by themselves are hard in their own right, but there's a combinatorics to them as well.
- ricksharp 9y ago
  Thanks! This is an excellent list of potential issues. "What are you going to use to actually encrypt messages? You don't want to directly use the public key primitives to do this." I'm not sure what you mean by this. Could you explain why there is a need for another encryption protocol beyond a public/private key encryption? If the protocol is secure against brute force attack, both the public key and the encrypted messages could be open and would not create a vulnerability to the private key. What am I missing?
  - tptacek 9y ago
    * Assymetric transforms are much, much slower than the AES transform or any other block or stream cipher. * In most cases, an asymmetric transform gives you a deceptively small amount of headroom within which to fit your data before losing security. * asymmetric transforms are less safe to implement than simple authenticated symmetric ciphers. * for that matter, cost-effectively authenticating messages will require "symmetric" primitives anyways. * modern asymmetric algorithms (like Curve25519) don't "directly" support encryption. That's just off the top of my head. It is hard to think of a single competent public key cryptosystem that encrypts directly with the asym transform.
tpolm 9y ago
you are missing the fact the OS that runs the system is already compromised and has government backdoors. No matter if you use Telegram / Whatsapp / whatever. Windows / Andriod / iOS / you name it already have a million ways to be compromised and have a backdoor if needed.
deleted 9y ago
[deleted]

closeparen 9y ago

Who do you trust to distribute the keys? This person is empowered to MITM. Who do you trust to know the metadata about how encrypted messages are flowing? Who do you trust to get the crypto implementation details right? How will you support use of multiple devices? People generally expect seamless switching between phone and laptop these days.

ricksharp 9y ago
Public keys are open, they can be distributed any way (they could be published to a hosted directory a shared wherever). Only the device that owns the private key could decrypt the message. In fact encrypted messages could be stored publically anywhere and only the intended recipient could read them. The flow of messages is not encrypted, the system only encrypts message contents. (However, there are options to make it very difficult to trace, but that is a different issue.) Trust is up to the user to decide and is always necessary. Multiple devices is easy enough, a device can encrypt its own private key and send it to another device (using the target devices public key). The target device would now have 2 private keys for decryption.
- JetSpiegel 9y ago
  Public keys are open, but the hard part is mapping real people to their public keys. How do you know that the public key they send is the real one, and wasn't modified en route? For people you know IRL, this is easy, but for strangers?
  - snakeanus 9y ago
    You could use OpenPGP public keys so you can use the web of trust that comes with them.

adrianN 9y ago

For example you're missing forward secrecy: Do old messages stay secure or not if a key is leaked?

ricksharp 9y ago
The public/private keys could be changed periodically. Old private keys could be deleted. Once lost, access to the messages they decrypt would be permanently lost (no searching of message history).

sipos 9y ago

One thing missing is that most users cannot be trusted not to lose their key and still want a way to recover it. LastPass, for example, provides ways to do that, for example by using devices they have used recently but, I don't think it is particularly secure. Spreading the key to multiple devices so that you have a copy of it on another device helps obviously, as does allowing an unencrypted backup of the key, for example on a USB key you store securely. The other problem is paying for it. To deliver messages quickly to all devices, even when they are offline, the messages obviously have to be stored serverside, which takes up space and bandwidth. A federated system, where a user is on a particular server and, you deliver messages to that server, which delivers to their devices (possibly when they come back online) makes managing paying for it easier - you can get other people to host it or, people who can can host it themselves. It also removes the single central point of failure.

ricksharp 9y ago
Yes, if you lose your private key, it is gone forever. Otherwise there is no security. (Backup options would depend on the use case.) Yes, payment is a separate issue. It would be assumed that there is value in having this system available to the users that would be outside their messaging needs.

tptacek 9y ago

Which public key algorithm? In what mode of operation? What are you going to use to actually encrypt messages? You don't want to directly use the public key primitives to do this. In what mode of operation are you going to use that second, bulk encryption algorithm? How are you going to authenticate messages? What will you do to validate the public keys of your peers? When you close the application, will it forget everyone's keys? How do you prevent MITM on first contact? What happens when your peers change devices, and thus public keys? How do you authenticate those changes? If you get any of this wrong, remote attackers can MITM messages. How will you handle file transfers (and images and videos and voice, which will probably need yet another cryptosystem)? How will you cryptographically bind those transactions to the (presumably, somehow) authenticated chat session you set up? What happens when someone's device is compromised? Is every chat they've ever sent also compromised? What happens if someone is briefly compromised? Is every message they send in the future also necessarily compromised? How will you handle updating your software when, inevitably, someone finds a vulnerability in it? What happens if you have to upgrade the whole protocol? None of this is easy. Most of these problems by themselves are hard in their own right, but there's a combinatorics to them as well.

ricksharp 9y ago
Thanks! This is an excellent list of potential issues. "What are you going to use to actually encrypt messages? You don't want to directly use the public key primitives to do this." I'm not sure what you mean by this. Could you explain why there is a need for another encryption protocol beyond a public/private key encryption? If the protocol is secure against brute force attack, both the public key and the encrypted messages could be open and would not create a vulnerability to the private key. What am I missing?
- tptacek 9y ago
  * Assymetric transforms are much, much slower than the AES transform or any other block or stream cipher. * In most cases, an asymmetric transform gives you a deceptively small amount of headroom within which to fit your data before losing security. * asymmetric transforms are less safe to implement than simple authenticated symmetric ciphers. * for that matter, cost-effectively authenticating messages will require "symmetric" primitives anyways. * modern asymmetric algorithms (like Curve25519) don't "directly" support encryption. That's just off the top of my head. It is hard to think of a single competent public key cryptosystem that encrypts directly with the asym transform.

tpolm 9y ago

you are missing the fact the OS that runs the system is already compromised and has government backdoors. No matter if you use Telegram / Whatsapp / whatever. Windows / Andriod / iOS / you name it already have a million ways to be compromised and have a backdoor if needed.

deleted 9y ago

[deleted]