IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2024/04/23
~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+bak83_
+cancername
+cumlord
+hk
+profetikla
+uop23ip
Arch
DeltaOreo
FreeRider
Irc2PGuest19353
Irc2PGuest46029
Irc2PGuest64530
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over1
acetone_
anon4
anu
boonst
enoxa
mareki2pb
mittwerk
not_bob_afk
plap
poriori_
shiver_
simprelay
solidx66
u5657_1
weko_
RN where does the underpants come in?
RN orignal, a southpark fan eh?
orignal I'm sorry I didn't watch it
RN underpants gnomes' plan: Step 1) collect underpants. 2) ... 3) profit
RN you probably saw a meme inspired by that episode...
orignal and how is it related to my proposal?
orignal simply "no s - use signing key"
RN you concluded with "profit"
RN just humor
RN not trying to detract from what sounds like a good idea
orignal seems it's a big challenge to sort it out
orignal I don't know why
orignal then I propose simple and dirty solution
dr|z3d what's wrong with hashing the current router ip with the router's key?
RN perhaps an over-abundance of caution slows progress. but I like the way things get hashed out before any major changes
orignal dr|z3d which of 2 keys?
dr|z3d router's private key.
orignal which one?
orignal there are 2 keys
dr|z3d the one linked to the routerid. that one.
orignal router ident is hash of two keys
dr|z3d if it matters. what matters is that the receiving router gets an ip and can cross check it with a signed hash from the router.
orignal and how does it help against this attack?
orignal seems you all don't understand what's realy going on
orignal but what really going on you can "connect" to a fake router
dr|z3d hmm, I was thinking signing the ip somehow might help, but maybe not.
orignal by thinking you are connected to it
orignal but actuualy connected to another one
RN if there are two keys associated with the real router, why not use both of them together to 'sign' or create something to verify? or use one for 'first round' and other one for 'additional verification' when needed?
orignal I'm not going to point finger, but NOBODY took this problem seriously since last summer
RN I haven't seen 'nobody' sign onto this irc in a long time
orignal RN an advesary can also sign an address with signbing key and produce valid RI
RN (we used to have a user with the name 'nobody')
dr|z3d now is not the time for flippancy, RN :)
RN but it would not be the correct signing key?
RN sorry dr
orignal if this issue was addressed properly we din't have this problem today
RN I thought the point of signing is to prove you are the only one with that key
orignal but we have heard "write a proposal" simly meaning "fuck off"
dr|z3d then you heard it wrong.
orignal RN absolutely right, but this attack doing oppiste
RN no. write a proposal means 'write up the details in a formal manner' so we can pick the issue apart to find solutions
orignal dr|z3d the proposal was written many months ago
orignal and who picked the issue?
orignal nobody
orignal I kept chasing idk with this issue for couple months
orignal then gave up
RN you did
orignal then zzz that ended up with another "write a proposal"
orignal RN do you understand what is the nature of the attack?
orignal and why it's even possible?
RN I would say I have a basic understanding how it works as a ddos
RN very basic
dr|z3d just to be clear, we talking about i2p-projekt.i2p/spec/proposals/163 ?
orignal no it's opposute
orignal ddos when an andesray use own resources to flood the netwrok
orignal here he uses the network to flood the network
orignal 163 is from weko?
RN ok, so triggering something that propigates.
orignal I don't have I2P open right now
dr|z3d no, wrong link.
orignal I'm talking about one for SSU2
orignal no signatures will help against this attack
orignal yes, 165
orignal in two words when you connect to a router through SSU2 you can't verify if you connect to that router
dr|z3d so we need a test as part of the initial handshake.
orignal and your handshake will be successive as long as you use right public "s"
orignal handshake must include router's indormation
orignal NTCP2 uses router ident
orignal as AES key
orignal so my idea is
orignal use router's signing key as "s"
orignal crypto key is not better than "s"
orignal an adesary can clone it too
orignal also I really don't undeestand what do we need two keys for in router identity
orignal one ed25519 key is enough for both purposes
dr|z3d what are the downsides?
dr|z3d I'm hearing accidental DDOS mentioned wrt mitigations, not sure I understand that.
orignal str4d would said that I'm a fucking idiot
orignal that's not right to use same key for different purposes
orignal proposal 165 contains right solution but nobody cares
RN saying nobody cares doesn't help move things forward
orignal that's why I offer simplier alternative
orignal that requores much less work
RN it is clearly documented you were concerned about this and the current state of affiars proves you were right
orignal I'm really disappointed that this old attack still takes place
orignal the attack that has right mitignation year ago
orignal the problem now is that only powerfull floodfiils can handle this attack from entire network
orignal because other routers try to build tunnels through fake routers
orignal ofc the next step of advesary will be to clone all routers with public ips
orignal not only floodfills
orignal that are less powerful than floodfiils
dr|z3d yeah, but sybil detection takes care of some of the issues, albeit at the expense of legit routers that had their ips cloned.
orignal and even worse
dr|z3d which is not to say it's sufficient, because obviously it isn't, but it's a partial mitigation for some of the effects of the attack, not the attack itself.
orignal say I'm cloned floodfill trying to build an IB though you
orignal and since I'm banned on your side this requst will never reach me
orignal if SSU2 didn't have this hole
orignal nobody could cnnect to a fake router and recognized it as dead
orignal but other router recognize it as alive
orignal and trying to send data
dr|z3d it will be fixed, and elegantly, you know how zzz operates. festina lente :)
orignal I don't see any evidence of it so far
dr|z3d sometimes it takes a prolonged attack to bring things into sharp focus.
orignal the attack keeps going
dr|z3d exactly.
dr|z3d it can't be ignored, in other words.
orignal yes we did something from our side
orignal to keep rate 10%
dr|z3d corrupt sessionconfirmed packets all over.
RN there you go Unbur.
Unbur i take it im not the only one facing connection issues[q]
Unbur i have hours upon hours of 'remote host closed socket' everywhere
Unbur thats the attack isnt it[q]
not_bob Correct.
not_bob We are under attack.
not_bob Unbur: If you run i2pd, do a pull from the git and recompile.
not_bob Otherwise, install the latest dev build of I2P+ and that should help out quite a bit.
RN not_bob!
not_bob What's up!
orignal what is corrupt sessionconformed about?
dr|z3d SSU2 handshake failure.
dr|z3d Seeing a huge amount of those right now.
dr|z3d here's some example output:
dr|z3d […andler 9/10] …blishmentManager: [SSU2] Received CORRUPT SessionConfirmed
dr|z3d • Router: [SSU2] InboundEstablishState 94.31.73.241:18806
dr|z3d • Lifetime: 282ms; Receive ID: -1257312924431045244; Send ID: 1799018147142317883; Token: 2698197131991171618 IB_STATE_FAILED
dr|z3d • IES2 Payload Error: [SSU2] InboundEstablishState 94.31.73.241:18806
dr|z3d • Lifetime: 282ms; Receive ID: -1257312924431045244; Send ID: 1799018147142317883; Token: 2698197131991171618 IB_STATE_CREATED_SENT
dr|z3d routers that ignore session termination packets are also pretty regular in the logs, sending 10,20 packets after session terminated.
dr|z3d both events possible symptoms of the attack?
orignal yes because they stared changing "s"
orignal ofc it doesn't match and crypto fails
dr|z3d possibly something to target, though it may be a case of addressing the symptom rather than the cause.
orignal we see bunch of clones with changed "s"
orignal I think they are trying to load routers with crypti
orignal because you can only recognize it in SessionConfirmed
orignal shared key mismatch
dr|z3d thinking out loud, I wonder if the fleet of chinese routers before the attack got into full swing suggests a nation state level attack.
orignal or it's just "salt" guy
dr|z3d he'd have been on your irc server by now taunting you.
orignal so any plans to resolve this SSU2 issue?
orignal for now we plan to not try to connect through SSU2 if NTCP2 failed for a non-confirmed router
orignal unrtunately we have to do some hacks
dr|z3d what about sybil detection, are you doing anything with that?
orignal partially like not pick tunnel from close IPs
orignal but current attack is not sybil
dr|z3d sure, but sybil detection routines that see too many routers on the same ip covers the current attack, albeit with side effects.
orignal no, because it also bans real routers
orignal that's not what we want
dr|z3d yeah, that's the side effects part.
orignal it's not our way
dr|z3d sure, it's something we all want to avoid.
orignal as result we have very low rate of floodfills
orignal becuase you guys ban us
orignal seems your response causes more troubles than the attack itself now
orignal another idea
orignal why can't we sign RI using "s" private key and include into address?
zzz orignal, weko, re: prop. 165 "taken seriously" -
zzz that will happen when you schedule a review, which you haven't done in 3 months
zzz nor did you even mention it between january and last week
zzz also, the proposal is a mess of alternatives, sub-alternatives, and sub-sub-alternatives, some with major compatibility problems that can't be taken seriousl
zzz also, none of the alternatives have enough detail to be implemented, even if I know which to choose
zzz I suggest to update the doc in light of recent events and to fix problems, and then schedule a review
zzz alternatively, you could schedule a pre-review discussion, if you'd rather do that before updating it
orignal my point is the problem exists for a long time
orignal and now we have this problem
orignal so you don't have own view how to fix this SSU2 hole?
zzz I don't even know what your recommendation is, because your proposal is a convoluted bag of alternatives. Please document what you want to do, and I'll evaluate it.
orignal to send Bob router ident
orignal during handshake
orignal also I offer 2 more alrenatives
orignal to use signing key for s
orignal or add signature of router identity to an address
zzz so write it up
orignal it's above
zzz I can't make any sense of "(1) can (2) should (3) no support (4) support" etc. in the proposal
zzz send me a patch to prop 165 markdown. I'm at the same place I was a year ago. Document your recommendations and schedule a review
orignal I'm on meeting
orignal will be back in 15 moinutes
orignal what is 1,2,3, 4?
orignal <orignal> why can't we sign RI using "s" private key and include into address?
orignal my today's idea
orignal every address in RI includes signature of router indenttity signed by "s" key
orignal this prevent advesary to insert an address to his fake RI
orignal and shit will be detected on earliest stage
orignal e.g. s signs router
Unbur finally im back. i think my connection issues are because of the attack.
Unbur how can i help[q]
orignal what do you think about my idea?
orignal sign addresses inside RI
Unbur im unfemiliar with the innerworking of i2p and the terms used around it. so i have no clue what RI is
Unbur from what i do know, maybe something similar like what tor uses to verify user sessions. a local computational proof bit that would scale horribly but is still doable for real users
Unbur it could limit the devices i2p can run on but most devices should still work
orignal_ do you understand the problem?
Unbur not really no
orignal what's the nature of the attack
orignal an adverasy copies address from real routers and insert them into his fakes
orignal and if someone tries to connect to such fake router they get connected
orignal to that IP of real router
orignal believe that fake router is real
orignal why it happens? because there is the hole in SSU2 protocol
zzz Alice (should(1), can(2)) send in payload RouterIdent block Flag_0 = 0 and Bob’s RouterIdent. Bob (should(3), can(4)) check
orignal zzz, there are few options to implement this
orignal but it my opinion, Alice should send Bob ident hash in SessionRequest if she needs to verify Bob
zzz right. there's dozens of combinations of them in your proposal. Make some choices please.
zzz so fix your proposal.
orignal if Bob recieves such block and ident doesn't match he must terminate
orignal the reason for this
zzz I can't make any sense of it and definitely can't implement it
orignal no crypto is being called from Bob's side if ident is wrong
orignal so it's not requeired from Alice to send this block if she knows Bob already
orignal but Bob must validate it
orignal please tell me what's wrong
orignal Alice can, Bob must
zzz there is no "must" in the proposal. only "can" and "should"
zzz and those are choices listed, some of which have compatibility issues?
orignal then shoud instead must
orignal and Alice "can"
orignal no compatibinty issue
orignal Only "unknown block" for older version
snex this kinda stuff would be a whole lot easier if we had an automated test suite and cleaned up the code
zzz it's not a proposal yet, it's a list of interlocking ideas. Make some choices, you probably know more than you did 3 months ago, and update it
zzz and specify your backward compatibility requirements
orignal I didn't do it weko did
zzz "With (1) Alice does not support old routers. With (2) Alice supports old routers."
orignal I know only what I would like to see
zzz then isn't (2) a requirement?
orignal Alice should rely on this block for new routers only
orignal and check router version first
zzz it has your name on it. fix it up so it makes some sense and matches your current recommendations
orignal where do I change it? on github?
orignal ok. time to rebuld and update
zzz orignal, I need a patch against the .rst file from github
zzz orignal, weko, you say the new block contains a router ident, I believe you mean a router hash
zzz orignal, weko, preliminary thought: a crypto solution like MixHash() or XOR (as you describe in the notes section) would be better than a new block
orignal so I make a patch and then PR>?
zzz orignal, weko, is all of this useless until a year from now when we can ban old versions?
orignal router ident hash
zzz no, patch and email
orignal e.g. 32 bytes sha256 hash
zzz router ident = full 391 byte identity
weko [16:36:19] <zzz> orignal, weko, you say the new block contains a router ident, I believe you mean a router hash
weko It is same terms, isn't?
weko zzz: thanks, will know
zzz fix all this (1) (2) (3) (4) can/should stuff to say: If Bob is >= version X, ALice must do this, otherwise, Alice must do that. If Bob sees this, bob must do that, otherwise bob must do something else
weko [16:37:09] <zzz> orignal, weko, preliminary thought: a crypto solution like MixHash() or XOR (as you describe in the notes section) would be better than a new block
weko Yes, you said it earlier, it is reason why I wrote it in notes
orignal MixHash of what?
orignal I didn't get your point
orignal wouldn't it break compatibimity?
orignal I see now. One more call of MixHash at the end
zzz e.g., set a flag in the session request header, then xor or MixHash() Bob's hash in somewhere
zzz orignal, weko, please assess and document the security of any recommended solution. Also consider a scenario where the attacker controls the 'real' router rather than just cloning somebody else's
zzz orignal, weko, in NTCP2 we simply XOR bob's hash into alice's ephemeral key. Is that not sufficient? Why are you proposing something completely different?
orignal if I remeber it's AES key
orignal for SessionRequest encryption
orignal because SSU2 doesn't use AES
orignal SSU2 uses "i" key instead
orignal i2p::crypto::CBCEncryption encryption;
orignal encryption.SetKey (m_RemoteIdentHash);
orignal that's what we do in NTCP2
zzz you're right, it's AES encrypted with bob's hash as the key
zzz not a simple XOR
orignal AFAIK this is only place where we use Bob's ident
orignal I did this analisys last summber
zzz in ssu2, we already have one layer of obfuscation, with the header encryption
orignal however
orignal why can't we use ident hash as "i" ?
zzz so maybe xor is enough? don't know. The idea was just to make it hard for DPI
zzz that's your section 3
orignal what is section 3?
zzz in your proposal that has your name on it ))
orignal "i" doesn't break compatibility
orignal unlike other changes in crypto
orignal in SSU2 with xor derived from chacha20
zzz compatibility is not broken if you design it right.
zzz old must be able to talk to new and vice versa. that's a requirement
orignal another problem with NTCP2
orignal you know that address from wrong router
orignal only when you receive SessionConfirmed
orignal e.g. advesary forces you to do whole handahske
orignal that CPU greedy
zzz that's noise XK. authenticity is not assured until the handshake is complete
orignal ideal solution is to let Alice know before trying to connect
zzz I still have no idea what your recommendation is, section 2 or section 3 or both or something new you haven't documented yet
zzz I'm more confused than I was a year ago
dr|z3d here's an idea, apologies in advance if it's naive.
dr|z3d if session request includes the remote router's ip in the packet, and the details are screwy, can't we just take the ip and ban that router without affecting the valid router?
orignal who should do it?