Bruce Shneier posted a fascinating article here. Tor allows you to be anonymous on the Internet. The challenge of anonymity on the Internet is an interesting problem we don’t often think about. The Internet was not designed to allow us to be anonymous. We know that all machines connecting to the Internet have a unique IP address. You’ll say, “that doesn’t tell anyone my name or the name of my company”. However, it does uniquely identify your traffic on the Internet. If you connect to a website your computer is actually connecting to a server (like we saw in the Netstat posting). The server wants to send back the web-page you just requested. The server knows you by the connection that you just established, and can send back the page you requested. So the server must know your IP, which, today is typically the IP of your router. Still, this IP identifies you or your household whether you like it or not; there is no and ifs or buts about it. You can imagine that there are people out there that are adamant about wanting to be private on the Internet. Perhaps they have nefarious reasons and that’s why they want anonymity. Others just don’t want websites or ISP’s knowing what they do on the Internet.

So Tor (the onion router) provides anonymity for people. It’s a highly complex system. In a very short explanation, your traffic is bounced between a number of Tor routers that are in different locations all over the world. The traffic is encrypted between each Tor router. After the traffic is bounced between the Tor routers it exits the last Tor router and is then routed normally on the Internet. The website whose server you connected to serves the web-page page back to that last TOR router, and it travels back path through all those TOR routers back to you. The only Ip that the server actually knows is the IP of the last Tor router – not your IP address. This solution is extremely robust. If any of the Tor routers were compromised they still would not reveal any information about your traffic due to the encryption scheme that is used between Tor routers.

This security researcher ran his own Tor exit nodes for an experiment. By examining the traffic (also called “sniffing”) on his TOR router, he ended up seeing many email log-on credentials, as well as other log-on information of Tor users. Some of these users were government agencies in Third World countries, and also corporate account credentials. These people using TOR did not understand what the real purpose of TOR actually is. Tor allows you to use the internet anonymously, by encrypting traffic within the Tor network. However, it ultimately needs to exit onto the internet. When it does exit, the traffic is routed in the clear, so it does not, in any way, encrypt traffic leaving the exit node. If you want to be secure you will need to use an ‘end to end’ encryption solution like SSL. Anonymity does not mean privacy. I like the analogy he uses with Alchoholics Anonymous.

I found a really neat Java Class the other day here ; a class that preforms one-way hash encryption. This class has some important Java concepts that beg to be discussed. What does this program do? We touched upon hashing in a previous host when talking public-key encryption. In this example we are taking some text and hashing into gibberish. We call it one-way because it’s impossible (assuming you’re using a good algorithm) to obtain the original text corresponding to this hashed string. One of the applications for this class is password authentication. Let’s say you signed up to use your bank’s online service. When you first started, you created your log-on credentials including a user-name and password. When you log-in, you supply your user-name as well as your password. The bank must have your password stored in a database with your user-name and other identifying information about you. Let’s say this database some how was lost, or some evil employee at your bank decided they wanted to log-on to your account. Assuming they had access, they can query the database and look up your password, right? Actually not if they are using one-way encryption. Instead of storing your password as clear-text it’s hashed into a non-sense value and that value is stored in the database. Now, when anyone looks at this password it’s useless, as they have no way of obtaining your real password. Each time you log in the password you provided is hashed , and compared against the value stored in the database for your password. If they match exactly you are granted access.

This one-way encryption class uses the singleton design pattern. I remember on my interview for my current job being asked to write a Java object using the singleton design. Here is the solution:

public class MySingleton{    

private static MySingleton instance;   

 private MySingleton()    {    }    

public static  synchronized SingletonObject getInstance()    {     

 if (instance == null)       

  instance = new MySingleton();  

return ref;    }

}

Typically Java objects are instantiated like this:
>Object obj = new Object();

A singleton is called differently.

MySingleton signleton = MySingleton.getInstance();

A singleton is an object that cannot be instantiated directly by other developers. The singleton class is controlling how the class itself is created. The first time getInstance() is called, the singleton object is instantiated. Subsequent getInstance() requests will return the instance that was created. The singleton is designed to ensure that there will be only one instance of this class created by the JVM. Why would I do such a thing ? Let’s say you are implementing a program that gives out sequential and unique numbers like the one you take at a crowded deli or Motor Vehicle Office. This class needs to be global across multiple threads, and your takeAnumber() method will be synchronized; meaning only one thread can take a number at a time, thus preventing any concurrency issues. Each “thread” waiting to get “on line” would need to call getInstance() to get the instance of this Counter class, and with the instance they can call the takeAnumber() method. This Counter class can maintain the counter and properly assign unique numbers to each thread. Along a similar vein, that’s why the author of the encryption class used the singleton design pattern. He wanted to be certain that each time the encrypt method was called it would hash into a unique value. By using the singleton design for the class he enforces all threads to use just one copy of the class, and also synchronizes the encrypt method; again making sure there were no collisions to the method by multiple threads. I added my own main method to the PasswordService class. The main method allows users to try out the encryption class by entering in user-names and passwords. I used a HashMap to store users since, I don’t have a database and I want to keep it simple. The key to hashmap is the username, and the encrypted password is the value. Here is my main() method.

public static void main (String args[]){ 

 String input=null;   String [] temp = null;   HashMap users  = new HashMap();  

 PasswordService passwordService = PasswordService.getInstance();

 // getting the instance to the PasswordService singleton class    

do {      

     System.out.println("(A)ADD,(L)List,AT(Authenticate)"); 

       try {             

                    input = stdin.readLine();              

                        temp=input.split(" ");      

          } catch (IOException e) {              

         // TODO Auto-generated catch block             

                e.printStackTrace();       }   

            try {   

           if(temp[0].equalsIgnoreCase("A")){               

            users.put(temp[1],passwordService.encrypt(temp[2]));      

              }    if(temp[0].equalsIgnoreCase("L")){       

               for (Iterator iter = users.keySet().iterator(); iter.hasNext();) {          

                       String key=(String) iter.next();            

                      System.out.println("username="+key+" ("+users.get(key)+")");      

                     }     }   

                   if(temp[0].equalsIgnoreCase("AT")){       

              String passedInPassword=passwordService.encrypt(temp[2]);        

             String storedPassword=(String) users.get(temp[1]);    

              if(passedInPassword.equals(storedPassword))        

              System.out.println("You are succesfully authenticated.");    

                 else        

            System.out.println("Wrong password. sorry.");      

  }    }catch (ArrayIndexOutOfBoundsException e){ 

   } 

 }while(true);}

Here is a screenshot showing the program running. Notice how I added a few users. I then listed all the users currently stored in my hash-map. Along with each user I printed the encrypted password gibberish in parentheses. Notice how there is absolutely no way anyone can get to the password from that mess. Lastly, I authenticated some users.