#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

orignal zzz, in KDF for SessionCreated we see

orignal h = SHA256(h || 32 byte encrypted payload from Session Request)

orignal it simply means that minimal size for payload is 16

orignal and 9 for padding

zzz orignal, that's a copy/paste error from NTCP2, where the session request was a fixed-size 16-byte options

zzz SSU2 session request is variable-size

zzz the minimum payload size of session request is 8 bytes. Since DateTime block is 7 bytes, at least one other block must be present

zzz I'll fix the proposal, good catch

zzz same error in Session Confirmed KDF: "24 byte encrypted payload"

zzz fix pushed

zzz oooh I have an idea

zzz right now, with X25519 enc type and Ed25519 sig type, we have 320 bytes of random padding in dests and router identities

zzz if we used a constant value in that padding, then the dest or ident would be compressible

zzz and in any protocol where we had gzip (I2NP DatabaseStoreMessage, SSU2 Session Confirmed, I2CP), the message would be almost 320 bytes smaller

zzz are there any security issues with doing this?

zlatinb interesting. MW does use compression almost everywhere and it transfers full b64s

zzz does it make the SHA256 of the dest or ident more crackable?

zzz here's an example with zero padding:

zzz Destination: On~YvYeJ3UPV4NVObazbBcQFNRb7LDpnkqDFE1ar~hIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

zzz AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOGYcuStQ2~eWhd8ODcieXJVNYOoSVDzvZL9M3rtlyTeBQAEAAcABA==

zzz we could make the padding a random value 0-255, if that adds any security, or even if it doesn't

zlatinb entropy is bound to be less, no way around that

zzz and *poof* everything is magically smaller, without any protocol changes

zzz sure, re: entropy, but does that allow somebody to make some sort of SHA256 rainbow table

zzz there'd still be 32 + 1 + 32 = 67 bits of entropy, minus a few for the constraints of the keys

zlatinb if they keys are properly random then it should be ok

zlatinb otherwise we can sacrifice 32 bytes with properly random padding and the rest zeroes

zzz pubkeys are certainly random, except for about 3 bits each

zzz correction, 67 bytes of entropy, not bits

zzz which is twice the size of the hash

zzz so at twice the size of the hash, all hash values are, presumably, all (equally) possible

zlatinb idk how the keys get generated so I'd feel better if there was at least a bit of purely random padding

zzz and with the padding in the middle, there's no chosen-prefix collision attack

zlatinb it would still be a big gain when compressing

zzz or after-padding attack

zzz 25519 public keys are a random value over a field (I think, kinda faking it)

zzz well, you can pick how much random padding you want, and then repeat it. 1 byte? 4 bytes? 16 bytes? 64 bytes?

zzz and then your savings is, roughly 320 - (pattern length)

zlatinb 64 bytes

zlatinb I'd be happy with such arrangement

zzz and something that 320 divides cleanly by also helps a little

zzz the nice thing about a pattern is people don't see a huge string of AAAAAAAAAAA and freak out that our crypto is broken

zlatinb yeah but makes multiple destinations less compressible when sent together

zlatinb either way, savings should be big enough

zzz I can't think of any protocol that sends multiple dests or RIs together

zlatinb muwire does

zlatinb :)

zlatinb in pongs

zlatinb which travel over gzipped streaming connection

zzz well, those dests wouldn't have the _same_ padding unless we used zeros everywhere

zlatinb I'm happy to have a 64-byte repeating pattern

zzz state your case for why 64 is the right number

zlatinb it's at the same time big enough to be safe and small enough to be compressible

zlatinb oh wait

zlatinb 256 bits is 32 bytes

zlatinb so I mean 32 byte

zlatinb whatever entropy can be squeezed in sha256 digest

zzz so we have roughly 64 bytes now (two 32-byte keys), which is twice the size of the digest

zzz so your case is that another random chunk the size of the digest makes it "safe"

zzz even if the public keys are somehow not random

zlatinb basically yes

zzz makes sense

zzz an even more conservative choice would be to only do this for transient destinations, not for server dests or RIs

zlatinb muwire would not benefit from it in that case

zzz right

zlatinb it's not a big deal, right now background chatter with default settings is less than 10kb/sec

zlatinb ofc I'd love to make it even less

zzz then send hashes instead of dests

zzz here's an example with 32 bytes of padding

zzz Destination: F8rXjVxJz2PF9fu7Q9Fsu~m-uPsDYSY66rQl7voE3AkHoGHN54SEm7AQtRI7t9DLrAZyWXW04o3GYnl7KtBbggegYc3nhISbsBC1Eju30MusBnJZdbTijcZieXsq0FuCB6BhzeeEhJuwELUSO7fQy6wGcll1tOKNxmJ5eyrQW4IHoGHN54SEm7AQtRI7t9DLrAZyWXW04o3GYnl7KtBbggegYc3nhISbsBC1Eju30MusBnJZdbTijcZieXsq0FuCB6BhzeeEhJuwELUSO7fQy6wGcll1tOKNxmJ5eyrQW4IHoGHN54SEm7AQtRI7t9DLrAZyWXW04o3GYnl7KtBbggegYc3nhISbsBC1Eju30MusBnJZdbTijcZieXsq0FuCB6BhzeeEhJuwELUSO7fQy6wGcl

zzz l1tOKNxmJ5eyrQW4IHoGHN54SEm7AQtRI7t9DLrAZyWXW04o3GYnl7KtBbglDvHXWvcyP3C43NOKL7bplBc2txiDMmJ0JaWN5gSyzlBQAEAAcABA==

zzz it's hard to spot the pattern, and in b64 it doesn't repeat 10 times

zzz more like 3?

zzz lets see how compressible b64 is...

zzz I know gzip looks at bits, not bytes

zzz 391 byte dest, 524 byte b64. gzipped b64 w/ random padding: 448 bytes. gzipped b64 w/ 32 byte random pattern: 235 bytes

zzz gzip header+footer is about 24 bytes min

zzz you should still send hashes, not b64 dests

zlatinb way too late in the game for such change

zzz actually, we're still sticking an unused ElG key in dests, so there's only 96 bytes of padding there. Still 320 in RIs

Xeha what for? cant we deprecate ElG?

zzz it's unused.

zlatinb can we somehow make that elg key compressible?

zlatinb or stick the same elg key in every destination?

zzz I need to look for places where we might validate the key against the private key, e.g. i2cp, privatekeyfile

zlatinb I'm happy to have it fixed/identical only for newly generated destinations

zzz all of this discussion only applies to new dests/RIs, of course