#ls2 (irc2p) | #ls2 proposal review channel : Upcoming reviews Tuesdays 7 PM UTC: prop. 169 Apr. 22

zzz reminder: Proposal 163 second review today 7 PM UTC here

zzz if you're here for the review, please say hi, even if you just plan to lurk

eyedeekay hi

orignal hi

altonen hi

orignal droad as usual ))

orignal *drozd

zzz ok. hello everybody, thanks for showing up

zzz this is the 2nd review of proposal 163, datagram 2, first reviewed on March 4

zzz I'll give a brief overview of what's changed, and then throw it open for comments

zzz the main thing that changed was in response to a comment/request from orignal

zzz to add a version with a hash only, and without a signature

orignal yes, but we agreed it should be Datgarm 3

zzz I called it 'datagram3' but I guess we could call them 2a and 2b, I don't care

zzz in the proposal, I called it datagram3

zzz so there's now two sections, one for datagram2 and one for datagram3, with separate pictures

zzz that's the end of the summary, I'll throw it open for comments and questions

orignal so, do you want me to explain how it should work without signature?

orignal and still be a repliable datagram

zzz well it is "repliable", it's just not authenticated

zzz but go ahead

orignal well it should authniticated

orignal e.g. you are not supposed to just accept it

orignal you need to verify it's identity too

zzz at what layer, and how?

orignal so, I presume that if it's repliable datagram you have LS to reply to alreadt

orignal layer is another topic

orignal so, I receive such datagram

orignal extract ident hash

orignal then find LS by this ident hash

orignal from LS I extract static key and compare with one from ratchets session datagram came from

orignal I'm thinking in i2pd categories

orignal not sure if it's doable in I2CP

orignal EOT

zzz ok should I respond now or ask for comments from others first?

orignal I think verification must be done on router's side

orignal but we need to know content of Data message

orignal I think others opinion

zzz ok, dr|z3d eyedeekay altonen any comments or questions?

zzz either on orignal's comments or on the proposal as a whole?

dr|z3d sorry I joined late, nothing right now, just getting the flavor of the conversation.

orignal but did you get my idea?

orignal that we need to remeber session datargam came from

altonen my q is: why would i use dgram2 if dgram3 has smaller overhead and sig is not needed?

dr|z3d I probably missed the first half of it.

zzz 2 vs. 3 is an application choice

orignal altonen because i2p still supports ElGamal

orignal that's only reason I see

zzz do you need authentication or not

altonen ok fair enough

orignal zzz, not only autenticaion

zzz we also have an eye on PQ, where a dest + sig is much much MUCH larger than just a hash

orignal you just can't pass full ident in case of PQ

orignal because huge overhead

altonen i don't know, orignal's argument makes sense to me if i can verify stuff using info from ratchhet

zzz well, you can, it's just large

orignal altonen the main concern is I2CP

zzz well, let's assume for the moment that the router is not doing any verification. I think there's still a use case for Datagram 3

orignal because they need to verify on client side

altonen ok ty orignal

zzz that's why I put datagram 3 into this proposal, because it's useful even without orignal's idea

zzz maybe somebody uses it, maybe not, but it's easy enough to code up

dr|z3d can someone explain the thrust of orignal's suggestion and why it's large?

zzz but the security analysis of unauthenticated datagrams is really up to the application developers

orignal why PQ ident is large? Becuase PQ keys length

dr|z3d ok, I didn't get the part where we were talking about pq. thanks.

eyedeekay I'm mulling over orignal's explanation but does reaching into ratchet to verify the message constitute a layering issue? Also, if the signature is verified using ratchet, I think the high-level description of how to do that should be part of the spec

zzz a x25519 dest + sig is 433 bytes

zzz a MLDSA44 dest + sig is 3739 bytes

eyedeekay \/sig/ident/

dr|z3d probably an obvious question, but if we need to peer into the packet to identify its contents in some way, can't we just add a flag in the header instead, and only handle the header?

zzz no. a datagram2 is dest + payload + sig

zzz ok lets get into it

orignal let's hear you

zzz I have two short answers and one long answer

zzz short answer 1: write a proposal for it ))

zzz short answer 2: I really don't see how we can do it with i2cp in the middle

orignal how? easy

orignal a router reads I2NP data message

orignal then gzip header recognizes it's datagram

zzz long answer: we'd have to gunzip every packet on the router side, peek in. Or, maybe, add something to I2CP for the router to tell the client something about the packet, if it was inside a session or not

orignal verifies and pass some flag/option to client

orignal like dr|z3d suggests

zzz this is your idea, so write it up and convince us. I'm not doing all the research for you.

orignal can we specify a session option that router is obliged to verify?

zzz and it's related to, but independent of, this proposal

zzz and I think your real idea is to use this to redesign streaming, so that turns into a big proposal

orignal not really

orignal let me explain

orignal for streaming it's not so critical

orignal because you send it only in SYN packet

orignal while for datagram you must do it in every single packet

orignal hence for streaming you can leave as it for not

orignal *now

orignal and not for datagrams

zzz but that's not the way datagrams work in the real world, like snark DHT

dr|z3d haha, orignal stealthing a streaming redesign. LOL.

orignal how does it work in snark?

orignal still repliable I guess

zzz you send one signed datagram with a token. The other guy responds with a raw datagram with the token in it. YOu can both keep going with raw datagrams with the token

orignal not raw

zzz you never ever send a bunch of signed datagrams in a row

zzz yes raw

orignal it depends on your implemntation

zzz right. the choice of signed/raw/2/3 is always up to the application design

orignal agree

zzz like with our old "streamr" UDP tunnel. You send ONE signed datagram to the audio server. He sends you a zillion raw datagrams, and you listen to your music

orignal I send once in 100 ms

zzz streamr was like every 10 seconds or 60 seconds or something, basically a 'subscribe' request

orignal anyways

orignal I think we should keep both 2 and 3

zzz let me list some alternatives on how to finish this

orignal dr|z3d I care more about PQ than streaming itself

zzz 1) approve as-is with 2 and 3

zzz 2) rip out 3, ask orignal to put it in his proposal, approve this proposal with 2 only

zzz 3) don't approve anything yet, wait for orignal's proposal

zzz EOT

orignal ha ha

orignal you know about 2. and 3. already

zzz well, the only way it's going to happen is if you do it, or you get somebody else to, and it's not going to be me, sorry

zzz I would like to get datagram 2 approved so I can start work on snark UDP announces

zzz but it's up to you guys

orignal yes, datragram is fine for me

altonen +1

zzz please make clear what you're voting for, option 1) 2) or 3)

eyedeekay I vote 1.

altonen i'm fine with 1

dr|z3d re gzip flags, this might be useful: mrbluyee.com/2024/03/25/zlib-and-gzip-format/#GZIP-header

zzz and orignal, what's your vote?

orignal fine

dr|z3d seems like we have a quorum, then. everyone votes "1".

zzz super. I'll get it moved into the specs

orignal 1

zzz anything else on proposal 163?

dr|z3d a quorum and a consensus. double chocolate.

zzz next week (NOT in two weeks) is the second review of PQ

orignal yes we have a lot to talk about PQ

zzz yes

zzz one thing I need help with, is research on what hash to use, stick with sha256 or switch

orignal I vote stick with sha256

zzz drz put an excellent link up in #saltr the other day, but that's just one guy's opinion (the guy who wrote it)

altonen why are you considering a switch?

zzz because now is the time if we want to

orignal because someone suggested it ))

zzz maybe we do, maybe not

zzz the guy suggested it and then drz banned him, for what it's worth

altonen lol

dr|z3d in case you missed the link: kerkour.com/fast-secure-hash-function-sha256-sha512-sha3-blake3

altonen ty

zzz do we have any volunteers to actually do research and make a recommendation next week (not just throw out a vibes opinion) ???

zzz maybe it's not doable in a week, which is fine, but can somebody step up for the research?

eyedeekay I can make/bring a chart

zzz charts are easy. I want to know whether THIS use case is vulnerable anytime soon.

zzz is hashing in noise handshakes a concern for collision? preimage? 2nd preimage? in what timeframe?

orignal especially since it's for mixhash only

zzz note that this is NOT a PQ issue. sha256 is not vulnerable to PQ.

orignal yes, it's noise

orignal can we add another "MixHash" with different hash just for PQ round?

zzz don't think that makes sense

zzz still looking for a volunteer to research and report

zzz hearing none, I'll ask again at the review next week

zzz thanks everybody

eyedeekay I can research sha2 attacks all week but I have serious doubts about my ability to narrow the focus to noise-specific issues

eyedeekay Thanks zzz

orignal I would like to disucss signatures

orignal because it's next step

dr|z3d some additional preliminary links for a different perspective from the one in the linked article above:

dr|z3d compare-hashing-algorithms.mojoauth.com/sha-256-vs-sha-512

dr|z3d guptadeepak.com/sha-2-family-choosing-between-sha-256-sha-384-and-sha-512

dr|z3d ssldragon.com/blog/sha1-sha2-sha256-sha-512

dr|z3d itoolkit.co/blog/2023/08/is-sha512-more-secure-than-sha256

dr|z3d > In summary, while SHA512 theoretically provides larger security margins than SHA256, both hash functions have demonstrated excellent collision resistance so far. For most applications today, SHA256 appears to offer sufficient security along with performance advantages. But SHA512 may prove beneficial where additional reassurance is needed considering future threats and cryptography advances.

dr|z3d (from the last linked article)

zzz ok, if nobody feels qualified to take the lead, then we'll all have to get smarter about it

zzz this issue may delay things by up to several months, but shouldn't stop progress elsewhere

zzz the collision resistance issue is, I assume, most relevant to our netdb, as it would catastrophically break things

zzz whether it has any relevance to noise handshakes, dunno

altonen could be relevant: eprint.iacr.org/2021/292.pdf

zzz orignal, to clarify my 'gunzip every packet' comment:

zzz I meant:

zzz 1) check every gzip header for protocol type

zzz 2) if it's datagram3, gunzip it to get the hash and verify it

zzz eot

orignal yes I know what it means

orignal but, usually real gzip is nothing

orignal jst memcpy