#saltr (irc2p) | I2P+ 2.7.0-9+ >> i2pplus.github.io | skank.i2p | git.skank.i2p | purokishi.i2p | vituperative.github.io/i2pchat | natter.i2p | notbob.i2p | ramble.i2p | shreddit.i2p | cake.i2p | /msg an op for voice

weko [17:24:32] <zzz> weko, ask jrandom... but 30 would be a long graceful shutdown

weko So, we can do graceful shutdown shorter. Okay, I will ask )))

weko I mean, maybe you have some explanation about it. If you have not, okay.

orignal I keep suggesting to implemenent tunnel termination/extension message for last 10 years ))

orignal same way as TBM

dr|z3d you know what zzz will say, orignal...

not_bob Possibly a message that can be sent to any routers tunneling through your router that says "Yeah, sorry. I can't fullfill my commitment much longer?"

not_bob I have no idea how that would be implemented, but it's an idea.

snex thats not how it works during graceful shutdown?

not_bob snex: No, your router just stops allowing new connections.

not_bob But, it fulfills all tunnels that it has already agreed to before you issue the shutdown.

not_bob Hence the roughly 10 min wait for shutdown.

tennis2 I'm at my wits end. Web search is not coming up with the solution that it has in the past multiple times. I need to enter the command to mount a USB that was ejected by accident. Its a really simple command but I just cna't remember it, I've been searching for two hours. I think the search engines have gotten rid of the working olution

tennis2 its a command related to fs** and you just need to check the devives

snex unplug and replug it

tennis2 snex yeah I did that, and a couple times. There's a command to reset, I can't believe I didn't save it, I save lots.

T3s|4 tennis2: not understanding how you searched for two hours. Found a bunch of articles in two seconds under DDG: 'remount ejected usb drive linux' - just one example: howtogeek.com/414634/how-to-mount-and-unmount-storage-devices-from-the-linux-terminal

orignal yes, I do. "write a proposal" ))

orignal not_bob_afk yes it's my another idea, but would work for inbound tunnels only

orignal in case of outbout this message will reach OBEP and what's next?

zzz for either out or in (other than IBGW) you still have to do impossible "mid-tunnel injection", there's no layer keys for that

orignal zzz I told many time how you can do it

orignal you just encrypt a message with your layer key and send to next peer

orignal once it reaches the owner, he start decrypting layer by layer

zzz sure but won't work because previous hop didn't encrypt first, that's why you can't "inject"

orignal you don't care

orignal an owner can decrypt a message initialed by intermediate hop

orignal because he decrypts layer by layer

orignal decrypt a next layer, check if start you message if known header

orignal and handle it

zzz yeah but you start with first layer, not last (i think?)

orignal but witll for for IB only

orignal it start in order "encrypted last decrypted first"

orignal otherwise it wouldn't work

zzz is that the way we do it now?

orignal yes

orignal if tunnel is 1-2-3, the owner decrypts it as 3-2-1

orignal no magic

zzz ok, so maybe we could do it for IB. But what's the point? OB is impossible, it's a security nightmare if OB middle hops can inject messages

orignal for (auto& it: m_Hops)

orignal {

orignal it.decryption.Decrypt (inPayload, outPayload);

orignal we always start from closest to us

orignal we it's a nighmare

orignal OBEP would never check results of intermediate decryptions

orignal only tunnel owner does

orignal and for OB owner decrypts everything before sending

zzz the only way to do OB is to allow the hops to inject messages backwards. But hops don't know if it is IB or OB. So they'd have to inject both backwards and forwards

orignal yes, hop insert such a message and OBEP will receive garbage

orignal that's all

orignal I don't know a way how to do it for OB

orignal the only way is bi-derectional tunnels, that was my another proposal

orignal but the original discussion was not about this

orignal why can't tunnel owner tell peers that they want to exptend a tunnel or terminate earlier?

orignal send another garlic similar to TBM

orignal or even TBM itself with additional code

zzz sure, anything is possible, the problem is that any tunnel that is extended or terminated or not 10 minutes is "different" from the others

zzz so it leaks information / allows correlation

orignal if a tunnels becomes inactive it produces the same infomration leak

zzz that's a lot more difficult than just looking at extend/terminate/exkpire messages or fields

dr|z3d can we go some way to mitigate the difference in tunnel duration by introducing some randomness when it comes to tunnel duration?

dr|z3d ie, if instead of a fixed duration, we set a low and high limit and randomize, then is correlation more difficult?

orignal yes, good point

orignal some variance

dr|z3d min 5m, max 20m perhaps.

dr|z3d (or some low and high limits)

dr|z3d the question is, can we then bail early or extend?

dr|z3d if Alice decides she wants a graceful restart, for example, but doesn't want to wait 10m, then with a random range of tunnel lengths, it won't look out of place if she bails after 5m. I think weko was touching on this with his "shorter duraation" idea.

zzz there's two parts to all this

zzz the "mechanics" part - new I2NP msgs, or TBM params, or mid-tunnel-injection, or backwards msgs, or bidir tunnels, and the req'd crypto - it's very messy but doable

zzz but the _security_ part - prove that this does not weaken security in any way, analyze all the tunnel hop threats in our threat model - I've never seen orignal or anybody else even try

dr|z3d bidirectional tunnels sounds like a step backwards to me.

zzz until the security is analyzed (which could take months), it's just another idea with marginal gain and unknown risk -> /dev/null

dr|z3d :)

orignal dr|z3d you should use diffrent bidericational tunnels for IB and OB

orignal however their are easier to maitain

dr|z3d not sure I fully understand what you're proposing, then, orignal

orignal bidrection lets you

orignal 1. let owner know that peer goes down immediately

orignal 2. correct latency measurement

orignal when you build a tunnel it's easier to find who to blamer

dr|z3d yeah, but bidirectional also gives an attacker the opportunity to monitor both inbound and outbound traffic in the same set of tunnels. unidirectional makes us less susceptible.

dr|z3d (we've always differentiated ourselves from Tor by virtue of unidirectional vs bidirectional tunnels/circuits)

not_bob unidirectional is very good for many reasons.

zzz right, so any bidir proposal needs to start by proving jrandom wrong. Now go look at proposal 119 and see what's missing.

orignal dr|z3d that's the whole idea. we still use 4 tunnels for bi-directional communications

orignal we consider bidrection tunnel as two different tunnels

dr|z3d write it up, orignal :)

orignal impossible ))

dr|z3d there's a bag of chocolate potato chips and a bottle of cherry vodka waiting.

dr|z3d where it's waiting I couldn't tell you, probably some dead drop site in the middle of Moscow.

orignal finally. after few years I have implemented sock5 for upstream socks proxy

not_bob_afk Very good!