1 2016-03-26 01:08:38	0|GitHub73|[13bitcoin] 15accraze opened pull request #7747: [docs] added depends cross compile info (06master...06depends-build-docs) 02https://github.com/bitcoin/bitcoin/pull/7747
 2 2016-03-26 08:00:13	0|jonasschnelli|gmaxwell: good point with including the ciphersuite into the KDF to avoid a weak-ciphersuite-attack. Haven't thought about that!
 3 2016-03-26 08:00:57	0|jonasschnelli|gmaxwell: you said "Personally I'd just suggest dropping the negoation;". I guess you mean only the ciphersuite-negotiation? Not the whole ECDH?
 4 2016-03-26 08:01:02	0|gmaxwell|nor did the authors of dozens of other protocols that didn't. I am not so smart, lots of people have failed here before, and I'm only repeating their mistakes.
 5 2016-03-26 08:01:07	0|gmaxwell|jonasschnelli: right.
 6 2016-03-26 08:02:37	0|jonasschnelli|gmaxwell: you said: " (also, you're going to need a 256 bit session ID for later auth, and two 512 bit keys for the authenticated encryption);" I don't understand that. I'm only aware of two 256bit keys for both directions ECDH.
 7 2016-03-26 08:02:46	0|jonasschnelli|I don't see a need for a auth session id.
 8 2016-03-26 08:03:26	0|jonasschnelli|Because I assume the encryption negotiation followed by a auth identity pubkey check will keep the authentication withing the encryption session?
 9 2016-03-26 08:03:52	0|sipa|jonasschnelli: you'll need a session id to sign when doing identity checking
10 2016-03-26 08:04:26	0|gmaxwell|the authentication must bind the session or varrious kinds of MITM identity proxying attacks turn up.
11 2016-03-26 08:04:33	0|sipa|sure, you could sign one of the encryption keys or the ECDH output directly, but it's generally better to separate them
12 2016-03-26 08:04:52	0|jonasschnelli|sipa: Ah. So during the encryption negotiation both side produce a 256bit session id and the other party needs to sign that (together with the pubkey) to ensure a link between the auth and the enc?
13 2016-03-26 08:05:40	0|sipa|jonasschnelli: auth is an overloaded term; do you mean MAC or identity verification?
14 2016-03-26 08:05:53	0|jonasschnelli|identity verification. sry.
15 2016-03-26 08:06:10	0|gmaxwell|jonasschnelli: right thats what the session ID is for.
16 2016-03-26 08:06:36	0|jonasschnelli|So the session ID can be transported unencrypted during ECDH nego.?
17 2016-03-26 08:06:42	0|jonasschnelli|no... wait.
18 2016-03-26 08:06:52	0|gmaxwell|the session ID is just a result of the ECDH.
19 2016-03-26 08:06:52	0|sipa|jonasschnelli: the session ID never ever transported
20 2016-03-26 08:07:04	0|sipa|not encrypted, not unencrypted
21 2016-03-26 08:07:12	0|jonasschnelli|hmm...
22 2016-03-26 08:07:20	0|gmaxwell|The ECDH runs, and the result is a session ID and a set of keys for the encryption/mac.
23 2016-03-26 08:07:37	0|gmaxwell|And the session ID can (optionally) be authenticated.
24 2016-03-26 08:07:52	0|jonasschnelli|so the ECDH calculated point could be the session ID, then run a KDF, get the sym. cipher key?
25 2016-03-26 08:08:32	0|sipa|jonasschnelli: ECDH output is used as seed for a PRNG; from that PRNG you read session id, IV, encryption keys, ... whatever you need
26 2016-03-26 08:09:13	0|jonasschnelli|And to verify identity (identity auth) the requesting peer needs to sign the ECDH calculated point (or a PRNG result from that seed) with his pre-shared idendity pubkey?
27 2016-03-26 08:09:36	0|sipa|yes
28 2016-03-26 08:09:39	0|gmaxwell|you never use the ECDH value directly. They'd sign the session ID. (a PRNG result)
29 2016-03-26 08:09:53	0|jonasschnelli|Okay. Got it!
30 2016-03-26 08:10:08	0|jonasschnelli|Wasn't aware of the possibility to use the ECDH point as seed.
31 2016-03-26 08:10:16	0|gmaxwell|The PRNG input should include the ECDH along with all the 'session context' e.g. any paramter negoiation that was sent.
32 2016-03-26 08:10:26	0|gmaxwell|(I recommend including one of the public keys in the KDF, to avoid the gratitious loss of entropy; but this is a minor thing)
33 2016-03-26 08:10:55	0|jonasschnelli|And probably the ciphersuite (if we keep this).
34 2016-03-26 08:11:12	0|sipa|jonasschnelli: i think it makes sense to have ciphersuite versions
35 2016-03-26 08:11:19	0|sipa|and just have one currently
36 2016-03-26 08:11:24	0|jonasschnelli|Yes. I also reserved it for future changes.
37 2016-03-26 08:11:37	0|sipa|negotiation is hard, and general trend is moving away from it
38 2016-03-26 08:12:02	0|sipa|instead just have version numbers of the protocol, and each version has one fixed set of ciphers
39 2016-03-26 08:12:34	0|gmaxwell|sipa: I'm not sure this is better though! consider, if you merely do that, how do you guard against downgrade attacks-- I guess only by supporting just a single version?
40 2016-03-26 08:12:49	0|gmaxwell|otherwise, what you need to do is have the protocol commit to whatever versions were offered.
41 2016-03-26 08:14:29	0|jonasschnelli|Okay. I'll update the BIP and write more specification about the negotiation, session ID, KDF
42 2016-03-26 08:14:47	0|jonasschnelli|pbkdf2?
43 2016-03-26 08:15:49	0|sipa|for KDF you could use rfc6979 (slow!), just a simple SHA256 of ECDH together with a counter, chacha20, or maybe SHAKE (sha3 variant with arbitrary length output)
44 2016-03-26 08:16:22	0|sipa|i like sha3 because it has such large state, so you can put a lot of context in without limiting entropy
45 2016-03-26 08:17:40	0|sipa|the pb in pbkdf stands for password based :)
46 2016-03-26 08:17:43	0|gmaxwell|jonasschnelli: another thing your spec is missing is rekeying. The chacha20/poly must be rekeyed periodically.
47 2016-03-26 08:17:55	0|jonasschnelli|^^
48 2016-03-26 08:18:00	0|gmaxwell|pbkdf2 is intentionally slow, not a requirement here.
49 2016-03-26 08:18:18	0|sipa|gmaxwell: my assumption was that you'd do another encinit session occasionally within the encrypted channel
50 2016-03-26 08:18:24	0|gmaxwell|I don't know if you noticed but I suggested that authentication could be done in a way combined with rekeying which would have some very nice properties.
51 2016-03-26 08:18:32	0|jonasschnelli|So... rekey = re-negotiate the whole ECDH secret every x minutes/hours?
52 2016-03-26 08:18:55	0|sipa|every gigabyte
53 2016-03-26 08:19:07	0|sipa|though having time limits is good too
54 2016-03-26 08:19:42	0|jonasschnelli|an right. would something speak against sipas idea of re-key within the current enc session?
55 2016-03-26 08:20:10	0|jonasschnelli|Would probably make the implementation simpler.
56 2016-03-26 08:20:15	0|jonasschnelli|(different message formats)
57 2016-03-26 08:20:40	0|sipa|jonasschnelli: gmaxwell's identity check idea would also automatically result in a rekey
58 2016-03-26 08:20:42	0|gmaxwell|I suggested that to auth, the auth requester send X H(sessionid,server_pubkey), and if the server knows the pubkey for X, she responds with a message saying that she is changing her encryption key, and changes to H(old_encryption_key, server_pubkey) as the new one.. and in the newly encrypted segment she tranmits the signature that proves she knows the secret.
59 2016-03-26 08:21:18	0|gmaxwell|This has a nice properity that if the server pubkey is kept secret; the confidentiality of past communications is preserved even if ECC is broken.
60 2016-03-26 08:21:43	0|gmaxwell|And it also proves that the servers identity key has remained online, if that procedure is used for each rekeying in the future.
61 2016-03-26 08:23:46	0|jonasschnelli|gmaxwell: H(old_encryption_key, server_pubkey)  <--- "old_encryption_key" would be the KDF derived  symmetric key?
62 2016-03-26 08:23:56	0|gmaxwell|Yes.
63 2016-03-26 08:24:09	0|jonasschnelli|And... right. That would be required "in both directions"...
64 2016-03-26 08:25:32	0|gmaxwell|My thought on that is that even when you don't have an identity you're expecting everyone could just support using the generator (private key 1).. so even without a known identity the same protocol would always be used... good for QA and for traffic analysis resistance.
65 2016-03-26 08:25:42	0|jonasschnelli|gmaxwell: and a re-keying without identity auth? new ECDH nego., new session id, but sym. key could be H(old_encryption_key, new_encryption_key)?
66 2016-03-26 08:26:44	0|gmaxwell|yes it could be there is no need to redo ECDH, just a waste of CPU time.
67 2016-03-26 08:27:11	0|jonasschnelli|but how would you create a new shared secret? Using a counter on both sides?
68 2016-03-26 08:27:32	0|gmaxwell|H(old_key) is sufficient.
69 2016-03-26 08:27:52	0|jonasschnelli|ah.. okay. I see. Just hash the hash, ...
70 2016-03-26 08:28:13	0|gmaxwell|for forward security reasons you don't want to be forced to keep the old keys around... they should be destroyed as soon as they're not in use.
71 2016-03-26 08:28:31	0|jonasschnelli|How would the other peer know when it is time to re-key. Probably requested by the responding peer with a new message type.
72 2016-03-26 08:29:01	0|jonasschnelli|s/./?
73 2016-03-26 08:29:02	0|gmaxwell|by sending a message in the channel, "everything that follows will be the next key"
74 2016-03-26 08:29:20	0|jonasschnelli|right. That makes sense.
75 2016-03-26 08:30:37	0|gmaxwell|and my earlier suggestion was to make the auth do this so that the pubkey could be used as a symmetric secret in the rekeying.
76 2016-03-26 08:32:04	0|jonasschnelli|And I suppose the identity auth also needs a timeout (probably time instead of consumed bandwith).
77 2016-03-26 08:33:03	0|gmaxwell|forward secrecy also wants a timeout, so something like 1 hour or 1GB whichever comes first.
78 2016-03-26 08:33:23	0|gmaxwell|not that our need for forward secrecy is so great, but if we're going to do something might as well do it right.
79 2016-03-26 08:36:16	0|jonasschnelli|Okay... Let me update the BIP. I think this iterative improvement approach might lead to something we can use (at least use it for later improvments).
80 2016-03-26 13:52:55	0|GitHub145|[13bitcoin] 15mruddy opened pull request #7748: test and regtest mempool: not require standard, non-mandatory, input script verification flags (06master...06nonstandard-sighash) 02https://github.com/bitcoin/bitcoin/pull/7748
81 2016-03-26 20:19:05	0|GitHub135|[13bitcoin] 15sipa opened pull request #7749: Enforce expected outbound services (06master...06checkservices) 02https://github.com/bitcoin/bitcoin/pull/7749