@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
hi
orignal
hi
zlatinb
hi
zzz
happy monday, what's on the agenda?
eyedeekay
hi
orignal
let's continue with SSU2
zzz
ok that's 1). what else?
orignal
nothing
eyedeekay
SAM ideas for android
orignal
good
zzz
ok that's 2). anything else?
zzz
good enough for now
zzz
1) SSU2
zzz
orignal, what's your status?
orignal
well
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
but
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
ok
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
orignal
yes
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 :)
orignal
ofc
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
ok
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
look
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
github.com/i2p/i2p.i2p/blob/12c4f43109461e860e773402856413fa2f7a8ff9/apps/sam/java/src/net/i2p/sam/SAMHandlerFactory.java#L30
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?
orignal
no
zzz
one hour flat, thanks everybody
zlatinb
hey take a look github.com/citizenlab/test-lists/blob/master/lists/global.csv
zlatinb
both geti2p.net and muwire.com are on it, nice