IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2026/01/09
@eyedeekay
&eche|on
&zzz
+R4SAS
+RN_
+StormyCloud
+T3s|4
+acetone
+cumlord
+dr|z3d
+eche|off
+hagen
+orignal
+postman
+qend-irc2p
+snex
+wodencafe
Arch
Birdy
Daddy_
Danny
FreefallHeavens
Irc2PGuest18759
Irc2PGuest20240
Irc2PGuest23323
Irc2PGuest26153
Irc2PGuest77981
Irc2PGuest98458
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Stormycloud_
aargh2
ac9f
anontor
b3t4f4c3__
bakenbard__
dr4wd3
duanin2
gellegery
leopold_
makoto
mareki2p_
n1
nilbog
onon_1
poriori_
profetikla
r00tobo
rapidash
shiver_
solidx66
u5657
uop23ip
user1
vivid_reader56
w8rabbit
x74a6
zelgomer
zzz ok orignal give me a couple more days, I've been distracted
orignal zzz, I have a question
orignal about ratchets
orignal say your server is crypto type 6
orignal and client comes with type 5
orignal are you able to obtain client's static key in this case?
dr|z3d server is 6, client is 5 -> unsupported crypto.
orignal the question is why
orignal no real reason to not support it
dr|z3d sure, it would be nice if we could support all 3 strengths, but we don't right now. there's probably a reason for that.
orignal my point is
dr|z3d but...
orignal if a client supports PQ, PQ type should be defined by server
dr|z3d that's probably better implemented on the client, not the server.
orignal I'm talking about client only
dr|z3d so the client just specifies pq (5,6,7) and uses whatever the server provisions.
orignal only concern is how a server would react to such leaseset
orignal clints specifies any of 4,5,6 meaning it supports all of them
orignal server must specify exact type
dr|z3d in java land, you can only have 2, and one of them must be ECIES if also using PQ.
dr|z3d unless there's something I've overlooked.
dr|z3d right, so we ideally want to support all pq standard instead of a specific strength, on the client.
dr|z3d then client determines what strength of pq it needs, and switches automatically.
orignal you can't have 0,4? lol
dr|z3d read what I wrote.
orignal client can't decide it's based on what server supprts
orignal a server doesn't support more than one PQ type for the reason
dr|z3d and your point is?
orignal because you will have to try all 3 for every fucking incoming packet
orignal my point is
orignal if a client is 4,6 it can connect to server with 5
orignal using 5 ofc
dr|z3d we've already established we want multi-strenth support _on the client_ not the server.
orignal my question is how would a server react
dr|z3d client on 5, server on 6, server says "nope, not supported, can we fallback to ECIES?"
dr|z3d the fix is to have the client establish what the server supports and switch.
zzz if server is 6,4 and gets 5, it tries 6 and 4 and fails (ofc)
orignal zzz, it's not about session
orignal it's about LS only
orignal client connect to server with 6
orignal but it's LS is 5
orignal e.g. it's just a verification
orignal that static key matches
zzz what are you trying to verify?
zzz you can only verify static key by going thru the IK handshake
orignal then a client sends their LS
orignal do you verify static key?
zzz yes
orignal so if a session was created as 6 but the key is in 5 wehat would you do?
zzz fail, because we look for a key of the correct type
orignal why can't you take any PQ type?
zzz to prevent the confusion you're proposing?
orignal think about NTCP2
orignal if Alice supports PQ it's based on Bob's type
orignal or you are also going to verify against Alice's RI?
zzz my principles when writing prop 169: 1) KISS; 2) a consensus on which PQ type we actually use will quickly form; 3) be flexible in case we were wrong on 2)
orignal if Alice v=3 connects to Bob with v=4 with PQ what would you do after servering SessionConformed?
zzz I think that would work? not sure
orignal would you check version with Alice's RI?
orignal from SessionConfrimed
orignal your handshake is 4 but Alice is 3
zzz looking...
zzz haven't added any code like that yet, and hadn't thought about it
orignal then what's diference with ratchets?
zzz PQ ratchet code is done. PQ transports code is not.
orignal you care only that a session is eatablished and static key is published in LS
orignal it can be improved
orignal I'm going to implement it in i2pd
zzz I'm focused on PQ transports right now, I have no brainpower left for ratchet changes. The way to convince others to do something is to write a proposal