1 2016-03-24 00:00:44	0|gmaxwell|oh hmph. made some pgoress but stuck again. :(
  2 2016-03-24 00:01:17	0|gmaxwell|now this looks like local corruption from running out of space. 2016-03-24 00:00:19 ERROR: ReadBlockFromDisk: OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)
  3 2016-03-24 00:01:50	0|sipax|ugh!
  4 2016-03-24 00:02:04	0|sipax|that means the block data wasn't written but the index entry for it was
  5 2016-03-24 00:02:20	0|sipax|remind me to investigate the write order during flush in such a case
  6 2016-03-24 00:03:17	0|gmaxwell|well it may have been out of space and the write could have failed. Our out of space handling is not so great always.
  7 2016-03-24 00:03:37	0|sipax|it should not go write a database entry for a file it failed to create
  8 2016-03-24 00:03:46	0|sipax|is it a pruned node?
  9 2016-03-24 00:03:49	0|gmaxwell|no.
 10 2016-03-24 00:03:56	0|sipax|in that case, certainly not
 11 2016-03-24 00:04:44	0|gmaxwell|what the heck, even after logging that a bunch of times it's making progress again.
 12 2016-03-24 00:06:01	0|gmaxwell|okay, actually the readblockfromdisk is being triggered by getblock rpcs being called by p2pool
 13 2016-03-24 00:06:40	0|gmaxwell|so this might just be an artifact of running getblock on a block we have headers for but no data.
 14 2016-03-24 00:07:31	0|sipax|gmaxwell: no, it shouldn't
 15 2016-03-24 00:07:45	0|sipax|getblock RPC checks whether the BLOCK_HAVE_DATA flag is present for that block index entry
 16 2016-03-24 00:14:33	0|gmaxwell|2016-03-23 23:58:18 ERROR: ReadBlockFromDisk: OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)
 17 2016-03-24 00:14:33	0|gmaxwell|2016-03-23 23:58:18 Received a POST request for / from
 18 2016-03-24 00:14:33	0|gmaxwell|well my log is full of
 19 2016-03-24 00:14:36	0|gmaxwell|2016-03-23 23:58:18 ThreadRPCServer method=getblock
 20 2016-03-24 00:32:54	0|gmaxwell|and now that it's caught up, no more..
 21 2016-03-24 02:19:06	0|morcos|gmaxwell: sipax: looks like thats just the error that happens, the RPC only checks the BLOCK_HAVE_DATA flag if you're pruning.  Ha!
 22 2016-03-24 06:45:23	0|jonasschnelli|encryption: would it be stupid to use the identity keypair (used for Auth / MITM protection) in a ECDH scheme to encrypt a dh key-exchange for further encryption?
 23 2016-03-24 06:45:47	0|jonasschnelli|I think we should not use the "static" identity key for encryption.
 24 2016-03-24 06:46:16	0|jonasschnelli|It would expose the shared ecdh secred (AES256key) to known-plaintext-attacks.
 25 2016-03-24 06:46:58	0|jonasschnelli|But not sure if using the identity key for a quick ECDH keyexchange (known-plaintext-attacks are pretty impossible) would make sense.
 26 2016-03-24 06:51:35	0|gmaxwell|It would be stupid beyond all comprehension.
 27 2016-03-24 06:52:13	0|gmaxwell|The encryption should be ephemerally keyed. There is no need for the key to outlive the session.
 28 2016-03-24 06:57:40	0|gmaxwell|What I suggested earlier-- which is a pretty standard and well studied architecture is to use randomly generated keys to establish a secure channel (with authenticated encryption like AES-GCM or chacha20-poly1305); then inside if-- if some identity is in use-- you use that identity to authenticate the secure session you just established. E.g. by signing the hash of the shared session key.
 29 2016-03-24 07:00:44	0|sipax|gmaxwell: that is MitMable?
 30 2016-03-24 07:01:02	0|gmaxwell|... No.
 31 2016-03-24 07:01:36	0|sipax|oh, no!
 32 2016-03-24 07:01:37	0|jonasschnelli|gmaxwell: how would you pass the random generated symmetric cipher key to "the other side"? ECDH channel with the identity key?
 33 2016-03-24 07:03:06	0|gmaxwell|Please please stop trying to use ecdh with long lived keys. This is almost always a severe design mistake.
 34 2016-03-24 07:04:21	0|gmaxwell|Each side sends a new, randomly generated public key to the other side. The session keys (there will be more than one, likely four-- auth and encrypt in each direction) are the output of ECDH with those keys, fed through a KDF.
 35 2016-03-24 07:06:16	0|jonasschnelli|gmaxwell: Okay. How would you protect from MITM. By auth with the identity key AFTER the encryption channel is setup?
 36 2016-03-24 07:08:03	0|gmaxwell|if identification is in use, inside the encrypted channel you send a signature of the session id (a hash of the ephemerial key from ecdh which also commits to all the channel parameters) using the relevant identity.
 37 2016-03-24 07:09:59	0|jonasschnelli|gmaxwell: how would you protect from attacking(DOSing) the encryption request (key generation!) if the auth is after the enc?
 38 2016-03-24 07:09:59	0|sipax|what do you mean by channel parameters?
 39 2016-03-24 07:10:02	0|jonasschnelli|Also fingerprinting
 40 2016-03-24 07:10:28	0|jonasschnelli|(the later is probably fine if the 4 key are generated randomly)
 41 2016-03-24 07:10:30	0|gmaxwell|key generation is very fast, faster then verifying your digital signatures you propose for authentication.
 42 2016-03-24 07:11:00	0|gmaxwell|Fingerprinting what?
 43 2016-03-24 07:11:12	0|sipax|jonasschnelli: if you always use freshly generated ecdh keys, there is no fongerprinting
 44 2016-03-24 07:11:14	0|jonasschnelli|gmaxwell: fingerprinting the node.
 45 2016-03-24 07:11:43	0|jonasschnelli|Well,.. right. We could ban a node after a failed encryption request.
 46 2016-03-24 07:12:11	0|sipax|i don't think it can fail
 47 2016-03-24 07:12:24	0|jonasschnelli|sipax: I mean the identity check afterwards
 48 2016-03-24 07:13:03	0|sipax|jonasschnelli: it's much cheaper for them to go ask us a bunch of random blocks, with far higher costs
 49 2016-03-24 07:13:08	0|sipax|if they want to dos
 50 2016-03-24 07:13:11	0|gmaxwell|jonasschnelli: no, it's fundimentally easier to generate a new keypair than to verify a ecdh signature. They're pretty close in timings, because we use a constant time implementation for the former.
 51 2016-03-24 07:13:14	0|jonasschnelli|But this would basically mean, every peer can request encrypted sessions... (which i'm not sure if its good or bad).
 52 2016-03-24 07:13:44	0|gmaxwell|they should, and they should all be encrypted so as not to distingush the ones using authentication.
 53 2016-03-24 07:14:09	0|gmaxwell|and this can be made faster than the existing transport (or at least not considerably worse).
 54 2016-03-24 07:14:38	0|sipax|jonasschnelli: for ECDSA, verify > sign >>> keygen
 55 2016-03-24 07:14:58	0|jonasschnelli|sipax: I see. Thanks!
 56 2016-03-24 07:15:17	0|sipax|jonasschnelli: computing the pubkey for a generated private key is similar to signing
 57 2016-03-24 07:15:24	0|gmaxwell|well if by keygen you mean generate a pubkey too, then sign == keygen, pretty much.
 58 2016-03-24 07:15:48	0|gmaxwell|and this is faster than verify.
 59 2016-03-24 07:16:01	0|sipax|same order of magnitude in any case
 60 2016-03-24 07:16:05	0|jonasschnelli|gmaxwell: So. The peer would pass one pubkey for the dh secret calculation and the (static) identity pubkey (static) for auth to the other peer. Right?
 61 2016-03-24 07:16:51	0|jonasschnelli|(doesn't the current[and most] ec keygen algos do a dummy sign/verify to ensure validity?)
 62 2016-03-24 07:17:05	0|sipax|jonasschnelli: if by auth you mean the signing of the session key, indeed
 63 2016-03-24 07:17:12	0|sipax|jonasschnelli: bitcoin does
 64 2016-03-24 07:17:14	0|gmaxwell|the only software ever created that does that is bitcoin core.
 65 2016-03-24 07:17:19	0|gmaxwell|as far as I can tell.
 66 2016-03-24 07:17:33	0|gmaxwell|and it's only sensible to do that for payment addresses, it wouldn't be done here.
 67 2016-03-24 07:18:15	0|gmaxwell|first an encrypted, authenticated channel would be brought up using a ephemeral pubkey sent in each direction.  Then _inside_ that channel, the participants could identify themselves by signing the session-id.
 68 2016-03-24 07:18:23	0|jonasschnelli|only signing the session key would not allow the remote peer to identify which identity is signing. Wouldn't it require at least the hash of the identity pubkey?
 69 2016-03-24 07:19:45	0|gmaxwell|Techincally the signature and message its signing is enough, you can just get the pubkey from that. Though it could send the pubkey its using.
 70 2016-03-24 07:20:13	0|jonasschnelli|Ah. Right pubkey recover.
 71 2016-03-24 07:20:20	0|gmaxwell|but there are better protocols for identifying than just sending a signature-- ones that do not leak the identity of at least one participant.
 72 2016-03-24 07:20:35	0|jonasschnelli|0-knowlage?
 73 2016-03-24 07:22:53	0|jonasschnelli|What about allowing auth without enc? We probably presume encryption when authenticating.
 74 2016-03-24 07:23:14	0|gmaxwell|13:14 < gmaxwell> There are protocols that avoid the fingerprinting; e.g. (the server protectng mode of) https://www.ietf.org/proceedings/54/I-D/draft-ietf-ipsec-jfk-04.txt
 75 2016-03-24 07:23:39	0|gmaxwell|jonasschnelli: I think there is no utility to identifying without encryption.
 76 2016-03-24 07:24:29	0|jonasschnelli|Agree. The current auth proposal would also require signing (auth) each message (which is resource hungry).
 77 2016-03-24 07:24:42	0|gmaxwell|thats unacceptably slow.
 78 2016-03-24 07:24:45	0|jonasschnelli|encryption before authentication allows to keep a auth-session.
 79 2016-03-24 07:25:34	0|sipax|jonasschnelli: note that authentication is used in two meanings here; there is identification (done by signing the session key) and MAC (which you still need, but ks covered by using an authenticated mode of encryption such as AES-GCM)
 80 2016-03-24 07:25:40	0|gmaxwell|(and signining indivigual messages provides non-repudiation, which is usually not what you want; except in specific instances where you do want it.)
 81 2016-03-24 07:26:14	0|jonasschnelli|I see.
 82 2016-03-24 07:26:38	0|sipa|jonasschnelli: so there is "auth" on each message, but it's done with a symmetric shared session key, rather than the identity key
 83 2016-03-24 07:26:48	0|jonasschnelli|And I guess it would be acceptable if the remote peer can fingerprint the requesting peer because it reveals its identity after the encryption channel is established.
 84 2016-03-24 07:27:29	0|gmaxwell|jonasschnelli: it's better than the other way around at least. preferably no one could fingerprint anyone; but it's not clear how possible that is.
 85 2016-03-24 07:27:32	0|jonasschnelli|sipa: Right. But we just need to make sure the symmetric shared session key was shared between the right parties and not Mitmdled.
 86 2016-03-24 07:27:42	0|sipa|jonasschnelli: i think you probably want a per-IP identity, or perhaps just randomly generated identities by default, and allow a peer to ask "hey, you're identity X, right? prove it"
 87 2016-03-24 07:27:51	0|gmaxwell|Other than the "connect to my own server" case it's not clear to me exactly how the identification would be used.
 88 2016-03-24 07:28:03	0|jonasschnelli|sipa: But that would not work for DHCP nodes (SPV)?
 89 2016-03-24 07:29:03	0|sipa|jonasschnelli: so perhaps a separate private non-random configurable host key, which is only used if requested by the peer
 90 2016-03-24 07:29:29	0|sipa|that means no TOFU, though
 91 2016-03-24 07:29:32	0|gmaxwell|we don't want to create cases where nodes can be tracked easily, we've worked to remove identifying information from the protocol...  having a protocol where there is mutual auth, say between your own 'server' and 'client'  or between your own hosts,  having the requester leak something the allows them to be correlated, but only inside an encrypted channel which they think is to their trusted pe
 92 2016-03-24 07:29:38	0|gmaxwell|er, would be minimally harmful.
 93 2016-03-24 07:30:39	0|gmaxwell|sipa: I don't know what use tofu would have... and what happens when a node goes away (say, gets deleted) and a new one is at that address? now you need an expiration mechenism.
 94 2016-03-24 07:31:03	0|jonasschnelli|gmaxwell: at least you could setup a honeypot-like peer that waits until other peers connect, request encryption and identify themself. You could than combine this data with other fingerprint possibilities (mempool and stuff like that).
 95 2016-03-24 07:32:13	0|gmaxwell|jonasschnelli: the party initating authentication would be the only one to lose privacy, so a honey pot would not work; unless it also successfully mitmed hosts that clients were attempting to connect to.
 96 2016-03-24 07:32:33	0|jonasschnelli|But somehow I think either you have a MITM attack possibility or you reveal ones identity. Maybe some zero knowledge prove method could be used here (not familiar with these)
 97 2016-03-24 07:32:51	0|gmaxwell|There are probably multiple usecases which would identify the channel in different ways; but the same secure channel mechenism would work.
 98 2016-03-24 07:33:58	0|gmaxwell|jonasschnelli: I linked a likely sutable identification protocol above.
 99 2016-03-24 07:35:27	0|gmaxwell|I am not suggesting we specifically use that, as much as pointing out that it's possible to do better... but even a very simple protocol does what we want, I think.
100 2016-03-24 07:35:42	0|sipa|jonasschnelli: you could also avoid the problem, and by default not have identification, and only have a "prove to me you're X before continuing" message inside the encryptee channel
101 2016-03-24 07:36:36	0|sipa|perhaps even using symmetric crypto, so it only works with a preshared symmetric key
102 2016-03-24 07:36:44	0|jonasschnelli|sipa: Yes. Agreed. Auth would only be necessary or useful if the both peers know each other (preshared key, same owner, SPV<->node stuff).
103 2016-03-24 07:37:31	0|gmaxwell|identification, when you say auth it easily gets confused with the authentication part of encryption which is necessary and cannot be omitted when encryption is used. :)
104 2016-03-24 07:37:47	0|jonasschnelli|A preshared preshared symmetric key would also work. Right. IMO its just easier to share two pubkeys instead of one "symmetric key".
105 2016-03-24 07:38:59	0|jonasschnelli|gmaxwell: Can you explain the differences between the identity authentication and the encryption authentication? Why would the later be required if both parties stay anonyme to each other?
106 2016-03-24 07:39:55	0|jonasschnelli|Once you exchanged encryption ephemeral pubkeys, MITM should no longer be possible?
107 2016-03-24 07:40:23	0|gmaxwell|jonasschnelli: any use of encryption _must_ come with symmetric-key authentication, or otherwise the encryption will be mallible and an attacker can corrupt the channel in ways that leak information about the content.
108 2016-03-24 07:41:35	0|gmaxwell|e.g. they flip a bit, and instead of instantly hanging up, the application is fed some gibberish, and then based on exactly how it responseds/doesn't respond the attacker learns something about the state of the connection and the prior encrypted data.
109 2016-03-24 07:42:26	0|gmaxwell|so the encryption must comes with a message-authentication-code keyed at the same time as the encryption, so any corruption is detected and the connection terminated without revealing anything, ideally before even decrypting the data.
110 2016-03-24 07:42:55	0|jonasschnelli|gmaxwell: sharing the encryption ephemeral pubkeys, calculate symmetric secret and hash the complete communication (starting with both pubkey in deterministic order), compare the hashes after decrypt..
111 2016-03-24 07:43:20	0|gmaxwell|jonasschnelli: that isn't sufficient.
112 2016-03-24 07:43:50	0|sipa|jonasschnelli: encryption provides confidentiality, not integrity
113 2016-03-24 07:44:30	0|jonasschnelli|hmm....
114 2016-03-24 07:45:05	0|Luke-Jr|jonasschnelli: it might or might not make sense to coordinate with the new payment protocol encryption stuff
115 2016-03-24 07:45:19	0|Luke-Jr|in BIP 75
116 2016-03-24 07:47:21	0|jonasschnelli|Luke-Jr: thanks. Will check. Agree on the p2p 16x num range.
117 2016-03-24 07:49:17	0|sipa|jonasschnelli, gmaxwell: the paper my const time aes is based on actually discusses aes-gcm (and easily has 4x the performance of the cbc case, as it can do 4 parallel encryption operations)
118 2016-03-24 07:50:27	0|jonasschnelli|gmaxwell sipa: hmm... (having a hard time to understand this correctly): so you would require to generate two keypairs at the same time, one for the encryption sym. cipher key, one for the MAC key. Then you sould sha256_hmac the complete message traffic on both sides and compare to validate the integrity?
119 2016-03-24 07:50:52	0|sipa|jonasschnelli: no, you use aes-gcm
120 2016-03-24 07:51:03	0|sipa|which does encryption and mac simultanelusly
121 2016-03-24 07:51:47	0|jonasschnelli|sipa: okay. I see. But the overall concept would be correct (just to understand the basics).
122 2016-03-24 07:51:56	0|jonasschnelli|s/./?
123 2016-03-24 07:52:10	0|sipa|though, conceptually, yes, you can use aes for encryption, and then do hmac-sha256 on the encrypted data for integrity
124 2016-03-24 07:52:56	0|gmaxwell|There should be two "keys" if using authenticated encryption (like AES-GCM, chacha20-poly, or things coming out of CAESAR) one key in each direction;  or four keys if constructing autenticated encryption from a cipher and hmac.
125 2016-03-24 07:53:15	0|jonasschnelli|What I have problems to understand is how attacks would be possible if you would take the encryption ephemeral publey calculated sym. key for the MAC...
126 2016-03-24 07:53:49	0|sipa|jonasschnelli: let's say you use aes-ctr
127 2016-03-24 07:53:57	0|sipa|you know ctr?
128 2016-03-24 07:54:17	0|jonasschnelli|streaming.
129 2016-03-24 07:55:26	0|sipa|someone may not be able to decrypt without having the key, but if they can guess what the contents is of a particular message, they can modify it by xoring it with both what they think the decrypted data is, and xoring it with what they want the decrypted data to be
130 2016-03-24 07:56:33	0|sipa|there are more complex bad things you can do with other encryption schemes
131 2016-03-24 07:56:52	0|jonasschnelli|sipa: Got it! Thanks!
132 2016-03-24 07:57:18	0|sipa|but ctr is a nice example, because it perfectly covers confidentially, but provides almost nothing else
133 2016-03-24 07:57:36	0|sipa|so it clearly shows the distinction
134 2016-03-24 07:59:38	0|jonasschnelli|sipa: But IIRC, your AES PR is CBC. So GCM would require another implementation while our codebase already supports SHA2 HMAC?
135 2016-03-24 07:59:57	0|sipa|jonasschnelli: GCM is easy :)
136 2016-03-24 08:00:19	0|jonasschnelli|sipa: for you or for all other lazy programmers.. :)
137 2016-03-24 08:00:35	0|gmaxwell|sha2 is slow.
138 2016-03-24 08:01:05	0|jonasschnelli|And I guess we could drop the message headers 4byte sha256 checksum once encrypted and MACed
139 2016-03-24 08:01:48	0|gmaxwell|(AES-GCM is also not astonishingly fast without hardware AES, but should be faster than sha2)
140 2016-03-24 08:02:09	0|gmaxwell|jonasschnelli: yes, and the result, with sutiable primitive selection would be _faster_ than the existing protocol, even though it was encrypted.
141 2016-03-24 08:02:25	0|jonasschnelli|hah. Thats an argument.
142 2016-03-24 08:02:32	0|gmaxwell|(faster in terms of cpu usage, it would likely have some more bandwidth overhead, but not a ton)
143 2016-03-24 08:03:14	0|jonasschnelli|But I'm mostly thinking "in implementations". So,... I could write a first implementation that drops the 4byte header sha and uses SHA2 HMAC for the MAC.. just to have an implementation basepoint.
144 2016-03-24 08:03:36	0|jonasschnelli|(in addition to the whole encryption keysharing stuff)
145 2016-03-24 08:04:58	0|jonasschnelli|I could be the guy that works on the code frontend while I require analysis and conceptual support from gmaxwell/sipa and others. This could lead to a pratical p2p encryption IMO.
146 2016-03-24 08:06:26	0|sipa|gmaxwell: my current const aes needs 270 cycles/byte; making it do 4 in parallel is trivial and would make it need 72; researchers claim they can do ~10 using simd
147 2016-03-24 08:06:37	0|sipa|and ~3 with aes-ni
148 2016-03-24 08:06:41	0|gmaxwell|sipa: I think with a.. right.
149 2016-03-24 08:07:13	0|gmaxwell|See also the motivationes behind the CAESAR competition.
150 2016-03-24 08:13:20	0|gmaxwell|sipa: lol one of the CAESAR entries is based on keccak and is named "keyak". That totally isn't going to cause any confusion...
151 2016-03-24 08:16:14	0|GitHub117|[13bitcoin] 15laanwj closed pull request #7694: Rename AcceptBlock/AcceptBlockHeader to StoreBlock/StoreBlockHeader (06master...062016-03-15-naming) 02https://github.com/bitcoin/bitcoin/pull/7694
152 2016-03-24 08:16:45	0|sipa|gmaxwell: i was just reading the keyak v2 paper
153 2016-03-24 08:18:03	0|btcdrak|I've asked a cryptographer to look at #7689
154 2016-03-24 08:22:59	0|jonasschnelli|Could we ask apoelstra?
155 2016-03-24 08:23:41	0|jonasschnelli|I'm not sure if a standalone AES library (move sipas PR to a custom library) would make sense.
156 2016-03-24 08:24:58	0|jonasschnelli|Adding more non-consensus stuff there will very likely lead to a openssl clone?!
157 2016-03-24 08:25:04	0|jonasschnelli|And adding SHA512 but not SHA256?
158 2016-03-24 08:25:40	0|wumpus|jonasschnelli: correct
159 2016-03-24 08:26:05	0|wumpus|I don't think petertodd's concern is so much about the library, but more about 'how much review doees this get'
160 2016-03-24 08:28:19	0|jonasschnelli|wumpus: after thinking about it. maybe a simple C bases AES library could have a reason to exists.
161 2016-03-24 08:28:22	0|sipa|gmaxwell: what is the fastest authenticated encryption scheme implementation that you know? (assume no hardware support, but constant time)?
162 2016-03-24 08:28:51	0|wumpus|jonasschnelli: sure, it could, but this is specifically a constant-time AES for wallet encryption
163 2016-03-24 08:29:38	0|jonasschnelli|wumpus: Right. If the p2p encryption will be implemented once, it could be extended there (AES CGM).
164 2016-03-24 08:29:46	0|gmaxwell|sipa: people who want that are using chacha20-poly1305.  AES-GCM with hardware support is apparently somewhat faster (and much less power hungry); but without it the chacha20-poly1305 stuff is faster.
165 2016-03-24 08:29:47	0|wumpus|it's e.g. not the fastest way to implement AES, because we specifically don't need that. There may not be many projects that want to tuse it at all, and there's a long tradition of copy/pasting crypto code anyhow....
166 2016-03-24 08:30:31	0|gmaxwell|people who care about fast AES use hardware or use these parallel implementations which cannot be used for CBC mode, which compatiblity with the wallet encryption needs.
167 2016-03-24 08:31:11	0|wumpus|gmaxwell: yes, exactly
168 2016-03-24 08:31:48	0|wumpus|for the AES code I really have only one concern: is it correct
169 2016-03-24 08:32:10	0|wumpus|for the random code I'm more scared because of the platform dependence and other uglyness involved
170 2016-03-24 08:32:45	0|sipa|wumpus: agree
171 2016-03-24 08:32:57	0|gmaxwell|currently we don't care at all about fast AES. We should somewhat care that it doesn't have stupid sidechannels.  Later, if we care about fast AES for p2p encryption, it would be AES-GCM and end up with a CBC incompatible implementation in any case.
172 2016-03-24 08:33:40	0|wumpus|yes, for P2P we could use a different implementation of AES, or not AES at all (chacha20 or so :p)
173 2016-03-24 08:34:26	0|gmaxwell|right or whatever CAESER selects, depending on what that happens.
174 2016-03-24 08:34:38	0|wumpus|yes
175 2016-03-24 08:35:25	0|sipa|gmaxwell: that's 2 years out
176 2016-03-24 08:35:46	0|gmaxwell|(most of the CAESER candidates are AES based in any case, mostly addressing security complaints about GCM, and expecting hardware support to address the obnoxiousness of constant time AES)
177 2016-03-24 08:37:56	0|gmaxwell|it has a mixed following, it's apparently enough faster on ARM and without AES-NI that many in the web world have considered it urgent to support... but apparently a lot of the datacenter folks are less than enthused since it ends up much more power hungry than hardware AES.
178 2016-03-24 08:39:23	0|wumpus|yes, right, it's specifically efficient in sw, if there is a hw implementation of AES it'll win out
179 2016-03-24 08:39:39	0|jonasschnelli|What MAC AAD would make sense for the p2p encryption? hash of the pubkey&pubkey? IP/Port?
180 2016-03-24 08:40:44	0|wumpus|let's just wait for hw chacha20 *ducks*
181 2016-03-24 08:41:03	0|gmaxwell|wumpus: well, its not like they have anything better to do with the transistors...
182 2016-03-24 08:41:35	0|wumpus|gmaxwell: agree, the dark silicon problem
183 2016-03-24 08:42:59	0|wumpus|then again - for bitcoin nodes we need to worry about consumer hw, not so much big datacenters
184 2016-03-24 08:43:39	0|wumpus|I think it's safe to say there won't be so many bitcoin nodes in datacenters to rival the number of https implementations, let alone be a power usage concern
185 2016-03-24 08:43:53	0|gmaxwell|well a lot of 'consumer hardware' has hardware aes now too, just not phones so much. :)
186 2016-03-24 08:44:00	0|gmaxwell|but indeed.
187 2016-03-24 08:44:41	0|wumpus|power usage on the other hand is mostly a phone concern. But yeah.
188 2016-03-24 08:46:32	0|gmaxwell|in any case both, given good implementations, should be faster the current 'checksum'
189 2016-03-24 08:48:16	0|sipa|jonasschnelli: the additional data is sent in every message
190 2016-03-24 08:51:14	0|sipa|jonasschnelli: you would include the message length there, for example
191 2016-03-24 08:51:20	0|jonasschnelli|sipa: hmm.. so hash would be too expansive?
192 2016-03-24 08:51:39	0|sipa|hash of what?
193 2016-03-24 08:52:06	0|jonasschnelli|hash of the encryption pubkeys or could also be a hash of the plaintext message.
194 2016-03-24 08:54:28	0|sipa|what are you trying to do?
195 2016-03-24 08:55:02	0|sipa|the additional data is a feature provided by authenticated encryption schemes; you don't need to use it if you have nk need for it
196 2016-03-24 09:04:09	0|jonasschnelli|sipa: So do I got this right? You could use something like the current protocol version "70012" as AAD. And during decryption, you feed the TAG (processed AAD) together with the AAD into the decryption method and get a true or false?
197 2016-03-24 09:04:17	0|jonasschnelli|And thanks for you time to explain that to me. :)
198 2016-03-24 09:06:00	0|gmaxwell|you could-- generally it's used for additional per message data that must be sent cleartext for protocol reasons, but which you'd still like included in the authentication.
199 2016-03-24 09:07:37	0|jonasschnelli|gmaxwell: Okay. Right. Message length would be ideal then.
200 2016-03-24 09:09:59	0|gmaxwell|that would be the kind of thing; even that may not be necessary, if the length was wrong, the auth would fail in any case-- wrong amount of data in it.
201 2016-03-24 10:15:57	0|sipa|jonasschnelli: i guess you can include the network magic to the aad
202 2016-03-24 10:16:43	0|jonasschnelli|sipa: okay. Would that be much different then the encrypted message length?
203 2016-03-24 10:18:56	0|sipa|jonasschnelli: i mean both... but there is no strong reason
204 2016-03-24 10:19:08	0|jonasschnelli|okay.
205 2016-03-24 10:19:37	0|sipa|essentially it guarantees that the length/magic came from someone with the session key
206 2016-03-24 10:20:39	0|jonasschnelli|ok
207 2016-03-24 10:36:39	0|sipa|aes-gcm uses 96-bit IVs, but they only require being unique for a given key
208 2016-03-24 10:36:48	0|sipa|and the key is establishes through ecdh
209 2016-03-24 10:37:23	0|sipa|so they can just be the message number, and don't need to be transmitted
210 2016-03-24 11:18:48	0|GitHub140|13bitcoin/060.12 14597494f 15Jonas Schnelli: Remove openssl info from init/log and from Qt debug window...
211 2016-03-24 11:18:48	0|GitHub140|[13bitcoin] 15laanwj pushed 1 new commit to 060.12: 02https://github.com/bitcoin/bitcoin/commit/597494f5a90c041945006b8f3eff8f7e482e0f2f
212 2016-03-24 11:20:01	0|GitHub121|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e5c35119e967...3ba07bdf7da4
213 2016-03-24 11:20:02	0|GitHub121|13bitcoin/06master 140e4b50a 15Alice Wonder: Description of RPM directory
214 2016-03-24 11:20:02	0|GitHub121|13bitcoin/06master 14146746b 15Alice Wonder: All files related to my RPM spec file project in one commit
215 2016-03-24 11:20:03	0|GitHub121|13bitcoin/06master 143ba07bd 15Wladimir J. van der Laan: Merge #7609: All files related to my RPM spec file project in one commit...
216 2016-03-24 11:20:08	0|GitHub36|[13bitcoin] 15laanwj closed pull request #7609: All files related to my RPM spec file project in one commit (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/7609
217 2016-03-24 11:21:31	0|GitHub199|[13bitcoin] 15laanwj closed pull request #7650: Cache CBlockIndex::GetMedianTimePast (06master...06enhancement/cache-getmediantimepast) 02https://github.com/bitcoin/bitcoin/pull/7650
218 2016-03-24 11:28:48	0|GitHub62|[13bitcoin] 15laanwj closed pull request #6973: Compress Blocks before sending (06master...06compress) 02https://github.com/bitcoin/bitcoin/pull/6973
219 2016-03-24 11:32:34	0|sipa|jonasschnelli: i now want to go implement gcm or poly1305...
220 2016-03-24 11:58:47	0|jonasschnelli|sipa: hah. Yes. Work on segwit. The p2p encryption is not urgent.
221 2016-03-24 12:02:26	0|jonasschnelli|sipa: regarding GCM IV: «[...] For a fixed value of the key, each IV value must be distinct, but need not have equal lengths [...]»
222 2016-03-24 12:03:11	0|jonasschnelli|96 bit is ideal though.
223 2016-03-24 12:09:15	0|sipa|jonasschnelli: you could get 64 bits of the iv out of ecdh, and then add a 32-bit message counter, but that shouldn't be needed
224 2016-03-24 12:38:37	0|Chris_Stewart_5|is there a BIP66 post mortem some where about the hard fork?
225 2016-03-24 12:39:17	0|sipa|BIP66 was not a hard fork... there were some miners that mined invalid blocks, and kept going
226 2016-03-24 12:40:32	0|Chris_Stewart_5|sipa: Essentially the miners not enforcing this function right? https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L98
227 2016-03-24 12:52:59	0|jonasschnelli|sipa: ecdh produces a 256bit secret? right? How would you take 64bits for the iv if you need to 256bits for the symmetric key?
228 2016-03-24 13:42:58	0|jonasschnelli|sipa gmaxwell: I'm happy if you are interested in reviewing the authentication and the encryption BIP (https://github.com/jonasschnelli/bips/blob/7e8a9f6e6a06cec1e7842452c85a9dec3730771b/bip-undef-1.mediawiki   https://github.com/jonasschnelli/bips/blob/7e8a9f6e6a06cec1e7842452c85a9dec3730771b/bip-undef-0.mediawiki)
229 2016-03-24 13:43:45	0|jonasschnelli|Don't review the language/orthography, will overhaul that once the technical details are clear.
230 2016-03-24 14:00:13	0|GitHub55|13bitcoin/06master 14d6cc6a1 15João Barbosa: Use CCoinControl selection in CWallet::FundTransaction
231 2016-03-24 14:00:13	0|GitHub55|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3ba07bdf7da4...b88e0b0c610a
232 2016-03-24 14:00:14	0|GitHub55|13bitcoin/06master 14b88e0b0 15Wladimir J. van der Laan: Merge #7506: Use CCoinControl selection in CWallet::FundTransaction...
233 2016-03-24 14:00:18	0|GitHub17|[13bitcoin] 15laanwj closed pull request #7506: Use CCoinControl selection in CWallet::FundTransaction (06master...06enhancement/use-coin-control-selection) 02https://github.com/bitcoin/bitcoin/pull/7506
234 2016-03-24 14:18:11	0|sipa|jonasschnelli: if you want to use a single negotiation to intialize encryption for both directions, you need to make sure that the IVs in bith directions are different, or you break the assumption that an attacker cannot see two different messages with the same key and iv
235 2016-03-24 14:20:27	0|sipa|jonasschnelli: my suggestion here would be to have an encinit ("if you want, you can start sending encrypted messages to me and this is my key") and an encack ("yeah, every message after this one will be encrypted, and this is my key"), which you both send in both directions
236 2016-03-24 14:21:24	0|sipa|jonasschnelli: that way, both directions have independent ECDH negotiations, and you also have no problems with synchronization
237 2016-03-24 14:22:18	0|sipa|jonasschnelli: an alternative is thinking hard about synchronization, and making sure that the initiator and accepter of the encryption connection use separate IVs
238 2016-03-24 14:22:44	0|sipa|jonasschnelli: reusing the key as IV is not very useful, i think
239 2016-03-24 14:24:50	0|sipa|jonasschnelli: you probably want to include some text about how this interacts with version/verack (does encinit have to be the first message entirely? can it be done at any time?
240 2016-03-24 14:31:31	0|sipa|jonasschnelli: your encrypted message protocol spec could make the authentication tag explicit (it's 16 bytes for aes-gcm, though we could decide to truncate it)
241 2016-03-24 14:40:49	0|jonasschnelli|sipa: thanks for the review! Will "process" your points and come back to you with feedback.
242 2016-03-24 17:27:46	0|sipa|jonasschnelli: this is interesting: https://github.com/jhcloos/openssh-chacha-poly1305/blob/master/PROTOCOL.chacha20poly1305
243 2016-03-24 17:28:10	0|sipa|openssh's chacha20-poly1305 aead at a high level
244 2016-03-24 17:28:30	0|sipa|they encrypt the packet sizes too, but with a separate key
245 2016-03-24 17:29:00	0|sipa|and then authenticate using the second key which is used for authentication and encryption of the data
246 2016-03-24 17:29:28	0|sipa|which means that an attacker can't even see the message sizes, except by traffic analysis
247 2016-03-24 17:30:02	0|btcdrak|Clever
248 2016-03-24 17:48:53	0|gmaxwell|a little sad to require 4 byte lenghts.
249 2016-03-24 17:59:30	0|gmaxwell|sipa: for identified links, we could do a nice thing with rekeying to make them strong against ECC breaks.
250 2016-03-24 18:01:16	0|sipa|cfields: if we'd want to use something like that, i guess we want an api that allows a client to tell the comnection manager "let me know when you have X bytes"
251 2016-03-24 18:01:50	0|sipa|cfields: which is oerhaps a cleaner abstraction than hardcoding a particular stream protocol?
252 2016-03-24 18:04:27	0|sipa|jonasschnelli: another suggestion: i think we should drop the network magic... resynchronization after garbage hasn't been supported in a long time, it wastes (a tiny bit of) bandwidth, and makes the encrypted stream look decidedly identifiable (though if encrypted connections bootstrap as unencrypted ones, that isn't solvable)
253 2016-03-24 18:05:05	0|gmaxwell|Alice connects to Bob, Alice sends,  Nonce_a, and alice ephemeral pubky (AEP), bob sends nonce_b and BEP.   ECDH runs,  then a KDF that takes the two nonces, and ecdh output, and spits out a session id and two keys (one for each direction.   Then Alice proposes, "I think you have identity X=H(bob pubkey, session_id)", if this is true, bob responds with "I am rekeying with IDX"  and takes his cur
254 2016-03-24 18:05:11	0|gmaxwell|rent encryption key and changes it to H(bob pubkey|enckey).  When alice sees that message she updates her keys for the stream. Then also does the same herselve (sends a message, updates key). Then bob sends a signature with his pubkey.     Then this authentication procedure can just be repeated every so many bytes in order to rotate the stream cipher keys.
255 2016-03-24 18:05:44	0|gmaxwell|If the 'public keys' are kept private, the link has at least symmetric keyed integrity and confidentality, even with an ECC break.
256 2016-03-24 18:28:29	0|wumpus|<sipa> which means that an attacker can't even see the message sizes, except by traffic analysis <- I think that would be quite essential for bitcoin, as so much can already be identified from the packet sizes
257 2016-03-24 18:28:56	0|wumpus|certain blocks, certain transactions, etc
258 2016-03-24 18:31:25	0|gmaxwell|I had assumed that the encrypted transport would encapsulate one or more length coded messages inside it... so mostly you'd just see the 'send units'.  Doing this would alow avoiding that extra layering, however... and thus decrease overhead.
259 2016-03-24 18:32:31	0|gmaxwell|though perhaps we should make the encoding support padding, so that messages can be padded up to particular size multiplies, to reduce the traffic analysis sidechannel.
260 2016-03-24 18:34:09	0|CodeShark|is there a meeting today?
261 2016-03-24 18:34:42	0|gmaxwell|yes, in about 20 minutes.
262 2016-03-24 18:35:01	0|gmaxwell|You've suffered DST. :)
263 2016-03-24 18:36:04	0|btcdrak|we dont suffer it over this side of the Atlantic until Sunday
264 2016-03-24 18:38:29	0|btcdrak|gmaxwell: is it maybe worth adding a version byte to the encryption scheme to allow upgrades in the future?
265 2016-03-24 18:38:31	0|jonasschnelli|gmaxwell: +1 for padding to reduce sidechannel identification.
266 2016-03-24 18:39:03	0|jonasschnelli|sipa: do you mean dropping the network magic for all post-encryption-init messages?
267 2016-03-24 18:39:27	0|sipa|also +1 to allowing multiple messages in a packet
268 2016-03-24 18:39:49	0|jonasschnelli|You mean one header with a message count int followed by n payloads?
269 2016-03-24 18:39:51	0|sipa|jonasschnelli: yes, it serves no purpose other than detecting accidental connection to the wrong network
270 2016-03-24 18:40:07	0|sipa|jonasschnelli: or just a concatenation of payloads even
271 2016-03-24 18:40:36	0|jonasschnelli|Okay. size + payload + size + payload, etc. That makes sense.
272 2016-03-24 18:41:44	0|sipa|jonasschnelli: inside the aead
273 2016-03-24 18:42:03	0|gmaxwell|that cuts down on the authentication overhead.
274 2016-03-24 18:42:08	0|jonasschnelli|sipa: But I still try to understand your AES GCM 96bit IV solution. How would you create distinctable IV  without transmitting in in the message?
275 2016-03-24 18:43:15	0|sipa|jonasschnelli: use 0000 + counter for one side, use 1111 + counter for the other?
276 2016-03-24 18:43:16	0|sipa|jonasschnelli: use 0000 + counter for one side, use 1111 + counter for the other?
277 2016-03-24 18:43:38	0|jonasschnelli|sipa: Are predictable IVs not a problem?
278 2016-03-24 18:43:45	0|sipa|jonasschnelli: no, just no reuse
279 2016-03-24 18:43:49	0|sipa|ivs are nkt secret
280 2016-03-24 18:43:52	0|sipa|*not
281 2016-03-24 18:44:11	0|jonasschnelli|Okay. I see.
282 2016-03-24 18:44:23	0|gmaxwell|sipa: AEAD packet size does imply memory usage implications though.
283 2016-03-24 18:45:16	0|gmaxwell|but its maximum could just be the same as the largest message.
284 2016-03-24 18:45:20	0|sipa|right
285 2016-03-24 18:45:44	0|jonasschnelli|So. Changes i'll work on a) ecdh exchange for both direction, two sym. keys, fix synchro. b) use chacha20 poly1305 instead of AES GCM c) optimize message structure (drop magic, allow multiple payloads in the AEAD part)
286 2016-03-24 18:46:17	0|sipa|jonasschnelli: no need to fix synchronization if both directions are independent
287 2016-03-24 18:46:58	0|jonasschnelli|yes. I mean fix syncho by using two keypair, one per direction.
288 2016-03-24 18:47:58	0|gmaxwell|great.
289 2016-03-24 18:47:59	0|jonasschnelli|Has chacha20-poly1305 been proven to be stable? Reasonable amount of cryptanalysis? Or do we threat stuff out of DJB's kitchen as stable anyways? :)
290 2016-03-24 18:48:18	0|gmaxwell|jonasschnelli: it's part of TLS and SSH.
291 2016-03-24 18:48:27	0|gmaxwell|I think it's sutiable for our purposes.
292 2016-03-24 18:48:31	0|wumpus|it's geting a lot of testing and review in ssh at least
293 2016-03-24 18:49:00	0|jonasschnelli|Okay. And how complex is an implementation? Or would this lead to a revival of openssl in core?
294 2016-03-24 18:49:12	0|gmaxwell|it's very simple.
295 2016-03-24 18:49:26	0|wumpus|their implementation is very short, that's one thing that is so cool about it
296 2016-03-24 18:49:29	0|jonasschnelli|what speaks again unsing openssl (p2p layer enc is non consensus)?
297 2016-03-24 18:49:46	0|jonasschnelli|*against
298 2016-03-24 18:50:07	0|gmaxwell|we're not taking 400,000+ lines of unreviewable, frequently CVEed code for this; I'd rather not have the functionality.
299 2016-03-24 18:50:11	0|wumpus|attack surface, making it impossible to get rid of openssl dependency
300 2016-03-24 18:50:44	0|wumpus|and you can already do it using stunnel
301 2016-03-24 18:51:22	0|gmaxwell|I hope that this works so that even if we don't care about the confidentiality improvement, it's just simply faster than the existing transport.
302 2016-03-24 18:52:06	0|jonasschnelli|Right. I think dropping the sha256 per message could be an improvement in performance.
303 2016-03-24 18:52:24	0|jonasschnelli|combining multiple messages into one encrypted message also
304 2016-03-24 18:53:03	0|jonasschnelli|The question is, how to "bundle" messages (example: bundle invs). When releasing them, etc. I mean for the implementation.
305 2016-03-24 18:53:13	0|gmaxwell|https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html has some benchmarks vs AES-GCM fwiw.
306 2016-03-24 18:53:17	0|sipa|jonasschnelli: we already do that
307 2016-03-24 18:53:38	0|sipa|jonasschnelli: SendMessages is a function in main that computes a block of messages to send at once