## Catchup Notice: My New(er) Website

A little while back I moved to posting tech articles (when/if I make them) on my site at http://darkotter.com/. All go check there if you want newer stuff! :P

## MKeys

I’ve just finished work on (the first version of) my specialised XMMS2 client, MKeys. As you might guess from the name, this client does one thing, and one thing only.

MKeys is designed to sit quietly in the background, and whenever you press a multimedia key (configured in GNOME) it captures it (much the same way as Banshee/Rhythmbox et al do), and instructs XMMS2 to take the appropriate action.

I like to think it’s pretty simple to use, all you really need to do is run it when XMMS2 is running (although it’s usually nicer to put a script to run it in your startup.d folder for XMMS2). It will automatically exit when XMMS2 closes.

For those who want to give it a whirl, the source code, Git repo, and tarballs of v0.1 are available at the project page on github: http://github.com/DarkOtter/MKeys

Posted in Software | Tagged , , , , | Leave a comment

## Techology Splurge

I’m planning a technology spend-a-thon of epic proportions soon, I plan to shell out a whole £206.73. I am quite excited about it though, my plan is as follows.

The most part of this expense is the new phone I plan to purchase, the Motorola DEXT. I wanted to try and upgrade to a phone that can also fulfil duty as an mp3 player (so it needs a standard headphone jack), and as a camera (so it needs a reasonable resolution – nothing too high, 5MP will do me). I was very pleased to find an Android phone available on pay as you go, as this means that my phone will run linux, I can add lots of interesting apps to do stuff, it will integrate well with my gmail e-mail should I choose to use it (and more importantly calendar), and it’ll mean my phone runs linux (enough geek points that I mentioned it twice :P). Hopefully, although I’m not 100% sure about this, it should mean that also for the first time I will have an mp3 player capable of playing OGG and FLAC files.

While the bulk of the money I plan to spend will be on that phone, there are two other items. Firstly, partly related to using my phone as an audio player, I found out that Sennheiser have released a successor to the PX-100s, the PX-100-IIs. I want them. Ad I am going to get them.

The fial and least expensive item is a ‘Patriot XT Boost 150X 8GB Flash Drive’. To put it simply, I want to replace my otherwise perfectly good but U3-ruined and unbootable flash drive with a super-fast, U3-free, bootable one. Plus, it’s supposedly ruggedised and waterproof, which should mean it’s at least a bit tougher whether or not it actually lives up to its claims.

However, the plan is not solid, and I suspect I may change my mind about the flash drive and go for a super-mini one in the end instead. Who knows.

EDIT: I have bought the phone and headphones so far. I don’t know if I will actually buy a new flash drive in the end – at least not yet.

## My BASH Prompt

I’ve just spent some time customising my BASH prompt. In fact I wrote a 111 line BASH script to set it up. And I suspect it’s going to get longer :P.

For now it’s got:
Username, highlighted red when you’re root (e.g. sudo -s)
Hostname, highlighted red when (the prompt thinks that) you’re sshed into a remote machine
The Path of the CWD (of course)
Some Git information (when in a Git repo), the current branch, current HEAD’s SHA (abbreviated), and whether there are any unstaged changes/untracked files, and if there are any staged changes.

I’ve put it up on github as a gist: prompt.sh

Posted in Software | Tagged , , , | Leave a comment

## Moving a GPG Key (Privately)

Sometimes I have to move my GnuPG key between computers for some reason, and although GnuPG does have features to export your private key, they are not as well documented, probably out of choice to discourage their use, as they can be a security issue. I have developed the following method to export both the public and private keys together, so that they can be easily imported, and with the minimum of secret data written to disk.

1. Find out the keyid of the key you wish to export. You can get this from the output of

 

gpg -K
 

Note that the capital K is important so that it lists secret rather than public keys.

2. First, export the public key. This is of course public info, so no worries about security here

 

gpg --output pubkey.gpg --export {KEYID}
 

3. Now, in one fluid step, we will export the secret key, combine it into one file with the public key, and then encrypt it for transfer

 

gpg --output - --export-secret-key {KEYID} |\
cat pubkey.gpg - |\
gpg --armor --output keys.asc --symmetric --cipher-algo AES256
 

You will be prompted for a passphrase during this, this is the passphrase just for this temporary encryption for transfer. So use a good passphrase for security, and remember that passphrase!

4. Now, transfer the keys.asc file to the new computer or wherever. Because it’s encrypted you could technically do this over the internet and it should still be secure, but I would suggest not using the internet for added security. When I last did this I just used a normal flash drive.
5. On the new computer, we need to import the keys from the file. So, run this command to unpack and then import the keys (using pipes again)

 

gpg --no-use-agent --output - keys.asc | gpg --import
 

6. And that, should be, that.
Posted in Uncategorized | 18 Comments

## Estimating Password Strength

This post was originally intended to be part of my guest series on cryptography at a friends blog, but I haven’t had word from him about it for a while. So, it’s mine now :P

The strength of a password is usually based on the idea that an attacker will have to guess the password by trying lots of different possibilities. Depending on the nature of the password this may be the kind of ‘lots’ that a computer can try very quickly, or it could be the kind of ‘lots’ that would take years.

### Entropy

To start with, let us assume that the attacker knows absolutely nothing about the password. Let us assume also that they are going to brute-force the password, either through necessity or by choice. This gives essentially the best possible case of password security.

The number of possibilities that the attacker will have to try in order to be guaranteed to find the password is related to the information entropy of the password, or more precisely the information entropy.

$H(X) = - \sum^n_{i=1}p_{x_i}\text{log}_2p_{x_i}$

The information entropy measures how close to random data the contents of a set are. In the context we will be using it, things are not too complicated. The set $X$ will be all the possible values of a byte (0-255 or 0x00-0xFF). The values $p_{x_i}$ are the probability of a particular value occurring.

### Best Case Scenario

To start with however we are going to leave the probability approximated, predicated on an assumption. Let us assume that the attacker only knows which classes of characters are used in the password. Take an example password: Hello!42. We would be assuming that the attacker knows that lower and upper case letters are use, numbers are used, and the character ‘!’ is used.

However, the attacker does not know how many times each of these characters is used in the password. This means that as far as the attacker knows, each possibility is equally likely. This means that each value in our set $X$ which falls within the classes we’ve just stated has a probability of $1/N$, $N$ being the number of characters in the classes. This allows us to make a simplification of the formula.

$H(X) = - \sum^N_{i=1} \frac{1}{N}\text{log}_2\left(\frac{1}{N}\right) = - \text{log}_2\frac{1}{N} = \text{log}_2 N$

This is vastly simpler. In our case $N = 26 + 26 + 10 + 1 = 63$. So the entropy of our character set is $\text{log}_2 63 \approx 5.977$. This may seem tiny, but this is the entropy of our character set, which should be roughly equivalent for the number of tries needed to guess each character. So to get the estimate of the strength of our password, we multiply by the length (8) to get 47.818 bits. So we can see that, even in this best case scenario, this password is a lot weaker than most encryption algorithms (hence why passwords are usually the weak link in a security system).

### Not All Characters Are Equal

However, another way of making a somewhat less ideal case estimate of the password strength is by directly using the entropy calculation. In this case we have to use the full formula, because $p_{x_i}$ will no longer be assumed to be a particular value and we will actually calculate it. This is simple to do, simply count the number of times the character occurs in the password, and then divide that by the length of the password.

However, introducing this into the calculation means that it’s more complicated to do, and so I wrote myself a python script to perform this calculation. The full script is available as one of the scripts in this one of my Github repositories. However the section which I will use for this is shown below:


def H_data(data, base = 2):
if not data:
return 0

entropy = float(0)
n = float(len(data))

for x in xrange(256):
p_x = float(data.count(chr(x))/n)

if p_x > 0:
entropy += - p_x*math.log(p_x, base)

return entropy


Running the above code on our example password gave an entropy of 2.750 bits, significantly less than our best case scenario. Multiply this by the length and you get a strength of only 22 bits. However, for the attacker to be able to break the password with this many tries he must know exactly which characters appear in the password, and how many times they appear – in other words the only thing he does not know is the order.

### Take a Chance

Thus far we have assumed that we will measure the strength of the password by the number of tries an attacker must make before he is guaranteed to find the password. So, using the first (and I suggest using this one usually) method, our password has a strength of 47.818 bits. This means the attacker must make $2^47.818 \approx 248114606917826$ guesses. This seems like a lot, although depending on various factors it could be just the blink of an eye for a computer. However, due to the laws of chance and probability, an attacker is more likely to have found the password than not found it as soon as he has searched half the possibilities. In other words, he will probably find it half way through.

This means he will probably have to make only half as many guesses. However, we need not deal with that large number, because of the rules of logs to base 2 etc. the end effect of this reduction of the number of tries is that the password strength goes down by one bit. In this case $47.818 - 1 = 46.818$. Nice and simple, n’est pas?

### Best Estimate

The first method of estimating password strength is usually used because it is assumed that the attacker is unlikely to learn the information required it make the second method valid without just finding out the whole password, in which case it will be useless to estimate how many tries he would need :P.

Thus, accounting for probability, our password is probably 46.818 bits strong. This is however far less strong than symmetric encryption algorithms which usually have 128 bit or 256 bit keys, so this password will still be a problem in security. Especially in the worst case scenario.

### From Bad to Worst

However, sometimes passwords can be even less secure. Other attacks can sometimes be used to guess a password, drawing on insecurities either of the password or the algorithms used to store it.

Dictionary attacks are used to crack weak passwords based on words. They shorten the number of possibilities by trying possibilities involving known words in English or another language first. They may also use additional algorithms to also crack passwords that are words with substitutions or additions. Our password would be vulnerable to a dictionary attack, because it is largely composed of the word ‘Hello’. Exactly how much quicker a dictionary attack would be is difficult to estimate, but it is thought to usually be a lot quicker.

Another method to speed the search can be used if passwords are stored in an insecure way. I won’t go into specifics in this post, but if a password is stored using a one way hash with a weak and or non-existent salt, a time-memory tradeoff technique can be used to reduce the time to crack passwords. The most common of these techniques is the use of Rainbow Tables. This form of password cracking may not seem all that bad seeing as using a one way hash without a salt is horrifically bad practice on the part of software developers.

However, guess who does it? That’s right, all Windows passwords are vulnerable to Rainbow Tables, meaning that specially made software such as Ophcrack can be used to crack most Windows passwords in a matter of seconds. Yet another reason to consider windows insecure.

### Windows Password Security

It is pointless trying to use a strong password for your windows login – as these passwords are vulnerable to Rainbow tables, any attacker will still be able to crack it well within an acceptable time-frame. This is one of the many reasons why I follow the following rule:

Any information that has been stored on a Windows computer is publicly accessible

This may be a bit paranoid and/or extreme, but at least this way I should stay as secure as possible :P.

Posted in Uncategorized | 2 Comments

## GnuPG Guest Series Finished

I’ve now finished the GnuPG part of my cryptography guest series on TmacUK. It’s been quite fun so far, I’m going to be away for a few days but when I come back I think I shall be continuing the guest series with a post on estimating password strength.

The various posts from this part of the series are:

Between them they cover the basics of the OpenPGP/GnuPG protocols and how they work, creating a GPG key, using it, and the basis of validity and the web of trust with regard to other peoples keys.

I hope you’ve found the series useful and/or interesting so far, stay tuned for more.

Posted in News | Tagged , , , | 4 Comments

## My Birthday

Happy birthday to me, happy birthday to me… you get the idea :P

## The Challenge Message

As mentioned previously, I’ve been writing a guest series on cryptography for one of my friends’ blog. Now, most of the readers of his blog (or so I’m led to believe) are white-hat crackers, as is he. So I decided that partway through the series (once I’d finished explaining the use of GnuPG) I would post up an encrypted message, encrypted using the testing key I generate during the tutorial, so that they can have a go at cracking it if they like.

To be perfectly honest, even if I’d just posted up a GPG message encrypted with standard parameters I don’t think they’d have much chance cracking it. But, just to make sure, I’ve pulled a few tricks :P. Firstly, the message has only hidden recipients, and the public key for the private key I used is not available on the web. So no factorisation attacks there. Secondly, just to make it a little more confusing I’ve put the GPG message in a picture. Oh, can’t tell where the GPG message finishes anymore eh? How long is it, which byte is the last byte of it, and when is it just picture? No-one knows (although it is pretty easy to work out).

So, hopefully it should provide some form of challenge for them. In case anyone’s interested, here’s the image:

Posted in Cryptography | Tagged , , | Leave a comment

## Cryptography Guest Series

I’ve just started work (and finished the first installment of) a guest series of posts on TMacUK. TMac is an old friend of mine from school, and recently he’s been studying ethical hacking (or something like that, I know he’s a white hat these days). As the title denotes, I’ve recently started writing some posts for him about cryptography.

The first post (already up here) is an introduction to GnuPG, the encryption system I’ll be using for the first section. It also discusses a few of the considerations of security in GPG. Next I shall be finishing off the rest of the things about GPG, which will probably be another 3 or 4 posts detailing how to use GPG, and I plan to finish off by posting a GPG message as a challenge for him and all his white hat friends to try and decipher. Needless to say, I’m going to make it hard for them if I can :P.

After the first part of the series discussing GPG, I’m going to move into the history and specifics of some of the algorithms, mainly RSA and AES (because they’re secure), and DES (because it’s an example of a cipher that has been broken). Unfortunately I’ll be on a lot thinner ice in terms of my expertise here, but I shall give it a go. I’ll probably also throw in a post on password strength and how to calculate it in there as well.

Hope you enjoy the series, keep your eyes open here to catch it.

Posted in News | Tagged , | Leave a comment