IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2024/11/05
@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+acetone
+dr|z3d
+hk
+orignal
+postman
+weko
+wodencafe
An0nm0n
Arch
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest21357
Irc2PGuest21881
Irc2PGuest43426
Leopold
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4_
aargh2
anon2
b3t4f4c3
bak83
boonst
cancername
cumlord
dr4wd3
eyedeekay_bnc
hagen_
khb
not_bob_afk
plap
poriori_
profetikla
r3med1tz
rapidash
shiver_
solidx66
tr
u5657
uop23ip
w8rabbit
x74a6
zzz eyedeekay, you have a schedule resolution yet? I'm going to keep working until you tell me to stop...
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?
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