orignal
zzz any plan to fix that SSU2 issue?
dr|z3d
been a while, Liorar!
Liorar
It has! I got swamped with life
Liorar
now I'm trying to remember how to do everything on here, LOL
Liorar
at least I got IRC working again!
Liorar
next step: get browsing eepsites working
dr|z3d
:)
dr|z3d
:4444 http proxy.
Liorar
aha, I think I solved that one now
Liorar
yeah, half the trouble was finding a browser I wanted to do it in
Liorar
the I2P private browsing extension for Firefox needs major work, lol
Liorar
and the browser I'd have *liked* to make it work in is too obscure and I use it for real sites, so I gave up and went and found one to use just for this
Liorar
only problem is, it won't load hardly any of the images in the router console and I'm really disliking that
Liorar
ahh, settings were a bit *too* secure, lol
Liorar
I'll work on getting torrents back running another day, but it's satisfying to be back
dr|z3d
you could use librewolf for i2p if you want to separate browsers.
dr|z3d
everything you expect from firefox.
Liorar
I ended up going with Mullvad, it's designed for privacy - just can't set it to the safest security or you lose half the pics, apparently
Liorar
Mullvad's Firefox-based also, so easy to use
dr|z3d
whatever works for you :)
dr|z3d
librefox is also privacy focused.
zzz
what issue orignal?
orignal
issue that and advesary can put IP, s and i of real router to his fake router
orignal
and a vectm will think they are connected to the fake router
orignal
because no way to recognize this situation in case of SSU2
zzz
on my list stats.i2p/docs/roadmap-2.5-zzz.html
zzz
awaiting your proposal
orignal
weko
weko
I'm busy, later
orignal
the simple proposal is to send Bob's ident hash in a spearate block
orignal
howeevr the best thing would be encrypted X like in NTCP2
orignal
not sure what is the best
orignal
I'm back with this because we had long discussion with weko why we can't use SSU2 as much as we could
zzz
yes, we've discussed many times. write it up, get help from the i2pd team if you need it
orignal
when did we discuss it?
zzz
write up the options then
zzz
and we can then discuss it
orignal
thanks. let weko do it ))
zzz
a month ago, two months ago, ...
weko
orignal: I'm think now should we use hash for enc or we can just send it
orignal
he was a volunteer to do it
orignal
I remember you only said "write a proposal"
orignal
seems you don't see a problem here
weko
So it will really easy. Block with 32 bytes of hash and nothing more needed if don't use hash in enc
zzz
not true, I agree it's a problem. I'm not sure how big a problem though, hopefully the proposal will explain that
weko
And simple check
orignal
let me formalate differetly
orignal
how do you solve it in Java now?
weko
zzz: attack ~year ago used this problem
weko
It's because we know this problem
weko
DDOS attack and can do deanon attack easier
zzz
I've said before, it sounds like an idea we should discuss, it's not going to be a waste of your time to write the proposal
zzz
it's on my list and I'm standing by :)
orignal
but what you do now in Java code?
zzz
I don't believe we have anything. If we could defend against it without a protocol change, then please tell us how in the proposal
weko
i2pd do not make ssu2 connection to "unconfirmed i" routers, as temporary fix
zzz
ok, add a section about that alternative in the proposal
weko
I guess it's not best solution, better do verify in ssu2
zzz
maybe. discuss the tradeoffs in the proposal
orignal
we just need a new block type
weko
orignal: so is it possible to add in SessionRequest? Better check as fast as possible
zzz
also in the proposal please discuss alternatives for the block. Does it need to be the full 32 byte hash, or is a 4 byte siphash-of-the-hash, or some HKDF or something, sufficient
orignal
also another option is to use router's identhash as "i" for SSU2
zzz
add it all to the proposal
orignal
that's exactly my problem
orignal
I'm too poor for ideas and anylisys
zzz
then get some help from the rest of the i2pd gang
orignal
if I had a choice I would use idenhash for i and that's it
orignal
no changes at all
weko
orignal: how i generating now?
zzz
I've written a thousand pages of proposals and specs in the last 10 years, you guys can do a few
orignal
weko just brandom 32 bytes
orignal
zzz English is your native langauage
orignal
but I can't write more than 5 sentences in English ))
weko
orignal: then for what I really needed?))
weko
Better alsways use ident
weko
I*
weko
i*
orignal
not necessary
orignal
you can use any i
weko
Damn.
orignal
but if you want to make your SSU2 address "trusted" use router's ident
orignal
for example if you are firewalled it doesn't matter
orignal
but if you are a floodfill better to go this way
weko
orignal: I mean i should be always = ident and even don't write it
weko
And for ntcp2 also
weko
-64 bytes for RI.
weko
And DPI sucks because we use empheral (fuck this word) key
zzz
so write 5 sentences, then get help from the i2pd gang for the rest ))
zzz
here's your outline:
zzz
goals
zzz
threat model
zzz
general approach
zzz
spec change:
zzz
- option 1
zzz
- option 2
zzz
- workaround 3
zzz
backward compatibility/migratin
weko
Even 3 options
weko
3 is remove i and use router ident as i
weko
But not compatably with old routers. We should add code to use ident as i, if there is no i in RI, and we later we will have option to remove i with continue supporting most routers
orignal
zzz maybe key=ident in SSU1 had some rationale?
zzz
I think it was just jrandom
weko
And was right
weko
Because ident also random value
orignal
ofc it was jrandom
orignal
but maybe he had this reason in mind'
zzz
we can discuss all the alternatives, but I think the simplest solution will probably be the best
weko
zzz: most simple is write i = ident I think. But, as I wrote, we can delete in future
weko
Ye same value can be effectively compressed, but in memory we saving uncompressed RI.
zzz
I don't understand what the change in "i" has to do with this problem. Isn't the simplest fix just to put the hash in the handshake?
weko
zzz: because if attacker will do new RI with same address, port, s, i, i will be != RI. So we need to save temp change, but set "confirmed" flag is i=ident
weko
Anyway we need to save it...
weko
Can be called "fix for old routers support"
weko
zzz: can you give number of proposal?
orignal
zzz if i = ident we can trust such address
zzz
weko 165, take one of these as a template github.com/i2p/i2p.www/tree/master/i2p2www/spec/proposals
weko
zzz: thanks
not_bob
I may not know what I'm talking about, but is there a way for the router to "test" the other router to make sure it works as expected?
not_bob
Something that doesn't break old routers?
Liorar
drat! my password for Postman doesn't work but I *had* an account there, wish I remembered what it was!
dr|z3d
ping postman, see if he can reset it for you.
Liorar
I remembered to check the old browser on the retired comp that used to run it - and I had saved it there, so I think I have it
Liorar
naturally, it took complaining about forgetting for me to remember, lol
Liorar
anyone know what's a reasonable amount of time for an email to arrive in one's i2p webmailbox? I signed up for a i2p-based forum with that email addy and am wondering how long to expect to wait for the confirmation email
dr|z3d
sometimes instant, sometimes can take a hour or more.
Liorar
Lol, well, it's on the "hour or more" scale, but I'll keep checking then
Liorar
thx
dr|z3d
and sometimes never, if the i2pmail.org domain has been blacklisted.
Liorar
lol, no idea, they didn't say "don't use addresses from i2pmail.org" in the signup form
weko
<not_bob> I may not know what I'm talking about, but is there a way for the router to "test" the other router to make sure it works as expected?
weko
<not_bob> Something that doesn't break old routers?
weko
profiling