#i2p-dev (irc2p) | 2.8.2-4 | ACTION REQUIRED git.idk.i2p account deletion http://i2pforum.i2p/viewtopic.php?t=1312 | Upcoming reviews Tuesdays 7 PM UTC #ls2: prop. 169 Apr. 22

orignal I tested with this test vectors github.com/openssl/openssl/blob/master/test/ml_dsa.inc#L1830

eyedeekay Sorry got distracted for a moment but yes zzz I do have a deduplication plan, so right now we've got goSam which is very convenient but lacks features and sam3 which is very feature-rich but suffers from code quality issues, go-sam-go is a refactor of sam3 to improve it and fix the code quality issues, at which point goSam and sam3 become consumers of go-sam-go

eyedeekay that way I deal with my code quality issues, unify on a single go SAMv3 library, and goSam and sam3 can present the same APIs that people are already used to

eyedeekay then the hierarchy of go sam libraries becomes(from low level to high level) go-sam-go->goSam/sam3->onramp->go-i2p-bt/go-i2ptunnel/go-i2p-smtp

eyedeekay ofc the way to remove the redundant mini SAM library from i2pkeys is to migrate it to go-i2p, which will be possible soon

zzz last call for translations, pulling in ~ 6 hours

zzz orignal, did you prepend my leaseset with the 0x03 type byte before verifying?

orignal no, I just took public keys 0-383, 391- and last bytes as signature

orignal please tell me how should I do it properly

orignal oh got it

orignal just msg to verify

orignal lemme try

zzz yeah I'll add a note to the zzz.i2p post

zzz I haven't tried any vectors yet

orignal vectors?

zzz MLDSA test vectors

orignal oh you mean test vector

orignal it worth to try

zzz no time yet, busy updating the proposal almost every day

orignal to make sure that all implemntations are the same

zzz ofc

orignal as you can see they refer to some other code

zzz one other thing I discovered in FIPS 204: "hedged" vs. "deterministic"

zzz they say default should be "hedged" (randomized), so every sig is different

zzz but the bouncycastle default seems to be deterministic and their configuration for hedged seems to be broken

orignal yes, that's what my initial issue

zzz you should check what openssl does

orignal I didn't verify it properly

orignal hence my sign/verify worked but test vectors didn't

orignal I have to change verification params

orignal in openss it's up to you

orignal how you specify

zzz the "hedged" thing is on the signing side

orignal right but when I tried this setting on verfication side it failed on test vectors

zzz yeah don't set it for verify

orignal so what we do for signing?

zzz you want to configure it for 'hedged' or randomized, not deterministic

zzz unless you're doing test vectors ofc

orignal I want to make it the same way as you

zzz I think I'm going to have to file an issue with bouncycastle, checking now if there is one or it's already fixed

orignal still failed even with 3

zzz rats

orignal need to investigate deeper

orignal maybe another my issue

zzz it will be a while for me, we're doing a release on monday and the review on tuesday

orignal take your time

zzz yup

zzz oh I see how to do configure the hedged version in bouncycastle.

zzz glad I figured it out before I opened a stupid issue and got mocked

zzz eyedeekay, re: go-i2p, thanks for the followup info

orignal zzz, looks like signing params matter

orignal and they must be the same for verifier

orignal my observation

orignal because if they are different sign/verify fails

zzz ok thanks will keep an eye open. ofc the bouncycastle java APIs are a lot different from openssl

zzz but could be an issue

orignal that's why it would be nice if you try openss;'s test vectors or give me bouncycastle's

orignal there is also some param for entropy

orignal *p++ = OSSL_PARAM_construct_int(OSSL_SIGNATURE_PARAM_DETERMINISTIC, &deterministic);

orignal *p++ = OSSL_PARAM_construct_int(OSSL_SIGNATURE_PARAM_MESSAGE_ENCODING, &encode);

orignal if (td->add_random != NULL)

orignal *p++ = OSSL_PARAM_construct_octet_string(OSSL_SIGNATURE_PARAM_TEST_ENTROPY,

orignal (char *)td->add_random,

orignal td->add_random_len);

orignal not sure what's this

zzz that's the 'hedged' randomization I was talking about.

zzz see FIPS 204 section 3.4

orignal we agreed to use "hedged", right?

orignal are we going to use randmization?

zzz yes, that's the recommendation in section 3.4

zzz adding it to the proposal now

orignal how long?

zzz huh?

orignal random is byte array

zzz don't know, not an option in bouncycastle, see what FIPS 204 says

orignal 32 bytes

zzz ok

zzz gotta run, back in an hour

orignal "test-entropy" (OSSL_SIGNATURE_PARAM_TEST_ENTROPY) <octet string>

orignal Used for testing to pass an optional deterministic per message random value. If set the size must be 32 bytes.

orignal how about encoding? do you use it?

orignal zzz, finally I was able to verify your LS

orignal I had to turn on encoding

zzz w00t

orignal finally

zzz Section 3.4 says that hedged and deterministic are compatible. My test files are deterministic right now

orignal you should mentioned in propoasl that

orignal you use Pure ML-DSA

zzz ok

zzz yes, not Hashed (prehash)

orignal The normal signing process (called Pure ML-DSA Signature Generation) encodes the message internally as 0x00 || len(ctx) || ctx || message. where ctx is some optional value of size 0x00..0xFF. This process is defined in FIPS 204 Algorithm 2 step 10 and Algorithm 3 step 5.

zzz ok

orignal it's not about hash

orignal it's about encoding

orignal e.g. addding some prefix

zzz ok, I got it

orignal but OpenSSL's test vectors are without encoding

zzz what are you quoting?

orignal docs.openssl.org/master/man7/EVP_SIGNATURE-ML-DSA/#description

zzz thanks

zzz test vectors may also require you use deterministic mode, depending on how they work

zzz getting a little smarter every day ))

orignal github.com/openssl/openssl/blob/master/test/ml_dsa_test.c

orignal see how they sign and verify test vectors

zzz and we're not using any optional context

orignal it matters if you add 0x00 or not

orignal and len(ctx)=0

orignal so, I can only verify you signature is encoding is on

zzz yes, len(ctx) == 0

orignal so two leading zeros

zzz eyedeekay, orignal, please review this bitcoin PR from vasild github.com/bitcoin/bitcoin/pull/32065

zzz he says it was eyedeekay's idea

orignal btw, if we are a talking about SAM

orignal someone said that Java's SAM doesn't reject session with same id

orignal is it true?

zzz don't know, ask 'someone' to create an issue

orignal the complain was

orignal "iMule doesn't work with i2pd but works withh Java"

orignal because it keeps trying to created session with same id

orignal i2pd declines them, Java doesn't

orignal my question is

orignal maybe I missed something in the logic?

eyedeekay Holy moley that was a long time ago

eyedeekay OK I will get on it

eyedeekay FWIW I definitely see Java I2P declining duplicate session ID's all the time

zzz if ( map.containsKey(nick) ) {

zzz throw new ExistingIdException();

orignal then nevemind

zzz don't know what imule does, thought it was long-dead

orignal me too

zzz eyedeekay, my first thought is that 10 standby sessions seems like a lot, except maybe at startup?

orignal but guys still use it

eyedeekay Same thought here, 10 seems like probably too many

zzz did you bump into vasild in person somewhere? don't recall you discussing this in a ticket anywhere

orignal is he russian or bulgarian?

zzz FYI I also recently pinged jon atack about reviewing vasild's big PR from last year about transactions

zzz maybe BG? can't remember

orignal what is hybrid signature?

eyedeekay It was quite a while ago in one of our first exchanges via email, I think he was talking about this same concern he had with the setup time and I suggested he could maintain a small pool of connections prior to actually needing them

eyedeekay But it was so long ago I assumed he had made peace with it

eyedeekay BG IIRC

eyedeekay re: imule somebody, maybe marek? got it to compile with a new version of the QT toolkit last year, never heard anything else about it

orignal two signatures together or what?

zzz yes orignal just concatenate two sigs, verify both

orignal what's the point?

orignal or I can verify any of them?

zzz that's the easiest way to do hybrid

orignal I don't understand what do you need hybrid signature for

zzz see the COMPOSITE-SIGS reference, that's what I based it on

zzz it's the same reason people are using hybrid in other places - you have two algorithms, in case one of them is broken

orignal it's about x509 but why do we need in i2p?

zzz maybe we do, maybe we don't, we can talk about it

orignal I'm trying to get prepared for the meeting ))

zzz but MLDSA-44 is probably too weak to use by itself

zzz MLDSA-65 is huge

zzz so MLDSA-44 + Ed25519 may be the best choice?

orignal my question

orignal why hybrid signture have lower numbers then regular ML-DSA

zzz numbers?

zzz oh, sig types

zzz I flipped a coin on which went first, if it bothers you we can change it

orignal MLDSA44_EdDSA_SHA512_Ed25519 12

orignal MLDSA44 15

orignal more logical to have mldsa first

zzz but one thing for sure, we're probably not using MLDSA-44 except for testing, it's security level 1

orignal no, I don't understand why MLDSA-44 + Ed25519 is the best choice

orignal if post-qutum computer can break Ed25519 and ML-DSA-44 is weak

orignal *post-quantium

zzz but it still might be twice the work to break them

orignal only twice is nothing

zzz true. point is, we're not smart enough to pick the "best" right now. I defined a bunch of choices so we can do experiments and more research

zzz there's a lot of info out there about MLKEM stuff. MLDSA is a lot harder to get good guidance about

orignal in my opinion we need to pick strong ML-DSA if EdDSA is considered not-strong for post-quntum computers

orignal e.g use EdDSA while no post-quntum computer yet

orignal and then ML-DSA

orignal for me hybrid in general is something ugly

zzz everybody is doing MLKEM hybrid, that's the only way you can do it. Harder to find out who is doing what with MLDSA, it's very early.

orignal everybody is doing for x.509

orignal i2p doesn't use x.509

zzz We may not need to pick which MLDSA flavor for another year or two, I don't think it's as much of an "emergency" as MLKEM

orignal fine. MLKEM is the next step

zzz we have x.509 certs for su3 files, so if we do PQ sigs for reseed, then we would need it

zzz but we're using 4096 RSA for reseed, it's not going to be broken for a LONG time.

zzz so for the review I want to discuss 'Is the "best" choice on the list here somewhere, even if we don't know which one right now'

zzz not pick the 'best' one now

orignal for my side I'm not going to implement hybrids for now

orignal for signatures

zzz that's fine

zzz the other thing about MLDSA is we have to wait until the floodfills support it. MLKEM ratchet we can do today, and I've already done some testing

orignal not necessary

orignal you can start with client leasesets

zzz true, and I have successfully tested that on the live net end-to-end

zzz I'm a few days away from finishing MLKEM testing on the live net

orignal nice

orignal and I will start shrtly

zzz unit test really helps for MLKEM, I updated mine from back when we did ratchet. I had about 100 bugs, would have taken me forever without it

zzz translations pulled and checked in, please review release diff by Monday 4 PM UTC

zzz Console news pushed to transifex, translators please update, your deadline is 5 PM UTC Monday

zzz eyedeekay, I don't see the 2.8.0 bundle entries in newsxml, did you forget to push those?

eyedeekay Yup, pushed just now

eyedeekay sorry about that

zzz nobody died ))

zzz however, I just pulled and nothing new, please double-check

eyedeekay There it goes, had to pull in the remote first

zzz thx

zzz and i2p.android.base? iirc you were going to merge your branch in a couple nights ago?

zzz if anybody sees this CVE that popped up yesterday against str4d's ed25519 lib cve.org/CVERecord?id=CVE-2020-36843

zzz we fixed it in 2019 in our code. He never did over in his repo afaik

zzz in case somebody squawks about it

eyedeekay Big branch merge is in on i2p.android.base, migrates the whole thing over to androidX and MagicIndicator

zzz same story, different branch; just pulled, nothing new since nov. 26

eyedeekay I'm checking, should be: 7e5fd42

zzz nope. I have 554a6 in i2p-android-2.8.0-androidx from March 10, and 5fac82 from Nov. 26 in master

eyedeekay Something weird here, the PR where I merged it says that should be the checkin but when I clone it afresh I see the same thing as you

eyedeekay I'm going to merge it here locally and push

eyedeekay There, you should be able to see it now, bf2dea5-61010b2, most of which is rote replacement of support libraries with AndroidX libraries

zzz got it

zzz best to double-check on gitlab web if you're doing something fancy like merging

zzz so what's still todo for a 2.8.0 android release?

eyedeekay There's something wrong with the tunnel display, sometimes it shows up, sometimes it does not, pretty sure it has something to do with how I'm setting things up in one of these onCreate* functions. Once I fix that it's 100%, every bug I know about is squashed again

zzz ok, keep at it this weekend, because next week you gotta do the 2.8.1 bundle

eyedeekay Ack, yeah it would be good to get this knocked out today if I can

eyedeekay There are no errors in the log in either case(display shows up or not) which is frustrating, I've got some logging added around the likely areas

zzz if you get that far, don't forget to pull translations and all the other checklist stuff

eyedeekay Ack will do

zzz good luck ))

zzz for your time planning next couple of weeks, I already have a few 2.9.0 MRs up and plenty more to follow

eyedeekay I'll try to get on them ahead of the 2.8.1 release

zzz no no, wait until after

eyedeekay OK

zzz we also have the 2.8.1 review this weekend, it's 6135 lines, pretty big for a point release

eyedeekay Yeah you're right there's plenty going on right now

zzz is the android tunnel issue only at startup, or anytime? TunnelControllerGroup takes a while to get going. If you need any help, holler

eyedeekay It's anytime, I think I'm closing in on it, it has something to do with the indicator migration stuff I did

eyedeekay one of the methods that updates the detail_fragment isn't being set up correctly

zzz ok

eyedeekay Fixed in landscape mode but not in portrait mode...