IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2022/03/07
@eyedeekay
+R4SAS
+RN
+RN_
+T3s|4
+Xeha
+orignal
FreeRider
Irc2PGuest46029
Onn4l7h
Onn4|7h
T3s|4_
aargh3
acetone_
anon4
cancername
eyedeekay_bnc
not_bob_afk
profetikla
shiver_
u5657_1
weko_
x74a6
zzz ok, I have acks working enough so that messages aren't timing out, so the connection stays up
zzz not sure if the windowing and congestion control is working at all
zzz haven't even looked at it yet
zzz 0) Hi
zzz happy monday, what's on the agenda?
orignal let's continue with SSU2
zzz ok that's 1). what else?
orignal nothing
eyedeekay SAM ideas for android
zzz ok that's 2). anything else?
zzz good enough for now
zzz 1) SSU2
zzz orignal, what's your status?
orignal I was able to send SessionRequest and receive SessionCreated back
zzz great!
orignal now I'm able to publish SSU2 address
orignal have some question about MixHash with header
orignal is it short header or long header?
zzz the mixHash() is of the short or long header, whichever it is. For Session Request and Created, it's the long header
orignal see the problem
orignal long header consists of two parts
orignal being encrypted differently
zzz right. but for outbound you mixHash, then encrypt the message, then encrypt the header
orignal and with encrypt second part of long header togheter with ephemeral key
zzz for inbound you decrypt the header, then mixhash, then decrypt the message
orignal I can't decrypt just header
zzz the mixHash() never includes the ephemeral key. Only 16 or 32 bytes
orignal I have to do it together with public key
orignal I know
orignal but see my problem
zzz please explain
orignal we take data for MixHash from two diferent places
orignal long header consists of two parts
orignal first 16 are result of XOR
orignal last 16 are first 16 bytes from 48 chacha encrypted bytes
zzz here's what I do:
zzz I do a "trial decryption" of the header to a temp buffer
zzz then check some fields to see if it looks right
orignal I do the same
zzz then copy back to the packet, overwriting the encrypted data
zzz then pass it to noise
zzz *then mixhash, then pass it to noise
orignal you can't decrypt just header
zzz right, I decrypt 64 bytes to temp buffer
orignal well let's do it
orignal I just wanted to double check if it's right
zzz I have 3 trial decrypt functions: 64, 32, and 16. Depends on the situation
zzz yeah, that's right
orignal my problem is
orignal that first part of buffer must be 8-bytes alighed for xor
orignal so I can't just use a buffer
orignal and need two portions of header for MixHash
zzz yeah, alignment is different for ipv6 and ipv4
orignal also header is cleartext. right?
zzz it's cleartext after header decryption, right
orignal and before encryption if Alice
zzz right
zzz you could just not worry about alignment and do byte-by-byte XOR, not the end of the world :)
orignal that's what I wanted to know
orignal I will be able to test with you seen
zzz good, you're asking the right questions
orignal I prefer alignment
orignal almost done
orignal now I have another question
orignal Are you able to handlle RI wth 7 addresses in in?
zzz in general, yes. In SSU2, big RIs are a problem if they don't fit in the Session Confirmed MTU
zzz that's why I added a gzip option for the RI block. Because it's a big big mess if it doesn't fit
zzz so the RI block has a flag byte, different than for NTCP2
zzz * a fragment byte
orignal I haven't reached to that point yet
orignal just saying you might see RI with 7 addreses
zzz that's fine. I think there's a limit of 16 somewhere, just for sanity
zzz I also want to mention tokens and token request and retry, which you probably haven't gotten to yet
zzz so, in my test code, I'll allow any nonzero token in the session request
zzz in the production code, I'll send you a retry if I didn't send you the token
zzz and there's a Token Request message to ask for a token
zzz so for initial testing, send a nonzero token
orignal thanks
orignal will do
zzz the whole token thing is more work, but it's important to protect against packet spoofing
zzz any other questions or status? if not, I'll report my status
orignal go ahead
zzz so I've moved away from my test code, to testing the production code on a LXC testnet
zzz 16 routers, two of them with SSU2 enabled
zzz for the last 3 days
zzz fixed a zillion bugs
zzz as of today, the session stays up, I have the handshake and data phase working
zzz sending and processing acks
orignal how many lines of the code for data phase?
zzz still a few problems, working through them, slow going
zzz the data phase itself, just processing the messages, is pretty easy
zzz maybe 200 lines
orignal no frarmnets like in SSU?
zzz the harder part is sending/receiving/processing acks
zzz yes there's still fragments
orignal that's basically part of data phase
zzz my code is mostly extenstions to SSU 1, so I have class extensions / overrides
zzz I'm happy with the data phase, it's much easier than SSU 1 to deal with
zzz as usual, the important part is thinking a long time about data structures
zzz what's the best and most efficient way to store state
orignal I haven't reached it yet
zzz but the acks and all that is MUCH better than SSU 1.
zzz basically you can ack a thousand messages in a few bytes
orignal will read
zzz don't fill your head with it until you're done with the handshake :)
zzz anyway, to end my status: I expect to turn it back on in the real net in maybe a week? it will crash old i2pd again, oh well
zzz I turned off floodfill on my router, maybe that will make it crash less routers
zzz maybe I'll reduce the bandwidth too
zzz that's the end of my status
zzz anything else on 1) ?
zzz 2) SAM ideas for android
eyedeekay IMO re: SAM, both zzz and I are right
eyedeekay There are of course thousands of malicious Android apps in the play store, Android is more hostile than almost anywhere else
eyedeekay But the inconvenience of configuring applications manually is still exactly what I would like to avoid, and that includes passwords
eyedeekay And kind of goes double for mobile
orignal let them crash
eyedeekay I'm getting to my point here
eyedeekay So I've been trying to find a way which reconciles both of these realities
eyedeekay And I think that I've got one but I think it might require changing the SAM protocol, i.e. SAMv3.4 possibly
eyedeekay What I would like to do is add the ability for SAM to instruct a client to `WAIT` on another response, and that between the WAIT and the session establishment being completed, solicit feedback from the user
zzz just for reference for the others, you're referring to the discussion at the bottom of zzz.i2p/topics/2988
eyedeekay i.e. An application want to make a SAM connection, tell it to WAIT, and in the case of android, use a Toast to present a message to the user "An application is trying to make a SAM connection $nickname" Allow/Deny
eyedeekay For desktop, the channel would be the new Notifications in the taskbar IMO
orignal you don't need to change protocol for it
zzz that's a very interesting idea
orignal when user tries to create a new session
zzz orignal is right, no protocol change needed, IF the client side doesn't time out waiting for response
eyedeekay I also thought, in the same vein, that SAM could also have the ability to use a client certificate to authenticate the clients themselves, which the client could pass to SAM by a similar process
orignal he also have to wait until we build new tunnels
orignal so no difference for androind
orignal it waits until user press Yes or No
zzz right, we wait 5 minutes for LS anyway
orignal do we really need cert rather than just password?
eyedeekay No I don't think so, at least for local
eyedeekay It was just a thought about something that might be useful
zzz agreed, I don't see how a cert is any better than a password
eyedeekay Looks like the timeout for Java is a full minute, that seems like plenty
zzz at which phase?
eyedeekay HELLO if I'm reading correctly, I just hastily grepped for it
eyedeekay private static final int HELLO_TIMEOUT = 60*1000;
zzz yeah you probably want to go farther than that before asking the user, but that's just an implementation detail
zzz one problem with the toast is you don't have any verifiable identification of the client
zzz you don't know who is asking
eyedeekay Yeah that is an issue
eyedeekay But IMO the default response we should recommend for the user is that if you don't know why the app is requesting a connection, say no
eyedeekay So lying about what your app is for only works if you trick the user first
zzz one way to do it is on the client side, create a random username/pw, and display it to the user on first connection
zzz then the toast on the router side says, new user/pw, accept?
eyedeekay Yeah and also that discourages password re-use
zzz or really just display the username on both sides. pw stays secret
zzz with that, you only have to go through the dance once
eyedeekay Good idea
zzz and the username could be e.g. 'appname - randomchars'
eyedeekay That's what I would do
zzz I'm glad we're coming a little closer together here, we started pretty far apart
zzz anything else on 2) ?
eyedeekay We just had to find a way to reconcile our goals
eyedeekay If we think this is a good idea I'm going to get to work on it in a branch
zzz concept ack :)
eyedeekay Thanks, nothing else on 2 for me
zzz anything else for the meeting?
zzz one hour flat, thanks everybody
zlatinb both geti2p.net and muwire.com are on it, nice