Tag Archives: Encryption

Google’s Privacy Bungle

Google has recently taken a large amount of criticism for capturing unencrypted wireless network traffic as part of its Street View project. Google admitted to the world that although it was only looking to capture station MAC addresses it inadvertently also captured the payload data. Many articles have emerged blasting Google for what Senator Conroy calls ‘This is probably the single greatest breach in the history of privacy’. I believe Google hasn’t done all that wrong, to understand why you need to know how a wireless network works.

Wireless networks can either be encrypted or unencrypted but in both these cases only the payload is encrypted. The packet headers which contain information about who the packet is addressed to and who it is from. The reasons for this are similar to why you might write a letter in code, but you would not write the envelope in code. In an unencrypted network the whole packet is sent in clear text including the envelope and contents. The difference between these analogies and how a real network works though is that to read the envelope you need to physically obtain it and there is only one copy. A wireless network broadcasts everything to everyone within 100 meters.

This isn’t really a problem if your network is encrypted as people will not be able to read it easily. If however your network is not encrypted its the equivalent of yelling out everything that you type into and read from your PC. Almost all banking websites will ask your PC to use extra encryption, but many other sites will not. So anyone in a 100 meter range of your computer or access point can watch everything you do on your computer.

What Google were trying to do was get a list of the locations of these access points. So they would have captured the headers of all packets they saw, grabbed the wireless routers address out of it and marked its location on a map. Except according to them they accidentally put code in that captured the whole packet. This meant that for all the unencrypted networks the Google Street View cars drove past they may have captured private information.

There is a class action in Germany against Google for capturing this data, and more can be expected elsewhere soon. Suing Google for this is like walking in to a public place, yelling out a bunch of private information and then suing anyone who happened to be recording at the time, or suing someone for writing down smoke signals you send to someone from the top of a mountain. If your access point is sending data unencrypted then every wireless device within 100 meters cannot help but hear your data, you’re just lucky most will ignore it.

If you really cared about your privacy you would at least make some attempt to restrict others access to your data. Not knowing is much an excuse as not knowing people were recording in that shopping mall. Don’t take your privacy for granted, check whether your network is encrypted, and if you don’t know how, get someone who does. Ignorance is not an excuse! This time it was Google, the next time it could be an identity thief.

Random Thought: If privacy is so important to people at the moment, what’s with all the data on Facebook?

Using EncFS to encrypt your files

About EncFS

EncFS is an encrypted filesystem based on FUSE. It transparently encrypts files stored in it and places them on another volume. This is in contrast to block level encrypted filesystems which transparently encrypt the data under the filesystem layer as it is being written to disk. Think of EncFS as a bind mount, except that the source for the mount is encrypted and the place it is mounted to is the only place it is available unencrypted.

The main advantage of EncFS filesystems is that when backing up only the files which have changed need to be backed up. This means it works perfectly with tools such as rsnapshot. Another advantage is that the filesystem doesn’t need a block of disk allocated to it and will shrink and expand as the files inside change.

Finally because this is all implemented with FUSE it is all done in userspace. No root access is required (apart from setting FUSE up) to create and alter encfs filesystems.

Setting Up an EncFS Volume

So the first thing you need to do to setup an encfs volume is to install FUSE and EncFS. If you don’t have root access you will have to ask your sysadmin to do this for you, otherwise follow your distribution specific method of installing new packages. On Fedora it is called ‘fuse-encfs’ and on Debian/Ubuntu its called ‘encfs’. On some older systems users wishing to use FUSE may need to be added to the correct group.

First you need to decide where you will put the encfs volume, and where you’ll mount it. I usually put mine in /home/daniel/.crypt and mount it to /home/daniel/crypt. But feel free to name it whetever you want. When you’ve decided run the EncFS with those arguments, for example to use the example I specified it would look like this:

<daniel@server ~>$ encfs /home/daniel/.crypt /home/daniel/crypt
The directory "/home/daniel/.crypt/" does not exist. Should it be created? (y,n) y
The directory "/home/daniel/crypt" does not exist. Should it be created? (y,n) y
Creating new encrypted volume.
Please choose from one of the following options:
 enter "x" for expert configuration mode,
 enter "p" for pre-configured paranoia mode,
 anything else, or an empty line will select standard mode.
?>

Standard configuration selected.

Configuration finished.  The filesystem to be created has
the following properties:
Filesystem cipher: "ssl/aes", version 2:2:1
Filename encoding: "nameio/block", version 3:0:1
Key Size: 192 bits
Block Size: 1024 bytes
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.
File holes passed through to ciphertext.

Now you will need to enter a password for your filesystem.
You will need to remember this password, as there is absolutely
no recovery mechanism.  However, the password can be changed
later using encfsctl.

New Encfs Password:
Verify Encfs Password:

As you can see the directories don’t need to be created first. There is also a prompt for what security settings you want to use. Hitting enter will give you standard settings, but for something more powerful you should hit ‘p’ then enter. You can now proceed to place files in /home/daniel/crypt and they will be encrypted and placed into /home/daniel/.crypt. If you don’t believe me go ahead and check.

See? I told you so. Now you can unmount it using ‘fusermount -u /home/daniel/crypt’ and mount it again using encfs /home/daniel/.crypt /home/daniel/crypt and typing your password.

Random Thought: When travelling to other countries, local laws may mean that customs can search your laptop, including encrypted filesystems. You may have to reveal your key, or be arrested.

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 keys.gnupg.net
(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 "smarthall@gmail.com".  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.

Setting Up GPG Keys

Yesterday you may have read my GPG Symmetric Encryption Guide. The last tip on that page was that you should setup GPG keys and publish them on a keyserver. I say this because publishing GPG keys allows you to encrypt things for anyone else who has published their GPG keys without contacting them and exchanging a symmetric key first.

Generating a GPG key

If you haven’t had a GPG or PGP key before, or the one you previously has has expired you will need to generate a new keypair. A keypair consists of a private key, that you keep absolutely secret, and a public key, that you publish to the world.

You should generate a GPG key on your desktop and not on a server. Most likely a server will not have enough entropy in its random number generator and could take a while. All you then have to do is:

gpg --gen-key

You then answer the questions as follows:

  • The type of key that you want is ‘DSA and Elgamal’ this way you can both encrypt messages and sign them.
  • 1024 bits is probably enough, if you are planning a long expiry for your key you may want to choose 2048, and if your extremely paranoid use 4096.
  • I’d suggest a key expiry of two years for a 1024 bit key, but remember you can set an expiry later, and you can also revoke your key at any time if you believe it is compromised.
  • Then you fill in your details in the prompts
  • Never use a key without a passphrase, any compromise of your key will result in all data people have encrypted for you being compromised and people will be able to sign things as coming from you.

After you enter the details you computer will start generating some very large numbers using cryptographically secure random data, and checking if those numbers are prime. Once your computer has two prime numbers it will generate your keys and save them for you.

Add extra uids to the key

A key can contain many uids. For example your key may contain a work uid and a home uid. If you work at many different companies or have a large number of email addresses then you could have many uids. The uids are what people who sign your key are indicating they trust. So I might decide to indicate that I trust your work uid but because I don’t know you personally  To add new uids to the key you type:

gpg --edit-key
Command> adduid

Then just as before you enter all your details. You can list the uids on the key by typing ‘uid’ at that same prompt. When you are done type ‘save’ to save the key.

Entering the web of trust

The first thing you should do is decide what keyserver you would like to publish your keys to. Most keyservers sync with other ones so this is not really that important. I would suggest hkp://keys.gnupg.net but the choice is up to you. When you have decided what keyserver you want to use place an entry in your ~/.gnupg/gpg.conf file like that says ‘keyserver hkp://keys.gnupg.net’ or whatever server you would like to use.

Now you are ready to build the inner circle of your web of trust. To do this you need to get other people to sign your keys, and them to sign yours. The more signatures you build up the easier it is to find a common link between you that is trusted.

To download another persons key you use the receive key argument for GPG. For example to download my key you can use any of the following commands:

gpg --search-keys "Daniel Hall"
gpg --search-keys "smarthall@gmail.com"
gpg --recv-keys "A3A386ED"

The first two may produce multiple matches and may ask you to select which particular key to download. At this point you should contact the user and confirm their ID so you get the right key.

Now that you’ve downloaded your friends keys you need to confirm who they are and then if all check out sign their keys. When you sign somebodies key you need to be extremely careful, signing a key is your declaration to the world that you trust that this key represents this person. If you sign keys without checking you could end up trusting people who aren’t who they say they are and people will begin to stop trusting you. To verify somebody you should meet them personally (or at an absolute minimum talk over the phone) to get their key fingerprint. As you are signing check that this fingerprint matches the key you are about to sign. To sign my key you could use the following command:

gpg --sign-key "A3A386ED"

Then you upload their key to the keyserver again to ensure that your signature on that key is now visible for the world to see. It is polite to ask people before you sign their key as many spam like signatures on a key may look bad in the eyes of others. If you had just signed my key you would upload it with:

gpg --send-key "A3A386ED"

Now all you need to do is get other people to sign your keys. I’d suggest you start with those people whose keys you have just signed as they’ll be the most willing to help you. You aim is to get enough signatures so that everybody who will need to send an encrypted document to you can find someone they trust who trusts you. It is a little more complicated than that but its essentially the idea.

Random Thought: What should the random thought on my next blog post be? Hrmmmm.

GPG Symmetric Encryption

I often come into a situation where I have to exchange some important confidential file with somebody who doesn’t have GPG keys setup. Explaining how to setup keys can be a pain, especially if you believe that the user will lose them or simply forget how to use them. There are all manner of propriety software packages to deal with this but this post is about an easy free way using software that almost anyone has access to. I will be showing you how to do this using GPG on Unix operating systems. For windows you could follow this guide.

Encrypting

To encrypt a file symmetrically using GPG just run:

gpg --symmetric <filename>

It will prompt you for a password twice and create a <filename>.gpg file in the current directory. If you want to put the encrypted text in an email then add the –armour flag. The –armour flag will cause gpg to instead output a <filename>.asc file which consists of ASCII text.

Decrypting

You decrypt it like any other GPG encrypted file:

gpg -d <filename>.gpg

This will prompt you for the password and decrypt the file, printing it to standard out.

Tips

  • Don’t send the password and the attachment over the same medium, especially not in the same message. I suggest you send the email with the file and call and tell them the password.
  • GPG uses really strong encryption, much more secure than that used in zipfile encryption. That said if you set the password to ‘123’ or ‘password’ no amount of encryption will help you. Your encryption is only as secure as the weakest point.
  • With enough time files like this can be cracked using brute force. You should still do all that you can to prevent the encrypted file falling into the wrong hands.
  • You really should setup GPG keys and publish them to a keyserver. That way you won’t have to worry about secure passphrase distribution.

Random Thought: How did people find the first search engine?