#i2p-dev (irc2p) | 2.8.2-6

orignal zzz, crypto type 5 works between both my sides

orignal when do you have time to test interoperability?

RN theoddone, aka Irc2PGuest67686 ask your question here... more devs that should know what you mean

theoddone Have a question about repliable datagrams and i2cp...

theoddone SendMessageMessage's payload is an integer + payload length - geti2p.net/spec/i2cp#payload

theoddone A repliable datagram includes the from "destination", but it can be variable length - geti2p.net/spec/datagrams#repliable-datagrams

theoddone I assume that the length of the payload in SendMessageMessage is the full payload after gzip, so I'm not sure how to parse out the destination on the receiving end.

RN you should get a more informed response here

RN :)

RN eventually

theoddone 🤞

eyedeekay Well I haven't done this yet but I'm up late again and I'll try to figure it out. Seems like there is probably a length to look for somewhere in the process...

theoddone I'm hardcoding 387 for the destination length for now so that I can push forward

theoddone oh, it's in the destination itself... the destination can be variable, but the last bit is a certificate that includes a length for the variable bits

theoddone geti2p.net/spec/common-structures#type-certificate

eyedeekay I thought it would be something like that

eyedeekay rang a bell in lib/common/destination

eyedeekay Good job figuring it out, I'll still be here for a few more hours

eyedeekay If you have any more questions

zzz orignal, gjhe5vodfvn5s5y34ikrpyv2wj35pva4ihtu6oyajta55hmxxeta.b32.i2p

zzz the rest of you should see 'unsupported crypto'

orignal thanks. will try later today

zzz altonen, can't build on latest ubuntu anymore after your recent updates

zzz error: rustc 1.80.1 is not supported by the following package:

zzz home@0.5.11 requires rustc 1.81

zzz plucky has 1.84 which will be out in a couple weeks. but all the LTSes are on 1.75

altonen i'll downgrade it, ty for reporting

dr|z3d rustup.

orignal zzz, tried to connect please check

orignal on yor side

zzz did it work?

orignal no

orignal no reply from you

orignal I see leaseet and able to send

orignal I'm wondering which block failed

zzz didn't see anything at the warn log level, I just switched to debug, try again

orignal tried

zzz got a failure, stand by

zzz ok I got two packets, one at 8:29:51 and one at 8:30:00, which one you want the logs for

orignal 8:29

orignal first one

zzz ok here's the ck and h before I load the packet

zzz 04/06 14:29:51.556 DEBUG [P reader 4/4] crypto.ratchet.ECIESAEADEngine: State before decrypt new session: IKhfs512 READ_MESSAGE Handshake State:

zzz Symmetric State:

zzz ck: sI-xc5JmyZBFf93GTlVA2Ao3mQaSKnjEse-GBtAVn00=

zzz h: ByRjKS6-z3lhB8E6JZuBvJG~KbGFJj~ZUoy4DszlBcw=

zzz here's the state at failure

zzz 04/06 14:29:51.557 DEBUG [P reader 4/4] crypto.ratchet.ECIESAEADEngine: Decrypt fail NS, state at failure: IKhfs512 FAILED Handshake State:

zzz Symmetric State:

zzz ck: tWXGGKF5IDokXjlgQi8rxaTo9OdnQ01IaMuxwqQAWCo=

zzz h: SFhlgkDKJDB5nQa0jCYhe-8TnxgdfYYcHU~9PdQlzr8=

zzz Cipher State:

zzz nonce: 0

orignal which block failed?

orignal let's start from here

zzz poly key: xk8QEqh89CZmaCo4YrQo8iyd7X4j8pZythhEgMGEEjw=

zzz Local static public key (s) : yX9UiX-WraVaHMyKB19xwSX0oOjI8bNf9uLNA-kS21w=

zzz Remote static public key (rs) : ndJ92uFi-b2T9BDiuRh252-hJmrqNRRJ~SQLPSMRbTM=

zzz Local ephemeral public key (e) : null

zzz Remote ephemeral public key (re) : Qtmd-Mriqi9juV4vNJAjkvwpdB3OE7aLshOT4oPE7Co=

zzz Local hybrid public key (e1/ekem1) : null

zzz Remote hybrid public key (e1/ekem1) : 800 bytes zQWM9eRG9YA1BrpK8nR1F4ObwyErQcK.....

zzz I;ll tell you which part it failed on in a minute

zzz actually give me 15 minutes

orignal take your time

orignal we use Noise_IKhfselg2_25519+MLKEM512_ChaChaPoly_SHA256 right?

zzz ok, good news, it got your e1 and s, please check the values above. It failed on the payload.

zzz everything is good until the payload

orignal thanks. will check

orignal maybe payload length ?

zzz could be

orignal are you able to print it out?

zzz the full state including ck, h, n, and poly key are above

orignal I don't think the issue with keys since no difference from 4 in that code

orignal I would rather check length

zzz sorry don't have length in the logs atm, I could add it and we could retest later

orignal yes, please

orignal let's do aftrennon or tommorow

zzz please compare e1, s, ck, h, n, polykey with above

zzz please confirm you've tested to yourself on the live net

zzz because there shouldn't be a length issue if you have

orignal yes I did on the live net

orignal yesterday

orignal 3m4w4que5ep4tgfvhyfmmzgpbjxf2v7tlrpagzyvolx7fshjf2xa.b32.i2p

orignal connects fine with 5

zzz so then it can't be length issues, it must be a KDF issue

orignal but static key is fine

zzz yup, so verify ck/h/n/polykey from above just before payload decrypt

orignal if new MK-KEM block was wrong it wouldn't decrypt static key

zzz true

zzz so tell me what doesn't match from above: ck/h/n/poly/e/e1/s/rs

orignal I didn't log at that point

orignal need to add more loggng first

orignal have you tried to hit mine to see how it works in oppiste direction?

zzz just tried it, got LS, no response

orignal I decrypted it right

orignal 11:26:08@608/debug - Garlic: Block type 0 of size 4

orignal 11:26:08@608/debug - Garlic: Datetime

orignal 11:26:08@608/debug - Garlic: Block type 11 of size 883

orignal 11:26:08@608/debug - Garlic: Type local

orignal I guess it's you ls

zzz I see your server is 4,5. What is your client? When you tested with yourself are you sure it used 5?

orignal my client is 5 only

zzz ok

zzz mine too

orignal what time did you try to connect?

orignal yes, server is 4,5

zzz 11:23:56

orignal sec

orignal 11:23:57@128/warn - Garlic: Payload section AEAD verification failed

orignal same story. failed payload

zzz yup

orignal will add more logiing and invertigate later afternoon

zzz ok, shouldn't be too hard to find, could be my problem, could be yours

orignal will print keys and lentgh

orignal we will see

zzz we've done this so many times before....

orignal yes, but the next step will be encaps/decaps

zzz happy we got this far the first time

orignal still not sure if they are compatible

orignal me too

zzz altonen and eyedeekay must be having flashbacks ))

eyedeekay no kidding

zzz lol

zzz hey eyedeekay please turn your attention to my remaining MRs, this is a short cycle

eyedeekay Oh right yeah, sorry got into it with go-i2p and sorta lost track of time, thanks for reminding me

eyedeekay Will switch modes

zzz great. are android and bundle done?

eyedeekay Bundle is, Android is in hurry-up-and-wait but shouldn't be much longer

eyedeekay Gplay

zzz nice

eyedeekay Comparatively routine yeah

eyedeekay gonna make sure the news made it to all the gits real quick while I'm thinking about it

zzz orignal, maybe found it

zzz check what your n is when encrypting payload

zzz should be zero

zzz the mixKey(sharedSecret) just before it means your n / nonce must get reset to 0, by definition

zzz mixKey() always updates chachakey and sets chacha n to 0

zzz for non-PQ it's already 0, but for PQ it's 1 and you have to reset it to 0

orignal zzz what nonce do we use for payload?

orignal yes, I though too

orignal will try'

zzz your code is a little fragile because mixKey() doesn't automatically set the nonce to zero

orignal I know

orignal because nonce it something extrenal

orignal need to rewrite

orignal finanlly got stats.i2p )))

orignal you turn, sir

orignal <orignal> finanlly got stats.i2p )))

orignal <orignal> you turn, sir

zzz woo, congrats

zzz stand by...

orignal 6jq3rwjbatucl2hwdq7q64kitlodp6uvy2s4bjrufmf27tptzgwq

orignal right? ))

zzz yes

zzz checking logs, stand by...

zzz I got a NSR back and hit some internal error while decrypting it

zzz not sure why

orignal got it

orignal I don't know if you were able to open or not

orignal I only see your LS

zzz pretty sure it's my problem, probably won't fix today

zzz good job, great progress

orignal absolutely

orignal could you remind why we use nonce=1 if static key is zero?

orignal great that encaps/decaps works properly between diffrent libraries

zzz whenever you encrypt/decrypt, you should do nonce++, so if you do it again with the same key, the nonce is different.

zzz except if you then do mixKey(), which resets the nonce

orignal thanks. will rewite state

zzz yeah, if your encrypt/decrypt have state, then you can autoincrement

orignal then I will move encrypt/decrypt to state first ))

zzz but only autoincrement on success, not failure... according to the noise spec... I just fixed that

orignal you know, initially I even didn't have MixKey and MixHash explicitly

orignal just called HKDF or Agree

orignal btw, what do you think to use encaps/decaps also with RSA?

orignal pleeeese

orignal *** tired from disconnects ***

zzz hybrid su3 sigs? it's in prop. 169... but... RSA-4096 isn't going to be broken for a lonnnnnng time, no rush

orignal no

orignal in rachets

orignal encaps/decaps over RSA instead ML-KEM

zzz I'm confused, but my brain isn't at 100% atm

orignal ecapcs/decaps operation exist not only for PQ but also for RSA

zzz not familiar

orignal I'm telling you

orignal for example opennssl examples are for RSA

zzz will have to research ))

orignal docs.openssl.org/master/man3/EVP_PKEY_encapsulate/#examples

orignal so we use the same schema as for ML-KEM but for RSA