~dr|z3d
@RN
@StormyCloud
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+RTP
+Unbur
+Xeha
+acetone
+j6
+profetikla
+r00tobo_BNC
+snex
+uop23ip
+weko
An0nm0n
Arch
Danny
DeltaOreo
DiCEy1904
Irc2PGuest43975
Irc2PGuest48909
Irc2PGuest67564
Nausicaa
Onn4l7h
anon2
anontor
anu
bak83_
boonst
cumlord
fujifilm
goose2
goose2_
itsjustme
mareki2pb
not_bob_afk
onon_1
poriori_
qend-irc2p
shiver_
thetia
u5657
unwr
veiledwizard
wetpussy
xen_NULL
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!