trevp

double_ratchet

Libraries & SDKs2014–2016

trevp / double_ratchet

double_ratchet

Double Ratchet Algorithm

Libraries & SDKs

Explore on GitHub Read Hacker News discussions

9Distinct people

10Mentions

0Explicit recommenders

377GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Double Ratchet Algorithm

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month10 dated mentions

Observed mentions: 2014-11-19 17:48:22 UTC to 2016-12-09 17:08:50 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
Nov 2014	2014-11-01 00:00:00 UTC	2014-12-01 00:00:00 UTC	1	1
Dec 2014	2014-12-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	1	1
Jan 2015	2015-01-01 00:00:00 UTC	2015-02-01 00:00:00 UTC	2	2
Feb 2015	2015-02-01 00:00:00 UTC	2015-03-01 00:00:00 UTC	1	1
Mar 2015	2015-03-01 00:00:00 UTC	2015-04-01 00:00:00 UTC	0	0
Apr 2015	2015-04-01 00:00:00 UTC	2015-05-01 00:00:00 UTC	0	0
May 2015	2015-05-01 00:00:00 UTC	2015-06-01 00:00:00 UTC	0	0
Jun 2015	2015-06-01 00:00:00 UTC	2015-07-01 00:00:00 UTC	0	0
Jul 2015	2015-07-01 00:00:00 UTC	2015-08-01 00:00:00 UTC	1	1
Aug 2015	2015-08-01 00:00:00 UTC	2015-09-01 00:00:00 UTC	0	0
Sep 2015	2015-09-01 00:00:00 UTC	2015-10-01 00:00:00 UTC	0	0
Oct 2015	2015-10-01 00:00:00 UTC	2015-11-01 00:00:00 UTC	0	0
Nov 2015	2015-11-01 00:00:00 UTC	2015-12-01 00:00:00 UTC	1	1
Dec 2015	2015-12-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	0	0
Jan 2016	2016-01-01 00:00:00 UTC	2016-02-01 00:00:00 UTC	0	0
Feb 2016	2016-02-01 00:00:00 UTC	2016-03-01 00:00:00 UTC	0	0
Mar 2016	2016-03-01 00:00:00 UTC	2016-04-01 00:00:00 UTC	0	0
Apr 2016	2016-04-01 00:00:00 UTC	2016-05-01 00:00:00 UTC	1	1
May 2016	2016-05-01 00:00:00 UTC	2016-06-01 00:00:00 UTC	0	0
Jun 2016	2016-06-01 00:00:00 UTC	2016-07-01 00:00:00 UTC	0	0
Jul 2016	2016-07-01 00:00:00 UTC	2016-08-01 00:00:00 UTC	0	0
Aug 2016	2016-08-01 00:00:00 UTC	2016-09-01 00:00:00 UTC	0	0
Sep 2016	2016-09-01 00:00:00 UTC	2016-10-01 00:00:00 UTC	0	0
Oct 2016	2016-10-01 00:00:00 UTC	2016-11-01 00:00:00 UTC	1	1
Nov 2016	2016-11-01 00:00:00 UTC	2016-12-01 00:00:00 UTC	0	0
Dec 2016	2016-12-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	1	1

What Hacker News says

10 sources

niftich·Dec 9, 2016

This is the Olm protocol by Matrix, which uses the Perrin-Marlinspike Double Ratchet described at [1], and makes some similar cryptographic decisions to the Signal Protocol, but has a different wire format. As complete protocols, Olm and the Signal Protocol started off close but have since diverged in a number and magnitude of ways that I lack the expertise to comment on. Nonetheless, here's the same thing directly out of both Arathorn and Moxie's mouths, devs of Matrix and Signal respectively [2]. Despite valiant efforts on many people's part to lessen the conflation and confusion of protocols, this happens a lot still, but we can all try to do our part to be as accurate as we can. [1] https://github.com/trevp/double_ratchet/wiki [2] https://news.ycombinator.com/item?id=11725652

In Signal protocol comes to XMPP/Jabber

Canada·Oct 15, 2016

This post doesn't explain the protocol all that well. This is a great explainer: https://vimeo.com/117532499 I can't seem to find the PDF of the slides of this talk anymore. These are also very useful for understanding: https://whispersystems.org/blog/advanced-ratcheting/ https://whispersystems.org/blog/private-groups/ https://github.com/trevp/double_ratchet/wiki

In How the Textsecure Protocol Works

defiancedigital·Apr 5, 2016

I'm looking at libaxolotl-c. I'm a little bit disturbed about perfect forward/future secrecy. Perfect forward secrecy ensure that a session key cannot be compromised if a long-term key is compromised in future. With something like OTR even if a session key is compromised at n, session key at n-1 or n+1 will not be compromised. Here, we got perfect forward/future secrecy. If i take a look at axolotl, in scenario Alice send message to bob when Bob is offline: (1) , (2) MK = HMAC-HASH(CKs, "0") // (3) msg = Enc(HKs, Ns || PNs || DHRs) || Enc(MK, plaintext) Ns = Ns + 1 CKs = HMAC-HASH(CKs, "1") // (4) return msg We can see that Alice re-use CKs to get a new symmetric key. So if an attacker get CKs(n) he could easily compute CKs(n+1) CKs is not a long term key, but we cannot honestly call this _perfect_ futur secrecy... One more thing, if

Read the rest

I remember correctly, according of perfect forward secrecy definition, an implementation must NOT re-use previous session key to derive a new one ... I'm wrong ? (1) Quoted from https://github.com/trevp/axolotl/wiki (2) see session_cipher_get_or_create_message_keys (https://github.com/WhisperSystems/libaxolotl-c/blob/0640b5ac...) (3) i think we should read MK = HKDF(HMAC-HASH(CKs, 0x00) see ratchet_chain_key_get_message_keys (https://github.com/WhisperSystems/libaxolotl-c/blob/0640b5ac...) (4) i think we should read MK = HMAC-HASH(CKs, 0x02) see ratchet_chain_key_create_next (https://github.com/WhisperSystems/libaxolotl-c/blob/0640b5ac...)

In WhatsApp's Signal Protocol integration is now complete

devit·Nov 23, 2015

Is Signal's crypto really "well-reviewed"? The best description of it seems to be at https://github.com/trevp/axolotl/wiki and it's not really understandable by someone who doesn't already know the protocol, so I doubt many people that don't work on Signal have reviewed it. It looks like the authors know what they are doing though, so it's probably good, but there might be a small risk that they overlooked something.

In Please Stop Writing Secure Messaging Tools

Rafert·Jul 15, 2015

You're free to re-implement the public-domain protocol[1] under your own license. Pond has a 3-clause BSD licensed Golang implementation[2] that Moxie even references in the Axolotl announcement blog post. 1: https://github.com/trevp/axolotl/wiki 2: https://github.com/agl/pond/tree/master/client/ratchet

In Show HN: Actor Messaging platform

rakoo·Feb 25, 2015

> (the message will only be encrypted when the pre-key can be retrieved). The pre-key is needed when you have never talked to someone (I guess it's also needed when the last conversation is really old, I haven't dug throuh the code); it's a necessary bootstrap step. After that all you need is inside your client. > So, my laptop is off-line, and I have access to a recipients public key. How do I encrypt my message, before moving it to a machine that's on-line for sending via smtp? You encrypt it on your laptop, transfer the encrypted blob to your online machine and send the blob through it. All state is managed by your laptop, intermediary machines are just forwarding the message (which is merely an opaque blob at this point, possibly with a "destination" to ease routing to the recipient(s)). > Nor does it appear to work for writing and en

Read the rest

crypting an sms while on an air-plane From a user pov, there is no difference between: - I type the message and hit send, the message is encrypted now and sent when I have connectivity - I type the message and hit send, the message is encrypted and sent when I have connectivity The problem here will not be technical but purely UX (the software has to allow deferring encryption and sending when resources are available) > It also carries more state around (on the "server" and on the "client") so it's not decentralized. The little state there is on the server really doesn't sound centralized to me in that it is really simple (the server must be able to store a given list of blobs sent by the client, and the server must not send twice the same blob, ever) and a client can choose any server (there is no concept of "registration", but the client has to trust the server it will not misbehave). The state on the client is really client-specific, it wouldn't make sense to share a client's ratchet state: as a comparison you wouldn't share the current bucket list of your DHT client with other machines because it doesn't make sense, you would rebuild it from scratch on another machine. Effectively this means every device of yours is considered another independent "peer". I think it's important at this point to say that this mechanism is the Axolotl ratchet (more details here: https://github.com/trevp/axolotl/wiki). It only describes how to exchange encrypted messages between two DH keys, asynchronously, and with forward secrecy. It doesn't care about : - what is the relationship between DH keys ("should I encrypt to 2 DH keys because they belong to the same user ?") - how do get someone's key, and is it the good one (the key distribution management) - how can I have a coherent message history between my phone and my computer These are all real problems that TextSecure aims to solve, but they're a whole another thing.

In PGP: There’s Life in the Old Dog Yet

gsbabil·Jan 1, 2015

If WhatsApp integrated everything they had in `Axolotl` [0] protocol specification, this wouldn't be the case. If WhatsApp would attempt to MITM, they would have to know someone's private-key (or break the crypto) which never leaves the phone, hence the E2E property. [0] https://github.com/trevp/axolotl/wiki

In Ask HN: How can I verify that WhatsApp uses E2E encryption?

substack·Jan 1, 2015

The proposal for forward secrecy in the spec (https://darkmail.info/downloads/dark-internet-mail-environme...) is not great and does not reflect the current state of the art: > PFS for message objects, as the description above suggests, is far more difficult, and contrary to the nature of email. It recommends just rotating public keys every few days with a paranoid mode. A much better solution is to implement the Axolotl Ratchet pioneered by Open Whisper Systems for TechSecure: https://www.whispersystems.org/blog/advanced-ratcheting/ https://github.com/trevp/axolotl/wiki With Axolotl Ratchet, you get: * forward secrecy - disclosure of private keys doesn't let an attacker in the future go back and read encrypted communication * future secrecy - disclosure of ephemeral private keys doesn't disclose (much) future content I also get the feeli

Read the rest

ng from a glance reading the spec that way too much trust is being placed on service providers. That there is even such a category as "trustful" where the server has access to your private keys is a huge red flag and that was exactly the problem with lavabit: http://www.thoughtcrime.org/blog/lavabit-critique/

In Dark Mail Technical Alliance

pmoriarty·Dec 23, 2014

Also see: [1] - https://github.com/rxcomm/pyaxo [2] - https://github.com/trevp/axolotl/wiki

In Advanced cryptographic ratcheting

rakoo·Nov 19, 2014

TextSecure doesn't use OTR, it uses a construction based on the Axolotl ratchet as described here: https://github.com/trevp/axolotl/wiki It's much much better than OTR in that: - Asynchronicity is on by default (you don't need both parties to be up and running at the same time to start a convo) - You don't need to wait for your recipient to answer before you can write something (ie you can send multiple messages one after another, directly) - Because you can do both of the above, you can easily do multiparty, something OTR struggles with. For more details: https://whispersystems.org/blog/asynchronous-security/ https://whispersystems.org/blog/private-groups/

In Open Whisper Systems partners with WhatsApp to provide end-to-end encryption