#ls2 (irc2p) | #ls2 proposal review channel : Reviews Tuesdays 7 PM UTC: none currently scheduled

zzz reminder: Proposal 169 review here today 7 PM UTC

dr|z3d here now, but may be a little late to the party when it starts.

orignal lol

dr|z3d keep my beer cold, orignal

orignal why non pop-corn?

dr|z3d you're in charge of snacks.. chocolate potato chips all round, thanks :)

zzz test test

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

eyedeekay hi

orignal hi

zzz ok

zzz hello everybody, today we're reviewing proposal 169

zzz I'll give a brief overview, and then throw it open for comments and discussion

dr|z3d hi and back in 20.

zzz this is a long proposal, and covers what may be 2-3 years of work

zzz so we're obviously not going to just approve it as-is and go off and start coding

zzz I've already made about 40 updates to it over 2 months

orignal hi

zzz none of us our PQ experts, we'll all be learning together

zzz the proposal lays out a number of choices that we are probably not prepared to make final decisions on today

zzz but with NIST approving MLKEM and MLDSA, and openssl and bouncy castle offering support, it seems like this is the right time to get started

zzz so let's focus on the high-level plan and see if we can find agreement, and I'm sure a lot of details will be discussed in future followup reviews

zzz EOT. I'll throw it open for discussion

zzz good idea? bad idea? good plan? bad plan? what do you all think

orignal my concern is lenght of signature and keys

orignal yes MLDSA/MLKEK is fine

orignal fully supported by openssl

orignal however people are concerned that 2 years is too long

zzz yeah, it's long, but some things need widespread ff support, so it takes a while even if coding is fast

orignal from my side I can backport from openssl 3.5 later to implemntatntion wirh pervious versions if neccesary

orignal so, back to my point #1

zzz I thing the most important thing is MLKEM, and it can also be the fastest

orignal we should use ident hashes instead full addresses in streams datagrams and sam

orignal let's talk about MLKEM

zzz ok let's start with MLKEM and come back around to MLDSA / stream / dg / sam later

orignal as I understand we add one more ephemral key

orignal and apply one more key agreement round

zzz correct

orignal it's fine but how do we differentite pure x25519 and MLKEK packets

orignal that's my main issue

orignal your idea about length doesn't seem good because payload

zzz try both, unless the length is enough to know for sure, but yes, payload

zzz basically we did the same thing for ElG + 25519

orignal yes but it has clean pattern

orignal when it's ElGmal

zzz we could put flags in the front, but then the OBEP/IBGW can see it

orignal flags is bad idea

zzz the other thing we do, as mitigation, is we keep counters for which type succeeded, and use that to decide which one to try first

orignal I would put them after X elligator ephemeral key

zzz put what?

orignal for eeplsite both migh be right if many different clients

orignal put flags xor-ed with something

zzz sure, you have to try both, but if you try the right one first, it works better

zzz I don't think flags will work

orignal me too

orignal when do you think you will be ready to run a dest supporitng crypto type 5?

zzz days to weeks, depending on how many changes we make today

orignal today?

zzz like if you want to flip 12-14 and 15-17

orignal I don't see we need to changes somthing for tackets

orignal no I'm fine with 15-17

zzz you wanted the non-hybrid to be 12-14?

orignal no, just asked why

zzz ok

orignal my point was simple

orignal stringer crypto should have higher umber

orignal *stronger

orignal let's ask others

orignal what's thier opinion

zzz eyedeekay?

orignal dr|z3d?

zzz let's come back to it, we're on MLKEM right now anyway

eyedeekay I'm indifferent to the numbering or the byte ordering as long as it's clear in the spec

orignal then leave it as it's not

zzz I'll have an opinion in 10 minutes ))

zzz eyedeekay, you have any thoughts about MLKEM in general?

orignal MLKEM looks clear for me

eyedeekay A lot of this is going over my head but I do get why flags wouldn't be a good idea, on a maybe related note I wonder how much more unique-looking doing all of this makes us at various layers(transport?)

zzz and do you two agree that MLKEM ratchet is the most important to work on first?

eyedeekay Yeah I think that does seem right as far as I understand it

orignal MLKEM is just ratchets with extra ephemral keys

orignal static key and session key remains the same

dr|z3d back

zzz the thing with flags is that the OBEP and IBGW see the raw garlic message. That's different than off-network observers looking at NTCP2 and SSU2, which is an additional layer of encryption

zzz so you really don't want garlic messages to be identifiable as particular types (NS/NSR/ES) or encryption types

orignal I don't want to

zzz that's why ratchet is the most convoluted of all our protocols and has the highest attention to security details

eyedeekay Yeah agreed, that seems especially bad

zzz especially if you have colluding OBEP/IBGW that can capture both the NS and NSR of a handshake

orignal zzz however another concern

orignal MLKEK ephemeral public key is looong

orignal hence OBEP/IBGW can regognize as a long message

zzz it's looong but not crazy looooooong like MLDSA

orignal while the rest of them traffic will be two tunnel messages

zzz as I said the other day, we may need to omit the data payload from NS. Or maybe add more padding to 25519 NS

orignal usualy they see like 2*1700

orignal even if no payload

dr|z3d so we standardize and pad, no?

dr|z3d make everything look the same.

orignal what is the longest MLKEK?

zzz not in the NS, which is usually just GET. We could also limit the payload in the NSR

orignal I think at least few kilobytes

zzz no, only ~1500

zzz MLKEM is not crazy big, but you're right to worry about the garlic message sizes

orignal is there a way we can split NS by two messages?

orignal like we do in SSU2 for SessionConfirmed

orignal MLKEM1024 3168

zzz a little messy but maybe

zzz would rather not

orignal right

orignal MLKEM512 1632

zzz those are private key sizes, not on the wire

orignal hence NS would look like a strandard two packeted garilc

orignal agree

orignal MLKEM1024 1568

zzz remember we probably don't need MLKEM1024. MLKEM768 is only about 1K each direction

orignal biggest

orignal than it's fine

orignal only matters that it doesn't exceed 3400

orignal however guess what?

orignal most like NS wull containt SYN

orignal with signature

orignal hence we shouldn't allow SYN in NS it it's PQ

zzz right. we may need to put only the LS in the NS. Save the SYN/dest/sig for the ES. We lose a round-trip time

zzz but we get full forward secrecy

zzz right now we are 'cheating' by putting the SYN in the NS, we don't have forward secrecy

orignal and LS also contains signature

zzz sounds like we need to do more research about the traffic analysis issues at the OBEP/IBGW

orignal yes

zzz I also note that the MLKEM "DH" is fast, 10-20X faster than 25519

orignal LS is a bigger issue once PQ signatures got implemnted

zzz half hour in, let's wrap up the MLKEM part and move on to MLDSA

zzz any other comments about MLKEM?

orignal why is it fatser?

zzz no idea ))

orignal oops

orignal how many each key agreemts you have there?

zzz cloudflare reports it's a little slower, so maybe java 25519 is just slow. don't know

orignal for regular x25519 3 x25519 + elligator

orignal I will take a look

orignal we need to understand the reason

zzz anyway, on to MLDSA

zzz here, things are MUCH bigger

zzz and there's also fewer answers on what the 'right' thing to do is

zzz and there's network compatibility issues to roll it out

zzz take a look at the charts under 'overhead analysis'

orignal I did

zzz that's all I know right now

zzz how about you do speed tests and let us know?

orignal of MLKEK?

orignal will do

zzz yes

zzz ok then. for real, let's move on to MLDSA

orignal yes

orignal so my prosal is the same

orignal 1. use ident hash instead identity

orignal 2. don't attack signature if rachets

orignal I mean for SYN

orignal *attach

orignal my algoirthm

orignal find leaseset from ident hash

orignal extract static key

orignal compare with static key of session where SYN came from

zzz I'm not sure it would work, and it's not directly related to PQ, and it would be a huge change and possibly be a big protocol layer violation. Can you write a separate proposal for it?

orignal instead signatures/full ident

orignal I can

orignal but without it there is a huge overhead for every SYN packet

orignal and remeber SYN comes for ever HHTP request

zzz so maybe the only way we can do PQ sigs with reasonable overhead is to implement some other proposal first

orignal yes, that's my point

zzz so I'm not saying no, but it does make my head hurt

orignal futhermore this proposal is not PQ only

orignal we should take an advantage from racthets

orignal especially PQ is supposed to be racthets only

zzz I can tell you I've successfully tested MLDSA end-to-end. They are big packets but it's not so big it doesn't work

orignal dr|z3d, eyedeekay your opinion?

dr|z3d "yeah"

dr|z3d *** smiles. ***

zzz yest. let's also take a step back. How important is MLDSA to do soon? is any other project doing it?

zzz and MLDSA-only vs. MLDSA-hybrid.

zzz it may just be too early. we don't want to be the first idiots

eyedeekay I was pretty focused on trying to get my head around PQ in general to prep for this meeting, if there's a good way to reduce overhead in advance of that I'll support it but I didn't come prepared to talk other protocol changes

orignal_ idiots?

zzz boringssl has MLKEM-like hybrid in production for years, but who is doing MLDSA at all?

orignal_ please implement tunnel swicth flag in I2CP

orignal_ I'm tired from disconnects

zzz please write a proposal for it

zzz not idiots, but we want somebody else to go first

eyedeekay to zzz's point re: somebody else first it would be nice to have an example to work from, but I don't know of one yet though

orignal full ident and signature is an overhead anyway

orignal nothing to do with PW

orignal PQ

orignal because racthets

zzz it just needs a full security analysis

orignal sure

orignal will do

zzz on the 12-14 vs 15-17, I think I'll agree to flip them around, and rebuild my test files

orignal my point is simple

orignal you can always extract full ident from LeaseSet you always have

orignal then go ahead an flip

orignal I will change the code

zzz agreed it _seems_ like we're sending the destination twice, and two sigs (one in LS and one in SYN), at least some of the time, just not sure how it would all work without it

zzz coming up on an hour, let's wrap things up, any further discussion?

orignal well I'm not sure how it will work through I2CP

zzz and should we put this on the calendar to talk about again in 6 weeks, which would be April 29?

orignal timeframes

orignal what is the next milstone?

orignal no I'm not abot to attenf on apr 29

orignal one week earlier

eyedeekay I agree to a follow up and can do April 29

orignal if possible

eyedeekay Either is fine with me

orignal also don't know my shedule in May yet

zzz everybody happy to keep going with a review every two weeks?

orignal can only say about april

orignal yes, fine

zzz so you are ok with April 29 orignal ?

orignal no as I said

orignal I can't attend on 29-th

orignal have another appointment

zzz ok if you can't do the 29th and don't know about May, then let's do April 22

orignal 22-th is fine for me

zzz ok

zzz in two weeks is our 2nd review of prop. 167 (service records), my changes from the review are already up

eyedeekay Ack 22nd

zzz in 4 weeks is our second review of prop. 163 (DG2), reminder - orignal you promised to get me your modifications

zzz anything else?

zzz thanks everybody

eyedeekay Thanks zzz

dr|z3d any day other than tues better for me, but I'm mostly just listening.

orignal no

orignal but for datgrams it's basically the propsals about ident/signature

orignal and for datagram2 we are free to do it without protocol chamge

orignal or I have better idea

orignal *since

zzz no, please send it to me as a diff to the .rst file

orignal ofc

orignal but you didn't get my main idea

orignal no place to discuss ideas now

zzz what I have now is 'datagram3' with a hash at the front, and no signature

orignal in forum format

zzz i2pforum.i2p?

orignal I'm banned there

zzz or 333.i2p is fine also

orignal you din't know it?

zzz maybe, maybe not

orignal I know for sure

orignal that's why 333 is the best

zzz hah

orignal I'm not going to share my dev idea at kislitsa ))

orignal while 4rum.i2p is also dead

dr|z3d feel free to post on ramble.i2p

zzz how about a i2p-dev forum on ramble then?

orignal haven't checked yet

dr|z3d we can do that, zzz.

dr|z3d would you use it?