&zzz
+R4SAS
+RN_
+T3s|4
+eche|off
+nilbog
+orignal
+postman
+qend-irc2p
+sourceress
Arch
Birdy
Danny
Irc2PGuest30010
Irc2PGuest36077
Irc2PGuest49364
Irc2PGuest51117
Irc2PGuest6564
Irc2PGuest65656
Irc2PGuest67278
Irc2PGuest74235
Irc2PGuest83482
MatrixBot
Onn4l7h
Over
Sleepy
Teeed
Yotsu
__bob_
aargh3
ac9f
acetone_
ahiru
anontor
b3t4f4c3__
cims
dr4wd3_
dr|z3d
duanin2
hababam
hagen_
leopold
makoto
marek
marek22k
n2
noidea
not_bob_afk2
nyaa2pguy
o3d3_
poriori
profetikla
r00tobo
rapidash
solidx66
stormycloud[m]
test7363673
uop23ip
urist_
user_
w8rabbit
zelgomer
zzz
orignal, pq=4 router ~Akx is up, verified doesn't break non-pq, pq flavor is unit tested only
zzz
gah, buffer size issues, not ready yet
zzz
ok, fixed
orignal
thanks. will try later today
orignal
mine also doesn't break anything
zzz
will work on live-net pq testing between 2 of my routers but probably not today
zzz
also, a couple weeks ago you talked about adding a lot of padding to non-PQ so they're about the same size...
zzz
I found a bug where I can only handle 256 bytes of padding max right now
orignal
no good
orignal
my whole idea is not just non-PQ
dr|z3d
you've been told, zzz, no good :)
orignal
for 3 we make messages size up to min of type 4
orignal
lol
zzz
the spec says the amount of padding should be "reasonable" but max is TBD.
zzz
I can fix it for PQ routers but don't send > 256 to non-PQ routers
zzz
I also don't want to get OOMed by getting spammed with 65535 byte padding connections, so we may need to agree on a limit
orignal
only if counter party is pq
orignal
not 64K ofc
orignal
msg of type 5 + few hundreds bytes max
orignal
the whole idea is random distribution
orignal
of mag sizes
zzz
since the spec says "reasonable", I'll downgrade my assessment from "bug" to "undocumented limit" ))
orignal
zzz, will you router be inline all the time
orignal
?
zzz
yes
zzz
re: the discussion the other day, I can't think of any reason for Bob to verify the pq value in the RI
zzz
that means you don't need to include pq in the address if you are firewalled, and you can use whatever version outbound that Bob advertises
orignal
zzz seems I'm connected to you now
orignal
I'm nKkG
orignal
nevermind it was SSU2
orignal
you closed the session
zzz
Failed to establish: Bad version: 4
zzz
some bug on my side
orignal
should I put 2?
zzz
in the options block? let me look, gimme a minute
orignal
it's not a bug it's incosistecy
orignal
what we put in options block
orignal
I put 4 right not but might be 2
zzz
yeah in the zzz.i2p post I said - Version field in the NTCP options block remains 2 even for the PQ variants.
zzz
so try that
zzz
or we could do it the other way, but thats what my code is now
orignal
always 2?
orignal
will try
zzz
hold on let me do some more double chekcing
zzz
yeah, always 2. We can change it if you want but for now, try 2
orignal
fine let's try
zzz
the good news is that message 1 decrypted successfully )))
orignal
that's right
orignal
at least until options frame
zzz
my thinking was, its pointless to put in 3/4/5, it won't decrypt if it's wrong. But maybe it's more confusing that way
orignal
then what was that option for?
zzz
future use, but I guess for changes in the block-level protocol, or maybe for changes later in the handshake
orignal
I don't check that option anyway
orignal
no I got response from you
orignal
NTCP2: SessionCreated time difference -2013473629 exceeds clock skew
orignal
seems wrong ts
zzz
hmm
orignal
no decrypton errors however
zzz
looking...
zzz
pretty sure I've screwed up the offsets for the option block in message 2 but it's going to take me more time than I have today
orignal
no problem
orignal
let's continue tommorow
zzz
super. congrats, we got the hard part right the first try!
orignal
yes, I was able to decrypt the options blocks without error
zzz
yup, msgs 1+2 basically work, I just clobbered my options block
zzz
because I'm encrypting in-place and didn't take into account the msg is bigger