Hacker News Reader

Hacker News

Comment by ricksharp | Hacker News Reader

Full thread

ricksharp

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?

View on HN

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.

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?

* 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.

> What happens if someone is briefly compromised?

Could you give an example please? How do current protocols deal with that?

https://en.wikipedia.org/wiki/Forward_secrecy

I know about forward secrecy but my question is how you could protect future seasons, not past seasons.

Negotiate new keys with Diffie-Hellman periodically, I think.

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

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).

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.

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.

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.

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.

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?

You could use OpenPGP public keys so you can use the web of trust that comes with them.

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.

Reply on news.ycombinator.com