Commit 0c69a8991b921cc2cd0398d63b6037e27e68c7ff
Updated a secure secure channel (markdown)
Dominic Tarr committed on 5/12/2015, 6:07:06 AMParent: 539e046ba1a9ba104def8af3ba40db2c0d1bdaa1
Files changed
| a-secure-secure-channel.md | changed |
| a-secure-secure-channel.md | ||
|---|---|---|
| @@ -1,9 +1,11 @@ | ||
| 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) | |
| 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). This protocol is inspired by [curvecp](https://github.com/ssbc/scuttlebot/wiki/secure-private-channels:-the-good,-the-bad,-and-the-ugly#curvecp) but avoid the [problems with curvecp](https://github.com/ssbc/scuttlebot/wiki/secure-private-channels:-the-good,-the-bad,-and-the-ugly#conclusion) | |
| 2 | 2 | |
| 3 | +This also differs from curvecp in that it is intended to function as a layer on top of a reliable tcp-like connection, instead of a UDP protocol. Although curvecp does solve some tcp problems by using udp, for my usecase I require the ability to encrypt connections over an arbitrary reliable duplex stream (in particular over tcp, but potentially over other protocols too) | |
| 4 | + | |
| 3 | 5 | ## version 1 (flawed) |
| 4 | 6 | |
| 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)) | |
| 7 | +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 | 8 | |
| 7 | 9 | > Alice generates DH key, initiates duplex connection (i.e. tcp) to Bob. |
| 8 | 10 | |
| 9 | 11 | Alice: here is my dh key. (this message is not signed, Bob doesn't yet know it's Alice, and Alice isn't sure it's Bob yet either) |
| @@ -111,5 +113,5 @@ | ||
| 111 | 113 | 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 | 114 | |
| 113 | 115 | 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 | 116 | |
| 115 | -This design realizes _all_ the [desirable secure channel properties](https://github.com/ssbc/scuttlebot/wiki/desirable-properties-for-a-secure-channel) | |
| 117 | +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