#i2p-dev (irc2p) | 2.10.0-3 | See important notes on zzz.i2p before updating

eyedeekay The go-i2cp library's about to get a lot more advanced...

orignal we will release this weekend

eyedeekay We're going tomorrow unless something else happens

eyedeekay zzz I've been running with the patch overnight and tried a few I2CP applications to see if it broke anything, I did not notice a problem but let me know if you're satisfied with the "soak time" so far.

eyedeekay It gave me a good reason to mess with go-i2cp more than I have, the only thing I used it for before was a presence test to see if I2P was running

zzz no calamaties overnight, all good here

zzz thanks for testing

eyedeekay Thanks for the patch

eyedeekay I'm going to get this show on the road in the next hour then

zzz super

zzz quick postmortem: Bad code, poor job of testing, compiler didn't catch, and one bug covered up the other

eyedeekay Thanks, btw question for after release: is there an implementation of an I2CP client library that is mostly feature-complete and preferably talks to the TCP port? go-i2cp is missing features and I need to make a checklist

zzz only ours, which is net.i2p.client.impl

zzz and whatever irc2pguest is up to

eyedeekay Works for me that's what I'll use

eyedeekay net.i2p.client.impl that is

zzz and ofc the msgs themselves are in net.i2p.data.i2cp

eyedeekay Release files are up on files.i2p-projekt.de

orignal I see usual high number of transit tunnels today

segfault zzz: you said me, ntcp2 a bit hard protocol, so i'll spend about 2 mounth before testing

segfault zzz: i start reading docs

segfault and ntcp2 use noise

segfault so, i can just use noice-c library, right?

segfault or will i do anything special?

segfault guys, also i have a terminology question. what are "static" and "ephemeral" keys?

segfault in noise protocol

eyedeekay Re: noise-c yeah probably you can, NTCP2 right now is basically done by preprocessing and post-processing standard noise interactions

zzz getting the su3 now to put on stats. eyedeekay I never got the 2.7.0 file ((( somewhere in the release process please ask me if I did it

eyedeekay sorry about that, announced this time, will keep announcing in the future. Re: fetching them you've got time, I've been refreshing tracker2 for a while so it won't be in the news until I get the torrent listed

zzz yeah not just announce but ask me if I did it, thanks

dr|z3d torrent won't be listed until you start it, eyedeekay...

eyedeekay I have to reach tracker2 to upload the torrent file

dr|z3d oh

dr|z3d I thought you meant you were refreshing the homepage to see if it got listed.

eyedeekay Nope, haven't been able to upload it yet

dr|z3d stop http client proxy, start..

dr|z3d you probably got rate limited.

eyedeekay Not the limiter, "destination unreachable"

dr|z3d works for me, instant.

zzz segfault, there are mods to the standard noise protocol, plus the data phase that's not specified by noise, our spec makes it all clear

zzz static keys are the permanent ones you publish in the netdb; ephemeral keys are one-time-use per-connection

zzz eyedeekay, maybe you told me last time and I forgot, dunno

eyedeekay Me either, regardless right now I'm working on getting the torrent out so that I can update the news

zzz it's a race now, place bets who's going to have NTCP2 working first, eyedeekay or segfault

segfault eyedeekay: zzz: thx

segfault eyedeekay: zzz: so, noice-c is not enough?

segfault zzz: i bet eyedeekay will be first, haha

segfault zzz: i hardly ever have free time for that

eyedeekay Not enough but most

zzz noise lib is a good starting point but not everything

segfault now i'm rtfm...

zzz 3rd section 'additions to the framework'

segfault "our spec makes it all clear" please, don't start implementation war. every developer say that his implementation is better

zzz haha. anyway, idk has a 3 year head start, but maybe he's stuck or distracted, you have a chance

orignal if I remeber NTCP2 is not standard noise

orignal like last round or something

zzz it's standard but with 'extras'

orignal but "standard" pretty much is MixKey and MixHash

zzz yup

orignal however someone here doesn't understand one thing

zzz just the padding and obfuscating X and Y are different

orignal you can't implement NTCP2 without signed own RouterInfo

zzz gotta start somewhere

orignal you could it with NTCP1

orignal but not with NTCP2

orignal someone should start with realistic tasks

orignal instead looking for a library "doing everything"

orignal RI includes identity, NTCP2 address with static key and signaure

zzz coming at some point, names subject to change

zzz Transport Type

zzz NTCP2PQ1 MLKEM512_X25519

zzz NTCP2PQ2 MLKEM768_X25519

zzz NTCP2PQ3 MLKEM1024_X25519

zzz SSU2PQ1 MLKEM512_X25519

zzz SSU2PQ2 MLKEM768_X25519

zzz or maybe not, may be able to do it with SSU2 options/flags

orignal are you talking DH?

zzz yeah hybrid DH

orignal what will be static key?

zzz X25519. MLKEM is ephemeral only

orignal longer X and Y?

zzz no

zzz MLKEM keys go in message 2 and 3 payloads

orignal then just a priprty

orignal of an address

zzz maybe, we could do SSU2 and SSU2PQ on the same port. But it's real hard to do NTCP2 and NTCP2PQ on the same port because we have no header or flags

zzz but I haven't thought about it too hard yet

zzz correction, the PQ keys are in messages 1 and 2

orignal run in on different ports, not a big deal for me

zzz here's the hybrid XK handshake. e1 and ekem1 ae the additions

zzz XK: XKhfs:

zzz <- s <- s

zzz Blinded message

zzz -> e, es, p -> e, es, e1, p

zzz <- e, ee, p <- e, ee, ekem1, p

zzz -> s, se -> s, se

zzz <- p <- p

zzz p -> p ->

zzz e1 = one-time ephemeral PQ key, sent from Alice to Bob

zzz ekem1 = the KEM ciphertext, sent from Bob to Alice

orignal woyld it fit MTU?

zzz SSU2PQ1 and SSU2PQ2 fit. There is no SSU2PQ3, it's too big, unless we completely rewrite SSU2 to fragment messages 1 and 2

orignal as exepected

zzz SSU2PQ2 is a little bigger than the minimum 1280 MTU though, so you can use it most of the time but not always

orignal 1280 is used too often

zzz pretty sure we'd start with the smallest one, MLKEM-512, it's probably good enough, especially as a hybrid

zzz Sizes, not including IP overhead:

zzz Type Type Code X len Msg 1 len Msg 1 Enc len Msg 1 Dec len PQ key len pl len

zzz X25519 4 32 80+pl 16+pl pl -- pl

zzz MLKEM512_X25519 5 32 880+pl 816+pl 800+pl 800 pl

zzz MLKEM768_X25519 6 32 1264+pl 1200+pl 1184+pl 1184 pl

zzz MLKEM1024_X25519 7 n/a too big

zzz that's for SSU2. Here it is again with better formatting

zzz Type Type Code X len Msg 1 len Msg 1 Enc len Msg 1 Dec len PQ key len pl len

zzz ================ ========= ===== ========= ============= ============= ========== =======

zzz X25519 4 32 80+pl 16+pl pl -- pl

zzz MLKEM512_X25519 5 32 880+pl 816+pl 800+pl 800 pl

zzz MLKEM768_X25519 6 32 1264+pl 1200+pl 1184+pl 1184 pl

zzz MLKEM1024_X25519 7 n/a too big

orignal when are we going to start implemnting this?

zzz dunno. I put a wild guess at the bottom of the proposal on various milestones from late 2025 - mid 2027

zzz but a lot of it isn't really that hard, we could go faster

orignal but do we even need to do it?

zzz don't know that either

orignal see

orignal eveybody understands x25519/EdDSA

orignal because it's faster

orignal and SHA1 is not strong anymore that why DSA must be replaced

zzz probably the most important one to do first is ratchet.

orignal but what the point of PQ?

orignal to be resistant against theritical machine?

zzz right. you've seen the charts on when X25519 will be broken. 2030? 2035? 2040?

orignal in my opinion not in our lives

orignal for me quantium computer is a hype

orignal to suck money

orignal same way as AI

zzz maybe. But NIST and Cloudflare say do it now. SSL already did it. I don't know what the right answer is

orignal because they are paid for telling this shit

orignal which ssl?

orignal not part of openssl yet

zzz you sure? it's in chrome and firefox. I'm looking for the reference

orignal chrome uses boringssl

orignal by google

zzz wolfssl has it wolfssl.com/support-for-the-official-post-quantum-standards-ml-kem-and-ml-dsa

orignal yes, but I'm talking about openssl/libressl

zzz yup. I was wrong, I thought they already had it

orignal boringssl has one

orignal if I start implemnting now I would take it from there

zzz it looks like support landed in openssl late last year github.com/openssl/openssl/pull/25938 github.com/openssl/openssl/issues/26006

zzz looks like they took it from boringssl

zzz no timeline as of last September: openssl-library.org/post/2024-09-17-post-quantum

zzz but now they're stuck on key formats, we don't really care openssl-library.org/post/2025-01-21-blog-positionandplans

orignal we will see

zzz ok, here it is, they'll have it in 3.5 scheduled for April 8. openssl-library.org/post/2025-02-04-release-announcement-3.5

zzz announced today

zzz good timing ))

orignal nice