[HN Gopher] Implementing Signal's Double Ratchet algorithm (2020)
       ___________________________________________________________________
        
       Implementing Signal's Double Ratchet algorithm (2020)
        
       Author : todsacerdoti
       Score  : 95 points
       Date   : 2024-11-07 05:27 UTC (8 days ago)
        
 (HTM) web link (nfil.dev)
 (TXT) w3m dump (nfil.dev)
        
       | lisper wrote:
       | An implementation of the double ratchet in Javascript:
       | 
       | https://github.com/rongarret/ratchet-js
       | 
       | based on an earlier implementation I did in Common Lisp:
       | 
       | https://github.com/rongarret/tweetnacl/blob/master/ratchet.l...
        
       | upofadown wrote:
       | 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.
        
         | thadt wrote:
         | 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...
        
           | upofadown wrote:
           | 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.
        
             | typicalset wrote:
             | 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.
        
       | mdhb wrote:
       | The new "gold standard" here for anyone who's interested is now
       | an IETF standard.
       | 
       | https://datatracker.ietf.org/doc/rfc9420/
        
       | rustcleaner wrote:
       | 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).
        
       ___________________________________________________________________
       (page generated 2024-11-15 23:02 UTC)