IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2025/03/18
~zzz
@eyedeekay
+R4SAS
+RN
+RN_
+StormyCloud
+T3s|4
+Xeha
+acetone
+hk
+orignal
+weko
FreeB
Irc2PGuest27999
Irc2PGuest3338
Irc2PGuest59134
Onn4l7h
T3s|4_
aeiou_
aisle1
altonen
ardu
dickless
eyedeekay_bnc
not_bob_afk
profetikla
qend-irc2p
u5657
x74a6h
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.
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
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
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
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
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
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
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 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 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 because racthets
zzz it just needs a full security analysis
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 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 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 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?