@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+acetone
+dr|z3d
+hagen
+hk
+not_bob_afk
+orignal
+postman
+radakayot
An0nm0n
Arch
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest31001
Irc2PGuest59134
Irc2PGuest74564
Irc2PGuest81747
Irc2PGuest85953
Irc2PGuest96699
Leopold_
Nausicaa
Onn4l7h
Onn4|7h
Sisyphus
Sleepy_
SoniEx2
T3s|4_
Yotsu
anon4
b3t4f4c3__
bak83
boonst
cumlord
eyedeekay_bnc
l337s
onon_1
plap
poriori_
qend-irc2p
r3med1tz
rapidash
scottpedia
segfault
shiver_
solidx66
u5657_
uop23ip
w8rabbit
wodencafe2
x74a6
zzz
eyedeekay, you have a schedule resolution yet? I'm going to keep working until you tell me to stop...
zzz
eyedeekay, hk, ping re: "the task at hand" github.com/eyedeekay/go-i2p/commit/a5b3c3f194b391d54e792b87296009cf1c00ffe3
hk
hello zzz, Yeah we've finally gotten through the ephemeral obfuscation necessary for noise. And the next step really for us is to implement NTCP2
orignal
AES or elligator?
hk
right now I believe eyedeekay is working on NTCP2. For me personally I am combing through to create RouterInfos to implement a proper testnet to test out ntcp2
hk
orignal: AES
orignal
it's just for NTCP2
orignal
the real one is elligator
hk
hm
orignal
ephemerals are also used in ECIES
hk
I see
hk
these changes could be made as we go, but riht now we just needed some for of obfuscation according to the flynn noise protocol
hk
right*
hk
form*
orignal
if I was you AES would be the last thing to implemenmt for NTCP2
orignal
start with x25519 shared seccret calculation
hk
hm hm
hk
If I may ask, why is AES not ideal?
orignal
you ephemral must be agreed with remote static key
hk
right
orignal
AES is tiny piece of the protocol
orignal
the only reason why it's there becuase zzz didn't want to implement complete elligator
hk
so AES could work for now, but if it were up to you you would deprecate aes in favor for elligator would you still keep it open as an option?
orignal
no
hk
and would you still keep it*
hk
hm
orignal
no reason to reaplce AES by elligator there
orignal
my point AES is not the main thing in NTCP2 protocol
hk
right it's just a small part of it
hk
sorry im still trying to understand it all, im still very new and learning
orignal
you need to implemnet x25519, HKDF and AEAD/Chaha20/Poly1305
orignal
do you have all these crypto ready?
orignal
also forgot SipHash
orignal
with non-stanradrd size
hk
If im understanding correctly, I dont think we have any of those ready at this time
hk
let me get you a list of what we have
hk
thank you for trying to help btw
hk
We have, aes-cbc, curve25519, dsa, ecdsa, ed25519, eglamal, hmac and rsa
hk
some of these aren't complete though
hk
need to work on that
hk
a few really
orignal
you need x25519 not EdDSA
orignal
differnt thing
orignal
although they both based on curve25519
orignal
x25519 uses different form of it
hk
ahh gotcha
orignal
so, you need more modern crypto
hk
we'll definitely put it on the roadmap then for the future
zzz
hk, y'all aren't in a position to be proposing protocol modifications atm ))
orignal
you can implemet HKDF though HMAC
hk
understood
orignal
zzz, if I understand he is trying to implement NTCP2
zzz
spec clarifications, fine, but for actual (incompatible) changes, keep a list and come back to us when you're done
hk
understood, thank you zzz. I think I'm a little confused so I apologize, I'll be more clear next time.
zzz
no need for sorry, it's fine
hk
yeah this is a great learning experience :)
zzz
btw are you the original hkparker, or just a nick coincidence?
hk
zzz: ahahah nope that is just a coincidence
orignal
or hong-kong guy ))
zzz
ok, good to know
hk
nah im not from hong kong :P
zzz
anyway I don't like any of your 4 options but I'll await idk's appearance to explai
hk
fair enough :)
dr|z3d
another XG/tunnels: hdsZ1DIgi~AMYbQ8q~6euPj9MadfEvy4L~o~ZcUN-3g=
eyedeekay
Sorry I was on the road today, re: schedule keep going for now zzz, I'm thinking first week February if everything holds, so you've got plenty of time
eyedeekay
as hk mentioned we're working through the remaining stuff we need to get NTCP2 done, we've actually advanced slightly from that comment section now
eyedeekay
Some of the packages we have don't have everything we need yet but we have enough noise and NTCP2 done now to see the holes
eyedeekay
Our x25519 is going to mostly come from SmallStep's x25519 implementation BTW
eyedeekay
That's why hk missed it, their interface actually matches ours, we don't need to touch it
zzz
eyedeekay, re: schedule, that's a little long, but as you wish, and would be nice if you got agreement w/ i2pd so I can firm up my plans
zzz
re: the task at hand eyedeekay
zzz
I suggest some tweaks
zzz
for one, there's 4 noise protocols required (eventually)... ignore SSU2/ratchet/tunnels for now, don't try to design a perfect API that captures all of them
zzz
but even for ntcp2, your 4 paths are all overly complex
zzz
we made almost no changes to our noise lib.
zzz
and it's better that way
zzz
think of it like this
zzz
almost all the obfuscation stuff should be done by preprocessing the input packets (to remove the nonstandard obfuscation) and postprocessing the output packets (to add it)
eyedeekay
Right now we are very focused on NTCP2 indeed
eyedeekay
Re: mods to the noise library, we're not actually talking about mods to flynn/noise here, we actually do 0 changes to it, our internal lib/transport/noise is actually our interface to do the mods on top of flynn/noise
eyedeekay
so we're not changing the noise implementation itself, just wrapping it in our own interface to let us do the preprocessing
eyedeekay
It's a little confusing because the parent library and the internal library have the same name, noise, but flynn/noise is the actual noise implementation, lib/transport/noise is the framework for modding it
zzz
ok that makes a little more sense
zzz
but the wrapper stuff is very protocol-specific
zzz
basically what you need to do is the equivalent of Inbound/OutboundEstablishState, which I'm sure you've been peeking at
eyedeekay
Yeah it does seem like coming up with a perfect API is futile
eyedeekay
But I'm pretty pleased with our wrapper so far, maybe we have to change how we do the mods when we get to the other protocols but it's working well for NTCP2 so far
zzz
yeah point is your wrapper will be VERY protocol-specific, don't spend any brainpower trying to make it generic for the other 3 protocols you haven't even looked at yet