--- Log opened Sat Aug 11 00:00:36 2018 00:06 -!- phwalkr [~phwalkr@2001:1284:f022:523f:7035:946:8938:5fc6] has quit [Remote host closed the connection] 00:09 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 00:25 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 00:42 -!- promag [~promag@83.223.226.94] has joined #bitcoin-core-dev 00:53 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has quit [Remote host closed the connection] 00:54 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has joined #bitcoin-core-dev 01:03 -!- Jmabsd [~jmabsd@pcd247152.netvigator.com] has quit [Quit: Leaving] 01:32 -!- promag [~promag@83.223.226.94] has quit [Remote host closed the connection] 01:33 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 01:33 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 01:34 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 01:35 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 01:38 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 01:54 -!- Murch [~murch@c-73-223-113-121.hsd1.ca.comcast.net] has quit [Quit: Snoozing.] 02:10 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 02:30 -!- anome [~anome@unaffiliated/anome] has joined #bitcoin-core-dev 02:36 -!- anome [~anome@unaffiliated/anome] has quit [] 02:36 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 02:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:38 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 02:40 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 02:42 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 02:42 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 03:15 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 03:17 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 03:24 -!- profmac [~ProfMac@2001:470:1f0f:226:d4e5:ecd7:c48c:9713] has quit [Ping timeout: 245 seconds] 03:39 -!- farmerwampum [~farmerwam@104.129.29.34] has joined #bitcoin-core-dev 03:39 -!- farmerwampum [~farmerwam@104.129.29.34] has quit [Client Quit] 03:40 -!- farmerwampum [~farmerwam@104.129.29.34] has joined #bitcoin-core-dev 04:06 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 04:08 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 04:23 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 04:24 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 04:31 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 04:38 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 04:39 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 05:03 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 05:32 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 05:33 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 05:34 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 05:53 -!- cdecker [~cdecker@mail.snyke.net] has quit [Quit: ZNC - http://znc.in] 05:55 -!- musalbas [~musalbas@algebra.musalbas.com] has quit [Quit: ZNC - http://znc.in] 05:57 -!- musalbas [~musalbas@algebra.musalbas.com] has joined #bitcoin-core-dev 06:02 -!- profmac [~ProfMac@2001:470:1f0f:226:c9c6:56cf:7b97:5240] has joined #bitcoin-core-dev 06:11 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 06:25 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 06:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:43 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 06:45 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 06:53 -!- farmerwampum [~farmerwam@104.129.29.34] has quit [Ping timeout: 240 seconds] 06:55 -!- farmerwampum [~farmerwam@167.160.172.90] has joined #bitcoin-core-dev 07:15 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 07:16 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 07:24 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 07:29 -!- CubicEarth [~CubicEart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds] 07:36 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 07:37 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:05 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 08:07 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 08:32 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 08:32 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:34 -!- profmac [~ProfMac@2001:470:1f0f:226:c9c6:56cf:7b97:5240] has quit [Ping timeout: 240 seconds] 08:35 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 08:49 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 08:58 -!- profmac [~ProfMac@2001:470:1f0f:226:c9c6:56cf:7b97:5240] has joined #bitcoin-core-dev 08:59 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 244 seconds] 09:03 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 09:05 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Ping timeout: 272 seconds] 09:08 -!- profmac [~ProfMac@2001:470:1f0f:226:c9c6:56cf:7b97:5240] has quit [Ping timeout: 240 seconds] 09:17 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 09:18 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:26 -!- profmac [~ProfMac@2001:470:1f0f:226:c9c6:56cf:7b97:5240] has joined #bitcoin-core-dev 09:35 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 09:36 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 09:46 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 09:48 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 09:48 -!- profmac [~ProfMac@2001:470:1f0f:226:c9c6:56cf:7b97:5240] has quit [Remote host closed the connection] 10:28 -!- CubicEarth [~CubicEart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 10:38 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 10:39 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 10:40 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Quit: https://www.Quanto.ga/] 10:43 -!- xHire [~xHire@kos.paskuli.cz] has quit [Quit: No Ping reply in 180 seconds.] 10:45 -!- xHire [~xHire@kos.paskuli.cz] has joined #bitcoin-core-dev 10:46 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 10:49 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 10:58 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 11:01 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 240 seconds] 11:05 -!- twistedline [~quassel@unaffiliated/twistedline] has quit [Ping timeout: 260 seconds] 11:06 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 11:24 -!- phwalkr [~phwalkr@179.216.40.195] has joined #bitcoin-core-dev 11:29 -!- phwalkr [~phwalkr@179.216.40.195] has quit [Remote host closed the connection] 11:45 -!- eslider [~eslider@104.red-83-37-229.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 11:58 -!- phwalkr [~phwalkr@179.216.40.195] has joined #bitcoin-core-dev 12:15 < jonasschnelli> I think the BIP151 proposed handshake requires some overhaul 12:16 < jonasschnelli> Non ideal is two simultaneous message push during encack 12:16 < jonasschnelli> The current flow is... 12:17 < jonasschnelli> 1. requesting peer asks for encryption sends "encint" 12:17 < sipa> before or after version/verack? 12:17 < 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) 12:17 < jonasschnelli> sipa: thats another topic 12:18 < jonasschnelli> 3. requesting peeer sends its "encack" and a "version" message (one unencrypted, one encrypted) 12:18 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 12:18 < jonasschnelli> sipa: right now, my implementation sends it before the version... which is also not ideal.. means not really backward compatible 12:19 < 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 12:19 < sipa> and have a service flag for encryption 12:19 < jonasschnelli> sipa: I came to the same conclusion... 12:20 < 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.? 12:20 < sipa> well you learn the IP of a peer whomewhere 12:20 < sipa> generally that somewhere has service flags 12:20 < jonasschnelli> Yes. Right... 12:21 < sipa> if the service flag says encryption supported, you try an encrypted connection 12:21 < jonasschnelli> The handshake could just be a pubkey from both sides (eventually a checksum) 12:23 < jonasschnelli> Maybe the handshake could be: (peer A) -> , (peer B) <- 12:24 < jonasschnelli> sipa: for encryption both (incoming / outgoing) channel, would it make sense to do... (peer A) -> (peer B) <- (peer A) -> ? 12:25 < sipa> encryption setup can by symmetric, i think 12:25 < jonasschnelli> sipa: you mean only one negotiation? 12:25 < sipa> yes 12:25 < jonasschnelli> I asked myself what the reason was for both direction encryption... 12:25 < jonasschnelli> (two secrets) 12:26 < sipa> for authentication it makes sense to split it up 12:26 < jonasschnelli> yes. that is another thing.. 12:26 < sipa> also for embedding it in the old protocol, perhaps splitting up made sense 12:27 < sipa> because you have an asynchronous thing to embed it into 12:27 < sipa> but if there is an entirely new protocol, not so much 12:27 < jonasschnelli> What do you mean with "asynchronous thing". The uncontrollable timing of messages? 12:27 < sipa> yes, you need a well-identifiable point when encryption starts for both directions 12:28 < sipa> gmaxwell: opinions? 12:28 < jonasschnelli> Yes. That is currently a problem in the implementation 12:28 < jonasschnelli> Currently, the second encack will enable the encryption,... since it's before the version, no other messages should interfere 12:29 < gmaxwell> I like handshakes that just send pubkeys because they're harder to DPI match. 12:29 < 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 12:30 < jonasschnelli> gmaxwell: but do we need two ECDH handshakes for both com directions? 12:31 < jonasschnelli> IMHO: (peer A) -> , (peer B) <- should be enough and no communication should happend before this handshake is complete in the new p2p protocol 12:31 < gmaxwell> You need one ECDH, but that requires two messages. 12:31 < gmaxwell> why even send cipher and checksum? 12:32 < jonasschnelli> gmaxwell: BIP151 currently require that both peers initiate a ECDH handshake. There are two secrets (one for incomming one for outgoind encryption) 12:32 < gmaxwell> Well there is no reason to do that. 12:32 < jonasschnelli> Okay... :/ 12:33 < sipa> in the old embedded protocol it was necessaey because it would be hard to coordinate the encryption switchover point otherwise 12:33 < sipa> if you start with a completely new protocol i don't think there is any reason to not just do a single negotiation 12:33 < jonasschnelli> Yes. But the question then would be, is the second encryption handshake partially encrypted since one channel is "ready"? 12:34 < gmaxwell> You can have simply: Client connects, sends a 32 byte pubkey. Server responds with its 32 byte pubkey, and an encrypted stream. 12:34 < jonasschnelli> gmaxwell: agree. What do you think by adding one byte for a possible cipherscheme upgrade (first message only)? 12:35 < jonasschnelli> (peer A) -> , (peer B) <- 12:35 < jonasschnelli> 4byte checksum required? or a crc? or nothing and detect it via wrong shared secret? 12:35 < gmaxwell> well that cipher can't be encrypted or authenticated. 12:35 < gmaxwell> If the shared secret is wrong auth will fail on the first message. So I don't see any reason for a checksum. 12:36 < gmaxwell> Also just sending as little as possible makes it maximally hard to DPI match the traffic. 12:36 < jonasschnelli> Yes. Agree, a week cipher attack would be possible,.. better drop that 12:36 < gmaxwell> Which shouldn't be a primary goal, but it's nice if we can have it for nearly free. 12:37 < jonasschnelli> I guess DPI could identify two 33byte packages (you wrote 32byte pubkey above, incorrect?) followed by a package of "versionmessage"-length? 12:37 < gmaxwell> jonasschnelli: we could signal ciphers, but in the server to client direction, where it could be encrypted and authenticated with the shared secret. 12:37 < gmaxwell> it would be best to use 32 byte pubkeys, which are close to uniform. The 33 byte encoding is really identifyable. 12:37 < sipa> jonasschnelli: just drop the 02/03 first byte of the pubkey 12:37 < sipa> and assume it's always 02 12:38 < gmaxwell> whats sipa says. 12:38 < jonasschnelli> ack 12:38 < sipa> i have a writeup on how to do ECDH over secp256k1 in a completely unidentifiable way 12:38 < sipa> but it's pretty complicated and not worth it imho 12:38 < gmaxwell> There are techniques to encode keys which are closer to uniform, but it's unclear if its worth the complexity. 12:38 < jonasschnelli> derive emphemeral keys until pubkey start with 02? 12:38 < gmaxwell> Esp since the send 32 bytes each way pattern is pretty identiable. 12:38 < sipa> jonasschnelli: just negate your key if it has a 03 pubkey 12:39 < jonasschnelli> ack 12:39 < sipa> the negation will be a 02 pubkey 12:39 < gmaxwell> jonasschnelli: if K starts with 03 then -K is the 02 version. 12:39 < jonasschnelli> I guess that code change would belong into the secp256k1 sources? 12:40 < gmaxwell> at least with this there are no fixed bytes to match on, which at least kills the dumbest DPI. 12:41 < 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. 12:41 < gmaxwell> (and for a session identifier that can get shown in RPC and which the later auth stuff will act on) 12:42 < jonasschnelli> Yes. I already added the HKDF derived session ID via RPC to allow detecting an MITM 12:42 < jonasschnelli> gmaxwell: but would two encryption key for each direction be required? 12:43 < gmaxwell> Yes. there are attacks otherwise. 12:43 -!- phwalkr [~phwalkr@179.216.40.195] has quit [Ping timeout: 240 seconds] 12:43 < jonasschnelli> Do you mind give me a hint where I can read that up? 12:43 -!- twistedline [~quassel@unaffiliated/twistedline] has joined #bitcoin-core-dev 12:44 < gmaxwell> just generate them like H(shared_secret||direction||enc_or_auth) e.g. H(secret||0||0) or similar. 12:44 -!- MDrollette [~mdrollett@feynman.drollette.com] has joined #bitcoin-core-dev 12:44 < jonasschnelli> Yup. Will do... 12:44 < sipa> where 0 is the side that connected, and 1 is the side that accepted the connection, e.g. 12:44 < 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. 12:45 < 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? 12:46 < 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) 12:47 < 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. 12:47 < jonasschnelli> I see. Yes. Makes sense. 12:47 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 12:48 < 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 12:49 < jonasschnelli> But I guess the changes are not too significant 12:49 < 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. 12:50 < jonasschnelli> Right,... 12:52 < 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? 12:52 < jonasschnelli> Like H(shared_secret||direction||enc_or_auth||ciphertype) 12:55 < gmaxwell> depends on how you handle failure... 12:55 < 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. 12:55 < gmaxwell> so by just blocking 2 you can force the use of 1. 12:56 < jonasschnelli> good point 12:57 < 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. 12:57 < jonasschnelli> Yes. I see that and I agree adding the 1byte ciphertype seems a bit pointless 12:58 < gmaxwell> it's just kind of unfortunate that AES uses less power on hardware that has it, but is otherwise really slow. 13:22 -!- ovovo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds] 13:27 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 13:37 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 13:38 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 13:42 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 13:42 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 13:53 < 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? 14:02 < sipa> jonasschnelli: at worst, it's a 1 bit security loss 14:02 < sipa> jonasschnelli: ECDSA does the same internally, btw 14:03 < sipa> the public nonce is encoded in the signature with only its x coordinate 14:17 -!- itaseski [~itaseski@213.135.176.202] has quit [Ping timeout: 240 seconds] 14:30 < gmaxwell> jonasschnelli: there is no reduction in any case, because 0x02 vs 0x02 would be visible in public in any case. 14:31 < 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. 14:32 < gmaxwell> the hybrid proposal I linked to just runs RLWE and ECDH in parallel and hashes them both into the shared secret. 14:33 < gmaxwell> jonasschnelli: I forget now, how does your proposal handle rotating the symmetric keys? are they updated with hashing after some fixed interval? 14:42 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Remote host closed the connection] 14:56 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has joined #bitcoin-core-dev 14:59 -!- unholymachine [~quassel@2601:8c:c003:9f16:9849:e5fb:7f8f:2134] has joined #bitcoin-core-dev 15:25 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 15:27 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 15:40 -!- Rootsudo [~textual@49.151.151.68] has joined #bitcoin-core-dev 15:43 -!- Rootsudo [~textual@49.151.151.68] has quit [Client Quit] 15:47 -!- rev_strangehope [~revstrang@ec2-13-115-230-7.ap-northeast-1.compute.amazonaws.com] has quit [Quit: ZNC 1.6.6 - http://znc.in] 15:51 -!- rev_strangehope [~revstrang@ec2-13-115-230-7.ap-northeast-1.compute.amazonaws.com] has joined #bitcoin-core-dev 16:47 -!- ken2812221 [~User@1.200.203.30] has quit [Ping timeout: 244 seconds] 16:58 -!- promag [~promag@83.223.225.111] has joined #bitcoin-core-dev 17:01 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 17:04 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 18:01 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev 18:12 -!- promag [~promag@83.223.225.111] has quit [Remote host closed the connection] 18:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 18:53 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 256 seconds] 19:19 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 19:22 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 19:30 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Remote host closed the connection] 19:43 -!- bytting [~corebob@2a02:fe0:c130:8b20:ae74:691a:622:9c9f] has joined #bitcoin-core-dev 19:51 -!- unholymachine [~quassel@2601:8c:c003:9f16:9849:e5fb:7f8f:2134] has quit [Remote host closed the connection] 20:17 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev 20:34 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 21:37 -!- Krellan [~Krellan@2601:640:4000:9258:c037:fba4:6791:e519] has joined #bitcoin-core-dev 21:43 -!- profmac [~ProfMac@2001:470:1f0f:226:4170:c2a5:7820:3124] has joined #bitcoin-core-dev 21:44 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 21:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 21:45 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 21:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 244 seconds] 21:51 -!- murrayn [~dafuq@unaffiliated/murrayn] has quit [Quit: Adios mofos] 21:59 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 244 seconds] 22:04 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 22:39 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has quit [Ping timeout: 260 seconds] 22:45 -!- ken2812221 [~User@1.200.203.30] has joined #bitcoin-core-dev 22:51 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has quit [Quit: Find me in #TheHolyRoger or https://theholyroger.com] 22:54 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has joined #bitcoin-core-dev 22:59 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has quit [Quit: Find me in #TheHolyRoger or https://theholyroger.com] 23:01 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 250 seconds] 23:03 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has joined #bitcoin-core-dev 23:04 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev 23:05 < jonasschnelli> gmaxwell: yes. rekeying is done after a fix amount of traffic in bytes. But re-hashing the secret would not change anything if ECDA of logged traffic can be broken? 23:08 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 23:09 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 23:33 -!- murrayn [~dafuq@unaffiliated/murrayn] has joined #bitcoin-core-dev 23:33 < gmaxwell> jonasschnelli: right, we should also perhaps consider rekeying once an hour. What rekeying accomplishes, assuming the old key is deleted, is that if a system is compromised you can't extract the keys from memory to decrypt traffic you logged before compromise. 23:38 < gmaxwell> The reason I suggest triggering on time is because if you have e.g. a SPV client, it might be days until it has transfered 1GB of traffic. which might make it interesting to try to go seize other nodes a target under observation was connected to in order to decrypt their traffic. Admittedly a really fring risk, but it should be ~free to avoid. 23:39 < gmaxwell> (basically a similar motivation to why we don't log IPs by default) 23:40 < sipa> the only reason not to rekey on every message is performance, right? 23:41 < gmaxwell> Right. 23:41 < gmaxwell> sha2 is slower than chacha.. :) 23:42 < gmaxwell> interestingly, I'm not aware of any well known cipher mode which natively has irreversable state. 23:42 < sipa> chacha takes a 256 bits key, and produces blobs of 512 bits of output 23:43 < sipa> why not say encrypt every message with the current encryption key, and then afterwards extract another 256 bits from the stream, which become the new encryption key? 23:43 < sipa> chacha has 0 initialization cost 23:44 < gmaxwell> Because thats not a well studied construct. it would also be 50% of the speed of using it normally. 23:44 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer] 23:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 23:46 < sipa> why would it be slower? 23:46 < sipa> ah, if you assume the messages are small i guess 23:47 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 23:47 < gmaxwell> ah I thought you meant per 512 bits of output rather than per protocol message. 23:48 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 23:48 < gmaxwell> we could also email djb to ask, might well be that someone has published on a mode that does this. Though I think elsewhere where this concern was addressed, it was always just addressed by rekeying from a higher level rather than at the block cipher level. 23:49 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 23:50 < gmaxwell> Though as I was saying, I think it's kind of a fringe concern, if we want to do something complicated, I'd rather it be armoring against ECDH break then N-th level optimizations to how fast we forget keying material. 23:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 23:51 < gmaxwell> (or even better, get the indistinguishable authentication protocol finished) 23:55 < sipa> right; i'm mostly wondering why "use a prng-based stream cipher, and after each message, read the next encrpytion key from the stream" isn't a common construction 23:55 < gmaxwell> Because almost everything has key init costs? 23:56 < gmaxwell> also because the whole reason you normally use a stream cipher is random access. 23:57 < gmaxwell> there have been some 'reuse resistant' quasi-stream-cipher proposals perhaps some of those get irreversability as a side effect. dunno. --- Log closed Sun Aug 12 00:00:37 2018