~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.
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
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?