#ls2 (irc2p) | #ls2 Proposal 168 review here 8 PM UTC Tues. Dec. 3

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