I2P LS2 Meeting: 2019-08-05 18:30 UTC
TL;DR Discussed:
- 147: using network ID to prevent cross-network communication
- minor fixes
- impl in 0.9.42 release
- 153: using ChaCha20 + ChaCha20-Poly1305 Tunnel Layer encryption
- summary of proposed changes
- efficiency of checking 8-byte nonces against Bloom filter
- 144: ECIES-X25519-AEAD-Ratchet
- key reuse cryptanalysis
- using
Split()in DH Ratchet - drop-until-secure messaging implementation
Logs:
2019-08-05 18:30:02 ~zzz 0) Hi
2019-08-05 18:30:03 ~zzz hi
2019-08-05 18:30:08 ~zzz what's on the agenda for today?
2019-08-05 18:30:12 orignal hi
2019-08-05 18:30:18 ~zzz I have 147 to mention
2019-08-05 18:30:23 chisana_ hi
2019-08-05 18:30:30 chisana_ 144, 153
2019-08-05 18:30:37 ~zzz we have a new 153 split out from 152
2019-08-05 18:30:51 ~zzz ok let's do the shorter ones first this week
2019-08-05 18:30:59 ~zzz 1) 147 2) 153 3) 144
2019-08-05 18:31:07 ~zzz anything else for the list?
2019-08-05 18:31:28 ~zzz ok 1) 147
2019-08-05 18:31:38 ~zzz I fixed some of the typos noted last week. fixed more today
2019-08-05 18:31:48 ~zzz implemented it today, I have it tested and running on the live net
2019-08-05 18:32:04 chisana_ what version will it go live?
2019-08-05 18:32:32 ~zzz I do still need to get agreement from backup for the reseed part, I heard back from him once but didnt get a response to my followup
2019-08-05 18:32:52 ~zzz it's backward compatible, so we don't all need to coordinate
2019-08-05 18:33:07 ~zzz but I plan to put it in for .42 if everybody's happy
2019-08-05 18:33:18 orignal I'm fine
2019-08-05 18:33:50 ~zzz ok, I'll update the official specs to match the proposal, and try to close the loop with backup
2019-08-05 18:34:13 ~zzz mikalv you here? you happy with it?
2019-08-05 18:34:48 ~zzz ok I guess that's it for 1) ?
2019-08-05 18:35:06 mikalv yea here, a bit busy soon not
2019-08-05 18:35:24 ~zzz mikalv, you happy with the 147 changes?
2019-08-05 18:35:49 mikalv yea
2019-08-05 18:36:00 ~zzz ok super
2019-08-05 18:36:02 ~zzz 2) 152
2019-08-05 18:36:07 ~zzz whups
2019-08-05 18:36:10 ~zzz 2) 153
2019-08-05 18:36:22 ~zzz it's live on the website, split out from 152
2019-08-05 18:36:41 ~zzz chisana_, can you summarize what changed along the way since 152?
2019-08-05 18:37:18 chisana_ yeah, added specs for inter-hop AEAD, and using two nonces for layer encryption
2019-08-05 18:38:03 chisana_ replaces AES256/ECB+CBC with ChaCha20 + ChaCha20-Poly1305
2019-08-05 18:38:31 ~zzz how many bytes are available for data?
2019-08-05 18:38:50 chisana_ 16 less than AES tunnel messages
2019-08-05 18:39:46 chisana_ we gain inter-hop AEAD for that 16 bytes, though
2019-08-05 18:39:50 ~zzz I think it's 1003 now? 1007? can't remember
2019-08-05 18:40:01 ~zzz 1003 I think
2019-08-05 18:40:27 chisana_ idk, would need to check my code for numbers
2019-08-05 18:40:44 chisana_ I have it implemented, well the crypto and messaging part
2019-08-05 18:40:52 ~zzz so that's almost a doubling of overhead, or a 1.6% decrease in usable bandwidth, more or less?
2019-08-05 18:42:32 chisana_ 63744 max for local AES tunnel, 62720 for ChaCha
2019-08-05 18:43:25 chisana_ 63708 max for tunnel delivery AES, 62684 for ChaCha
2019-08-05 18:43:26 ~zzz not the max, I mean how much data can you fit in a single tunnel message
2019-08-05 18:43:49 ~zzz you're taking 16 more bytes out of the 1KB tunnel message, right?
2019-08-05 18:44:02 chisana_ right, I'm giving total diffs in overall I2NP size
2019-08-05 18:44:32 ~zzz the proposal has two nonces but I don't see any justification for that. why two nonces?
2019-08-05 18:45:20 ~zzz and why do we have to check the bloom filter for both nonces? that's expensive
2019-08-05 18:45:22 chisana_ you need two nonces to ensure nonce uniqueness, and to encrypt the nonces
2019-08-05 18:45:33 chisana_ it's not expensive to check
2019-08-05 18:46:34 ~zzz allow me to assert what's expensive in my code :) also, two values is either twice the bloom filter size or twice the filters, which is the same thing
2019-08-05 18:46:43 chisana_ you can't just truncate AES IV (16-byte unique random value), because the first half of two unique values could be identical
2019-08-05 18:47:02 chisana_ it's not twice the bloom filter size
2019-08-05 18:47:11 chisana_ definitely not two filters
2019-08-05 18:47:37 chisana_ it needs to be the same filter, because the nonces need to be unique for the same key
2019-08-05 18:47:38 ~zzz oh wait, the nonces are only 8 bytes each?
2019-08-05 18:47:41 chisana_ yes
2019-08-05 18:47:51 ~zzz so can I just glue them together and do a 16 byte check like we do now?
2019-08-05 18:47:58 chisana_ no
2019-08-05 18:48:10 chisana_ they need to be checked individually
2019-08-05 18:48:25 chisana_ because each one needs to be unique
2019-08-05 18:48:58 ~zzz we could still just concatenate them
2019-08-05 18:49:02 chisana_ otherwise we could just split the AES IV in half, and have ChaCha-AES tunnels working together
2019-08-05 18:49:03 chisana_ no
2019-08-05 18:49:06 chisana_ you can't
2019-08-05 18:49:06 ~zzz or we chould check the HMAC instead, probably?
2019-08-05 18:49:11 chisana_ nope
2019-08-05 18:49:25 chisana_ well, the hmac thing maybe
2019-08-05 18:49:38 chisana_ I'm going to use siphash for my bloom filter
2019-08-05 18:49:50 chisana_ I don't know what your impl looks like
2019-08-05 18:50:17 chisana_ but again, you need a way to ensure that both nonces are unique
2019-08-05 18:50:22 ~zzz I don't really understand yet, but I don't need to yet
2019-08-05 18:50:42 chisana_ if you cat them, one half could be identical, and produce a unique hmac
2019-08-05 18:51:10 ~zzz why is one called obfsnonce? is it obfuscated? I don't see any explaination of that
2019-08-05 18:51:20 chisana_ its just a name
2019-08-05 18:51:24 ~zzz or, what does obfs stand for?
2019-08-05 18:51:43 chisana_ nothing, everything, idk
2019-08-05 18:51:52 chisana_ its better name than nonceNonce
2019-08-05 18:52:05 chisana_ it's only used for encrypting the tunnel nonce
2019-08-05 18:52:14 ~zzz ok well I'd suggest a more descriptive name, and a description of what it's for
2019-08-05 18:52:27 chisana_ what color would you like it to be?
2019-08-05 18:52:53 ~zzz that's all the comments I have for now... anybody else have comments on 153?
2019-08-05 18:53:01 chisana_ there is a description of what it's for
2019-08-05 18:53:22 chisana_ a very detailed one
2019-08-05 18:53:31 chisana_ with examples
2019-08-05 18:53:49 chisana_ please reread the spec proposal
2019-08-05 18:53:50 ~zzz ok, must have missed that part
2019-08-05 18:53:55 chisana_ must have
2019-08-05 18:54:10 ~zzz hey, at least I read it
2019-08-05 18:54:23 ~zzz orignal, mikalv, any comments on the 153 changes?
2019-08-05 18:55:56 ~zzz anything else on 153?
2019-08-05 18:56:10 mikalv still putting kids to sleep, but what I've read so far is OK
2019-08-05 18:56:48 ~zzz ok, please read up during the week, not during the meeting, this is the only way we're going to get anything done, thanks
2019-08-05 18:56:57 ~zzz 3) 144
2019-08-05 18:57:38 ~zzz before we get started, let me try to summarize where we ended last week, and everybody can say if that sounds right
2019-08-05 18:58:17 ~zzz we seem to be headed toward agreement that using a noise-IK-like new session reply is workable and desirable
2019-08-05 18:59:02 ~zzz but we have disagreement about using the same ephemeral and static keys in multiple new session requests, and multiple new session replies
2019-08-05 18:59:12 ~zzz are those two statements accurate?
2019-08-05 18:59:24 chisana_ seems right to me
2019-08-05 18:59:44 ~zzz orignal, mikalv, sound right?
2019-08-05 19:00:25 mikalv no objections
2019-08-05 19:00:59 ~zzz so, the current 144 on the website documents reuse, primarily as it's a big efficiency win for POSTS
2019-08-05 19:01:11 orignal нуы
2019-08-05 19:01:12 orignal yes
2019-08-05 19:01:33 ~zzz if we go to noise-like replies, the win would be even bigger because it would apply to GETs
2019-08-05 19:02:03 chisana_ it could also break the cryptosystem
2019-08-05 19:02:16 chisana_ and makes analysis of our design harder
2019-08-05 19:02:20 ~zzz there also may be some benefit in tying messages together better, but if we're going to add a session number, maybe that's not so important
2019-08-05 19:02:43 ~zzz so, chisana_, make your case on why we shouldn't do it, please
2019-08-05 19:03:09 chisana_ key reuse is explicitly against noise spec
2019-08-05 19:03:35 chisana_ we do it, we throw out all the formal analysis and tooling following Noise specs provides
2019-08-05 19:03:45 chisana_ for a marginal performance plus
2019-08-05 19:03:58 ~zzz it's not marginal
2019-08-05 19:04:01 chisana_ bad idea (tm)
2019-08-05 19:04:35 chisana_ marginal in comparison to attack vectors and theoretical weakening of the cryptosystem
2019-08-05 19:04:38 ~zzz what's the noise-over-UDP protocol? wireguard? I wonder what they do
2019-08-05 19:05:19 chisana_ not sure, haven't looked deeply at there specs, or at all since we talked about them months ago
2019-08-05 19:05:21 ~zzz so you're estimating a marginal gain, and saying it's not worth analyzing it at all? that we shouldn't even investigate it or try to make it work?
2019-08-05 19:06:00 chisana_ no, maybe we should look at it, but looking at it, it appears a fool's errand
2019-08-05 19:06:15 ~zzz it could save about 10 DH's per GET (assuming decent-size response), that's not minimal
2019-08-05 19:06:40 chisana_ that's equivalent (approximately) to one ElGamal DH
2019-08-05 19:06:45 ~zzz and more if you're not going to delay the reply
2019-08-05 19:07:09 chisana_ and that's only during session setup
2019-08-05 19:07:28 chisana_ once the handshake is complete, that all goes out the window
2019-08-05 19:07:42 ~zzz one ElG DH is significant. That's why we're doing 144 at all
2019-08-05 19:08:00 ~zzz sure, all the DH stuff is at setup only
2019-08-05 19:08:03 ~zzz sure, we're not talking about the symmetric phase
2019-08-05 19:08:08 chisana_ and the rest of the session (the majority of the traffic) is dependent on the security of the crypto guarantees provided by the handshake
2019-08-05 19:08:40 ~zzz which we need to investigate anyway. this isn't noise and we can't depend solely on noise docs
2019-08-05 19:08:46 chisana_ so jeopardizing the security of the majority of session traffic hardly seems worth a few DH calcs
2019-08-05 19:09:18 ~zzz I'm proposing that we take time to research it. You're proposing that we don't even bother?
2019-08-05 19:09:37 chisana_ no, I understand we can't just rely on noise. but if we follow noise pretty closely, we give any prospective auditors a lot of tools to verify a correct implementation
2019-08-05 19:09:53 chisana_ freeing up more time to do cryptanalysis on the rest of the scheme
2019-08-05 19:10:17 chisana_ even if those auditors end up just being us (which I hope it isn't)
2019-08-05 19:10:39 chisana_ I'm proposing time could be better spent elsewhere
2019-08-05 19:11:01 chisana_ like investigating crypto libraries that do X25519 DH really efficiently/quickly
2019-08-05 19:11:13 ~zzz I'm not predicting what the research may reveal. Until we do our research, talk of "jeopardizing", "break the cryptosystem", "fools errand", "theoretical weakening", etc. .is just handwaving with nothing to back it up, isn't it?
2019-08-05 19:11:14 chisana_ that seems like a bigger win
2019-08-05 19:11:48 ~zzz implementation choices are not relevant to this discussion
2019-08-05 19:11:59 chisana_ no, reusing ephemeral keys, and explicitly going against reqs in the Noise specs is not "handwaving"
2019-08-05 19:12:26 chisana_ they are relevant if the main reason your choosing the scheme is "performance gains"
2019-08-05 19:12:33 chisana_ you're
2019-08-05 19:12:44 ~zzz the main reason for 144 is performance gains
2019-08-05 19:12:52 chisana_ disagree
2019-08-05 19:13:06 chisana_ forward-secrecy is a much stronger reason to use 144
2019-08-05 19:13:17 ~zzz and I believe orignal feels the same
2019-08-05 19:14:06 chisana_ feels or has evidence the scheme is secure when reusing keys?
2019-08-05 19:14:43 ~zzz feels that performance is the primary goal for 144
2019-08-05 19:14:55 orignal 144 is a replacement of ElGamal
2019-08-05 19:15:00 ~zzz the current ElG scheme has a lot of performance issues
2019-08-05 19:15:00 chisana_ that's a poor goal for a crypto protocol
2019-08-05 19:15:07 orignal permormance is the key
2019-08-05 19:15:12 chisana_ terrible
2019-08-05 19:15:55 orignal because there is the real attack to adddresses with elgamal
2019-08-05 19:15:55 ~zzz it's not the only goal. But if the performance isn't much better, we've failed badly
2019-08-05 19:16:15 chisana_ performance is a nice side-benefit to using ECIES, but the crypto-security of the protocol should be the main focus
2019-08-05 19:16:35 orignal if preformance is not better we weill start with ECIES-P256
2019-08-05 19:16:50 orignal because the performance is much better
2019-08-05 19:17:12 ~zzz yeah, if the performance of 144 isn't better than ELG then we shouldn't do it
2019-08-05 19:17:24 chisana_ great, so start over with another proposal with even less analysis
2019-08-05 19:17:46 ~zzz please no sarcasm
2019-08-05 19:17:52 orignal my expectatin 144 is better than ECIES-P256
2019-08-05 19:17:57 orignal because x25519
2019-08-05 19:18:26 chisana_ not sarcasm, ECIES-P256 hasn't even been discussed since I've been attending meetings, and the proposal is much less fleshed out than 144
2019-08-05 19:18:46 orignal it was discussed
2019-08-05 19:18:58 orignal in february and last meeting
2019-08-05 19:19:24 chisana_ two times, versus how many meetings have we spent the majority of time discussing 144?
2019-08-05 19:20:28 chisana_ even last meeting (or two ago) ECIES-P256 was cursorily discussed, and deferred to your implementation for "it's already out there, not changing anything"
2019-08-05 19:20:43 ~zzz so, since chisana and str4d have raised concerns about reusing keys, I propose that we go do research to see if those concerns are valid, or not
2019-08-05 19:20:57 ~zzz and I think that time would be well-spent given the potential performance gains
2019-08-05 19:21:04 chisana_ anyway, once we have a working 144 impl, we can do performance testing
2019-08-05 19:21:40 ~zzz we don't need a full 144 impl to know how much time it takes to do a DH
2019-08-05 19:21:44 ~zzz we know that now
2019-08-05 19:21:59 chisana_ I think the evidence is your burden zzz, everything I've read recommends against the reuse of ephemeral keys
2019-08-05 19:22:31 orignal you can introduce better ECIES-P256 with different code
2019-08-05 19:23:03 ~zzz ok, if you don't want to help out, I'll do it myself
2019-08-05 19:23:09 ~zzz please provide links to evrything you've read
2019-08-05 19:23:24 ~zzz other than the noise spec which ofc I know how to find
2019-08-05 19:23:33 chisana_ I've provided my analysis, and can reference other readings
2019-08-05 19:23:44 ~zzz mikalv, can you help me with this?
2019-08-05 19:24:06 mikalv yea I can try that
2019-08-05 19:24:14 ~zzz super
2019-08-05 19:24:28 ~zzz orignal, how about you?
2019-08-05 19:24:37 chisana_ and I am helping, it's just not what you want to hear zzz
2019-08-05 19:24:44 orignal in my opinion whay not introduce ECIES-x25519 similar to ECIES-P256 ?
2019-08-05 19:24:57 chisana_ in what way orignal?
2019-08-05 19:25:27 orignal just replace ECDH by x25519 there
2019-08-05 19:26:01 orignal to make it even faster
2019-08-05 19:26:21 chisana_ so totally throw out 144, and copy-pasta ECIES-P256 spec w/ s/ECDH/X25519?
2019-08-05 19:26:34 orignal that's the way I would go
2019-08-05 19:26:43 chisana_ that seems like even more backward "progress"
2019-08-05 19:26:47 orignal not sure
2019-08-05 19:26:53 orignal basically I'm lost in your 144's discussions
2019-08-05 19:27:00 orignal I can't say anything useful
2019-08-05 19:27:28 chisana_ basically throwing out what the current best practices are in protocol design, and reverting to shooting from the hip
2019-08-05 19:28:15 chisana_ is it good protocol design? is there formal analysis behind it? are there tools to help with verification?
2019-08-05 19:28:32 chisana_ no to all those questions if we do the ECIES-P256 swap
2019-08-05 19:29:21 orignal I'm a simple guy :)
2019-08-05 19:29:21 orignal don't like inifite analysises
2019-08-05 19:29:44 ~zzz note that str4d didn't have any concrete objection to key reuse either, he just said it made him 'uneasy', so hopefully he can help with the research
2019-08-05 19:29:53 chisana_ endless analysis could be as bad as none, but that's not what we're talking about
2019-08-05 19:30:53 chisana_ in fact, what I'm suggesting actually shortens the analysis time by letting us use the tools developed for noise formal analysis
2019-08-05 19:31:07 ~zzz as usual, the noise specs are fairly cryptic about the specifics of reuse and why it's bad. the noise spec is the most incomprehensible spec I've ever seen
2019-08-05 19:31:19 chisana_ and lowers the expense of hiring third-party auditors
2019-08-05 19:31:24 ~zzz that's why we basically rewrote it for the NTCP2 proposal
2019-08-05 19:32:05 ~zzz simplicity is a goal but it's not as important as performance and security
2019-08-05 19:32:17 chisana_ idk, the noise spec can be a little hard to get used to, but nowhere near as complex as analyzing I2P specs
2019-08-05 19:32:53 chisana_ once terminology and patterns are straight in noise spec, it's a fairly easy read imho
2019-08-05 19:33:30 ~zzz so, anyway, that's where we're at. We don't have any consensus. Some people aren't convinced reuse is bad, nobody is convinced reuse is fine, so it's time to go get smarter
2019-08-05 19:33:39 ~zzz anything else on 3) 144?
2019-08-05 19:34:02 chisana_ did you read my diffs on using split for DH kdf?
2019-08-05 19:34:26 ~zzz I didn't.
2019-08-05 19:34:26 chisana_ and the parts not related to key reuse
2019-08-05 19:34:29 ~zzz orignal, mikalv how about you?
2019-08-05 19:34:42 orignal what's your question?
2019-08-05 19:34:48 mikalv no hasn't had time yet
2019-08-05 19:35:04 ~zzz did you read the chisana diffs on using split for DH KDF?
2019-08-05 19:35:25 orignal not yet
2019-08-05 19:35:42 orignal neither 144 itself
2019-08-05 19:35:57 ~zzz I don't see how we can do split() if there's different keys in every message anyway
2019-08-05 19:35:59 chisana_ please do, it's important for ensuring security of the cryptosystem
2019-08-05 19:36:22 ~zzz I don't see how any of this works with different keys in every message
2019-08-05 19:36:25 chisana_ you call split when creating the outbound and inbound symmetric states
2019-08-05 19:36:47 ~zzz right
2019-08-05 19:37:33 chisana_ Bob creates symmetric states for each NSR sent to Alice, so that he can receive the ES message for the NSR Alice receives first
2019-08-05 19:37:54 ~zzz you're splitting the DH result. but if you have several new session dh results and several new session dh reply results, I don't know how alice and bob decide which dh result is the one to split
2019-08-05 19:38:03 chisana_ *that* set of inbound and outbound sessions becomes the established session for Alice and Bob
2019-08-05 19:38:19 ~zzz thats why I think it has to be the same keys
2019-08-05 19:38:37 chisana_ the first NSR Alice receives becomes *the* inbound/outbound sessions
2019-08-05 19:38:48 chisana_ the others are processed and discarded
2019-08-05 19:39:30 chisana_ Bob needs to maintain at least an inbound session for each NSR sent, because he doesn't know which Alice will receive first
2019-08-05 19:39:46 ~zzz thats really icky, we can't have bunches of sessions, that's part of the mess we have now that 144 tries to get rid of
2019-08-05 19:40:09 chisana_ once he receives an ES message from Alice, he knows which session to send messages on, and discards the others
2019-08-05 19:40:14 ~zzz and that's why I didn't look at the split() stuff yet because I don't think it's very workable
2019-08-05 19:40:20 chisana_ its only temporary
2019-08-05 19:40:49 ~zzz alice could have sent a bunch of new session messages too, so it's a combinatorial explosion
2019-08-05 19:40:56 chisana_ I agree that its not very clean
2019-08-05 19:41:24 chisana_ the other solution I recommended, dropping packets until a secure channel is established, you shot down
2019-08-05 19:41:29 ~zzz so let's all go look at wireguard
2019-08-05 19:41:47 chisana_ but that's the way TLS does it, and other secure protocols within I2P
2019-08-05 19:42:01 ~zzz it's not "me" shooting it down, it was inconsistent with the goals listed in the proposal
2019-08-05 19:42:07 chisana_ and is, imho, the cleanest way to establish end-to-end sessions
2019-08-05 19:42:14 ~zzz TLS shouldn't be a model for anything
2019-08-05 19:42:17 chisana_ no
2019-08-05 19:42:32 chisana_ but it's the widest used secure protocol over the internet
2019-08-05 19:42:34 ~zzz we're veering into philosophy here...
2019-08-05 19:42:42 ~zzz anything else on 3)
2019-08-05 19:42:42 ~zzz anything else for the meeting?
2019-08-05 19:43:18 ~zzz ok. I'm on a plane next week
2019-08-05 19:43:19 chisana_ if we're looking for performance gains, we should consider the drop-until-secure method
2019-08-05 19:43:35 ~zzz we can cancel the meeting, we can reschedule it, or you guys can meet without me. what do you want to do?
2019-08-05 19:43:48 chisana_ reschedule for the following week pls
2019-08-05 19:44:03 chisana_ I don't want to lose momentum on 144 progress
2019-08-05 19:44:14 chisana_ no one else seems invested
2019-08-05 19:44:42 ~zzz to be clear, I can't meet on 8/12. You want to reschedule for 8/19, or for some time later the week of 8/12?
2019-08-05 19:45:00 chisana_ sometime later in the week, if you're available
2019-08-05 19:45:13 ~zzz orignal, mikalv opinions?
2019-08-05 19:45:18 chisana_ I won't be able to do Thursday of that week
2019-08-05 19:45:41 orignal I'm fine with any date
2019-08-05 19:45:51 mikalv I don't think I have an issue with any date either
2019-08-05 19:46:21 ~zzz how about tuesday the 13th?
2019-08-05 19:46:23 ~zzz same time?
2019-08-05 19:46:29 chisana_ works for me
2019-08-05 19:46:32 orignal yes
2019-08-05 19:46:42 ~zzz ok it's a deal
2019-08-05 19:46:52 ~zzz happy meeting 50!
2019-08-05 19:47:10 ~zzz everybody please read up and do research between meetings, or we will never finish
2019-08-05 19:47:45 chisana_ yeah, will be reading up more on ephemeral reuse, and cryptanalysis for/against
2019-08-05 19:47:49 -- zzz has changed topic for #ls2 from "Proposals 123, 144-146, 148-152 | Meeting #50: 6:30 PM UTC August 5 | Meeting logs: https://gitlab.com/tini2p/meta/issues" to "Proposals 123, 144-146, 148-152 | Meeting #51: 6:30 PM UTC *TUESDAY* August 13 | Meeting logs: https://gitlab.com/tini2p/meta/issues"
2019-08-05 19:47:58 chisana_ thanks all :)