Commit 6000cc6639c61da5bc96147cb99d1d99f6dfc0b1
Updated a secure secure channel (WIP) (markdown)
Dominic Tarr committed on 5/12/2015, 4:26:48 AMParent: 514cc68e02929327edfaf2dbce63da868bd6f415
Files changed
| a-secure-secure-channel-(WIP).md | changed |
| a-secure-secure-channel-(WIP).md | ||
|---|---|---|
| @@ -34,20 +34,21 @@ | ||
| 34 | 34 | ## Version 2 |
| 35 | 35 | |
| 36 | 36 | version 2 also supports property [#16](https://github.com/ssbc/scuttlebot/wiki/desirable-properties-for-a-secure-channel#16-mitmwrong-number-cannot-learn-or-confirm-keys) |
| 37 | 37 | |
| 38 | -### Crypto_box | |
| 38 | +### crypto_box | |
| 39 | 39 | |
| 40 | -This depends on the crypto_box primitive as implemented in [nacl](http://nacl.cr.yp.to/box.html) | |
| 41 | -unfortunately, that primitive is not very well documented, so I will attempt to explain those properties here. | |
| 40 | +This depends on the `crypto_box` primitive as implemented in [nacl](http://nacl.cr.yp.to/box.html) | |
| 41 | +unfortunately, that primitive is not very well documented, so I will attempt to explain those properties here. The security model of this primitive is only briefly covered on the documentation site so this is based mainly on my reading of the code. Please do check my reasoning here, and make an issue if you think I missed something. | |
| 42 | 42 | |
| 43 | -crypto box takes a message, a nonce, a public key and a private key. | |
| 43 | +`crypto_box` takes a message, a nonce, a public key and a private key. | |
| 44 | 44 | `crypto_box(message, nonce, alice.public_key, bob.private_key)` which is decrypted by |
| 45 | -`crypto_box_open(boxed, nonce, alice.private_key, bob.public_key)`. note that this derives a symmetric key that is the same for `{alice.private_key, bob.public_key}` AND for `{bob.private_key, alice.public_key}`. So either bob or alice may open the box. | |
| 45 | +`crypto_box_open(boxed, nonce, bob.public_key, alice.private_key)`. | |
| 46 | +The message is encrypted with [chacha20 cipher, and authenticated with poly1305. There is no length delimitation so if you wish to transmit this message it must be framed, or have a fixed size, the other party requires the same nonce in order to perform the decryption so that must be provided some way (i.e. either by sending it along with the message, or by having a protocol for determining the next nonce) | |
| 46 | 47 | |
| 47 | -#### security hole if one party looses their private key | |
| 48 | +Although it's described as Bob _encrypting to_ Alice ("Bob boxes the message to Alice") the encryption is not directional, and either Bob _or_ Alice can decrypt the message. This is because it derives a shared key in the manner of a diffie-helman key exchange, _not_ by encrypting a key to Alice's pub key (which would be an operation that Bob could not reverse). This has a surprising property if this is used as an authentication primitive: If an attacker gains Bob's private key, and knows Alice's key then they can not only impersonate bob to Alice (or anyone), but surprisingly they can impersonate _anyone_ to Bob (provided they know that public key)! | |
| 48 | 49 | |
| 49 | -If crypto_box is used without signatures inside it, and one party looses their private key... | |
| 50 | +This would make loosing control 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 a unlikely event, but the antics of the bitcoin network 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 dangerously if keys are compromised) then it's reasonable to make other aspects of the protocol fail safely in the case of key compromise. | |
| 50 | 51 | |
| 51 | -If an attacker gets hold of bob's private key, and knows alice's public key, then he can construct messages that appear to be from alice by boxing `crypto_box(message, nonce, alice.public_key, bob.private_key)` unless bob expects the message to contain a signature from alice, then bob may be fooled that it's a message from alice, when actually it's a message from himself (or from his private key) | |
| 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). | |
| 52 | 53 | |
| 53 | 54 | ### todo, describe protocol... |
Built with git-ssb-web