19

I want to understand the process of the Signal Protocol. I have google it, but I am unable to find any good article or tutorial.

I want to understand the basic definition and functionality of the Signal Protocol, and it would be great if any diagram describing the process is available.

parsley72
  • 195
  • 7
Taha Kirmani
  • 549
  • 2
  • 4
  • 9
  • 1
    I'd like to hear more about this too but it would get better attention on here if you demonstrated what you do know and put forth your own understanding of how it works so that people on here can correct you and / or add to your understanding. For example, the Wikipedia article (https://en.wikipedia.org/wiki/Signal_(software)) has diagrams and basic definition and functionality. Read that and expand your question. – mcgyver5 Apr 23 '16 at 14:09
  • 1
    You may want to listen / read the transcript of the Security Now podcast, episode 555 - "WhatsApp". Transcript https://www.grc.com/sn/sn-555.htm Audio: http://media.GRC.com/sn/SN-555.mp3 It's about WhatsApp, but very much goes into detail of the underlying protocol, which is Signal. The topic starts about half way in. – nulldev Jan 29 '18 at 12:22

1 Answers1

17

Take a look at this technical white paper from WhatsApp, they recently moved to the Signal Protocol for e2e encryption.

Public Key Types

  • Identity Key Pair – A long-term Curve25519 key pair, generated at install time.
  • Signed Pre Key – A medium-term Curve25519 key pair, generated at install time, signed by the Identity Key, and rotated on a periodic timed basis.
  • One-Time Pre Keys – A queue of Curve25519 key pairs for one time use, generated at install time, and replenished as needed. Session Key Types
  • Root Key – A 32-byte value that is used to create Chain Keys.
  • Chain Key – A 32-byte value that is used to create Message Keys.
  • Message Key – An 80-byte value that is used to encrypt message contents. 32 bytes are used for an AES-256 key, 32 bytes for a HMAC-SHA256 key, and 16 bytes for an IV.

To establish a session:

  1. The initiating client (“initiator”) requests the public Identity Key, public Signed Pre Key, and a single public One-Time Pre Key for the recipient.
  2. The server returns the requested public key values. A One-Time Pre Key is only used once, so it is removed from server storage after being requested. If the recipient’s latest batch of One-Time Pre Keys has been consumed and the recipient has not replenished them, no One-Time Pre Key will be returned.
  3. The initiator saves the recipient’s Identity Key as Irecipient, the Signed Pre Key as Srecipient, and the One-Time Pre Key as Orecipient.
  4. The initiator generates an ephemeral Curve25519 key pair, Einitiator.
  5. The initiator loads its own Identity Key as Iinitiator.
  6. The initiator calculates a master secret as master_secret = ECDH(Iinitiator, Srecipient) || ECDH(Einitiator, Irecipient) || ECDH(Einitiator, Srecipient) || ECDH(Einitiator, Orecipient). If there is no One Time Pre Key, the final ECDH is omitted.
  7. The initiator uses HKDF to create a Root Key and Chain Keys from the master_secret.

Receiving Session Setup

After building a long-running encryption session, the initiator can immediately start sending messages to the recipient, even if the recipient is offline. Until the recipient responds, the initiator includes the information (in the header of all messages sent) that the recipient requires to build a corresponding session. This includes the initiator’s Einitiator and Iinitiator.

When the recipient receives a message that includes session setup information:

  1. The recipient calculates the corresponding master_secret using its own private keys and the public keys advertised in the header of the incoming message.
  2. The recipient deletes the One-Time Pre Key used by the initiator.
  3. The initiator uses HKDF to derive a corresponding Root Key and Chain Keys from the master_secret.
joshperry
  • 361
  • 1
  • 8
  • 1
    In the whitepaper, it is stated that `message_key = HMAC-SHA256(chain_key, 0x01)` and also it is stated that `message_key` is 80 bytes. How is that possible? `HMAC-SHA256` has output size of 32 bytes. – Ramazan May 27 '16 at 14:19
  • @Ramazan Great question. The other resources I've looked at don't describe the `message_key` in that way. I wonder if that section of the whitepaper is broken. https://github.com/trevp/double_ratchet/wiki https://whispersystems.org/blog/advanced-ratcheting/ – joshperry Oct 07 '16 at 16:34
  • 3
    Hi, is there a short explanation of why the protocol has to use so many keys ? I thought one long-lived identity key and one one-time key generated for each message would suffice to provide authentication and forward secrecy. – Hey Jan 03 '17 at 00:35
  • What do you mean with 'rotated on a periodic timed basis'? – richardaum Jun 26 '17 at 18:36
  • @Richard This text is directly from the PDF document. I assume it means that a maximum lifetime is used for this key and is rotated when that lifetime expires. – joshperry Jun 29 '17 at 17:50
  • @Ramazan This might no longer be relevant to you, but I found some signal doc that explains how to go from 32-byte HMAC output to the 80-byte value used by whatsapp using HKDF. See the recommendations for ENCRYPT here: https://signal.org/docs/specifications/doubleratchet/#recommended-cryptographic-algorithms – define cindy const May 13 '19 at 05:33
  • @joshperry thank you for the great explanation. One doubt I had: Why can't someone snoop in on the keys server is sending to the initiator and use that because everything there seems public. Pardon my lack of understanding but does the math magic lie in use of private keys on recipient side to be able to decrypt the message. And if it requires private key of recipient then how does conversation go forward, how can initiator read recipient's subsequent reply? – Harshdeep Jul 19 '19 at 13:32