&eche|on
&zzz
+FreefallHeavens_
+R4SAS
+RN_
+Romster
+StormyCloud
+cims
+eche|off
+hagen
+mesh
+nilbog
+nyaa2pguy
+orignal
+postman
+red
+snex
+wodencafe
Arch
Danny
Holmes
Irc2PGuest28384
Irc2PGuest47578
Irc2PGuest92627
NiceBoat_
OfficialCIA
Onn4l7h
Onn4|7h
Over
SilentWave
Sleepy
U1F642
Wikk_0
Zapek
aargh4
ac9f
acetone_
ahiru
anontor
dr4wd3
duanin2
eyedeekay_
eyedeekay_bnc
ice_juice
leopold_
mahlay
makoto
marek
mareki2p_
n2
not_bob_afk
poriori
profetikla
qend-irc2p_
r00tobo_BNC
rapidash
test3847473
thetia
uop23ip
utp
vivid_reader56
x74a6
zelgomer
orignal
zzz, I have a question about SessionRequest encryption
orignal
do he encrypt ML-KEM and HeaderX in on shot, or separately?
orignal
*we
nyaa2pguy
is go-i2p currently in the state of being 'ready enough' to contribute to the network generally? i.e., with an idle router, is it a net gain or net loss on i2p
orignal
nevermidn it's different key
orignal
go-i2p is being developed for more than 5 years
nyaa2pguy
ahh thats longer than I thought
orignal
zzz, I'm confused about SessionCreated
orignal
in the specs
orignal
"ChaCha20 data (MLKEM) |
orignal
+ Encrypted and authenticated data +
orignal
| length varies |
orignal
+ k defined in KDF for Session Created "
orignal
and " ChaCha20 data (payload) |
orignal
+ Encrypted and authenticated data +
orignal
| length varies |
orignal
+ k defined in KDF for Session Created "
orignal
so, I read as you use the same key for MLKEM and for payload
orignal
that's definitly wrong
orignal
because you must apply MLKEM to MixKey and then decrypt payload
orignal
please clarify
zzz
orignal, you're asking about SSU2?
orignal
yes
orignal
speak is not clear about SessionCreate
orignal
d
orignal
*specs
zzz
ok one minute to pull up the spec
zzz
ok the spec looks the same as for NTCP2 PQ
zzz
looking at the trevor perrin spec
orignal
I'm reading this one about SSU2
zzz
yeah but we based it on the trevor perrin hybrid spec, just making sure
orignal
for SSU2 nothing metions MixKey
orignal
and make impression that MLKEM and payload use same key
zzz
i think I know the answer, just double checking before I say anything, one minute
orignal
I think I know too ))
zzz
so, mixKey() is specified in the Alice/Bob 'KDF for MEssage 2' which is in the "Noise Handshake KDF" section that applies to both NTCP2 and SSU2
zzz
it's not the same key after the MLKEM in message 2 because there's a mixKey().
zzz
it does kinda imply it's the same key, but it's not
orignal
ofc it can't be
orignal
how about MixHash
orignal
?
zzz
I guess we need another 'k=keydata[32:63]' after the mixKey() in the 'KDF for Message 2' sections
orignal
I apply MixHash with key from decaps after MLKEM
orignal
*mixKey
orignal
not sure about MixHash since MLKEM is in header
zzz
we did it right for NTCP2, do the same thing for SSU2, I'll fix the specs to make it more clear
orignal
not really the same
zzz
yes, that's right, mixKey after decaps
orignal
in NTCP2 you encrypt MLKEM with ChachaPoly
orignal
in SSU2 with chacha only
zzz
no. if the specs say that it's wrong
zzz
it's exactly the same
zzz
that's why there's only one 'Noise Handshake KDF' section in the proposal, it applies to both
orignal
ChaCha20 encrypted data (MLKEM)
orignal
not clear if it's ChaCha20 or ChaCha20/Poly1305
zzz
yup, I'll fix it, thanks
orignal
"Current SSU2 contains only the block data in the ChaCha section. With ML-KEM, the ChaCha section will also contain the encrypted PQ public key."
orignal
This is in the specs
zzz
that's not right either
zzz
maybe some of the fixes from the NTCP2 section didn't get into the SSU2 section
zzz
I'll go through it tomorrow and fix everything
orignal
no problem
orignal
same as in NTCP2 soundd enough
zzz
yeah but when copied from proposal to spec they go in two different specs
zzz
thanks for finding the problems