Monthly Archives: September 2009

Cryptographically Secure Random Numbers in Java

The Random Class

Most people wanting to generate random numbers in Java do something similar to the following:

public static void main(String[] args) {
  Random generator = new Random();
  int randomnumber = generator.nextInt(5) + 1;
  System.out.println("Dice rolled: " + randomnumber);

This is perfectly fine for a simple dice rolling application where there isn’t going to be much effort put into cracking it. For example in this application the only real reason you would bother cracking it would be to show off a neat party trick to your geeky friends. No doubt though the effort wouldn’t be worth it.

Java states that the Random class and its subclasses must produce predictable results when seeded with the same data. This however is not why this is insecure, and it is useful when testing. The reason that this class is predictable though is the way in which it is seeded. The Random class, in the absence of a seed in its constructor it will seed its random number generator with the current time in milliseconds. This means that if somebody knows the time that the Random object was seeded and has several consecutive bytes of output then they can reasonably predict the next numbers. Once somebody has discovered the seed for the generator all number produced from it can be seen as compromised.

The SecureRandom Class

The SecureRandom class is different, it again uses algorithms that when seeded will produce predictable results, but the algorithm is much more complex. It uses a digest algorithm such as SHA-1 on the seed and a counter to generate random data. SHA-1 is much more costly than the simple algorithm used in the Random class and as such it is much harder to brute force.

Its true strength however lies in the method in which it is seeded. The SecureRandom class is seeded using true random data gathered by the operating system. This is data gathered by the OS from sources of true randomisation, such as mouse movements, network packet arrival times, IO statistics and interrupts. On Linux the data is gathered from /dev/random and on Windows via the CryptGenRandom() call in Windows.

When using SecureRandom though you should be aware of a few things:

  • The more random numbers some can get a hold of the more likely they can figure out the seed. You should either throw away the SecureRandom object every now and then or reseed it. Keeping in mind the next point though.
  • The seeding the generator takes entropy out of the system, if it cannot get any entropy it will block until the system has some. This means if you’re reseeding the generator too often your program will hang along with anything else on the system requiring entropy.
  • Don’t seed the SecureRandom class yourself, unless you are 100% absolutely sure you are seeding it with purely random data, or you are testing and need repeatable results. Whatever you do, don’t let your testing code leak into a production system.

How to decide

Generally when you’re coding you don’t need secure random numbers. For example if you’re writing a number guessing game, or a quiz generating program then high quality random numbers aren’t required. It should be noted though that if money is involved people will often go to greater lengths and a more secure generator will be required, such as in a slot machine.

Again generally if what you are generating is a security token of some sort then you will need a secure generator. For example a session id, a one time password or an encryption key. The exception here is a salt for a password, salts can be generated using predictable entropy sources, even a simple time stamp would work here (especially if your also storing the time stamp to measure password expiry).

Random Thought: For those of you who don’t know Bruce Schneier is the Chuck Norris of cryptography.

Google C&Ds CyanogenMod

In an act that appears to contradict both the ‘do no evil’ and the ‘android is open’ mantras of Google they sent a Cease and Desist to CyanogenMod creator Cyanogen. This effectively means that all cooked versions can now no longer include and Google applications, sync with Google services or the many other closed source parts of the ROM. I use Cyanogen’s mod and this effectively cripples it to a worthless Linux phone distribution. Google have essentially said to me “You know that T-Mobile G1 you brought that was supposed to be completely open? Well we never made all the good bits open, and now we’re taking them away.”. I can’t use the Official ROM because I live in Australia and it constantly sends text messages to T-Mobiles myFaves which costs me a fortune. So Google has removed my ability to use their services on my ‘Google’ phone. So now wherever you read a press release where Google claims that Android is open you know what they really mean is they made the stuff they had to open and closed the rest.

I see only one way out of this mess, we need developers to replace all the closed source parts of Android with free software solutions. This means Android will be free and fully open source. Why stop there though? Lets make Google’s decision into one they will regret! As the open source community is replacing the closed source apps we should build in functionality to allow the phone to work with Google’s competitors. When you first used the G1 you had to sign in using your Google account. What if that same box let you sing in with your Live Id, your Yahoo account or even OpenID? Imagine the Android phone being written in completely open source to work on any operator! It wouldn’t be hard either, most are beginning to provide APIs to their accounts and I’m sure they’d love to help.

Edit: According the the Save Cyanogen Petition application on the market it is impossible to even run the ROMs that Google claim to support without the Google binaries.

Random Thought: Did you know the first Australian computer was built by Trevor Pearcey and Maston Beard in 1947-1951.

Using Subversion over SSH

Subversion is an amazing tool that you can use to keep track of all the changes you make to a group of files. If you haven’t used it before, or have never heard of ‘version control’ then you should probably read the Subversion Book.

Few people don’t realise that subversion has the ability to connect to a remote repository via SSH. Its extremely simple and can give you all the advantages of storing your important files on a server while still having them readily accessible on your desktop. This means that for example you could have your files (and every old version of your files) stored on a RAID device on a server while working with them locally on your desktop.

To set this up its actually rather simple. First you create your repository and perform the initial import of the files. I usually make it in my home directory as follows:

mkdir -p /home/daniel/svn/newproject
svnadmin create /home/daniel/svn/newproject
mkdir -p /tmp/newrepo/{trunk,branches,tags}
svn import /tmp/newrepo file:///home/daniel/svn/newproject -m "Create Initial Structure"
rm -rf /tmp/newproject

These commands are basically what you’d use to create any subversion repository and people familiar with it require no explanation. Most people probably even have is scripted to make it just that much easier. Here comes the fun part though. Next we (on our local machine) check the files out. To checkout subversion repositories over ssh you simply use the following command:

svn checkout svn+ssh://username@servername/home/daniel/svn/newproject/trunk newproject

All going well you will now see a password prompt and upon successful authentication the files will be checked out. This is all that is required and from now on you can simply use the ordinary svn commands.

Random Thought: … and I says to the kernel developer, I says “git this!”

The T-Mobile G1 Phone

The T-Mobile G1 Phone goes by a few names. HTC Dream and Google Android Development phone are two more. Essentially they are the same hardware and the only change is the software. The Android Development phone unlike the others comes with an unlocked bootloader allowing you to flash any software image you want where the other two will only allow software signed by either HTC or T-Mobile.

I bought mine two weeks ago and it has completely replaced my Windows Mobile phone to the point where I actually gave it away. The main issues that I have with Windows Mobile was the instability and the difficult to use interface. This new phone was a breath of fresh air. Amazingly when I was testing it out with the seller it received a weeks worth of SMSes indicating that my Windows Mobile phone had stopped accepting them.

I opted for the T-Mobile option. Mainly because I found one cheap on eBay but also because I knew of an exploit to easily get root, flash a new bootloader and install whatever OS I wanted. I knew with almost absolute certainty that I would want to be able to play with root access to the OS. I could have went with the HTC Hero or Magic (the successors to the G1) but I liked the idea of the flip out keyboard way too much.

The G1 is easy to use without a stylus, in fact it won’t work with a stylus as is uses a capacitive touch screen. This means all the applications, the keyboard and the core OS are designed with that in mind. While I could use my old phone with my thumbs many of the controls were impossible to use without perfect precision. Generally all the controls on the Andriod are larger and easier to manipulate, where the Windows Mobile controls are clunky and small.

The Android marketplace is also something that Windows Mobile could certainly have done with. It is an almost perfect image of the iPhone App Store, except that in the culture of open source most of the applications are free. The applications are easier to search for, review and download making the Android Marketplace a much easier to use and more polished tool.

One thing this phone and my last one have in common was the hacker community around them. Both have multiple ROMs available and its relatively easy to flash a new one. I’m currently running the latest stable CyanogenMod (4.0.4) which was extremely easy to flash courtesy of the latest kernel vulnerability and some specially designed tools.

Random Thought: I thought Androids could make breakfast for me.

GPG Asymmetric Encryption

So you have your keys all set up, you’ve found a dozen people to sign them and you’ve entered the web of trust. Now you have an extremely confidential file, let’s say your tax records, and you want to send them to your accountant.

The first step is to find your accountants key. You know from talking to him earlier that he publishes to the same keyserver as you, but he forgot to give you his key id. To find him we have to run a GPG search as follows:

$ gpg --search-keys "Mister Accountant"
gpg: searching for "Mister Accountant" from hkp server
(1)    Mister Accountant 
 1024 bit DSA key 63ABD9EC, created: 2007-11-07
(2)    Mister Accountant 
 1024 bit DSA key 01129335, created: 2006-09-11
(3)    Mister Jones 
 1024 bit DSA key DFAAA99E, created: 2006-02-18
Keys 1-3 of 3 for "".  Enter number(s), N)ext, or Q)uit >

You’ll notice from the output that multiple results have been returned. Two of them even have the same uid. So how to we know which one to use? At the moment we don’t really. We know what his email address is from his business card so let’s download both those matching keys. You can either enter multiple numbers on that screen or use this command:

$ gpg --recv-keys 63ABD9EC 01129335
gpg: key 63ABD9EC: public key "Mister Accountant " imported
gpg: key 01129335: public key "Mister Accountant " imported
gpg: Total number processed: 2
gpg:               imported: 2

Now we have both keys we need to establish which one really belong to our accountant. To do this we’ll examine the signatures on the keys. For that we use the following commands:

$ gpg --list-sigs 63ABD9EC
pub   1024D/63ABD9EC 2006-09-11
uid                  Mister Accountant 
sig          A3B14DFA 2006-09-11  Daniel Hall 
sig 3        63ABD9EC 2006-09-11  Mister Accountant 
sub   2048g/DAA19215 2006-09-11
sig          63ABD9EC 2006-09-11  Mister Accountant 

[daniel@rosella ~]$ gpg --list-sigs 01129335
pub   1024D/01129335 2007-11-07
uid                  Daniel Hall 
sig 3        01129335 2007-11-07  Daniel Hall 
sub   2048g/BBBBBBBB 2007-11-07
sig          01129335 2007-11-07  Daniel Hall 

You now see that your good friend Daniel, who you trust has signed one of the keys, but nobody has signed the other. This means that as long as you trust Daniel then you can trust that key to be Mister Accountant. So now comes the easiest part of the process. Now you encrypt the file. In this case we also want to sign it so that our accountant knows these documents come from us. We just run the command:

$ gpg -e -R 63ABD9EC --sign 

Again you can add the armour option to output the file as ASCII which is suitable for attaching to an email, or for those of us who are ultra secretive hiding inside a JPEG file. If you want to try your hand at hiding things in JPEG files install SteGUI or steghide.

Random Thought: Did you know the first compiler was written by a woman? Read the story of the first compiler.