+RN_
+orignal
+postman
+qend-irc2p
+sourceress
Birdy
Daddy_I2P_
Irc2PGuest30010
Irc2PGuest36077
Onn4l7h
Over
Sleepy
T3s|4
Teeed
Yotsu
aargh3
ac9f
acetone_
b3t4f4c3__
duanin2
f00b4r_
hagen_
leopold
leopold_
makoto
marek
marek22k
not_bob_afk2
nyaa2pguy
o3d3_
poriori
profetikla
r00tobo
rapidash
solidx66
test7363673
urist_
orignal
zzz, NTCP2-PQ
orignal
do we apply MixHash after ML-KEM block
orignal
?
zzz
orignal, whatever we did for IK
orignal
wait
orignal
for NTCP2 there is no MixHash after options block
orignal
it's different than for ratchets
zzz
hmm
orignal
never mind
orignal
you apply it not after KDF1 but before KDF2
zzz
prop. 169 'Alice KDF for Message 1'
orignal
let me check
zzz
or see the Trevor Perrin reference Noise-Hybrid
orignal
see my point
zzz
both e1 and ekem1 patterns are EncryptAndHash
orignal
NTCP2 specs mentions MixHash in KDF2
orignal
not KDF1
zzz
looking...
orignal
it's fine if you have only one frame
orignal
but consuusing in case of 2 frame
orignal
if we apply this MixHash in KDF1 or not
zzz
yeah I see. We're smarter now than we were in 2018 )) We wanted to "unroll" the noise spec so we all understood it
zzz
so yeah I see your point
orignal
we shouk change the specs to hace MixHash as last opreation
orignal
so we appply MixHash of ML-KEM, right?
zzz
that mixhash in kdf2 is for the payload
zzz
so we're adding a mixhash for the PQ section, that's part of EncryptAndHash()
orignal
not really
orignal
you apply MixHash after ML-KEM frame
orignal
then use it for tag of options frame
orignal
you can't just apply it in KDF2
zzz
there's X, then the PQ frame, mixhash, mixkey, then the optinos frame, mixhash, then the padding, mixhash
orignal
right
orignal
expept no enncrytion for paddig
orignal
also I don't see MixHash after options
zzz
the only change in my noise code is the initializers and the patterns
orignal
do you unserstand?
orignal
we aplly MixHash only with whole message
orignal
no MixHash after options block
orignal
please double check
zzz
yeah you're right
zzz
// take h saved from message 1 KDF
zzz
/ MixHash(ciphertext)
zzz
h = SHA256(h || 32 byte encrypted payload from message 1)
orignal
then we must agree that also no MixHash after ML-KEM
orignal
of after noth ML-KEM and options
zzz
no, see the Perrin spec. The e1 pattern is EncryptAndHash(). The PQ key is another key, it's not part of the payload.
zzz
-> e, es, e1, p
zzz
<- e, ee, ekem1, p
orignal
so tell me what I do?
zzz
in between es and p, do e1, which is encryptAndHash(). The mixHash() after the payload is over 32 bytes (16 byte options and 16 byte mac), same as regular NTCP2, no change
orignal
do I add MixHash after ML-KEM frame encryption?
zzz
right. you do EncryptAndHash(KEM key) and then EncryptAndHash(options)
orignal
so if I'm PQ I MixHash options and no MixHash if not PQ. Right?
zzz
where EncryptAndHash(d) = [ciphertext = AEAD(d) and then mixHash(ciphertext)
orignal
please clarify
zzz
no. We always did MixHash(options), but as you said, in the spec, it's at the start of KDF2. But the payload is always EncryptAndHash()
orignal
2 MixHash if PQ and no MixHash for options in non-PQ
orignal
no
orignal
KDF2 is MixHash with padding
orignal
of whole message
orignal
I'm asking about options block now
zzz
2 mixhash if PQ (1 for PQ block and 1 for options block). 1 mixhash if non-PQ
zzz
the "whole message" mixhash is only the options block (the payload)
zzz
32 bytes
orignal
nover mind see it
orignal
it's just mess in specs
orignal
all we need is MixHash after options encryption
zzz
KDF2 in the spec shows two MixHashes. One for the msg 1 payload and one for the msg 1 padding
zzz
yeah. the ntcp2 spec is confusing now that we know what we're doing ))
orignal
right I see now
zzz
anyway, same change as for IK. Just stick in a new PQ block, do an encryptAndHash() on that block, done.
orignal
fine
orignal
no want to talk about padding size
orignal
I think we should make padding to make SessionRequest of type 2 up to minimal size of type 3
orignal
same betweeb 3 and 4 and 4 and 5
zzz
but if the whole network goes to 4 except for old routers, that doesn't help much
zzz
we would have large padding in one direction but small padding in the other
orignal
do large padding in oopiste deirection too
orignal
the whole idea is ditribution between msg sizes
zzz
I'm saying one new router and one old router version 2 handshake. For new routers on both sides, they'll be using version 4
orignal
also I'm going to do it optional
orignal
e.g. if v=4 if doesn't mean I will connect with PQ even if I supprt
orignal
why version 4?
orignal
it should be configurable
zzz
sure, but just like for ratchet, MLKEM 768 is probably the right choice
orignal
it's not like racthets
orignal
because you have to think how to hide your traffic
zzz
sure, different threat model
orignal
that's why I want to disctruter sescion request packet size without spikes
zzz
maybe we should invent in-between flavors MLKEM 896 and MLKEM 1280
orignal
what for?
orignal
for me only matter is padding size now
orignal
I can only use types in openssl now
zzz
I'm open to changing the padding, the question is threat model, whats the RU and china firewalls and DPI doing these days. I have no idea
zzz
stormy just found an old chinese patent for NTCP 1 identification
orignal
ofc, first message had fixed size
StormyCloud
speak of the devil, looks like GFW had a leak almost 600gb in size. gfw.report/blog/geedge_and_mesa_leak/en