On 2013-09-04, at 8:09 PM, josef.win...@email.de wrote:
> Can a developer please explain to me why something like the
> following obfuscation of 'torified traffic' is exploitable?
>
> Suppose a scenario where a collective of authorities is able
> to observe large parts of the www. Then observing
On 4 September 2013 20:09, wrote:
> Now node B does not stream the data to node C, but obfuscates
> it. That means if there are n packages it transforms them into
> m packages in some unpredictable way and each new packages gets
> a small amount of additional random-data.
> (The point is that the
Can a developer please explain to me why something like the
following obfuscation of 'torified traffic' is exploitable?
Suppose a scenario where a collective of authorities is able
to observe large parts of the www. Then observing traffic
correlation can unreveal a connection through the network.
Sorry to have missed the chat. Just dealing with the +1 in my family :)
Update below:
>#16 Make push-to-talk VoIP work
>August:
>- Unclear. Asked Nathan in private mail on September 4.
- ChatSecure OTR-Data feature is complete, enabling arbitrary data
stream with mime-type sharing within OTR T
On 8/30/13 8:00 AM, Karsten Loesing wrote:
> Hi all,
>
> I'd like to schedule an IRC meeting to discuss what progress we made on
> sponsor F deliverables in August. Time and place are:
>
> Tue September 3, 18:00 to 19:00 UTC in #tor-dev
Below are my notes from our discussion in #tor-dev yeste
>> # HS descriptor related extension to getinfo event:
>> GETINFO desc/hs/n.onion [network]
>>
>> n.onion fromcache
>> n.onion fetchok
> I guess that is not used in this case.
Yes, it is / should be. It may require a bit of extension to the structure
holding the descriptor to carry it around.
