Commit 376aff64f1d07509ff2b55396b57dad4a041780d
Created secure private channels: the good, the bad, and the ugly (markdown)
Dominic Tarr committed on 4/22/2015, 7:15:46 AMParent: d184e44596c9d86c998e4ae974da9fcea14e88de
Files changed
| secure-private-channels:-the-good,-the-bad,-and-the-ugly.md | added |
| secure-private-channels:-the-good,-the-bad,-and-the-ugly.md | ||
|---|---|---|
| @@ -1,0 +1,112 @@ | ||
| 1 | +researching what makes a good connection protocol for secure-scuttlebutt, am investigating different protocols to see what level of privacy & simplicity is achievable. | |
| 2 | + | |
| 3 | +One thing that is fairly obvious is the TLS is not very good, and unsuitable for a p2p protocol. | |
| 4 | +In a p2p protocol we can usually regard key management as a solved problem - with the web, there is the whole CA system to certify that a given peer (ip address) is actually the owner of the given domain, but in a p2p system peers are identified by their public key (which is stable) and not their ip address, which is unstable. Usually there is a some sort of look-up system to get the ip addresses, | |
| 5 | +so it may not be necessary to send the key inside the connection. | |
| 6 | + | |
| 7 | +## private-stream | |
| 8 | + | |
| 9 | +[private-stream](https://github.com/dominictarr/private-stream) is a very simple private protocol that I wrote. It provides encryption, but not authentication. That is, you cannot be sure exactly who you are talking to, but you may be sure that no one else is listening. It is a symmetrical protocol, in that client and server handshake are identical. Each peer sends a Diffie Helman public key + an Initialization Vector (8 byte random number). The DH keys are combined to produce a shared key, and a cipher streams (salsa20) are constructed using the shared key and the two ivs so that each channel (A->B, and B->A) have the same key but different IVs (which is sufficient for security) | |
| 10 | + | |
| 11 | +I was considering putting authentication inside of this protocol but I am now re-evaluating that. | |
| 12 | + | |
| 13 | +### dramatization of private stream | |
| 14 | + | |
| 15 | +alice and bob meet in a dark alleyway | |
| 16 | + | |
| 17 | +Alice & Bob (simultaniously) passes each other a secret note, also with random number written on outside. | |
| 18 | + | |
| 19 | +> Alice and Bob now combine their secret, with the secret they received and the random numbers, | |
| 20 | +> to communicate with each other. | |
| 21 | + | |
| 22 | +Alice does not know who Bob is and vice versa, but no one can tell what they are saying either. | |
| 23 | + | |
| 24 | +### Further Reading | |
| 25 | + | |
| 26 | +* [readme](https://github.com/dominictarr/private-stream) | |
| 27 | + | |
| 28 | +## bittorrent obfuscation | |
| 29 | + | |
| 30 | +BT encryption is not well regarded, but because it chooses insecure algorithms, not because it's abstract design is bad. It provides the same assurances (or it would, if it's ciphers where secure) as private-stream, except it's a little uglier because it's not symmetrical. (the stream has to know whether it's the caller (client) or answerer (server), so it can derive a distinct key) | |
| 31 | + | |
| 32 | +### Dramatization of Bittorrent Obfuscation | |
| 33 | + | |
| 34 | +Alice and Bob meet in an alleyway wearing silly costumes. | |
| 35 | +They do not realize there is a security camera. | |
| 36 | +Luckily nobody really cares what they are up to. | |
| 37 | +Alice and Bob exchange notes and feel like they are spies. | |
| 38 | +etc, etc. | |
| 39 | + | |
| 40 | +### Further Reading | |
| 41 | + | |
| 42 | +* [bittorrent creator on why obfuscation is silly](http://bramcohen.livejournal.com/29886.html) | |
| 43 | +* [message stream encryption](http://wiki.vuze.com/w/Message_Stream_Encryption) | |
| 44 | +* [wikipedia page](https://en.wikipedia.org/wiki/BitTorrent_protocol_encryption) | |
| 45 | + | |
| 46 | +## tls | |
| 47 | + | |
| 48 | +### dramatization of a TLS handshake: | |
| 49 | + | |
| 50 | +Alice: "hello, I speak english, spanish, and mandarin" | |
| 51 | +> (alice opens connection, and describes the cihper suite she supports) | |
| 52 | + | |
| 53 | +Bob: "hi this is bob and I speak english, just ask carl" | |
| 54 | +> (bob selects cipher, identifies himself, with a reference. | |
| 55 | +> carl is a respected member of the community (a CA) who knows bob (has issued bob a cert). | |
| 56 | +> alice may choose to quickly contact carl to check if bob is cool) | |
| 57 | + | |
| 58 | +Alice: | |
| 59 | + (whispers) "hey bob, the key is 'foofoo'" | |
| 60 | +> (alice chooses a secret and encrypts it to bob) | |
| 61 | + | |
| 62 | +> Bob/Alice now encrypt all further messages with the key. | |
| 63 | + | |
| 64 | +### Further Reading | |
| 65 | + | |
| 66 | +* [tls handshake](http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake) | |
| 67 | + | |
| 68 | +## SSH | |
| 69 | + | |
| 70 | +SSH seems very complicated and has a variety of methods of authenticating. Flexibility in a security protocol is bad because then there are more edge cases and thus more surface area to audit / cracks for bugs to hide in. [djb agrees](http://curvecp.org/security.html) | |
| 71 | + | |
| 72 | +SSH differs from our model p2p protocol because there is no key/address lookup system, and so a client cannot know that it's information on a host is uptodate. Also, it may only update information about a host by connecting to it | |
| 73 | + | |
| 74 | +### Dramatization of SSH connection | |
| 75 | + | |
| 76 | +Alice: "hi I want to talk to you, in english, spanish or mandarin (prefer english)" | |
| 77 | +> Alice opens a connection, and lists the ciphers she supports, with preference. | |
| 78 | +Bob: "hi I speak in english, spanish or mandarin (prefer english), okay lets whisper now" | |
| 79 | +Alice: passes a secret note to Bob | |
| 80 | +> generates DiffieHelman key, sends public DH key to bob. | |
| 81 | +> begins DH exchange | |
| 82 | +Bob: passes a note back, with I AM BOB signed on the outside. | |
| 83 | +> bob replies with bob's public DH key, bob's public RSA key, and a signature to prove they are bob. | |
| 84 | +> Alice now knows she is talking to Bob, Bob does not know who Alice is yet, | |
| 85 | +> but they do have secure communication now. | |
| 86 | + | |
| 87 | +To be honest, this seems a little unfair on bob. He has answered the phone and identified himself to a stranger. It happens to be his friend Alice, but it _could_ be a telemarketer, who is now updating their database because they now know where bob lives. | |
| 88 | + | |
| 89 | +Alice and Bob now have secure communication, and inside that, Alice authenticates to Bob. | |
| 90 | +I think the reason that SSH is designed this way is to support a variety of client authentication protocols, such as password, host based (checks the ip address of the client (!)), keyboard interactive (usually used for a password, the client's keyboard is directly connected to a program running on the server so it can be literally anything (!)), and finally, pubkeys. | |
| 91 | + | |
| 92 | +We are only interested in pubkey based authentications. | |
| 93 | + | |
| 94 | +The following is all private so Alice and Bob can speak normally. | |
| 95 | +Alice: hey I'm alice and I want to use pubkey auth with <algorithm> and <key> | |
| 96 | +Bob: okay go ahead "Alice" | |
| 97 | +Alice: see it's me <signed> | |
| 98 | +Bob: Alice it is you!!! | |
| 99 | + | |
| 100 | +### Further Reading | |
| 101 | + | |
| 102 | +* Architecture of SSH protocol [rfc4251](http://tools.ietf.org/html/rfc4251) | |
| 103 | +* SSH transport protocol [rfc4253](http://tools.ietf.org/html/rfc4253) (encryption, and server auth) | |
| 104 | +* SSH Client Authentication Protocol [rfc4252](http://tools.ietf.org/html/rfc4252) | |
| 105 | + | |
| 106 | +## CurveCP | |
| 107 | + | |
| 108 | +djb's new Mutual Authenticated UDP based protocol. It uses a UDP to get around some weaknesses in TCP (such as the ability to forge a reset packet and force a tcp connection to close) and also to use a different congestion than tcp does. | |
| 109 | + | |
| 110 | +### Further Reading | |
| 111 | + | |
| 112 | +* [curvecp website](http://curvecp.org) | |
Built with git-ssb-web