Implementing Signal's Double Ratchet algorithm (2020) | Hacker News Reader

Implementing Signal's Double Ratchet algorithm (2020)

nfil.dev

97 pointstodsacerdoti8 comments

An implementation of the double ratchet in Javascript:

based on an earlier implementation I did in Common Lisp:

https://github.com/rongarret/tweetnacl/blob/master/ratchet.l...

For anyone sensitive to metadata collection (phone numbers), there's SimpleX.chat which is private and secure by default. If you want more complete metadata protection you will also want Orbot (in Power User Mode) and make the following config changes in SimpleX:

Network & servers > Use SOCKS proxy - ON

Network & servers > SOCKS proxy settings > Proxy - 127.0.0.1:9050

Network & servers > SOCKS proxy settings > Use .onion hosts - Required

Network & servers > SOCKS proxy settings > Use random credentials - ON

Network & servers > Advanced network settings > Private routing - Always

Network & servers > Advanced network settings > Allow Downgrade - No

Network & servers > Advanced network settings > Show message status - ON

Network & servers > Advanced network settings > Transport isolation - Chat profile

Audio & video calls > Always use relay - ON [NOTE: get a good VPN to protect call metadata]

Privacy & security > Send link previews - OFF

Privacy & security > Show last messages - OFF

Privacy & security > Auto-accept images - OFF

Privacy & security > Blur media - [As desired]

The above configuration beats the pants off Session (Signal alternative typically recommended) and actually works decently (unlike Session)!

IMO the above really needs to come set by default and I might fork the client to do it (calling it SimplerX).

This article sort of addresses a question that I have had for a long time. I always wondered why it was called a "double" ratchet. There is only one hash ratchet. The triple Diffie-Hellman isn't anything like a ratchet. From the article it seems that the 3DH is called a ratchet anyway.

It's easy to get thrown off by the fact that it uses Diffie-Hellman in two places: 3DH for the original key exchange, but then also as part of the continuing key stream. There is only one hash ratchet, but occasionally each party will generate another DH keypair, ratcheting the key stream forward [1].

The hash ratchet protects new messages, but if the hash key is compromised at one point in time, an attacker can derive all future message keys indefinitely. The DH ratchet defeats that by generating a new key. If the attacker can't get that key, they lose the chain, making the protocol self healing against point-in-time key compromises.

[1] https://signal.org/docs/specifications/doubleratchet/#diffie...

That's the reason that the hash ratchet has never seemed all that valuable to me. I mean, yeah, it is kind of cool that each and every message is in a sense forward secret, but as you point out it isn't a very good form of forward secrecy. Most would be happy with dumping the keys after a chat session or when it actually matters, when the corresponding archived messages are deleted.

It is a fine form of forward secrecy: past messages aren't compromised by later keys being compromised. The sender/receiver ratchets essentially provide a notion of what a session means in an asynchronous environment, and the double ratchet algorithm shrinks the window as much as is possible i.e. every time the sender/receiver changes. Dumping the keys only when messages are deleted is an extremely poor security practice.

Dumping the keys before the messages are deleted is kind of pointless. An attacker that gets some form of access to the private key material is going to also have access to any archived messages in any sort of instant messaging environment. You can't make old messages go away simply by forgetting the session key used to transmit them if you keep them around in some other form.

The new “gold standard” here for anyone who’s interested is now an IETF standard.

https://datatracker.ietf.org/doc/rfc9420/

Reply on news.ycombinator.com