Commit 56107a3195fa8e6bd35cdcb9bd43a952268f4633
Updated secure private channels: the good, the bad, and the ugly (markdown)
Dominic Tarr committed on 5/6/2015, 4:14:51 AMParent: 15749974fea18764691762c8995024d946fa8a9e
Files changed
| secure-private-channels:-the-good,-the-bad,-and-the-ugly.md | changed |
| secure-private-channels:-the-good,-the-bad,-and-the-ugly.md | ||
|---|---|---|
| @@ -159,8 +159,12 @@ | ||
| 159 | 159 | |
| 160 | 160 | * what are the properties of a "box" exactly? |
| 161 | 161 | (from what I gather `Box[message](A->B)` encrypts `message` so that only A and B can read it, and A reader may verify it if they have B's pubkey?) |
| 162 | 162 | |
| 163 | +### Further Reading | |
| 164 | + | |
| 165 | +* [curvecp website](http://curvecp.org) | |
| 166 | + | |
| 163 | 167 | ### ipfs's secure channel |
| 164 | 168 | |
| 165 | 169 | [ipfs](http://ipfs.io) contains a simple secure channel protocol. It encrypts the content of the session with forward secrecy, prevents replay and man-in-the-middle attacks. It does leak some metadata: the keys that are communicating are shared in plaintext, and thus a passive eavesdropper can see who is talking to who. The protocol is symmetrical, so there is no difference between the client and server messages. |
| 166 | 170 | |
| @@ -169,8 +173,9 @@ | ||
| 169 | 173 | Alice and Bob (simultaniously): Hi, I am {Alice,Bob}. I speak {ciphers,key-exchange,hashes}. {random number} |
| 170 | 174 | > Alice and Bob both open with a packet containing their public key, a nonce, and the cipher suite they support. |
| 171 | 175 | > Alice and Bob both select the cryptographic functions to use (key-exchange, hash, cipher) by hash(Alice's nonce + Bob's key) and comparing that to hash(Bob's nonce + Alice's key). Although the hash function used by the protocol is negotiated, at this point it uses a hard coded hash (sha256). Also, ipfs encodes hashes as [multihash](https://github.com/jbenet/multihash), which start with an identifier and then a length. These are bytewise compared, and that determines who's cipher suite has preference. (It seems the intention here is to ensure that cipher suite selection is fair. Forcing the ciphersuite could lead to some attacks, such as a downgrade attack. However, it is fairly easy, if Alice knows she is contacting Bob, to mine for a nonce such that hash(Bob's key, nonce) is very high, and thus likely to win the cipher selection) |
| 172 | 176 | > (Personally, I feel having a ciphersuit selection process at all is troublesome, and express my thoughts about it in the [original pull request](https://github.com/ipfs/go-ipfs/pull/34)) |
| 177 | +> Once the order is decided, each peer selects each {KeyExchange, Cipher, Hash} by taking the order winner's first choice which is also supported by the other peer. | |
| 173 | 178 | |
| 174 | 179 | Alice and Bob (simultaniously): you said X, and I said Y, and here is my key exchangep. signed, Alice/Bob :lock_with_ink_pen: |
| 175 | 180 | |
| 176 | 181 | > Alice and Bob now send a DiffieHelman key, and a signature. Alice's signature is: `sign(Alice's hello + Bob's hello + Alice's DH key)`. Bob's is `sign(Bob's hello + Alice's hello + Bob's DH key)`. |
| @@ -183,7 +188,4 @@ | ||
| 183 | 188 | Alice and Bob (simultaniously): here is the random number you gave me. |
| 184 | 189 | |
| 185 | 190 | > Alice and Bob both send back the the nonce the other sent to them. This confirms they are authorized with the other peer, and can now begin secure communication. (NOTE: this means that the first nonce.length bytes of the ciphertext are a [high entropy] plaintext known to an eavesdropper) I don't think there is any special reason to send the nonce back, it might as well be the string "ACCESS GRANTED" (unless I am mistaken?) |
| 186 | 191 | |
| 187 | -### Further Reading | |
| 188 | - | |
| 189 | -* [curvecp website](http://curvecp.org) | |
Built with git-ssb-web