IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2022/03/16
@eyedeekay
+R4SAS
+RN
+RN_
+T3s|4
+Xeha
+acetone
+orignal
+weko
Irc2PGuest89954
Leopold_
Onn4l7h
Onn4|7h
T3s|4_
aargh2
anon2
cancername
eyedeekay_bnc
hk
not_bob_afk
profetikla
shiver_
u5657
x74a6
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 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