1 2018-08-11T00:05:02  *** d9b4bef9 has quit IRC
  2 2018-08-11T00:05:40  *** Victorsueca has quit IRC
  3 2018-08-11T00:06:08  *** d9b4bef9 has joined #bitcoin-core-dev
  4 2018-08-11T00:06:50  *** Victorsueca has joined #bitcoin-core-dev
  5 2018-08-11T00:07:22  *** farmerwampum has quit IRC
  6 2018-08-11T00:20:59  *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
  7 2018-08-11T00:26:41  *** Murch has quit IRC
  8 2018-08-11T00:30:45  *** IGHOR has quit IRC
  9 2018-08-11T00:33:06  *** IGHOR has joined #bitcoin-core-dev
 10 2018-08-11T00:50:51  *** Cogito_Ergo_Sum has quit IRC
 11 2018-08-11T00:55:20  *** BashCo has quit IRC
 12 2018-08-11T00:55:26  *** BashCo_ has joined #bitcoin-core-dev
 13 2018-08-11T01:02:47  *** anome has quit IRC
 14 2018-08-11T01:17:56  *** BashCo_ has quit IRC
 15 2018-08-11T01:20:23  *** BashCo has joined #bitcoin-core-dev
 16 2018-08-11T01:47:49  <gmaxwell> [ot followup] ossifrage: Their blinking patent filings more or less confirm it was an intentional backdoor: http://i.blackhat.com/us-18/Thu-August-9/us-18-Domas-God-Mode-Unlocked-Hardware-Backdoors-In-x86-CPUs.pdf
 17 2018-08-11T01:47:59  *** DylanM21 has joined #bitcoin-core-dev
 18 2018-08-11T02:06:33  *** Krellan_ has joined #bitcoin-core-dev
 19 2018-08-11T02:09:57  *** Krellan has quit IRC
 20 2018-08-11T02:37:18  *** DylanM21 has quit IRC
 21 2018-08-11T03:28:35  *** vicenteH has quit IRC
 22 2018-08-11T03:29:17  *** vicenteH has joined #bitcoin-core-dev
 23 2018-08-11T03:56:57  *** MrPaz has quit IRC
 24 2018-08-11T04:07:02  *** d9b4bef9 has quit IRC
 25 2018-08-11T04:08:08  *** d9b4bef9 has joined #bitcoin-core-dev
 26 2018-08-11T04:16:17  *** Jmabsd has joined #bitcoin-core-dev
 27 2018-08-11T04:21:28  *** BashCo has quit IRC
 28 2018-08-11T04:23:29  *** BashCo has joined #bitcoin-core-dev
 29 2018-08-11T04:33:03  *** phwalkr has joined #bitcoin-core-dev
 30 2018-08-11T05:00:57  *** Jaring has joined #bitcoin-core-dev
 31 2018-08-11T05:00:57  *** BashCo has quit IRC
 32 2018-08-11T05:01:16  *** Jaring has left #bitcoin-core-dev
 33 2018-08-11T05:02:43  *** BashCo has joined #bitcoin-core-dev
 34 2018-08-11T05:09:44  *** BashCo has quit IRC
 35 2018-08-11T05:12:05  *** BashCo has joined #bitcoin-core-dev
 36 2018-08-11T06:19:58  *** itaseski has joined #bitcoin-core-dev
 37 2018-08-11T07:06:17  *** phwalkr has quit IRC
 38 2018-08-11T07:09:12  *** Guyver2 has joined #bitcoin-core-dev
 39 2018-08-11T07:25:20  *** Guyver2 has quit IRC
 40 2018-08-11T07:42:23  *** promag has joined #bitcoin-core-dev
 41 2018-08-11T07:53:58  *** no_input_found has quit IRC
 42 2018-08-11T07:54:18  *** no_input_found has joined #bitcoin-core-dev
 43 2018-08-11T08:03:20  *** Jmabsd has quit IRC
 44 2018-08-11T08:32:51  *** promag has quit IRC
 45 2018-08-11T08:33:01  *** d9b4bef9 has quit IRC
 46 2018-08-11T08:33:58  *** BashCo has quit IRC
 47 2018-08-11T08:34:09  *** d9b4bef9 has joined #bitcoin-core-dev
 48 2018-08-11T08:35:00  *** BashCo has joined #bitcoin-core-dev
 49 2018-08-11T08:38:27  *** Murch has joined #bitcoin-core-dev
 50 2018-08-11T08:54:13  *** Murch has quit IRC
 51 2018-08-11T09:10:21  *** SopaXorzTaker has joined #bitcoin-core-dev
 52 2018-08-11T09:30:11  *** anome has joined #bitcoin-core-dev
 53 2018-08-11T09:36:05  *** anome has quit IRC
 54 2018-08-11T09:36:05  *** BashCo has quit IRC
 55 2018-08-11T09:38:05  *** AaronvanW has joined #bitcoin-core-dev
 56 2018-08-11T09:38:37  *** BashCo has joined #bitcoin-core-dev
 57 2018-08-11T09:40:57  *** BashCo has quit IRC
 58 2018-08-11T09:42:15  *** BashCo has joined #bitcoin-core-dev
 59 2018-08-11T09:42:21  *** Aaronvan_ has joined #bitcoin-core-dev
 60 2018-08-11T09:45:44  *** AaronvanW has quit IRC
 61 2018-08-11T10:15:00  *** BashCo has quit IRC
 62 2018-08-11T10:17:18  *** BashCo has joined #bitcoin-core-dev
 63 2018-08-11T10:24:25  *** profmac has quit IRC
 64 2018-08-11T10:39:11  *** farmerwampum has joined #bitcoin-core-dev
 65 2018-08-11T10:40:05  *** farmerwampum has joined #bitcoin-core-dev
 66 2018-08-11T11:06:49  *** BashCo has quit IRC
 67 2018-08-11T11:08:54  *** BashCo has joined #bitcoin-core-dev
 68 2018-08-11T11:23:03  *** BashCo has quit IRC
 69 2018-08-11T11:24:34  *** BashCo has joined #bitcoin-core-dev
 70 2018-08-11T11:31:16  *** Aaronvan_ has quit IRC
 71 2018-08-11T11:38:11  *** BashCo has quit IRC
 72 2018-08-11T11:39:51  *** BashCo has joined #bitcoin-core-dev
 73 2018-08-11T12:03:49  *** belcher_ has joined #bitcoin-core-dev
 74 2018-08-11T12:32:05  *** SopaXorzTaker has quit IRC
 75 2018-08-11T12:33:02  *** d9b4bef9 has quit IRC
 76 2018-08-11T12:34:09  *** d9b4bef9 has joined #bitcoin-core-dev
 77 2018-08-11T12:53:18  *** cdecker has quit IRC
 78 2018-08-11T12:55:46  *** musalbas has quit IRC
 79 2018-08-11T12:57:30  *** musalbas has joined #bitcoin-core-dev
 80 2018-08-11T13:02:40  *** profmac has joined #bitcoin-core-dev
 81 2018-08-11T13:11:59  *** SopaXorzTaker has joined #bitcoin-core-dev
 82 2018-08-11T13:25:10  *** rafalcpp has joined #bitcoin-core-dev
 83 2018-08-11T13:26:02  *** AaronvanW has joined #bitcoin-core-dev
 84 2018-08-11T13:43:21  *** BashCo has quit IRC
 85 2018-08-11T13:45:02  *** BashCo has joined #bitcoin-core-dev
 86 2018-08-11T13:53:51  *** farmerwampum has quit IRC
 87 2018-08-11T13:55:09  *** farmerwampum has joined #bitcoin-core-dev
 88 2018-08-11T14:15:47  *** BashCo has quit IRC
 89 2018-08-11T14:16:42  *** BashCo has joined #bitcoin-core-dev
 90 2018-08-11T14:24:37  *** SopaXorzTaker has quit IRC
 91 2018-08-11T14:29:05  *** CubicEarth has quit IRC
 92 2018-08-11T14:36:27  *** BashCo has quit IRC
 93 2018-08-11T14:37:45  *** BashCo has joined #bitcoin-core-dev
 94 2018-08-11T15:05:56  *** Victorsueca has quit IRC
 95 2018-08-11T15:07:17  *** Victorsueca has joined #bitcoin-core-dev
 96 2018-08-11T15:32:10  *** BashCo has quit IRC
 97 2018-08-11T15:32:57  *** BashCo has joined #bitcoin-core-dev
 98 2018-08-11T15:34:21  *** profmac has quit IRC
 99 2018-08-11T15:35:13  *** Guyver2 has joined #bitcoin-core-dev
100 2018-08-11T15:49:10  *** drexl has joined #bitcoin-core-dev
101 2018-08-11T15:58:27  *** profmac has joined #bitcoin-core-dev
102 2018-08-11T15:59:55  *** vicenteH has quit IRC
103 2018-08-11T16:03:30  *** vicenteH has joined #bitcoin-core-dev
104 2018-08-11T16:05:31  *** jb55 has quit IRC
105 2018-08-11T16:08:51  *** profmac has quit IRC
106 2018-08-11T16:17:21  *** BashCo has quit IRC
107 2018-08-11T16:18:30  *** BashCo has joined #bitcoin-core-dev
108 2018-08-11T16:26:27  *** profmac has joined #bitcoin-core-dev
109 2018-08-11T16:35:01  *** d9b4bef9 has quit IRC
110 2018-08-11T16:36:08  *** d9b4bef9 has joined #bitcoin-core-dev
111 2018-08-11T16:46:53  *** Victorsueca has quit IRC
112 2018-08-11T16:48:02  *** Victorsueca has joined #bitcoin-core-dev
113 2018-08-11T16:48:20  *** profmac has quit IRC
114 2018-08-11T17:28:41  *** CubicEarth has joined #bitcoin-core-dev
115 2018-08-11T17:38:58  *** BashCo has quit IRC
116 2018-08-11T17:39:47  *** BashCo has joined #bitcoin-core-dev
117 2018-08-11T17:40:03  *** lnostdal has quit IRC
118 2018-08-11T17:43:26  *** xHire has quit IRC
119 2018-08-11T17:45:33  *** xHire has joined #bitcoin-core-dev
120 2018-08-11T17:46:59  *** BashCo has quit IRC
121 2018-08-11T17:49:03  *** BashCo has joined #bitcoin-core-dev
122 2018-08-11T17:58:19  *** Emcy_ has joined #bitcoin-core-dev
123 2018-08-11T18:01:21  *** Emcy has quit IRC
124 2018-08-11T18:05:39  *** twistedline has quit IRC
125 2018-08-11T18:06:36  *** SopaXorzTaker has joined #bitcoin-core-dev
126 2018-08-11T18:24:27  *** phwalkr has joined #bitcoin-core-dev
127 2018-08-11T18:29:00  *** phwalkr has quit IRC
128 2018-08-11T18:45:34  *** eslider has joined #bitcoin-core-dev
129 2018-08-11T18:58:34  *** phwalkr has joined #bitcoin-core-dev
130 2018-08-11T19:15:26  <jonasschnelli> I think the BIP151 proposed handshake requires some overhaul
131 2018-08-11T19:16:26  <jonasschnelli> Non ideal is two simultaneous message push during encack
132 2018-08-11T19:16:40  <jonasschnelli> The current flow is...
133 2018-08-11T19:17:03  <jonasschnelli> 1. requesting peer asks for encryption sends "encint"
134 2018-08-11T19:17:30  <sipa> before or after version/verack?
135 2018-08-11T19:17:39  <jonasschnelli> 2. remote peer give its "encack",.. but then require to ask also for an "encinit" for the other-way communication (sends two messages the same time)
136 2018-08-11T19:17:45  <jonasschnelli> sipa: thats another topic
137 2018-08-11T19:18:15  <jonasschnelli> 3. requesting peeer sends its "encack" and a "version" message (one unencrypted, one encrypted)
138 2018-08-11T19:18:29  *** Guyver2 has quit IRC
139 2018-08-11T19:18:46  <jonasschnelli> sipa: right now, my implementation sends it before the version... which is also not ideal.. means not really backward compatible
140 2018-08-11T19:19:04  <sipa> my preference would to throw it all away, and just start with a completely new protocol, not embedded in the old one; if you get disconnected when trying the encrypted proto, mark the peer as not supporting encryption, and retry another peer
141 2018-08-11T19:19:17  <sipa> and have a service flag for encryption
142 2018-08-11T19:19:49  <jonasschnelli> sipa: I came to the same conclusion...
143 2018-08-11T19:20:17  <jonasschnelli> But in oder to "see" the service flag, you need to talk with the legacy protocol... or do you mean more for addman/dns seeds, etc.?
144 2018-08-11T19:20:39  <sipa> well you learn the IP of a peer whomewhere
145 2018-08-11T19:20:46  <sipa> generally that somewhere has service flags
146 2018-08-11T19:20:48  <jonasschnelli> Yes. Right...
147 2018-08-11T19:21:01  <sipa> if the service flag says encryption supported, you try an encrypted connection
148 2018-08-11T19:21:20  <jonasschnelli> The handshake could just be a pubkey from both sides (eventually a checksum)
149 2018-08-11T19:23:23  <jonasschnelli> Maybe the handshake could be: (peer A) -> <pubkey|cipher|4byte_hash_checksum>, (peer B) <- <pubkey|4byte_hash_checksum>
150 2018-08-11T19:24:33  <jonasschnelli> sipa: for encryption both (incoming / outgoing) channel, would it make sense to do... (peer A) -> <pubkey|cipher|4byte_hash_checksum> (peer B) <- <pubkey|pubkey|4byte_hash_checksum> (peer A) -> <pubkey|cipher|4byte_hash_checksum>?
151 2018-08-11T19:25:04  <sipa> encryption setup can by symmetric, i think
152 2018-08-11T19:25:31  <jonasschnelli> sipa: you mean only one negotiation?
153 2018-08-11T19:25:38  <sipa> yes
154 2018-08-11T19:25:52  <jonasschnelli> I asked myself what the reason was for both direction encryption...
155 2018-08-11T19:25:59  <jonasschnelli> (two secrets)
156 2018-08-11T19:26:07  <sipa> for authentication it makes sense to split it up
157 2018-08-11T19:26:29  <jonasschnelli> yes. that is another thing..
158 2018-08-11T19:26:46  <sipa> also for embedding it in the old protocol, perhaps splitting up made sense
159 2018-08-11T19:27:01  <sipa> because you have an asynchronous thing to embed it into
160 2018-08-11T19:27:11  <sipa> but if there is an entirely new protocol, not so much
161 2018-08-11T19:27:36  <jonasschnelli> What do you mean with "asynchronous thing". The uncontrollable timing of messages?
162 2018-08-11T19:27:59  <sipa> yes, you need a well-identifiable point when encryption starts for both directions
163 2018-08-11T19:28:17  <sipa> gmaxwell: opinions?
164 2018-08-11T19:28:25  <jonasschnelli> Yes. That is currently a problem in the implementation
165 2018-08-11T19:28:58  <jonasschnelli> Currently, the second encack will enable the encryption,... since it's before the version, no other messages should interfere
166 2018-08-11T19:29:34  <gmaxwell> I like handshakes that just send pubkeys because they're harder to DPI match.
167 2018-08-11T19:29:48  <jonasschnelli> but sending the encack along with the version message (two PushMessage in the same codeblock, one plan, the other encrypted) result in things not working as it should
168 2018-08-11T19:30:20  <jonasschnelli> gmaxwell: but do we need two ECDH handshakes for both com directions?
169 2018-08-11T19:31:25  <jonasschnelli> IMHO: (peer A) -> <pubkey|cipher|4byte_hash_checksum>, (peer B) <- <pubkey|4byte_hash_checksum> should be enough and no communication should happend before this handshake is complete in the new p2p protocol
170 2018-08-11T19:31:32  <gmaxwell> You need one ECDH, but that requires two messages.
171 2018-08-11T19:31:54  <gmaxwell> why even send cipher and checksum?
172 2018-08-11T19:32:09  <jonasschnelli> gmaxwell: BIP151 currently require that both peers initiate a ECDH handshake. There are two secrets (one for incomming one for outgoind encryption)
173 2018-08-11T19:32:28  <gmaxwell> Well there is no reason to do that.
174 2018-08-11T19:32:45  <jonasschnelli> Okay... :/
175 2018-08-11T19:33:13  <sipa> in the old embedded protocol it was necessaey because it would be hard to coordinate the encryption switchover point otherwise
176 2018-08-11T19:33:41  <sipa> if you start with a completely new protocol i don't think there is any reason to not just do a single negotiation
177 2018-08-11T19:33:55  <jonasschnelli> Yes. But the question then would be, is the second encryption handshake partially encrypted since one channel is "ready"?
178 2018-08-11T19:34:02  <gmaxwell> You can have simply: Client connects, sends a 32 byte pubkey. Server responds with its 32 byte pubkey, and an encrypted stream.
179 2018-08-11T19:34:40  <jonasschnelli> gmaxwell: agree. What do you think by adding one byte for a possible cipherscheme upgrade (first message only)?
180 2018-08-11T19:35:00  <jonasschnelli> (peer A) -> <pubkey|cipher_1BYTE|4byte_hash_checksum>, (peer B) <- <pubkey|4byte_hash_checksum>
181 2018-08-11T19:35:32  <jonasschnelli> 4byte checksum required? or a crc? or nothing and detect it via wrong shared secret?
182 2018-08-11T19:35:39  <gmaxwell> well that cipher can't be encrypted or authenticated.
183 2018-08-11T19:35:59  <gmaxwell> If the shared secret is wrong auth will fail on the first message. So I don't see any reason for a checksum.
184 2018-08-11T19:36:20  <gmaxwell> Also just sending as little as possible makes it maximally hard to DPI match the traffic.
185 2018-08-11T19:36:22  <jonasschnelli> Yes. Agree, a week cipher attack would be possible,.. better drop that
186 2018-08-11T19:36:42  <gmaxwell> Which shouldn't be a primary goal, but it's nice if we can have it for nearly free.
187 2018-08-11T19:37:15  <jonasschnelli> I guess DPI could identify two 33byte packages (you wrote 32byte pubkey above, incorrect?) followed by a package of "versionmessage"-length?
188 2018-08-11T19:37:21  <gmaxwell> jonasschnelli: we could signal ciphers, but in the server to client direction, where it could be encrypted and authenticated with the shared secret.
189 2018-08-11T19:37:46  <gmaxwell> it would be best to use 32 byte pubkeys, which are close to uniform. The 33 byte encoding is really identifyable.
190 2018-08-11T19:37:47  <sipa> jonasschnelli: just drop the 02/03 first byte of the pubkey
191 2018-08-11T19:37:56  <sipa> and assume it's always 02
192 2018-08-11T19:38:01  <gmaxwell> whats sipa says.
193 2018-08-11T19:38:05  <jonasschnelli> ack
194 2018-08-11T19:38:25  <sipa> i have a writeup on how to do ECDH over secp256k1 in a completely unidentifiable way
195 2018-08-11T19:38:35  <sipa> but it's pretty complicated and not worth it imho
196 2018-08-11T19:38:36  <gmaxwell> There are techniques to encode keys which are closer to uniform, but it's unclear if its worth the complexity.
197 2018-08-11T19:38:41  <jonasschnelli> derive emphemeral keys until pubkey start with 02?
198 2018-08-11T19:38:48  <gmaxwell> Esp since the send 32 bytes each way pattern is pretty identiable.
199 2018-08-11T19:38:55  <sipa> jonasschnelli: just negate your key if it has a 03 pubkey
200 2018-08-11T19:39:03  <jonasschnelli> ack
201 2018-08-11T19:39:07  <sipa> the negation will be a 02 pubkey
202 2018-08-11T19:39:09  <gmaxwell> jonasschnelli: if K starts with 03 then -K is the 02 version.
203 2018-08-11T19:39:42  <jonasschnelli> I guess that code change would belong into the secp256k1 sources?
204 2018-08-11T19:40:01  <gmaxwell> at least with this there are no fixed bytes to match on, which at least kills the dumbest DPI.
205 2018-08-11T19:41:08  <gmaxwell> in any case, once you have a shared session key you can use hashing to get keys for encrypt and auth in each direction.
206 2018-08-11T19:41:32  <gmaxwell> (and for a session identifier that can get shown in RPC and which the later auth stuff will act on)
207 2018-08-11T19:42:15  <jonasschnelli> Yes. I already added the HKDF derived session ID via RPC to allow detecting an MITM
208 2018-08-11T19:42:46  <jonasschnelli> gmaxwell: but would two encryption key for each direction be required?
209 2018-08-11T19:43:06  <gmaxwell> Yes. there are attacks otherwise.
210 2018-08-11T19:43:27  *** phwalkr has quit IRC
211 2018-08-11T19:43:28  <jonasschnelli> Do you mind give me a hint where I can read that up?
212 2018-08-11T19:43:43  *** twistedline has joined #bitcoin-core-dev
213 2018-08-11T19:44:19  <gmaxwell> just generate them like H(shared_secret||direction||enc_or_auth)  e.g. H(secret||0||0) or similar.
214 2018-08-11T19:44:27  *** MDrollette has joined #bitcoin-core-dev
215 2018-08-11T19:44:39  <jonasschnelli> Yup. Will do...
216 2018-08-11T19:44:44  <sipa> where 0 is the side that connected, and 1 is the side that accepted the connection, e.g.
217 2018-08-11T19:44:46  <gmaxwell> jonasschnelli: we use a stream cipher _ANY_ reuse of the secret is fatal because an attacker can xor the two ciphertexts and learn the xor of the messages.
218 2018-08-11T19:45:50  <jonasschnelli> I guess this is the never reuse nonce&key? Right? And we can't control the sequence number (==nonce) in a bidirectional/async protocol?
219 2018-08-11T19:46:06  <gmaxwell> we should get this done before I start proposing we use https://gitweb.torproject.org/user/isis/torspec.git/plain/proposals/XXX-newhope-hybrid-handshake.txt?h=draft/newhope (but with secp256k1 instead of ed25519 for code reuse reasons)
220 2018-08-11T19:47:22  <gmaxwell> jonasschnelli: well I assume our sequence number is just starting at zero in each direction. You could hard partition the sequence space for each direction and be okay, but that seems about as complex as just derriving different values for each direction entirely, and more failure prone.
221 2018-08-11T19:47:40  <jonasschnelli> I see. Yes. Makes sense.
222 2018-08-11T19:47:48  *** SopaXorzTaker has quit IRC
223 2018-08-11T19:48:55  <jonasschnelli> I'm going to write an overhaul of BIP151 (I hope nobody complain since it initial draft has been published via the BIPS long long ago). I know Armory has a complete implementation and they may not like the fact that they need to rewrite some parts
224 2018-08-11T19:49:12  <jonasschnelli> But I guess the changes are not too significant
225 2018-08-11T19:49:55  <gmaxwell> if someone complaints, you can just make a new BIP number... and they can stay using the old one: after all, they weren't talking to us with it anyways.
226 2018-08-11T19:50:26  <jonasschnelli> Right,...
227 2018-08-11T19:52:23  <jonasschnelli> gmaxwell: if the ciphertype (which we just dropped) in the handshake request would be part of the encryption and authentication key, wouldn't this mean its not attackable?
228 2018-08-11T19:52:50  <jonasschnelli> Like H(shared_secret||direction||enc_or_auth||ciphertype)
229 2018-08-11T19:55:05  <gmaxwell> depends on how you handle failure...
230 2018-08-11T19:55:23  <gmaxwell> I mean if we only implement 1 on day one, then anyone trying to use 2 will expect it to fail and then need to retry.
231 2018-08-11T19:55:40  <gmaxwell> so by just blocking 2 you can force the use of 1.
232 2018-08-11T19:56:21  <jonasschnelli> good point
233 2018-08-11T19:57:14  <gmaxwell> I assume if we change ciphers it would just be to something totally different, probably also at that point adding post-quantum key argreement like the hybrid above.
234 2018-08-11T19:57:39  <jonasschnelli> Yes. I see that and I agree adding the 1byte ciphertype seems a bit pointless
235 2018-08-11T19:58:37  <gmaxwell> it's just kind of unfortunate that AES uses less power on hardware that has it, but is otherwise really slow.
236 2018-08-11T20:22:35  *** ovovo has quit IRC
237 2018-08-11T20:27:24  *** owowo has joined #bitcoin-core-dev
238 2018-08-11T20:37:02  *** d9b4bef9 has quit IRC
239 2018-08-11T20:38:09  *** d9b4bef9 has joined #bitcoin-core-dev
240 2018-08-11T20:42:05  *** BashCo has quit IRC
241 2018-08-11T20:42:11  *** BashCo_ has joined #bitcoin-core-dev
242 2018-08-11T20:53:40  <jonasschnelli> sipa, gmaxwell: if we negate K in case of an ODD pubkey (0x03), don't we reduce the possible keyspace and therefore the bits of security?
243 2018-08-11T21:02:19  <sipa> jonasschnelli: at worst, it's a 1 bit security loss
244 2018-08-11T21:02:53  <sipa> jonasschnelli: ECDSA does the same internally, btw
245 2018-08-11T21:03:06  <sipa> the public nonce is encoded in the signature with only its x coordinate
246 2018-08-11T21:17:35  *** itaseski has quit IRC
247 2018-08-11T21:30:00  <gmaxwell> jonasschnelli: there is no reduction in any case, because 0x02 vs 0x02 would be visible in public in any case.
248 2018-08-11T21:31:37  <gmaxwell> sipa: maybe we should consider merging in RLWE, there is a small, tidy, BSD licensed C implementation.  The motivation is that for encrypted communication there is an incentive for an attacker to log all the traffic and then years later, when ECDH in secp256k1 is weakened, go and crack past logged connections.
249 2018-08-11T21:32:13  <gmaxwell> the hybrid proposal I linked to just runs RLWE and ECDH in parallel and hashes them both into the shared secret.
250 2018-08-11T21:33:13  <gmaxwell> jonasschnelli: I forget now, how does your proposal handle rotating the symmetric keys? are they updated with hashing after some fixed interval?
251 2018-08-11T21:42:23  *** belcher_ has quit IRC
252 2018-08-11T21:56:28  *** jhfrontz has joined #bitcoin-core-dev
253 2018-08-11T21:59:46  *** unholymachine has joined #bitcoin-core-dev
254 2018-08-11T22:25:50  *** BashCo_ has quit IRC
255 2018-08-11T22:27:20  *** BashCo has joined #bitcoin-core-dev
256 2018-08-11T22:40:05  *** Rootsudo has joined #bitcoin-core-dev
257 2018-08-11T22:43:35  *** Rootsudo has quit IRC
258 2018-08-11T22:47:21  *** rev_strangehope has quit IRC
259 2018-08-11T22:51:11  *** rev_strangehope has joined #bitcoin-core-dev
260 2018-08-11T23:47:30  *** ken2812221 has quit IRC
261 2018-08-11T23:58:45  *** promag has joined #bitcoin-core-dev