@eyedeekay
&zzz
+FreefallHeavens
+R4SAS
+RN
+ReturningNovice
+StormyCloud
+T3s|4
+acetone
+cims
+eche|off
+fa
+mareki2p
+nilbog
+orignal
+postman
+psychopuck
+qend-irc2p
+rednode
+snex
+wodencafe
Arch
Danny
Irc2PGuest28384
Irc2PGuest66257
Irc2PGuest75631
Irc2PGuest81267
Onn4l7h
Onn4|7h
Over
Sisyphus_
Sleepy
T3s|4_
U1F642
Watson
Zapek
aargh4
ahiru
ananas
anontor
calamares
dr4wd3
dr|z3d_
duanin2
i2potus
ice_juice
justaperson
luvme
mahlay
makoto
marek22k
n2_
not_bob_afk
onon_
pinotto
poriori
profetikla
r00tobo
rapidash
test7363673
uop23ip
w8rabbit
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