zzz
eyedeekay, you need some help with what the UpdateManager is doing with that key?
zzz
it's an internal opaque hashcode and it's not going to tell you anything
zzz
what I'm doing is a little subtle and uncommented so holler and I'll explain it
eyedeekay
Actually zzz I think I just needed to know where it was failing, turns out I was checking on the wrong object when trying to retrieve the context, which was causing my UpdatePostProcessor to never register
eyedeekay
The hashcode is indeed unhelpful but it not being in the error message led me to what was actually going on
zzz
eyedeekay, the key is going to be a random 10 digit number which isn't appropriate for display to the user
zzz
it's just a combination of the update type and the file type used as an internal key
zzz
there's a hundred ways to key off of the combination of two things A and B, since it's internal and opaque it doesn't matter
zzz
so I took the easiest and fugliest
zzz
if you want to display both A and B, then display ftype + ' ' + updateType
zzz
but the key is meaningless
eyedeekay
Ack I'll change it to ftype + ' ' + updateType since that's actually a little helpful
eyedeekay
Thanks zzz
zzz
np, it's hackish and not commented, so I'm sure it wasn't obvious
orignal
zzz please confirm that for SessionRequest we do 3 encryptions
orignal
16 bytes XOR, 48 bytes Chacha, and payload with AEAD/Chacha/Poly
orignal
I also couldn't understand the idea with XOR
orignal
if you have to call chacha twice for every single packet
orignal
because you take nonce from end of packet
zzz
correct
zzz
actually 4 chachas. there's two xors, for 0-7 and 8-15
orignal
that can be compined to one
orignal
*combined
orignal
but why xor not chacha directy?
zzz
no they can't be combined to one
zzz
the xor thing is copied from QUIC
orignal
why?
orignal
you xor 16 bytes instead 2 8 bytes
orignal
what's a difference?
orignal
for 16 byte you can use "pxor" instruction in Intel
zzz
the first 8 bytes (almost) always uses the same key
zzz
the second 8 bytes uses a different key in different phases
orignal
why does it matter if you use different nonce
orignal
e.g. how can it help
orignal
even if keys is the same
orignal
you still have to call chach20 for each packet
zzz
the first 8 bytes is the conn id. it almost always uses your intro key so you can quickly map a packet to a connection without complex heuristics
zzz
the second 8 bytes is the packet number, it's critical data so it needs a key derived from the handshake
zzz
see 'Nonces are Noticed' paper
zzz
the chart of when to use what key is under i2p-projekt.i2p/spec/proposals/159#header-encryption
zzz
that section now also has a long list of goals we're trying to accomplish with header encryption
zzz
that's what I've been working on the last couple weeks
orignal
I still don't undertstand
orignal
before I enncrypt first 8 bytes
orignal
I have to call chacha20 with nonce from end of packet
orignal
basically payload
zzz
right
orignal
even worse, random padding
zzz
no, there's no random padding outside the payload
zzz
all padding is in a padding block
orignal
them please tell me what we use for nonce
orignal
last 24 bytes, no?
zzz
correct, AFTER encryption of the payload
zzz
here's the processing steps:
zzz
Outbound Packet Creation
zzz
Handshake messages (Session Request/Created/Confirmed, Retry) basic steps, in order:
zzz
Create 16 or 32 byte header
zzz
Create body
zzz
mixHash() the header (except for Retry)
zzz
Encrypt the body using Noise (except for Retry, use ChaChaPoly)
zzz
Encrypt the header, and for Session Request/Created, the ephemeral key
zzz
Data phase messages basic steps, in order:
zzz
Create 16-byte header
zzz
Create body
zzz
Encrypt the body using ChaChaPoly using the header as AD
zzz
Encrypt the header
orignal
so, you encrypt with chacha/poly
orignal
and then use last 24 bytes
orignal
?
zzz
correct
orignal
with tag of without tag?
orignal
*or
zzz
there are no tags in this protocol
zzz
only a header
orignal
I mean 16 bytes poly
orignal
where do you take 24 bytes from?
zzz
the last 24 bytes of the encrypted message, including the MAC. So it's the 8 bytes before the MAC, plus the MAC, to make 24 bytes
orignal
what is payload is zero?
zzz
this is after payload encryption, so it won't be zero
orignal
or it must be at least 8 bytes?
zzz
oh, zero size?
orignal
it could be 16
orignal
payload of zero size
orignal
why not?
zzz
We may have to require a minimum 8 byte size
orignal
chacha/poly will ropduce 16 bytes
orignal
and you need 8 bytes more
orignal
therefore SessionRequest is not 80+ bytes
orignal
but 88+
zzz
right, which is no big deal, a payload block header is 3 bytes, a padding block header is 3 bytes, a datetime block is 7 bytes
orignal
got it
orignal
so datetime is required for SessionRequest
zzz
yes
zzz
and datetime and address blocks are required for SessionCreated
orignal
now. how are you going to xor?
zzz
and RI block is required for SessionConfirmed
zzz
what do you mean how?
orignal
byte by byte?
zzz
yes
orignal
or you use something?
orignal
slow
zzz
who cares, xor is 100x faster than the chacha
zzz
you can do all 8 at once if that's easier, doesn't matter
orignal
just asking
zzz
it's a java thing, its
zzz
it's not easy to switch back and forth between bytes and longs
orignal
thinking if I should align to 8
orignal
no unions in Java?
zzz
no
orignal
anyway let me change
zzz
I'm happy you're asking questions and asking why. I feel like it's taken me a year to really understand the problems and fit the whole thing in my head all at once
zzz
it doesn't feel impossible any more :)