~R4SAS
~orignal
~villain
&N00B
+Xeha
+relaybot
AreEnn
Guest24958
Leopold
Most2
Nausicaa
Nikat
Opax
Stark
Vort
acetone
anon2
anontor
fidoid
grimreaper
itsAMe
karamba_i2p
ncop
osoznayka
polistern
poriori_
profetikla
qend
r00tobo
scratch
soos
teeth
tensor
tetrimer
typhoon
uis
un
weko
whothefuckami
колдобина
колдырь
zzz
line 540:
zzz
const uint8_t nonce[12] = {0};
zzz
take nonce from header
orignal
I see
orignal
that's my problem
orignal
will fix
orignal
zzz, for do we use as non for long header encryption? all zeroes or packetnum?
orignal
specs says zeores but I guess it should be packet num
zzz
for retry and token request, it's the packet number
orignal
please fix specs
zzz
where is the spec wrong, I'll fix it
orignal
/ For Retry, Token Request, and Peer Test only:
orignal
iv = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
orignal
/ encrypt the third part of the header
orignal
Header Encryption KDF
orignal
it basically says iv is all zeroes for third part that's wrong
zzz
that's about the header encryption, not the AEAD nonce
orignal
yes, but I'm asking about header encryption
orignal
bytes 16-32 basicallty
orignal
AEAD is clear
zzz
ok, got it
zzz
so my answer above is wrong, the spec is right
orignal
but then it's wrong
orignal
because same key, same all zeroes token
orignal
same nonce
orignal
and saome connid
orignal
and advesary could recognize it easily
orignal
anyay may I ask what's the reason for it to use all-zero nonce since we know packetnum at that moment?
zzz
hmm
zzz
so, we're talking about bytes 16-31 of the Retry and Peer Test headers
zzz
that contains the Source Connection ID and Token
zzz
correction:
zzz
so, we're talking about bytes 16-31 of the Retry and *Token Request headers
zzz
that contains the Source Connection ID and Token
zzz
the source conn. ID is random number.
zzz
token is random number for retry, 0 for token request
zzz
so it's going to look different after header encryption, every time
zzz
and different from each other
zzz
sorry, I have to go, back in two hours
orignal
sec
orignal
connid is not always random it's the same for seme session
orignal
also this part doesn't depend on hearder at all
zzz
back
zzz
so, your concern is that the headers for two messages in bytes 16-31 will look the same
zzz
which two messages?
orignal
zzz SSU2: SessionConfirmed part 2 AEAD verification failed now
orignal
zzz, yes
orignal
but I have changed anyway using zero nonce for now
orignal
so you shold receive SessionCreated back
zzz
checking...
orignal
SesdionConfirmed is the next issue
zzz
I don't see any outbound attempts to you from my router today
zzz
let me look at your session confirmed code real quick and see if I see anything
zzz
line 441:
zzz
m_NoiseState->MixHash (buf + 16, 48); // h = SHA256(h || ciphertext);
zzz
that doesn't look right
zzz
shouldn't it be (buf + 48, remaining length) ?
zzz
wait, that's part 1
zzz
that's right
zzz
are all of the session confirmed messages failing? or just from Java? or just from some java routers?
zzz
because java will send out garbage if the RI is too big
zzz
orignal, I think I see the bug
zzz
nonce should be 0 for part 2
zzz
compare to your NTCP2 code
orignal
therouter we are talking about in my FF
orignal
xZ9n
orignal
I haven't tried from i2pd yet
orignal
I will check
zzz
doesn't look like you set the nonce to 0 after part 1
orignal
probably
orignal
it's easier to compare with sending since it's defintly works
zzz
funny how AEAD doesn't work unless everything is perfect :)
orignal
strange
orignal
how receiving part works?
orignal
although I use 1 there
orignal
lol I see )))
orignal
thank you for tip
orignal
fill fix and rebuild
orignal
in 30 minutes
zzz
:)
orignal
the next problem will be ack for session confirmed
orignal
let me check
orignal
restarted
orignal
let's wait
uis
Зачем в заголовке потокола потока(streaming) одновременно поток отправления и поток назначения?
orignal
я тоже никогда не мог этого понять
zzz
looks like I had a good outbound connection to xZ9n from about 12:09 to 12:19, and about 15 data packets each way, no problems
orignal
let me check
orignal
I don't see any errors
orignal
good that it works
orignal
finally
orignal
also strted ipv6 router
orignal
had an issue with fragments this morning