-
Notifications
You must be signed in to change notification settings - Fork 30
Some notes on recent Signal Protocol analysis paper #188
Comments
I should clarify that the goal is to talk about the Signal protocol, not just this particular analysis, but this particular analysis was published recently and offers a nice formal language. we should be careful not to mistake the protocol in this paper for the real protocol, as im sure some differences exist (or will exist). |
Some quickly jotted down notes. (DISCLAIMER: these are quick observations and probably wrong.)
Yay!
Useful protocol exchange diagram. But notation is dense and sub-optimal. I think tweaking the notation, more abstraction/more greek, or another pass at it could seriously improve presentation and understandability. I wonder what Signal team thinks about this diagram, and the paper as a whole. TODO: figure it out / ask them.
Hmmm. seems like a big assumption. We should endeavor to understand the model better there and what advantages an adversarial key server could exploit. This will help design a byzantine-tolerant distributed key server. I would like to get to "as long as there is a byzantine-tolerant broadcast channel for keys, everything works", because then all we need is byzantine agreement (eg a blockchain, stellar, something stamped to a blockchain, etc). Further questions here-- what historical data can a malicious key server store? I was impressed by the signal announcements here: https://whispersystems.org/bigbrother/eastern-virginia-grand-jury/ -- in particular the tiny attachment. but that seems like that showed less than what everything the server actually has, server should have some the public keys too (identity key, medium term keys, etc). More Qs: what about message ciphertexts? are they only exchanged p2p synchronously? i thought it supported async distribution? Some of these questions seem to be answered in https://whispersystems.org/blog/asynchronous-security/
So assuming this is still the case for Signal, this means the ciphertext moves in the push notification. May or may not be in Signal's servers, but definitely the push notification server (apple, etc). This does seem to leak more messaging metadata (message times, maybe lengths or rough lengths (order of magnitude)) than i thought previously. Still secure (forward secrecy; OTR-style), but adversary can collect the metadata. (this is good news for a distributed version, as it lowers the bar to achieve the same guarantees, though less private than other, mixer style protocols).
That seems very concerning. Is this right? or did the paper get this wrong? If it's right, what exactly is the threat model here? IIUC, this claim is that WhatsApp could MITM the communication with minimal to no warning (what does the "retransmission mechanism" look like for the user? what's the UX?). Maybe not without being detected (rolling the key may produce a warning for the user, but a warning without total halting or a BRS may not go heeded by most average consumer users.). |
In case of android I read that GCM servers (push) are only used to notify Signal to fetch the message, so it is Push for wake-up and pull for the encrypted message. |
Subscribing myself to this threat. |
So I'd really like to use the signal protocol for OpenBazaar offline messaging. There is even a Go implementation. But the problem I have is it seems to be designed entirely for a client server model, not p2p. For example, users upload pre-keys to a server which vends them to other parties on request and keeps track of which ones have been issued. The pre-keys are then used to start the ratchet protocol. Does anyone have an idea how to make this work? We could obviously seed a list of pre-keys on IPFS, but then there's a chance a sender will pick one that had been used before. (obviously an initial handshake is one way around it, but that prevents sending messages where both parties haven't yet done a handshake). |
Also, I'm trying my best to keep the metadata leakage to a minimum, and I think the signal protocol has the sender and recipient IDs attached to each message. The server is trusted to keep the metadata secure (I think). Again, adapting that to a p2p environment is challenging. |
Here's something I read recently that may or may not help to understand how Signal works http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html. |
On the WhatsApp retransmission vulnerability - this was reported earlier this year (see https://tobi.rocks/2016/04/whats-app-retransmission-vulnerability/). WhatsApp just responded that it is a threat model they don't protect against. |
Subscribing. |
Moxie & Trevor just published double ratchet spec: https://whispersystems.org/docs/specifications/doubleratchet/ |
Also X3DH key agreement: Signature schemes: |
Thanks for posting these links @christianlundkvist ! Hopefully they will publish exactly what gets stored on third-party servers and for how long it's (intended) to be there. I may email and ask. Reading this, and re-reading the OTR paper, i'm curious how they do groups.
|
I'll dig deeper into Matrix's megolm. This post is promising https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-encryption-security-assessment-released-and-implemented-cross-platform-on-riot-at-last/ and the security review is here: https://www.nccgroup.trust/globalassets/our-research/us/public-reports/2016/november/ncc_group_olm_cryptogrpahic_review_2016_11_01pdf (from NCC Group). If this works for our use case (which seems very close to Matrix's) -- then this is great (available library, just audited, wow this comes in good time!). I'll be curious to hear what Moxie, Trevor, @zooko, and @warner think of it, too. |
I'm reading through A Formal Security Analysis of the Signal Messaging Protocol https://eprint.iacr.org/2016/1013.pdf. I'll be taking some notes here relating to:
signal.js
?)please feel free to jot down your own notes here or discuss as needed. my goal is to get to some version of Signal that can work well with ipfs distribution models.
The text was updated successfully, but these errors were encountered: