#ls2 (irc2p) | #ls2 proposal review channel : Reviews Tuesdays 7 PM UTC: none scheduled

zzz Reminder: Proposal 169 3rd review today 7 PM UTC here

zzz If you're here for the meeting, please say hi, even if you're just planning to lurk ))

orignal hi

Leopold HI ><

altonen hi

orignal glory to ukraine ))

eyedeekay Hi

zzz slava, etc. etc.

orignal he should answer "heroyam slava"

zzz ok

zzz 0) Hi

zzz we are here for the 3rd review of proposal 169

orignal Bandera's slogan

orignal PQ, right?

zzz I'll give a brief summary of where we are at, and what I'd like to accomplish today

zzz our last review was April 22

zzz we took some time off for trips to Bora Bora )) and hash research

zzz I'd like to come to a decision on the hash function, and if possible approve the ratchet part of the proposal today

zzz so with that, I'll turn it over to eyedeekay to tell us what he's found out, and hopefully the rest of you spent May researching hash functions also

zzz go ahead eyedeekay

eyedeekay I put together some notes in advance of the meeting

eyedeekay going to post them directly if you don't mind

eyedeekay Regarding hashes: I researched several algorithms and tried to evaluate the current state-of-the-art in attacks against them leveraging quantum computers.

eyedeekay The results are mostly "good news" in that attacks on SHA2 and other hashing algorithms are not expected to become practical in the event of a cryptographically-relevant quantum computer.

eyedeekay There are quantum algorithms(Grover's), and combinations of quantum algorithms(Broussard's and some others) that promise speedups.

eyedeekay However the speedups that the quantum algorithms are capable of, even hypothetically, do not improve the possibility that a collision could be found in a practical timeframe.

eyedeekay The popular opinion seems to be that SHA2 will remain secure for a very long time.

eyedeekay The concerns about it in general seem to be things that are very well understood which we handle correctly, like length-extension attacks which are dealt with using HMAC.

eyedeekay I did also look at other hash algorithms however.

eyedeekay Maybe interestingly, the BLAKE family of hash functions seems to be in exactly the same situation as SHA2, as in, CRQC will be able to use Grover's algorithm for it, but it won't lead to finding a collision in a *practical* timeframe. The BLAKE2 family also shares some underlying constructions with SHA2, I think that is why it's the case.

eyedeekay I also looked at SHA3, which is interesting for the opposite reason, it uses a completely different underlying construction, "sponge" which is part of why it was chosen by NIST.

eyedeekay Last time spoke on this I was unsure of our agility and/or our ability to support multiple hashes.

eyedeekay I think my answer to this is changed, because at the very least SHA3 and BLAKE support variable-lengths so we could simply differentiate them by length.

eyedeekay SHA2 | SHA3 | BLAKE2b

eyedeekay ------------------------------------------------------------

eyedeekay Requires HMAC | Length-ext resistant | Length-ext resistant

eyedeekay HW Accel(Intel)| Generally slower | Generally Faster

eyedeekay Slow(ARM) | NIST Approved | No NIST approved

eyedeekay NIST Approved | S.O.T.A.(Sponge) | Similar to SHA2

eyedeekay Grover's | No PQ Attacks | Grover's

eyedeekay Broussard's | Variable-length | Broussard's

eyedeekay The short answer is that I don't think we need to change away from SHA256 at all, but we can if we want to.

eyedeekay Hypothetically, BLAKE2b might be faster on Android devices for instance, but taking out all the HMAC stuff and/or switching between SHA2 and BLAKE2b hash-handlers might be complicated.

eyedeekay Ultimately, it does not seem like development of a cryptographically-relevant quantum computer will affect the security of SHA2.

zzz give us an EOT when you're done and then a couple minutes to read

eyedeekay EOT, take your time

orignal what do we use hashes explicitly in PQ?

dr|z3d delayed "hi" from me.

zzz this is in the Noise handshake, mixHash()

orignal got it. thanks

zzz my source is the PQ SSH RFC datatracker.ietf.org/doc/draft-ietf-sshm-mlkem-hybrid-kex which basically says SHA-2 is fine in this application

Leopold Hi Dr.

dr|z3d *** waves. ***

zzz I think the normal concerns about collisions don't apply very well to using a hash for a running integrity check in noise handshakes. Is that right eyedeekay ?

eyedeekay No I don't really see how they would

zzz and ditto length extension?

eyedeekay I really thought hard about how the heck I could make that matter, but I really don't think I can for the way we use it

zzz SSH proposes SHA384 to be used with MLKEM-1024 (our type 7), but without a lot of justification

zzz I don't think we're really going to use type 7 so I'd rather not go through a whole bunch of work to change the hash on it

zzz orignal, what are your thoughts?

orignal leave it as is

orignal e.g. HMAC with sha256

zzz I think I agree

orignal also mind about sha-ni

orignal on modern x64 cpus

zzz if we need to change later, we have 64K - 8 enc type numbers still available

eyedeekay I couldn't find anything that looked like *serious* justification to move from one modern hash to another outside of A) they think one is easier to use than another or B) running into people's compliance issues. People moving from BLAKE2 to SHA3 because they needed to be using a NIST-approved cipher, or from SHA2 to BLAKE2b because they don't want to HMAC. Very little on PQ.

zzz if SHA-2 is broken all of I2P netdb is broken, we have worse problems than hybrid ratchet

zzz sounds like we're happy with SHA-256 for 5/6/7. Any more discussion about hashes?

orignal not from my side

zzz thanks eyedeekay for the good research and summary

eyedeekay no problem, nothing to add from me

zzz ok, if not, next I'd like to talk about the ratchet part of the spec in general. Is there anything else we need to review or change or discuss, or are we ready to approve that part of it?

zzz I made very minor changes to the proposal shortly after the last review, but haven't touched it since April 24th

dr|z3d mareki2p: you're welcome to contribute to the discussion here.

mareki2p SHA-512/256 and SHA-384 (both variants of 64 bit SHA-512) do not suffer from length extension attacks. SHA-512 is HW accelerated on latest Zen5 and ArrowLake/LunarLake processors.

mareki2p SHA-256 (and SHA-224 and SHA-1) are HW accelerated for a long time already.

mareki2p Sorry, I thought I have no permission to speak here.

zzz all are welcome

zzz thanks mareki2p

zzz ok, hearing no more comments about ratchet, would you all please state your approval or thumbs up or something about the ratchet part of proposal 169?

zzz me: ++

orignal what''s that?

orignal is there something new vs. we have now?

zzz do you approve the ratchet part of proposal 169?

zzz nothing new since last meeting really

eyedeekay ++

dr|z3d *** throws a ++ into the ring. ***

orignal so you are asking me if I approve current implemntation?

zzz the current spec, which matches the current implementation for i2pd and java, which we have tested, yes

mareki2p What is the idea of Blake2b vs Blake3?

orignal ++

zzz super I think we're all happy then

zzz mareki2p, let's defer blake talk until after the meeting, we're on a little bit of a roll here...

zzz ok next topic: preferred choice out of 5/6/7

zzz I recommend that we use 6 and 6,4 as the preferred choices

zzz 5 is too weak and 7 is too big

zzz so for compatibility, we should highlight 6 and 6,4 as the preferred choices in our docs and UI

orignal what's the LS size for 6?

orignal usual

orignal for 5 tunnels

orignal that's my concern

zzz no change in LS size, remember these are ephemeral keys only

orignal fine then

orignal let's do 6

zzz so a 6,4 LS is what, 36 bytes more than a type 4-only LS

eyedeekay 6,4 is fine with me

zzz NIST security categories [FIPS203] :

zzz Algorithm Security Category

zzz MLKEM512 1

zzz MLKEM768 3

zzz MLKEM1024 5

zzz 'security category 1' is basically crap

zzz and the noise handshake size increase for ratchet:

zzz Size increase (bytes):

zzz Type Pubkey (Msg 1) Cipertext (Msg 2)

zzz MLKEM512_X25519 +816 +784

zzz MLKEM768_X25519 +1200 +1104

zzz MLKEM1024_X25519 +1584 +1584

zzz ok, everybody happy with 6,4 as the recommendation?

orignal yes, I'm fine

eyedeekay Yes

orignal will swith 333 to 6,4

zzz ok, lets talk about schedule for a moment

zzz I think we can probably roll it out as a beta for 0.9.67 (August 2025) and official in 0.9.68 (November 2025), how does that sound?

orignal my problem is that openssl 3.5 is not everywhere

orignal fine for me

orignal if nov

dr|z3d can you bundle 3.5 as a fallback?

orignal I would prefer after ubuntu 25.10 relese

orignal not sure

zzz I don't know when we would make it a default. Right now our http client proxy is still 4,0 by default

orignal what it depends on

zzz And I don't want to do 6,4,0

orignal forget about 0

orignal Elg is dead

zzz right, just haven't forgotten about it yet, I guess now is the time

dr|z3d we'd love to forget about it, but there are still ElG only websites out there.

orignal my servers are 4 by default

orignal going to remove 0 from the code

orignal for example?

dr|z3d have a look on notbob.i2p

dr|z3d in the diamond column, anything that has a bottom half red segment is ElG only.

zzz bitcoin is still 4,0 thru SAM

zzz bigly is changing from 4,0 to 4 this release

zzz I don't know if somebody asks for 4,0 thru SAM and you don't support 0, would you error out or just ignore the 0

zzz anyway, I think for the August release I'd like to hide PQ behind an advanced-config flag

dr|z3d or, technically speaking, dsa_sha1.

orignal I thought it's DSA

orignal nothjing to do wit Elg

dr|z3d we drop 0, we lose all the dsa_sha1 servers, no?

orignal august release?

orignal ofc no

orignal look at animal.i2p ))

orignal it's DSA with 4 only

zzz next release is probably around late august, early sept., 3 months from last week

orignal than it's fine

dr|z3d I'd rather not.

dr|z3d ok, well about time dsa_sha1 was gone for good, too.

zzz any other discussions on schedule/rollout of ratchet?

orignal let me think about fallback implemntation

orignal what's our next step in PQ?

zzz good question, that's my final topic

zzz I propose that next we work on NTCP2 and SSU2 hybrid XK handshakes

orignal ratchets work fine in my opiunion

zzz with flags in the RouterAddress saying we support hybrid

orignal DSA_SHA1 is more complicated thing

orignal becuse old addresses

zzz like v=2,3 or something

zzz I still think MLDSA sigs is last on the priority list, maybe next year or even later

zzz opinions on doing hybrid NTCP2/SSU2 next?

orignal fine

orignal let's do it

orignal NTCP2 is easier

zzz should be pretty easy for both

zzz SSU2 is easier, we have flag bits to support both on the same port

orignal how about SSU2 to fix that issue with ident

orignal maybe we can do it together with PQ?

zzz for NTCP2, I have an idea: we have ONE spare bit (the MSB of the eph. key)

orignal then maybe we can satrt with SSU2 to solve both problems

orignal because this is still outstanding issue

orignal nice

zzz for the SSU2 cloning issue, we're standing by since last year, whenever you'd like to update your proposal and schedule a review

orignal if we pass encapsulation for PQ we can also pass ident or apply one more MixHash before PQ

orignal without additional flag for this

zzz maybe, but it would be nice to fix it for non-PQ also

orignal e.g. if you use PQ you must aplly this MixHash

orignal why?

orignal it works now, later on we will require PQ only

zzz maybe, but I don't know when, we haven't talked about it

orignal in few years

zzz that could be 2-3 years away

orignal no rush anyway

orignal right now the only drawback is that NTCP2 is being chosen more often that SSU2

zzz if you want to fix the cloning issue soon, we need two flag bits. We have 8 flag bits now in Session Request, all unused

zzz chosen by whom?

orignal as I said no rush

orignal i2pd chooses NTCP2 to connect to uknnown routers

orignal for me no rush to fix this issue

orignal because the workaround works well

zzz well, until you're in a rush, I guess we're not going to do anything about it

zzz anything else on next steps?

orignal that's why I suggest to fix it as part of PQ

zzz it's either important or not, independent of PQ

zzz anthing else for the meeting?

eyedeekay Hybrid transports seem like the next logical step to me, nothing to add really

orignal imporatnt but not critical

mareki2p Can I talk about Blake?

zzz one sec mareki2p

zzz our next review will be in two weeks, the 3 1/2 year old proposal 160, UDP bittorrent announces

zzz if nobody shows but Bigly, that's fine, but hopefully we can get R4SAS here too

orignal fine

orignal I doubt you will see R4SAS

orignal he is too busy

zzz anything else before the baffer?

zzz ok

orignal no

zzz thanks everybody

zzz go ahead mareki2p

mareki2p Three quick points: Blake2b - up to 512 bit digest, no parallelism, for longer digest you need Blake2x, for parallelism you need BLAKE2bp/Blake2sp.

mareki2p Blake3 - arbitrary digest length, parallel computation (each 1kB block could be computed in parallel independently, later combined together).

mareki2p Blake3 is faster than Blake2b.

zzz good to know, thanks for your comments and your patience ))

Leopold media.defense.gov/2023/Aug/21/2003284212/-1/-1/0/CSI-QUANTUM-READINESS.PDF

Leopold Early planning is necessary as cyber threat actors could be targeting data today that would still require protection in the future (or in other words, has a long secrecy lifetime), using a catch now, break later or harvest now, decrypt later operation. Many of the cryptographic products, protocols, and services used today that rely on public key algorithms (e.g., Rivest-Shamir-Adleman [RSA], Elliptic Curve Diffie-Hellman [ECDH], and Elliptic Curve Digital

Leopold Signature Algorithm [ECDSA]) will need to be updated, replaced, or significantly altered to employ quantum-resistant PQC algorithms, to protect against this future threat.

Leopold nsa recommendations refer to nist