~dr|z3d
@RN
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%acetone
%mareki2p
%snex
+Atticfire
+FreefallHeavens
+Onn4l7h
+Onn4|7h
+fa
+marek22k
+onon_
+profetikla
+qend-irc2p
+r00tobo
+sexy
+uop23ip
Arch
Danny
Irc2PGuest21708
Irc2PGuest28384
Irc2PGuest4937
Irc2PGuest66257
Irc2PGuest75631
Irc2PGuest99986
Over1
RTP_
Watson
ahiru
anontor
cims
i2potus
interesting
justaperson
lokzz
luvme3
mahlay
makoto
n2_
nilbog
not_bob_afk2
pinotto
poriori
r00tobo[2]
rednode
sahil
uberius
user_ygg2_
zzz
fun fact: expire conns faster -> more routers can connect per minute, netdb size gets larger
orignal
onon_ everybody knows that RN is from Alaska, That's why ))
onon_
Oh, i didnt know that
dr|z3d
re late replies, even with a 5 minute grace period, still seeing 40 odd routers.
dr|z3d
seriously, you take >5m to respond to a query? you're either borked or hostile.
dr|z3d
zzz: the latest audit report, from "ZionStar"? Does that sound right?
zzz
havent heard of that
dr|z3d
zzz: also, this commit might be of interest: github.com/I2PPlus/i2pplus/commit/ad983a3427fea75d266a14ba9cbc868caa2a38b9
zzz
whats the symptom?
dr|z3d
decryption failure.
zzz
ok thanks will take a look
zzz
found by testing or logging or AI or report or?
dr|z3d
ran the AI over the router code to look for potential bugs.
dr|z3d
it's mostly a logging thing, the end result is the same, we fail the handshake, but with the patch, we get a better insight into why the handshake failed.
zzz
how about an actual fix then?
dr|z3d
the fix is there.
dr|z3d
we detect reused tags and issue a prompt "no thanks".
zzz
so it's not a race at all, just a dup tag?
zzz
and the comment says "to prevent race condition" but you say it doesn't prevent anything?
dr|z3d
The scenario:
dr|z3d
1. NSR (New Style Reply) creates a tagset with a single _state (HandshakeState)
dr|z3d
2. This state can only be used once - it's consumed when creating the SessionKey
dr|z3d
3. Multiple packets with tags from the same NSR tagset can arrive concurrently
dr|z3d
The race:
dr|z3d
Thread A: gets tag #1 from tagset X
dr|z3d
Thread B: gets tag #2 from tagset X (same tagset)
dr|z3d
Thread A: calls getSessionKey() -> uses _state
dr|z3d
Thread B: calls getSessionKey() -> ALSO uses _state (same state!)
dr|z3d
Both thru"����� the same _state, but it can only be used once. The state gets "double-spent" - causing:
dr|z3d
- Duplicate key derivation
dr|z3d
- Decryption failures
dr|z3d
- "Decrypt fail NS/NSR/ES" logs
dr|z3d
The fix:
dr|z3d
if (_nsrStateConsumed) {
dr|z3d
log.warn("NSR state already consumed, rejecting tag");
dr|z3d
return null; // Reject instead of double-using
dr|z3d
}
dr|z3d
_nsrStateConsumed = true;
dr|z3d
Now the second tag is rejected with a warning instead of silently causing decryption issues. This prevents the race condition from producing corrupted/decryption-failed packets.
dr|z3d
does that make sense?
zzz
looking...
zzz
has your new log ever triggered?
zzz
has your new log ever triggered?
dr|z3d
yes
zzz
hmm. RTS javadoc says caller's responsibility to sync, every consume() call I see in RSKM is synced
dr|z3d
I see 432 instances of the warning in the latest log file.
dr|z3d
WARN [...PReader 3/6] ...et.RatchetTagSet: NSR state already consumed, rejecting tag gOhG~Ujnq7g= in TagSet #33799 -> Possible duplicate or stale tag
dr|z3d
could be a dodgy implementation on a router fork?
zzz
dunno, will put it on my list, not enough head space to do it now. ratchet handshake is really messy
dr|z3d
ok