Hacker News Reader

Comment by upofadown | Hacker News Reader

>The “double ratchet” algorithm is integral to modern end-to-end-encrypted chat apps, such as Signal, WhatsApp, and Matrix.

Signal protocol uses a hash ratchet for the message to message forward secrecy. So you don't need to do the expensive key agreement stuff unless that hash ratchet falls out of synchronization.

It isn't really clear if any messaging application really needs message to message forward secrecy in the first place. You really only need to do that expensive key agreement operation when you want to get rid of some old messages that someone has captured off the wire. That can be reasonably done at the end of a session or even weekly. Very few people need messages that have not even scrolled off the screen to be forward secret, assuming they need it at all.

View on HN

I'm not sure you gain much by moving the forward secrecy to a weekly or session based level, and I think you lose a lot in terms of simplicity.

It is simpler to design and analyze if it applies at every message. It's a design for the best case. No longer need to make judgement calls on if 1 week is enough, or maybe 2, or maybe some middle ground.

Say it takes a $5,000 machine 24 hours to break the code. Clearly it's much more attractive to an attacker if they can break a weeks worth of messages than 10 seconds worth.

You really only need to do that expensive key agreement operation when you want to get rid of some old messages that someone has captured off the wire.

Could you perhaps share more of your analysis here? I'd like to be able to better follow what you are trying to say.

If you are using a temporary shared secret then after you forget that shared secret you will need a new secret which you will have to generate. I mean nothing more than that.

Right, why would anyone ever be better off holding that temporary secret over many messages and many days?

My entire point is that it is not really necessary to do shared secret generation at any but a very slow rate. Even if you don't so it the Signal protocol way it is still perfectly reasonable to only do it once in a while. That might be a short while but it could reasonably be quite long.

Why is it reasonable to only do shared secret generation once in awhile? What's the win to doing that? The win to not doing it is that it narrows the blast radius of a single key compromise to a small number of messages (or, in full ratchets, to a single message). Why would I ever, ever want to increase the blast radius of a key?

On the assumption that it's expensive (I don't know if it's true or not, but upofadown said so explicitly and you didn't contradict them), the win is saving that expense. Obviously if you can reduce the blast radius for free then you do so, but if it's not free then it's reasonable to ask how big the difference between one message/several messages/a week's worth of messages is in your threat model.

It is not expensive.

> What's the win to doing that?

The win is that you spend less processing power on elliptic-curve cryptographic operations. Just like (even if RSA didn't have all its other problems) there's a win to using ECC instead of X-thousand-bit RSA.

> That can be reasonably done at the end of a session or even weekly.

At the end of a session might be reasonable cryptographically, but isn't really reasonable in terms of application development; you don't consistently get to have use CPU and network when a session ends and you may not get access again until a new session begins. A weekly trigger is more likely to be practical, but that may not work consistently either. Better to do the ratchetting as you're doing the messaging to guarantee it gets done.

Reply on news.ycombinator.com