12018-08-11T00:05:02  *** d9b4bef9 has quit IRC
  22018-08-11T00:05:40  *** Victorsueca has quit IRC
  32018-08-11T00:06:08  *** d9b4bef9 has joined #bitcoin-core-dev
  42018-08-11T00:06:50  *** Victorsueca has joined #bitcoin-core-dev
  52018-08-11T00:07:22  *** farmerwampum has quit IRC
  62018-08-11T00:20:59  *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
  72018-08-11T00:26:41  *** Murch has quit IRC
  82018-08-11T00:30:45  *** IGHOR has quit IRC
  92018-08-11T00:33:06  *** IGHOR has joined #bitcoin-core-dev
 102018-08-11T00:50:51  *** Cogito_Ergo_Sum has quit IRC
 112018-08-11T00:55:20  *** BashCo has quit IRC
 122018-08-11T00:55:26  *** BashCo_ has joined #bitcoin-core-dev
 132018-08-11T01:02:47  *** anome has quit IRC
 142018-08-11T01:17:56  *** BashCo_ has quit IRC
 152018-08-11T01:20:23  *** BashCo has joined #bitcoin-core-dev
 162018-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
 172018-08-11T01:47:59  *** DylanM21 has joined #bitcoin-core-dev
 182018-08-11T02:06:33  *** Krellan_ has joined #bitcoin-core-dev
 192018-08-11T02:09:57  *** Krellan has quit IRC
 202018-08-11T02:37:18  *** DylanM21 has quit IRC
 212018-08-11T03:28:35  *** vicenteH has quit IRC
 222018-08-11T03:29:17  *** vicenteH has joined #bitcoin-core-dev
 232018-08-11T03:56:57  *** MrPaz has quit IRC
 242018-08-11T04:07:02  *** d9b4bef9 has quit IRC
 252018-08-11T04:08:08  *** d9b4bef9 has joined #bitcoin-core-dev
 262018-08-11T04:16:17  *** Jmabsd has joined #bitcoin-core-dev
 272018-08-11T04:21:28  *** BashCo has quit IRC
 282018-08-11T04:23:29  *** BashCo has joined #bitcoin-core-dev
 292018-08-11T04:33:03  *** phwalkr has joined #bitcoin-core-dev
 302018-08-11T05:00:57  *** Jaring has joined #bitcoin-core-dev
 312018-08-11T05:00:57  *** BashCo has quit IRC
 322018-08-11T05:01:16  *** Jaring has left #bitcoin-core-dev
 332018-08-11T05:02:43  *** BashCo has joined #bitcoin-core-dev
 342018-08-11T05:09:44  *** BashCo has quit IRC
 352018-08-11T05:12:05  *** BashCo has joined #bitcoin-core-dev
 362018-08-11T06:19:58  *** itaseski has joined #bitcoin-core-dev
 372018-08-11T07:06:17  *** phwalkr has quit IRC
 382018-08-11T07:09:12  *** Guyver2 has joined #bitcoin-core-dev
 392018-08-11T07:25:20  *** Guyver2 has quit IRC
 402018-08-11T07:42:23  *** promag has joined #bitcoin-core-dev
 412018-08-11T07:53:58  *** no_input_found has quit IRC
 422018-08-11T07:54:18  *** no_input_found has joined #bitcoin-core-dev
 432018-08-11T08:03:20  *** Jmabsd has quit IRC
 442018-08-11T08:32:51  *** promag has quit IRC
 452018-08-11T08:33:01  *** d9b4bef9 has quit IRC
 462018-08-11T08:33:58  *** BashCo has quit IRC
 472018-08-11T08:34:09  *** d9b4bef9 has joined #bitcoin-core-dev
 482018-08-11T08:35:00  *** BashCo has joined #bitcoin-core-dev
 492018-08-11T08:38:27  *** Murch has joined #bitcoin-core-dev
 502018-08-11T08:54:13  *** Murch has quit IRC
 512018-08-11T09:10:21  *** SopaXorzTaker has joined #bitcoin-core-dev
 522018-08-11T09:30:11  *** anome has joined #bitcoin-core-dev
 532018-08-11T09:36:05  *** anome has quit IRC
 542018-08-11T09:36:05  *** BashCo has quit IRC
 552018-08-11T09:38:05  *** AaronvanW has joined #bitcoin-core-dev
 562018-08-11T09:38:37  *** BashCo has joined #bitcoin-core-dev
 572018-08-11T09:40:57  *** BashCo has quit IRC
 582018-08-11T09:42:15  *** BashCo has joined #bitcoin-core-dev
 592018-08-11T09:42:21  *** Aaronvan_ has joined #bitcoin-core-dev
 602018-08-11T09:45:44  *** AaronvanW has quit IRC
 612018-08-11T10:15:00  *** BashCo has quit IRC
 622018-08-11T10:17:18  *** BashCo has joined #bitcoin-core-dev
 632018-08-11T10:24:25  *** profmac has quit IRC
 642018-08-11T10:39:11  *** farmerwampum has joined #bitcoin-core-dev
 652018-08-11T10:40:05  *** farmerwampum has joined #bitcoin-core-dev
 662018-08-11T11:06:49  *** BashCo has quit IRC
 672018-08-11T11:08:54  *** BashCo has joined #bitcoin-core-dev
 682018-08-11T11:23:03  *** BashCo has quit IRC
 692018-08-11T11:24:34  *** BashCo has joined #bitcoin-core-dev
 702018-08-11T11:31:16  *** Aaronvan_ has quit IRC
 712018-08-11T11:38:11  *** BashCo has quit IRC
 722018-08-11T11:39:51  *** BashCo has joined #bitcoin-core-dev
 732018-08-11T12:03:49  *** belcher_ has joined #bitcoin-core-dev
 742018-08-11T12:32:05  *** SopaXorzTaker has quit IRC
 752018-08-11T12:33:02  *** d9b4bef9 has quit IRC
 762018-08-11T12:34:09  *** d9b4bef9 has joined #bitcoin-core-dev
 772018-08-11T12:53:18  *** cdecker has quit IRC
 782018-08-11T12:55:46  *** musalbas has quit IRC
 792018-08-11T12:57:30  *** musalbas has joined #bitcoin-core-dev
 802018-08-11T13:02:40  *** profmac has joined #bitcoin-core-dev
 812018-08-11T13:11:59  *** SopaXorzTaker has joined #bitcoin-core-dev
 822018-08-11T13:25:10  *** rafalcpp has joined #bitcoin-core-dev
 832018-08-11T13:26:02  *** AaronvanW has joined #bitcoin-core-dev
 842018-08-11T13:43:21  *** BashCo has quit IRC
 852018-08-11T13:45:02  *** BashCo has joined #bitcoin-core-dev
 862018-08-11T13:53:51  *** farmerwampum has quit IRC
 872018-08-11T13:55:09  *** farmerwampum has joined #bitcoin-core-dev
 882018-08-11T14:15:47  *** BashCo has quit IRC
 892018-08-11T14:16:42  *** BashCo has joined #bitcoin-core-dev
 902018-08-11T14:24:37  *** SopaXorzTaker has quit IRC
 912018-08-11T14:29:05  *** CubicEarth has quit IRC
 922018-08-11T14:36:27  *** BashCo has quit IRC
 932018-08-11T14:37:45  *** BashCo has joined #bitcoin-core-dev
 942018-08-11T15:05:56  *** Victorsueca has quit IRC
 952018-08-11T15:07:17  *** Victorsueca has joined #bitcoin-core-dev
 962018-08-11T15:32:10  *** BashCo has quit IRC
 972018-08-11T15:32:57  *** BashCo has joined #bitcoin-core-dev
 982018-08-11T15:34:21  *** profmac has quit IRC
 992018-08-11T15:35:13  *** Guyver2 has joined #bitcoin-core-dev
1002018-08-11T15:49:10  *** drexl has joined #bitcoin-core-dev
1012018-08-11T15:58:27  *** profmac has joined #bitcoin-core-dev
1022018-08-11T15:59:55  *** vicenteH has quit IRC
1032018-08-11T16:03:30  *** vicenteH has joined #bitcoin-core-dev
1042018-08-11T16:05:31  *** jb55 has quit IRC
1052018-08-11T16:08:51  *** profmac has quit IRC
1062018-08-11T16:17:21  *** BashCo has quit IRC
1072018-08-11T16:18:30  *** BashCo has joined #bitcoin-core-dev
1082018-08-11T16:26:27  *** profmac has joined #bitcoin-core-dev
1092018-08-11T16:35:01  *** d9b4bef9 has quit IRC
1102018-08-11T16:36:08  *** d9b4bef9 has joined #bitcoin-core-dev
1112018-08-11T16:46:53  *** Victorsueca has quit IRC
1122018-08-11T16:48:02  *** Victorsueca has joined #bitcoin-core-dev
1132018-08-11T16:48:20  *** profmac has quit IRC
1142018-08-11T17:28:41  *** CubicEarth has joined #bitcoin-core-dev
1152018-08-11T17:38:58  *** BashCo has quit IRC
1162018-08-11T17:39:47  *** BashCo has joined #bitcoin-core-dev
1172018-08-11T17:40:03  *** lnostdal has quit IRC
1182018-08-11T17:43:26  *** xHire has quit IRC
1192018-08-11T17:45:33  *** xHire has joined #bitcoin-core-dev
1202018-08-11T17:46:59  *** BashCo has quit IRC
1212018-08-11T17:49:03  *** BashCo has joined #bitcoin-core-dev
1222018-08-11T17:58:19  *** Emcy_ has joined #bitcoin-core-dev
1232018-08-11T18:01:21  *** Emcy has quit IRC
1242018-08-11T18:05:39  *** twistedline has quit IRC
1252018-08-11T18:06:36  *** SopaXorzTaker has joined #bitcoin-core-dev
1262018-08-11T18:24:27  *** phwalkr has joined #bitcoin-core-dev
1272018-08-11T18:29:00  *** phwalkr has quit IRC
1282018-08-11T18:45:34  *** eslider has joined #bitcoin-core-dev
1292018-08-11T18:58:34  *** phwalkr has joined #bitcoin-core-dev
1302018-08-11T19:15:26  <jonasschnelli> I think the BIP151 proposed handshake requires some overhaul
1312018-08-11T19:16:26  <jonasschnelli> Non ideal is two simultaneous message push during encack
1322018-08-11T19:16:40  <jonasschnelli> The current flow is...
1332018-08-11T19:17:03  <jonasschnelli> 1. requesting peer asks for encryption sends "encint"
1342018-08-11T19:17:30  <sipa> before or after version/verack?
1352018-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)
1362018-08-11T19:17:45  <jonasschnelli> sipa: thats another topic
1372018-08-11T19:18:15  <jonasschnelli> 3. requesting peeer sends its "encack" and a "version" message (one unencrypted, one encrypted)
1382018-08-11T19:18:29  *** Guyver2 has quit IRC
1392018-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
1402018-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
1412018-08-11T19:19:17  <sipa> and have a service flag for encryption
1422018-08-11T19:19:49  <jonasschnelli> sipa: I came to the same conclusion...
1432018-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.?
1442018-08-11T19:20:39  <sipa> well you learn the IP of a peer whomewhere
1452018-08-11T19:20:46  <sipa> generally that somewhere has service flags
1462018-08-11T19:20:48  <jonasschnelli> Yes. Right...
1472018-08-11T19:21:01  <sipa> if the service flag says encryption supported, you try an encrypted connection
1482018-08-11T19:21:20  <jonasschnelli> The handshake could just be a pubkey from both sides (eventually a checksum)
1492018-08-11T19:23:23  <jonasschnelli> Maybe the handshake could be: (peer A) -> <pubkey|cipher|4byte_hash_checksum>, (peer B) <- <pubkey|4byte_hash_checksum>
1502018-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>?
1512018-08-11T19:25:04  <sipa> encryption setup can by symmetric, i think
1522018-08-11T19:25:31  <jonasschnelli> sipa: you mean only one negotiation?
1532018-08-11T19:25:38  <sipa> yes
1542018-08-11T19:25:52  <jonasschnelli> I asked myself what the reason was for both direction encryption...
1552018-08-11T19:25:59  <jonasschnelli> (two secrets)
1562018-08-11T19:26:07  <sipa> for authentication it makes sense to split it up
1572018-08-11T19:26:29  <jonasschnelli> yes. that is another thing..
1582018-08-11T19:26:46  <sipa> also for embedding it in the old protocol, perhaps splitting up made sense
1592018-08-11T19:27:01  <sipa> because you have an asynchronous thing to embed it into
1602018-08-11T19:27:11  <sipa> but if there is an entirely new protocol, not so much
1612018-08-11T19:27:36  <jonasschnelli> What do you mean with "asynchronous thing". The uncontrollable timing of messages?
1622018-08-11T19:27:59  <sipa> yes, you need a well-identifiable point when encryption starts for both directions
1632018-08-11T19:28:17  <sipa> gmaxwell: opinions?
1642018-08-11T19:28:25  <jonasschnelli> Yes. That is currently a problem in the implementation
1652018-08-11T19:28:58  <jonasschnelli> Currently, the second encack will enable the encryption,... since it's before the version, no other messages should interfere
1662018-08-11T19:29:34  <gmaxwell> I like handshakes that just send pubkeys because they're harder to DPI match.
1672018-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
1682018-08-11T19:30:20  <jonasschnelli> gmaxwell: but do we need two ECDH handshakes for both com directions?
1692018-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
1702018-08-11T19:31:32  <gmaxwell> You need one ECDH, but that requires two messages.
1712018-08-11T19:31:54  <gmaxwell> why even send cipher and checksum?
1722018-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)
1732018-08-11T19:32:28  <gmaxwell> Well there is no reason to do that.
1742018-08-11T19:32:45  <jonasschnelli> Okay... :/
1752018-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
1762018-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
1772018-08-11T19:33:55  <jonasschnelli> Yes. But the question then would be, is the second encryption handshake partially encrypted since one channel is "ready"?
1782018-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.
1792018-08-11T19:34:40  <jonasschnelli> gmaxwell: agree. What do you think by adding one byte for a possible cipherscheme upgrade (first message only)?
1802018-08-11T19:35:00  <jonasschnelli> (peer A) -> <pubkey|cipher_1BYTE|4byte_hash_checksum>, (peer B) <- <pubkey|4byte_hash_checksum>
1812018-08-11T19:35:32  <jonasschnelli> 4byte checksum required? or a crc? or nothing and detect it via wrong shared secret?
1822018-08-11T19:35:39  <gmaxwell> well that cipher can't be encrypted or authenticated.
1832018-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.
1842018-08-11T19:36:20  <gmaxwell> Also just sending as little as possible makes it maximally hard to DPI match the traffic.
1852018-08-11T19:36:22  <jonasschnelli> Yes. Agree, a week cipher attack would be possible,.. better drop that
1862018-08-11T19:36:42  <gmaxwell> Which shouldn't be a primary goal, but it's nice if we can have it for nearly free.
1872018-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?
1882018-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.
1892018-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.
1902018-08-11T19:37:47  <sipa> jonasschnelli: just drop the 02/03 first byte of the pubkey
1912018-08-11T19:37:56  <sipa> and assume it's always 02
1922018-08-11T19:38:01  <gmaxwell> whats sipa says.
1932018-08-11T19:38:05  <jonasschnelli> ack
1942018-08-11T19:38:25  <sipa> i have a writeup on how to do ECDH over secp256k1 in a completely unidentifiable way
1952018-08-11T19:38:35  <sipa> but it's pretty complicated and not worth it imho
1962018-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.
1972018-08-11T19:38:41  <jonasschnelli> derive emphemeral keys until pubkey start with 02?
1982018-08-11T19:38:48  <gmaxwell> Esp since the send 32 bytes each way pattern is pretty identiable.
1992018-08-11T19:38:55  <sipa> jonasschnelli: just negate your key if it has a 03 pubkey
2002018-08-11T19:39:03  <jonasschnelli> ack
2012018-08-11T19:39:07  <sipa> the negation will be a 02 pubkey
2022018-08-11T19:39:09  <gmaxwell> jonasschnelli: if K starts with 03 then -K is the 02 version.
2032018-08-11T19:39:42  <jonasschnelli> I guess that code change would belong into the secp256k1 sources?
2042018-08-11T19:40:01  <gmaxwell> at least with this there are no fixed bytes to match on, which at least kills the dumbest DPI.
2052018-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.
2062018-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)
2072018-08-11T19:42:15  <jonasschnelli> Yes. I already added the HKDF derived session ID via RPC to allow detecting an MITM
2082018-08-11T19:42:46  <jonasschnelli> gmaxwell: but would two encryption key for each direction be required?
2092018-08-11T19:43:06  <gmaxwell> Yes. there are attacks otherwise.
2102018-08-11T19:43:27  *** phwalkr has quit IRC
2112018-08-11T19:43:28  <jonasschnelli> Do you mind give me a hint where I can read that up?
2122018-08-11T19:43:43  *** twistedline has joined #bitcoin-core-dev
2132018-08-11T19:44:19  <gmaxwell> just generate them like H(shared_secret||direction||enc_or_auth)  e.g. H(secret||0||0) or similar.
2142018-08-11T19:44:27  *** MDrollette has joined #bitcoin-core-dev
2152018-08-11T19:44:39  <jonasschnelli> Yup. Will do...
2162018-08-11T19:44:44  <sipa> where 0 is the side that connected, and 1 is the side that accepted the connection, e.g.
2172018-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.
2182018-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?
2192018-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)
2202018-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.
2212018-08-11T19:47:40  <jonasschnelli> I see. Yes. Makes sense.
2222018-08-11T19:47:48  *** SopaXorzTaker has quit IRC
2232018-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
2242018-08-11T19:49:12  <jonasschnelli> But I guess the changes are not too significant
2252018-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.
2262018-08-11T19:50:26  <jonasschnelli> Right,...
2272018-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?
2282018-08-11T19:52:50  <jonasschnelli> Like H(shared_secret||direction||enc_or_auth||ciphertype)
2292018-08-11T19:55:05  <gmaxwell> depends on how you handle failure...
2302018-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.
2312018-08-11T19:55:40  <gmaxwell> so by just blocking 2 you can force the use of 1.
2322018-08-11T19:56:21  <jonasschnelli> good point
2332018-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.
2342018-08-11T19:57:39  <jonasschnelli> Yes. I see that and I agree adding the 1byte ciphertype seems a bit pointless
2352018-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.
2362018-08-11T20:22:35  *** ovovo has quit IRC
2372018-08-11T20:27:24  *** owowo has joined #bitcoin-core-dev
2382018-08-11T20:37:02  *** d9b4bef9 has quit IRC
2392018-08-11T20:38:09  *** d9b4bef9 has joined #bitcoin-core-dev
2402018-08-11T20:42:05  *** BashCo has quit IRC
2412018-08-11T20:42:11  *** BashCo_ has joined #bitcoin-core-dev
2422018-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?
2432018-08-11T21:02:19  <sipa> jonasschnelli: at worst, it's a 1 bit security loss
2442018-08-11T21:02:53  <sipa> jonasschnelli: ECDSA does the same internally, btw
2452018-08-11T21:03:06  <sipa> the public nonce is encoded in the signature with only its x coordinate
2462018-08-11T21:17:35  *** itaseski has quit IRC
2472018-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.
2482018-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.
2492018-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.
2502018-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?
2512018-08-11T21:42:23  *** belcher_ has quit IRC
2522018-08-11T21:56:28  *** jhfrontz has joined #bitcoin-core-dev
2532018-08-11T21:59:46  *** unholymachine has joined #bitcoin-core-dev
2542018-08-11T22:25:50  *** BashCo_ has quit IRC
2552018-08-11T22:27:20  *** BashCo has joined #bitcoin-core-dev
2562018-08-11T22:40:05  *** Rootsudo has joined #bitcoin-core-dev
2572018-08-11T22:43:35  *** Rootsudo has quit IRC
2582018-08-11T22:47:21  *** rev_strangehope has quit IRC
2592018-08-11T22:51:11  *** rev_strangehope has joined #bitcoin-core-dev
2602018-08-11T23:47:30  *** ken2812221 has quit IRC
2612018-08-11T23:58:45  *** promag has joined #bitcoin-core-dev