IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2024/02/11
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 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 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
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!