Commit 86f2caf244730fcefb1d6f2d7290cae5cae25dcc
Updated a secure secure channel (markdown)
Dominic Tarr committed on 5/12/2015, 5:59:27 AMParent: e41b30a7fc217739155b6f841ef32db85f10fb37
Files changed
| a-secure-secure-channel.md | changed |
| a-secure-secure-channel.md | ||
|---|---|---|
| @@ -1,7 +1,7 @@ | ||
| 1 | 1 | Alice wants to connect to Bob and communicate privately. Also, we want to realize _all_ the [desireable properties for a secure channel](https://github.com/ssbc/scuttlebot/wiki/desirable-properties-for-a-secure-channel) |
| 2 | 2 | |
| 3 | -## version 1 | |
| 3 | +## version 1 (flawed) | |
| 4 | 4 | |
| 5 | 5 | this version actually fails to provide all the properties desired (or rather, while writing this I realized there was another weakness that could be supported [#16](https://github.com/ssbc/scuttlebot/wiki/desirable-properties-for-a-secure-channel#16-mitmwrong-number-cannot-learn-or-confirm-keys)) |
| 6 | 6 | |
| 7 | 7 | > Alice generates DH key, initiates duplex connection (i.e. tcp) to Bob. |
| @@ -50,9 +50,9 @@ | ||
| 50 | 50 | This would make a compromise of his private key a decidedly schizophrenic experience for Bob! Although to other parties, Bob suddenly acting weird would be simple enough to diagnose - Bob has been hacked - but Bob may instead experience _everyone he knows_ suddenly going schizophrenic. This could potentially be more destructive than merely impersonating Bob. Hopefully loosing control of one's private keys is an extremely unlikely event, but the antics of bitcoin has certainly shown this is possible via a variety of avenues if attackers are sufficiently motivated. If it's reasonable to design a protocol to be forward secure (not leak information if keys are compromised) then it's reasonable to make other aspects of the protocol fail safely in the case of key compromise. |
| 51 | 51 | |
| 52 | 52 | Therefore, my conclusion is that `crypto_box` is not suitable as a _user authentication primitive_, and signatures should be used instead (though, the signatures may be inside a `crypto_box` for privacy). |
| 53 | 53 | |
| 54 | -### protocol | |
| 54 | +### protocol description | |
| 55 | 55 | |
| 56 | 56 | Alice: Hi call me Andy |
| 57 | 57 | > Alice generates a temporary key, Andy, and sends it to (the server she thinks is) Bob |
| 58 | 58 | |
| @@ -109,5 +109,7 @@ | ||
| 109 | 109 | ``` |
| 110 | 110 | |
| 111 | 111 | Now Alice and Bob are mutually authenticated! Bob knows he's talking to Alice, and Alice knows she is talking to Bob. _as far as I have determined, no weird edge cases_. Of course, if your key is compromised, then someone can impersonate you, this is to be expected, and key revocation should be solved in another part of the cryptosystem. |
| 112 | 112 | |
| 113 | +the rest of the session is encrypted with Aaron/Barbara. Even the existence of these keys is a secret from both an eavesdropper or a man in the middle! | |
| 114 | + | |
| 113 | 115 | This design realizes _all_ the [desirable secure channel properties](https://github.com/ssbc/scuttlebot/wiki/desirable-properties-for-a-secure-channel) |
Built with git-ssb-web