[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Sum legl trubs wid TOR en France + more



I agree with you about the hops. Thanks for posting the info about hard drives. I had no idea.

On Sun May 14 21:58:42 2006, crackedactor@xxxxxxxxxxx <crackedactor@xxxxxxxxxxx > wrote:

FYI.

Hard Disks.. (so abou the length)

It is possible to find old data on "scrubbed" disks even with 100's of cycles of writeover.

The reason is coz of wobble or track shape. Imagine washing machine at home, as it spins it wobbles. Now look at your hard disk (get an old one out that is past it and open it up!) you'll see the disk rotates at high speed. Thoughout its life it has a wobble, just a small one. But this wobble changes now and then with time. So when your write/read head lays down its magnetic bits on a track it does so with a wobble in it. The track itself is wider than the individual bit patterns and so there is only partial overlap with past bit patterns. When a disk finds a bits pattern which is wrong (from the extra data it stores for check bits)  and it cant recover logically the original pattern it starts to "wipe" away the edges of the bit pattern on the track, so as to "clean" the signal. It does this by offsetting the head from the current midpoint of the track. It then tries a RE-READ the cleaned track. This is often susuccessful in removing "noise" from past bit patterns so as to ge
t "clean" read of the last bit pattern. If not successful this process might be done any number of times upto the maximum "re-reads" specifed in the disk firmware.

It is this EXTRA width and the varying wobble that allows data to be left on the disk even if "military strength" scrubbing is perfomed by software. This is particularly relevant ot data put on when the disk is young remaining there for some months so that the disks bearing wear changes the wobble. New bit patterns written over this old bit pattern are almost vertaain to bew able to be read - even years later!


The more..

A while back it was asked if "3 hops is enough". At the time I had prblems getting to my email account so here's my 2 cents.

The current set 3 hops is a predictable number of hops and because of that, the predictability is a DEFINITE weakness in TOR.

Its all about ENTROPY (the mathematical concept not the network).

If the current systme of a fixed 3 hops was changed to allow 3-6 hops then I think this would create a much LESS predictable system.

Pulling the records on a ALL our TOR servers is possible. And then going through them records to see the 3 fixed hops by computer is simple!

You then only need to monitor the traget web site to see the EXIT server and follow them back. Remeber all US, European, Australasian & many Asian govs are now co-operating. so much of the data is ALREADY being pooled.

BUT if a random 3 to 6 hops was the norm then TOR becomes much less predictable and the computers now have to do mulptile path analysis for 3 to6 nodes, instead of just 3.

Ok so not everyone would need this, or want it and ewe dont know the effects on the system.

It looks like we have enough middle men to cope so why not give it a go.

Allow the users to set their min and max hops (3 to 6) and let TOR client portion set up random length circuits within those limits.

If this was to be tried out it would be best to use 3 to 4 in the intial version and see how it goes.

Also to hinder timiing attacks and log lookup software it would be a good idea to allow the TOR client side to specify random "delay" for the hops to put into its packets. Specify max packet delay time and then the hop randomly distributes between this and zero delay, some packets might then get forwarded in the wrong order, that would further confuse any attack software. I say this should be the clients instruction because they may not want any delay (eg for streams such as voip).

Once again a little at a time, from one version to the next!



Ok .. i'm done.

Message sent with Supanet E-mail
Signup to supanet at https://signup.supanet.com/cgi-bin/signup?_origin=sigwebmail