zzz
I'm working on a nasty streaming problem and it's not going to be fun
dr|z3d
what's the issue?
zzz
I think it's a jrandom design flaw, but I'll need to kick out major to discuss further
zzz
maybe later
dr|z3d
oh, that bad. :|
weko
zzz: can you comment my suggestion, please?
zzz
weko, I agree with the issues dr|z3d said, and there's a lot more problems also
weko
zzz: what problems? And I just don't understand, how publishing public info can deanonimize router.
zzz
- you can't send a message _to_ the middle of a tunnel, because of tunnel encryption
zzz
- you can't send a message _from_ the middle of a tunnel, because of tunnel encryption
weko
zzz: garlic?
zzz
- the OBEP doesn't know who created the tunnel and wouldn't know where to send the response
weko
zzz: what is OBEP?
zzz
- neither the middle hops nor the OBEP have any keys to encrypt a response
zzz
outbound endpoint
weko
zzz: we can say OBEP our inbound tunnel, how in tunnel creation tunnel.
weko
zzz: routers can use keys, that thay recived from tunnel owner
zzz
yes the OBEP knows what IBGW to send the tunnel build response to, but that IBGW may be gone later
zzz
the keys are unique to the tunnel build process, they can't be used to encrypt arbitrary messages
weko
zzz: we can say in IBGW every polling packet
zzz
that's de-anonymizing
weko
zzz: it is really hard to be changed?
weko
zzz: why?
weko
We send our tunnel data, nor our router data
zzz
middle hops don't know if they are IB or OB
zzz
middle hops shouldn't know the 'paired' IBGW of the creator
weko
zzz: but IBGW and OBWP knowns. middle hops don't need knowing this
zzz
middle hops don't know anything
zzz
plus my first two issues
weko
We don't say tunnel data for response for middle hops, only for OBEP
weko
zzz: I answer to this issues
weko
Can you say why I don't right?
zzz
I don't understand, please try again
weko
What you don't understand? What message?
zzz
<weko> We don't say tunnel data for response for middle hops, only for OBEP
weko
We use key, what we give OBEP; another routers can't encrypt this data
weko
This is why we can say something to only one router
zzz
these are the encryption problems:
weko
Like in tunnel creation garlic, as I said before
zzz
<zzz> - you can't send a message _to_ the middle of a tunnel, because of tunnel encryption
zzz
<zzz> - you can't send a message _from_ the middle of a tunnel, because of tunnel encryption
zzz
<zzz> - neither the middle hops nor the OBEP have any keys to encrypt a response
weko
But we can implement this. This mechanism like a tunnel creation, but after of tunnel creation
zzz
This is the anonymity problem:
zzz
<zzz> - the OBEP doesn't know who created the tunnel and wouldn't know where to send the response
zzz
sure, we can implement anything
weko
We say OBEP our inbound tunnel
weko
Like in tunnel creating
zzz
<zzz> yes the OBEP knows what IBGW to send the tunnel build response to, but that IBGW may be gone later
zzz
<zzz> the keys are unique to the tunnel build process, they can't be used to encrypt arbitrary messages
zzz
I've told you why it's hard
zzz
you tell me why it's important
weko
1. We say IBGW for response in every tunnel polling message
weko
2. But transits use encryption, that means transits already have symmetric encryption keys; we can use it keys.
weko
zzz said we can't say sth to OBEP only (why?)
weko
Okay, I think no actual issues, what means I can write proposal.
weko
Should I write specific implementation details in proposal, or should I just describe how it works in detail?
weko
If first I mean specific protocol example
weko
In*