#ls2 (irc2p) | #ls2 proposal review channel : Upcoming reviews Tuesdays 8 PM UTC: prop 169 Mar. 18; prop. 167 Apr. 1l prop. 163 Apr. 15

zzz Reminder: Proposal 163 review today 8 PM UTC here

zzz test test test

dr|z3d we hear you, zzz. ***test completed successfully***

zzz *phew*

dr|z3d *** chuckles ***

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

altonen hi

ardu hi

dr|z3d hihi

zzz multiple a-name people, welcome

dr|z3d *** pokes orignal with a shitty stick. ***

orignal hi

orignal 2 more minutes

zzz ping eyedeekay

zzz ok

zzz hello everyone

zzz today we're going to review proposal 163, Datagram2

zzz I'll start with a brief overview, then throw it open for comments and questions

eyedeekay Sorry got disconnected at the last second, I'm here now

zzz This is the leftover part of proposal 123, LS2, where we can't send datagrams from offline-signed destinations

orignal hi

zzz so it's been about 6 or 7 years

zzz the second thing we want to solve is replay prevention, which we already fixed for streaming

zzz and the third thing is to add some flags and options fields, so we don't have to do this again next time we change something

zzz that's it, it's a pretty simple proposal

zzz so I'll throw it open for questions and comments

orignal my first question

zzz go ahead

orignal why do we even need signature for each datagram if it goes through ratchets session?

orignal for me it's too much overhead

zzz well, datagrams came well before ratchets

orignal we only need it for very first datagram to link static key with dest

orignal I know

zzz whatever ratchet knows about, doesn't get out through I2CP to the client

orignal hence can we have a flag is signature included or not?

zzz so you don't want the from field either?

orignal you need it because it's repliable

orignal in case of I2CP client should rely on router

zzz you either know where it's from or you don't

orignal I just don't want to sign and verify through established session

orignal because overhead

orignal and yes from can be exaluded

zzz if we don't need 'from' or 'signature' any more, shouldn't we fix i2cp and streaming first?

orignal and it's this case it's raw datagram

orignal for streaming it's first packets only

zzz we have no way to pass the 'from' field through i2cp right now

orignal all follow-on packets use streamid

orignal then can we just have flags?

zzz that's the same for most normal UDP protocols. Use Repliable for the first packet, and RAW for the rest

orignal like in streaming

zzz that's what we do in snark

orignal from, signature, etc.

zzz well, without FROM/SIG it's just RAW anyway. You don't need DG2 at all ???

orignal I might want to send with Form and without sig

orignal and oppiste

orignal sig without from

eyedeekay Speaking to orignal's point we're not doing a lot of repliable/raw switching in SAM libraries by default but we could find a way

zzz orignal, what's your use case for from w/o/sig and opposite?

orignal for exapmle ping

orignal I send "ping" message and expect "pong"

orignal should add from and no sig

zzz isn't that insecure?

orignal and you do need from even without sig

orignal you receive datgram

orignal take "from"

orignal find leaseset

orignal get static key from there

orignal and compare with session

orignal if matches assume it's good

orignal if not drop

zzz so we do always need 'from' ?

orignal if you don't always have from an advesary can spoof

orignal yes we do

zzz ok

orignal my point is that signature is too expisive

orignal unlike from

zzz you're saying because of ratchet, it can't be spoofed, and we don't need the signature?

orignal right

orignal that's my point

orignal in case of ratchets you are good without it

zzz ok I understand your point. I'll have to think about it more

orignal thanks

zzz let's move on for now, any other comments or questions orignal?

orignal no more question from me

zzz anybody else?

dr|z3d nothing from me right now.

zzz does the replay prevention look good, by including the receiver hash in the signature?

eyedeekay As long as we have signatures it makes sense but what orignal's said about them has put me off balance

orignal yes we should do it

zzz would we still need sigs for elgamal?

orignal the same way as for streaming

zzz because you only get static key verification with ratchet

orignal I think Datagram2 shouldn't supprt ElGamal at all

orignal and if you want to keep it

zzz it's a different layer, so it doesn't matter

orignal you should use flag if signature included or not

orignal same for receiver hash

zzz you want a flag for receiver hash included in sig?

zzz if there's no sig then you don't need a 2nd flag for no receiver hash

zzz the hash isn't being sent, it's just included in the sig

zzz PQ sigs, btw, are ~2400-4600 bytes

orignal no

orignal only for sig itself

zzz ok

zzz any other questions or comments?

orignal as long as we have options section everything else looks good

eyedeekay My concern re: removing aspects of the proposal is that if stuff gets taken out then we end up needing it it's probably a big headache

eyedeekay But that's the point of having the ability to set flags right?

zzz so I agree with eyedeekay, the no-sig proposal has shaken things up a little

zzz yeah if there's no flag there there's no options section, not even a two-byte 0 0

zzz since we don't have any idea for it right now, doesn't seem like we should waste two bytes

zzz I want to reiterate that using DG2 for every packet would be extremely wasteful. Normally Alice would just send one, with a token

zzz and then Bob sends back one or more RAW packets with the token in them

zzz well the no-sig flag is an 'addition' to the proposal

zzz but I think we need to think about it and come back later

zzz what do you think about a second review on April 15th?

eyedeekay I should be good

orignal yes

zzz ok then

dr|z3d sure, let's shoot for then.

zzz anything else for the meeting?

eyedeekay Nothing else from me

orignal nothing

zzz *** *bafs* the meeting closed ***

zzz thanks everybody

zzz in two weeks: PQ prop. 169

eyedeekay thanks zzz :) looking forward to the next one

zzz FYI the MLDSA parts of the proposal are in pretty good shape; the MLKEM parts need some work

zzz I'll be updating/fixing the MLKEM parts this week

orignal I'm still waiting for openssl 3.5

zzz 3.5 scheduled for April 8, keep your pants on

zzz don't need 3.5 to review the proposal ))

orignal I want to try PQ

orignal that's all

zzz happy to send a LS to a dest of your choosing to see if you crash ))

orignal let me check the code

orignal const size_t MAX_LS_BUFFER_SIZE = 3072;

orignal that's what I have now

zzz yeah I found some buffer overflows in streaming trying to sign/verify

zzz I'm thinking about the APIs for datagrams for whether we would require a signature or not

zzz that might be messy

orignal and it consider unknows signature types as DSA ))

zzz one way to do it: define Datagram2 (type 19) requires sigs, and Datagram3 (type 19) where we don't have sigs, or they're optional

orignal thanks. will check streaming code

zzz correction datagram3 would be type 20

orignal 2/3 looks good

zzz just a two second idea, we have 6 weeks to think about it

orignal yes

zzz re: PQ overhead, PQ adds from 3380 to 7456 bytes to every LS, Streaming SYN, or repliable datagram

orignal again what's the saigntire size for PQ?

orignal uint8_t signature[256];

orignal I have such shit in the code

zzz Type Length (bytes) Since Usage

zzz MLDSA44_EdDSA_SHA512_Ed25519 2484 0.9.xx See proposal 169

zzz MLDSA65_EdDSA_SHA512_Ed25519 3373 0.9.xx See proposal 169

zzz MLDSA87_EdDSA_SHA512_Ed25519 4691 0.9.xx See proposal 169

zzz MLDSA44 2420 0.9.xx See proposal 169

zzz MLDSA65 3309 0.9.xx See proposal 169

zzz MLDSA87 4627 0.9.xx See proposal 169

orignal it my code streaming will just produce error

orignal LogPrint (eLogError, "Streaming: Signature too big, ", signatureLen, " bytes");

zzz overhead chart:

zzz Type Pubkey Sig Key+Sig RIdent Dest RInfo LS/Streaming/Datagram (each msg)

zzz EdDSA_SHA512_Ed25519 32 64 96 391 391 baseline baseline

zzz MLDSA44_EdDSA_SHA512_Ed25519 1344 2484 3828 1383 1351 +3412 +3380

zzz MLDSA65_EdDSA_SHA512_Ed25519 1984 3373 5357 2023 1991 +5668 +5636

zzz MLDSA87_EdDSA_SHA512_Ed25519 2624 4691 7315 2663 2631 +7488 +7456

zzz MLDSA44 1312 2420 3732 1351 1319 +3316 +3284

zzz MLDSA65 1952 3309 5261 1991 1959 +5668 +5636

zzz MLDSA87 2592 4627 7219 2631 2599 +7072 +7040

orignal so what's the max LS size? 6K?

orignal or 8K?

zzz your current max + 7456 ))

orignal 10K then