{"action":"created","issue":{"url":"https://api.github.com/repos/ipfs/notes/issues/188","repository_url":"https://api.github.com/repos/ipfs/notes","labels_url":"https://api.github.com/repos/ipfs/notes/issues/188/labels{/name}","comments_url":"https://api.github.com/repos/ipfs/notes/issues/188/comments","events_url":"https://api.github.com/repos/ipfs/notes/issues/188/events","html_url":"https://github.com/ipfs/notes/issues/188","id":188125200,"number":188,"title":"Some notes on signal protocol analysis","user":{"login":"jbenet","id":138401,"avatar_url":"https://avatars.githubusercontent.com/u/138401?v=3","gravatar_id":"","url":"https://api.github.com/users/jbenet","html_url":"https://github.com/jbenet","followers_url":"https://api.github.com/users/jbenet/followers","following_url":"https://api.github.com/users/jbenet/following{/other_user}","gists_url":"https://api.github.com/users/jbenet/gists{/gist_id}","starred_url":"https://api.github.com/users/jbenet/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jbenet/subscriptions","organizations_url":"https://api.github.com/users/jbenet/orgs","repos_url":"https://api.github.com/users/jbenet/repos","events_url":"https://api.github.com/users/jbenet/events{/privacy}","received_events_url":"https://api.github.com/users/jbenet/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-11-08T22:47:13Z","updated_at":"2016-11-08T23:25:51Z","closed_at":null,"body":"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:\r\n\r\n- security considerations in applications of the signal protocol\r\n- security and thread model considerations for distributing/decentralizing the key server (i.e. how to do this without honest key servers)\r\n- considerations for implementations in other programming contexts (`signal.js` ?) \r\n- considerations for CRDTs / orbit-db\r\n\r\nplease 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."},"comment":{"url":"https://api.github.com/repos/ipfs/notes/issues/comments/259292049","html_url":"https://github.com/ipfs/notes/issues/188#issuecomment-259292049","issue_url":"https://api.github.com/repos/ipfs/notes/issues/188","id":259292049,"user":{"login":"jbenet","id":138401,"avatar_url":"https://avatars.githubusercontent.com/u/138401?v=3","gravatar_id":"","url":"https://api.github.com/users/jbenet","html_url":"https://github.com/jbenet","followers_url":"https://api.github.com/users/jbenet/followers","following_url":"https://api.github.com/users/jbenet/following{/other_user}","gists_url":"https://api.github.com/users/jbenet/gists{/gist_id}","starred_url":"https://api.github.com/users/jbenet/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jbenet/subscriptions","organizations_url":"https://api.github.com/users/jbenet/orgs","repos_url":"https://api.github.com/users/jbenet/repos","events_url":"https://api.github.com/users/jbenet/events{/privacy}","received_events_url":"https://api.github.com/users/jbenet/received_events","type":"User","site_admin":false},"created_at":"2016-11-08T23:25:51Z","updated_at":"2016-11-08T23:25:51Z","body":"Some quickly jotted down notes. (disclaimer: these are observations and probably wrong.) \r\n\r\n- Relevant HN discussion: https://news.ycombinator.com/item?id=12899398 -- mostly discussion on the product, not the paper/protocol.\r\n- Relevant Reddit discussion: https://www.reddit.com/r/netsec/comments/59rf92/a_formal_security_analysis_of_the_signal/ (includes authors, but very few comments).\r\n\r\n> (abstract) We then prove the security of Signal’s core in our model, demonstrating several standard security properties. We have found no major flaws in the design\r\n\r\nYay!\r\n\r\n> (Figure 2, pg 7)\r\n\r\nUseful 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. \r\n\r\nI wonder what Signal team thinks about this diagram, and the paper as a whole. TODO: figure it out / ask them.\r\n\r\n> (S6) _Out-of-band key verification_ .... We simply assume that long-term and medium-term public key distribution is honest, and do not analyse the out-of-band verification channel.\r\n\r\nHmmm. 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. \r\n\r\nI 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).\r\n\r\nFurther 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?\r\n\r\nSome of these questions seem to be answered in https://whispersystems.org/blog/asynchronous-security/ \r\n\r\n> (The TextSecure Protocol) Package up the prekey id, the locally generated key exchange message, and the ciphertext. .... Send it all in one bundle to the destination client. ... The user experience for the sender is ideal: they type a message, hit send, and an encrypted message is immediately sent. .... The destination client receives all of this as a single push notification.\r\n\r\nSo 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).\r\n\r\n> (S6) **Application Variants** ... WhatsApp implements a re-transmission mechanism: if Bob appears to change his identity key, clients will resend messages encrypted under the new value. Hence, an adversary with control over identity registration can disconnect Bob and replace his key, and Alice will re-send the message to the adversary.\r\n\r\nThat 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](http://2.bp.blogspot.com/-_Qq0ss2SaDs/VaGFLwDwc8I/AAAAAAAACJ8/HQqtvlc3WF4/s1600/chrome-red-screen-security-warning.jpg) may not go heeded by most average consumer users.)."}}
{"actor":{"display_login":"jbenet"}}