@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
:)
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