Here’s how I set mine up using my GnuPG key. First, I created a ~/.mutt/passwords file. The file is in plain text. Before encrypting it, here are its contents:

set imap_pass="password"
set smtp_pass="password"

I then encrypt that file with the following command:

% gpg -r your.email@example.com -e ~/.mutt/passwords
% ls ~/.mutt/passwords*
/home/user/.mutt/passwords /home/user/.mutt/passwords.gpg
% shred ~/.mutt/passwords
% rm ~/.mutt/passwords

The last two commands are to ensure that the temporary file you created for encryption is securely wiped from the disk using the GNU Shred utility. Now, you should only have an encrypted binary data file that contains your passwords. All that is left is to configure Mutt to decrypt them when starting up. You can set that easily in your Muttrc:

source "gpg -d ~/.mutt/passwords.gpg |"

The string is just a standard string. Also, it’s important to have “|” at the end of the command, to pipe the output to Mutt, so it can be appropriately sourced.

At this point, you should be able to launch Mutt, be asked for the passphrase for your private GnuPG key, and it should log you in to your IMAP account. You should also be able to send mail as normal, logging automatically into your SMTP account. The only time you are asked for a password, is your GnuPG passphrase when starting Mutt. If your “gpg-agent” is already running, and you’ve configured GnuPG to use the agent and added your private key to it, then starting Mutt won’t ask you for your key passphrase, and will use the agent instead.

Other than temporarily creating the plain text file to encrypt, which stores your passwords, and which you promptly and securely shred later, your IMAP/SMTP passwords for your remote account are never on disk in plain text.

Happy encrypted hacking!

|1|kFJT5z0x3ndyutgZ4E5pRk+ORBA=|hzXvdYUudo+qK9BGlFWtSAUXlXc=
|1|8wo1+FO0hkATPgQZoeNHeIlvAjw=|dt/a9jz9CnLKP72j+Jr8MKMjgEE=
|1|pvBQEKEGLnH0RCJr+8Dmqqnvlrs=|fJJvjyG/TmHFnuIX57nDThq/C4M=
|1|HKV4DzgDkajXoUHf9B82JBu7J10=|c/K+MdJvWaZeJFs/W7iqhqo0wvE=
|1|rtvQhRVnNanQZYkLUMbjoBGNhn0=|0U6a1LUQqLL6P1T2Wji3VWw69pw=
|1|0ziSYi4c+xBXGEBZcNN1LMhYUc4=|qRSN5GSPyQi+fmaVz2zNwkmKoy8=
|1|6nv6Vpk3AYgICHxJGVgVdsYRuq0=|fBNOIz1l3RW+N61jyDPunKX9n7E=
|1|+b4uA+Mq7RHRAFW21qv8aO3rIRs=|1eizMri01IxEKrXquBnwTYP61Ow=
|1|BkB0PZu2qtsLID/Ibe/D68gANQU=|qW6uAzcpecOOKNI4zEvngyfpGkI=
|1|n+QrRn7QXeAJ5hRe2M8v8IspihE=|EqUxXdSeIF1cl1fQjl5zILebkGY=
|1|BOKuKnWojy028tJf9Y671lws0d0=|SuBQJmJZp5JNVYG/rP9yb9ZhJcE=
|1|WACsxtodOiM89kf4rNPLgF1CXZ4=|UTccVeLDZJF3wlH8V05XJNlsOBw=
|1|o6FFoirXYblM7wBMdeJDYGMPI58=|5jJB7T7itY702ZHHByXtSpGk9SE=

The column fields are similar to that of the /etc/shadow file on GNU systems, except where the “$” is the column delimiter, “|” is in this case. If the string was “|1|o6FFoirXYblM7wBMdeJDYGMPI58=|5jJB7T7itY702ZHHByXtSpGk9SE=”, then the breakdown is as follows:

• |1- HASH_MAGIC. This tells the client that the host information has been salted and hashed with the SHA1 algorithm.
• |o6FFoirXYblM7wBMdeJDYGMPI58= This is the salt applied to the host- base 64 encoded 160-bit string.
• |5jJB7T7itY702ZHHByXtSpGk9SE= This is the base 64 encoded version of the hashed host

Now, if you want to get at the actual strings, not base 64 encoded, you could run the following command (I admit, not elegant, and could probably be better solved without nesting, and a single awk(1) statement, but I’ll get to that later):

% echo $(echo o6FFoirXYblM7wBMdeJDYGMPI58= | openssl base64 -d | xxd | cut -c 10-48) | sed 's/ //g'
a3a145a22ad761b94cef004c75e24360630f239f
% echo $(echo 5jJB7T7itY702ZHHByXtSpGk9SE= | openssl base64 -d | xxd | cut -c 10-48) | sed 's/ //g'
e63241ed3ee2b58ef4d991c70725ed4a91a4f521

There you have it. Very cool. Now, the only question is how to apply the salt to the hostname, to get to the hash? I’m working that out, but I wasn’t motivated enough to get to it. Of course, there’s no application to this, that I can tell, unless you want to brute force the known_hosts file.

I placed a hidden message in my email headers for a bit (I’ve since stopped, for various reasons). I considered it an “Easter Egg” of sorts, waiting for someone to notice. Here is what I placed in the headers:

Crypto-Challenge: iVBORw0KGgoAAAANSUhEUgAAADwAAAA8AQMAAAAAMksxAAAABlBMVEX
       ///8AAABVwtN+AAAAtklEQVQokXXQMQ6CMBQG4McCiykXMPEKsuEiV2nCBdoLWNgN
       Xqld7MYZeoQSFgbisyZWER//9E1//vcAYhQOvkB0X3AQotBAoZ5lV9hpA63ZxCP5Q
       SiE5N28QpjRxT0rhFzi7BWUlx3LQvMH+x1jx7IEAoer8hVqR4Crhp1fhf9QI976tF
       oAIGlYWTkCCr3I7yTCpTkaDQTqWUhjtFtCNizNgEbbZxMFDnIYrHUEwjPRnywQiHk
       CI/3gDHrryF4AAAAASUVORK5CYII=
Crypto-Hint: image/png

Quickly, you should identify the “Crypto-Challenge” header as base 64-encoded string. The hint says it’s an image, of type PNG. So, the following Python code should do the trick:

Running that code with the base 64-encoded string above gives the following image:

Scanning the QR code reveals the text “42″, of which most geeks should recognize as “The Answer to the Ultimate Question of Life, the Universe, and Everything”.

Of course, steganography isn’t encryption. It’s security by obscurity, which isn’t security, where a message is hidden by obscuring it through some means. Wikipedia has a great article on it at https://en.wikipedia.org/wiki/Steganography.

What can you do with hidden messages in images (or vice versa, as in the case with my email “Easter Egg”)? Well, for one, you can easily get around email attachment restrictions. For example, take a ZIP archive. Perhaps some organization blocks email with .zip attachments. Why not convert the archive to base 64, then convert the result to an image. You might end up with something like this:

Your final image might end up like:

In our case, I just created a file from /dev/urandom, zipped it up, and converted to an image. Thus, the reason the data in the image appears so random. More structured files will show actual structure in the final image. Also, notice the string of black at the bottom as a result of our padded zeros to adjust for a square image, without losing data.

Of course, to get back to the archive, you just need to reverse the process of converting the image to a base64 string, then back to the original file. Now, I’m no Python expert, and I realize there is much more to add to the code, such as “try/except” blocks for testing files, writable directories, etc. The point of the code was just to demonstrate an overall algorithm.

Hopefully, this is of some interest to some of my readers. I’m open to code improvements. Thanks to https://diablohorn.wordpress.com/2010/12/04/whats-in-a-picture for use of the code above.

We’re introducing a method that lets you opt out of having your wireless access point included in the Google Location Server. To opt out, visit your access point’s settings and change the wireless network name (or SSID) so that it ends with “_nomap.” For example, if your SSID is “Network,” you’d need to change it to “Network_nomap.”

Great. Just great. Google will now be tracking my wireless access point unless I append “_nomap” to the SSID. How many people do you think are going to do this? How many people have even changed their default AP login from “admin:admin”? Google is taking advantage of people, and they know it. I hope the backlash is severe, because I find this to be a breach of trust. Whatever happened to “Do No Evil”?

So, the question is: do you trust the short URL? Well, I’ve generally gotten into the habit of asking people to expand the shortened url for me if on IRC, email or IM, and it’s worked just fine. But, I got curious if there was a way to do it automagically, and thankfully, you can use wget(1) for this very purpose. Here’s a “quick and dirty” approach to expanding shortened URLs (emphasis mine):

$ wget --max-redirect=0 -O - http://t.co/LDWqmtDM
--2011-10-18 07:59:53--  http://t.co/LDWqmtDM
Resolving t.co (t.co)... 199.59.148.12
Connecting to t.co (t.co)|199.59.148.12|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://is.gd/jAdSZ3 [following]
0 redirections exceeded.

So, in this case “http://t.co/LDWqmtDM” is pointing to “http://is.gd/jAdSZ3″, another shortened URL (thank you Twitter for shortening what is already short (other services are doing this too, and it’s annoying- I’m looking at you StatusNet)). So, let’s increase our “–max-redirect” (again, emphasis mine):

$ wget --max-redirect=1 -O - http://t.co/LDWqmtDM
--2011-10-18 08:02:12--  http://t.co/LDWqmtDM
Resolving t.co (t.co)... 199.59.148.12
Connecting to t.co (t.co)|199.59.148.12|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://is.gd/jAdSZ3 [following]
--2011-10-18 08:02:13--  http://is.gd/jAdSZ3
Resolving is.gd (is.gd)... 89.200.143.50
Connecting to is.gd (is.gd)|89.200.143.50|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://wiki.ubuntu.com/UbuntuOpenWeek [following]
1 redirections exceeded.

So, in this case, the link finally points to https://wiki.ubuntu.com/UbuntuOpenWeek. I’m familiar enough with the Ubuntu Wiki, that I know I should be safe visiting the initial shortened URL. If you want to add this to a script or shell function, then you can get a bit more fancy:

$ expandurl() { wget -O - --max-redirect=$2 $1 2>&1 | grep ^Location; }
$ expandurl http://t.co/LDWqmtDM 1
Location: http://is.gd/jAdSZ3 [following]
Location: https://wiki.ubuntu.com/UbuntuOpenWeek [following]

In this case, our “expandurl()” function takes two arguments: the first being the URL you wish to expand, and the second being the max redirects. You’ll notice further that I added “-0 -” to print to STDERR. This is just in case you give too many redirects, it will print the content of the page’s HTML to the terminal, rather than saving to a file. Because you’re grepping for “^Location”, and sending the HTML to your terminal anyway, technically you could get rid of the “–max-redirects” altogether. But, keeping it in play does seriously increase the time it takes to get the locations. Whatever works for you.

UPDATE (Oct 18, 2011): After some comments have come in on the post, and some discussion on IRC, there is a better way to handle this. According to the wget(1) manpage, “-S” or “–server-response” will print the headers and responses printed by the FTP/HTTP servers. So, here’s the updated function that you might find to be less chatty, and faster to execute as well:

$ expandurl() { wget -S $1 2>&1 | grep ^Location; }
$ expandurl http://t.co/LDWqmtDM
Location: http://is.gd/jAdSZ3 [following]
Location: https://wiki.ubuntu.com/UbuntuOpenWeek [following]

Perfect.

PGP/MIME

1. Uses the OpenPGP RFCs and standards.
2. The “signature.asc” detached signature is in plain text.
3. Flexibility in algorithm choice for encryption, signing and compression.
4. Relies on a distributed trust model.
5. Not as widely deployed in MUAs as S/MIME.
6. Public key must be distributed separately from the signature.
7. Trivial to integrate with webmail providers.
8. Can only be used with signing documents.
9. An expiration date does not need to be set on the public key.
10. Free.

S/MIME

1. Based on a number of RFCs and standards.
2. The “smime.p7s” detached signature is in a binary format.
3. Generally, the Certificate Authority (CA) chooses the algorithm and key size.
4. Relies on a centralized trust model.
5. More widely deployed than PGP/MIME
6. Public certificate distributed in each detached signature.
7. Difficult to integrate with webmail providers.
8. Can be used for both signatures and encryption.
9. Generally, the public certificate expires once per year.
10. Some CAs provide certs free for personal use, but most if not all CAs charge for professional use. As low as $20 per year, depending on the CA.

This isn’t an exhaustive list, but it’s pretty good. I’ve tried to keep any bias out of the list, and just mention the facts. Really, I get a kick out of using both, so meh. But, if I were forced to choose, I would choose the distributed OpenPGP model for signatures.

The biggest reason for this choice actually doesn’t even use PGP/MIME, thus the reason it’s not listed. That reason is I can set preferences in my key as to what must be used when encrypting documents to me. Thus, I can force you to send me a 2048 RSA encrypted document. With S/MIME, which can handle encryption, no such preferences exist, which means that there is nothing from stopping you sending me a 40-bit RSA encrypted document. I think you can see the security problem here.

Another problem I see with S/MIME is the reliance on a centralized authority. Essentially, you can trust I signed my mail with S/MIME, because my certificate is signed by DigiNotar and we all trust DigiNotar. Oh, wait. While the issuance of fraudulent public keys is a reality, the probability is much less likely, due to the distributed Web of Trust. Of course, this means there is a fair amount of homework that you must do in verifying that the key is legit, and that confidential information can be trusted with that key, but it is possible to make such assumptions.

Lastly, S/MIME is rather trivial to maintain. You pay a CA for a certificate, and you install the certificate in your mail client, and you’re ready to go. OpenPGP and PGP/MIME isn’t so trivial. You must generate your own keys, generally with PGP or GnuPG, and know the difference between your private and public keys. Then, you must install a plugin or extension into your MUA, which all don’t support, and configure that plugin to work with your keys. Then you must distribute your public key to friends and family, as well as keyservers, so others can grab a copy. But they can’t trust your data, until they meet up with you and do a keysigning, which means you must then redistribute the public key after their signature has been applied. In both cases, however, you can’t encrypt data to people unless you have their public key or certificate.

Both are internet standards, and both are fairly widely deployed. Unfortunately, there is work on your end that must be done on setting it up, and maintaining it, whether it’s a yearly cost or attending keysigning parties. As a result, it’s not as widely used in practice as much as it could be. I’ve made it a personal philosophy that I won’t send mail unless it’s cryptographically signed. This is true both personally and professionally. I would love it if my family and friends took the steps necessary to verify the signature, but it just isn’t going to happen. End-to-end security with email seems to have just too many speed bumps that people are willing to handle. That won’t stop me though.

Anyway, I hope this was at least somewhat informative.

These are best practices from the client perspective, not the server. Many of these points you will have already been familiar with, but some of them not as much. If you sit down and think about what you are doing as a client when you SSH to a server, some of the implications mentioned here make sense.

Lastly, security is a big topic, and not something that can be flipped on and off with a switch. Security always starts with the user. Unfortunately, increasing your security could mean making usability more of a pain in the rear. However, as an OpenSSH client, I hope the techniques mentioned here won’t decrease your usability too bad, while greatly increasing your overall OpenSSH security. With that said, let’s get started.

0. Use ECC first, then RSA, then DSA with maximum bit strength.
When generating your OpenSSH keys, you should be aware of the cryptographic algorithms of the OpenSSH server that you are accessing, and what you can and cannot use. As of OpenSSH version 5.7, elliptic curve cryptography is a supported algorithm. It is proving to be a very secure, robust and light crypto algorithm, but it also must be supported by both the client and the remote server. This means that both the client and the server must be relatively new installations of OpenSSH- something that RHEL 6 and earlier, Debian GNU/Linux Stable 6 and earlier, Ubuntu 10.10 and earlier, and likely many other stable releases from other GNU/Linux operating systems, do not support. When you can, use elliptic curve cryptography for your SSH keys.

If ECC is not available on either your client or server, then you should choose RSA as your key’s crypto. DSA suffers from a weakness, where if the host does not have a sufficiently strong pseudorandom number generator (PRNG), then the “random k” could become exposed from the public key, allowing the attacker to build the private key from the public. The PRNG supplied by GNU/Linux (the device file “/dev/urandom”) is sufficiently strong, providing good random data from entropy pools- thus, GNU/Linux generally doesn’t suffer from this problem. Other operating systems could.

A great demonstration of DSA’s weakness can be found in this excellent blog post, where the author demonstrates how trivial it is to build the private key when the “random k value” is known. Fortunately, RSA does not suffer from this weakness, and also allows you to build larger keys than DSA.

If neither ECC nor RSA is supported by the client nor server, as is the case with some archaic proprietary SSH implementations, then DSA is your only option. Unfortunately, it is also the default for OpenSSH when generating a key. So, you should always get into the habit of passing the “-t [type]” switch when generating your keys.

In all 3 cases, where possible, you should choose the maximum bit strength that the algorithm allows. This will put a bit of strain on the client’s CPU, but it will also give you the greatest strength when authenticating on the wire. When generating your key, use the “-b [size]” switch to specify the bit strength.

1. Use SSH keys and make your servers require them.
There are three reasons why you would want to use SSH keys:

1. SSH keys with a passphrase provide two-factor authentication.
2. SSH passwords can be read in plain text on the remote server.
3. SSH keys aren’t subject to brute force dictionary attacks, like passwords.

Let’s cover each in detail. First, two-factor authentication. SSH keys use public key cryptography. You are given a private and public key when generated. During generation, you are asked to provide a passphrase for the private key. DO NOT GIVE IT AN EMPTY PASSPHRASE! By providing a passphrase to your key, you have enabled the two-factor authentication- something you have (the key) and something you know (the passphrase). Using SSH keys can be troublesome, however. As a result, take advantage of the SSH agent for your system to cache the passphrase locally on your client. This will increase your usability by only entering your key passphrase once, and using the agent to login to other servers without providing the key passphrase again.

Second is reading the user password in plain text on the remote SSH server. You may not think this is possible, as everything in OpenSSH is encrypted, right? Wrong. The two Achilles Heel’s in the connection are the client and servers themselves, where the decryption is taking place. Other users, specifically those who have superuser access, can exploit this. To demonstrate this, make a connection to a server that you have superuser access on. Then, from the client initiate a connection that would require your server password, but don’t supply it. Go back to the server, and find the process of the connection, and run an strace on the PID. Go back to the client, and type in your password. Watch, very likely in horror, the password be displayed on your console.

Here is an excellent writeup by Joseph Hall on this very issue. The problem lies in whether or not you trust those who have superuser access on the server. You should only trust them enough to do their job on the server, and nothing more. Just because they have superuser access on the server, doesn’t mean they can be trusted with your banking account information. Because people use the same passwords over and over across multiple accounts, it’s likely that the password sniffed out of the connection is the same password for their email account. Or bank.

Third, as should be obvious, SSH keys aren’t subject to brute force dictionary attacks like passwords are. If you control the SSH server, and require that SSH keys are the mode of authentication, then brute force attacks will be in vain, regardless how long they try. If you have a publicly facing SSH server, you’re likely aware of how hard your server gets hit from attackers all over the world. By forcing key authentication, all those attacks are in vain.

2. Don’t use a blank passphrase on your keys.
This should come as no surprise, but needs to be mentioned. Your SSH keys are something that should be guarded carefully, with sufficient paranoia. If for any reason, your SSH client is compromised, your SSH keys are a way in to the remote servers that you have access to. If your keys are not protected by passphrases, then after scouring your shell history, or SSH config for hosts to connect to, they’re in the SSH server with little effort. You must protect your keys with strong passphrases!

Now, I understand that there are some like me, who use SSH as the connection for nightly local backups, at which point the client will be asked for the passphrase of the SSH key. Because you wish this to be an automated process, and likely when you’re in bed, you won’t be available all the time to provide the credentials. So, you create an SSH keypair that is not passphrase protected. In such a scenario, here is what I would do:

1. Only install this key on the backup SSH server, and no where else.
2. Do not install this key into an account that has superuser access.
3. Do not install this key into the superuser account.
4. On the backup server, change the key entry in the authorized_keys file to only allow connections from that client using that key (documented how below).

The first, second and third points are easy enough to configure, but how do you configure the fourth point, and is it even possible? When you copy the key to the authorized_keys file on the SSH server, it could look something like this:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAzoblHIUARNP5Kq12QwUqxB6T7m8TWti4LIFcvOCa...

Change the beginning of that entry to this:

from="10.19.84.10",command="/home/user/bin/validate.sh" ssh-rsa AAAAB3NzaC1y...

This tells the server that the only connections allowed to use this key can come from “10.19.84.10″, and when the connection is made, a local script is ran called “validate.sh”. Here are the contents of that script for me:

Make sure the script is executable by the user account on the SSH server, and test it before committing to it as part of your backup policy. If the client host is behind a dynamic IP address, or some other variable that prevents it from having a static address, you can remove the “from=” part, but leave the “command=” part. The goal is to minimize damage that can be done with that key.

Again, this is all if you need to perform an automated backup with SSH keys, where a passphrase cannot be performed. In almost every other case, your SSH key should be protected by a good, strong, loaded with entropy passphrase. Using one from a passwordcard is probably best.

3. Use a separate key for every client you SSH from.
I admit that when I first started using SSH, this didn’t make much sense to me. The amount of keys that I generated was a lot, and managing them became somewhat of a pain. Then, when becoming system administrator of a large organization, and controlling upwards of 300 servers, managing that many keys become immensely intense.

I soon came to the realization that it wasn’t that big of a deal. It is trivial to copy the key to the remote host (this can be done with the “ssh-copy-id(1)” command). Further, for work SSH keys, while I am in charge of managing those keys, I should only worry about work keys at work, and home keys at home. In other words, separate the management of the keys.

But the point of this is to NOT copy the same client key to multiple clients. Think about it. By copying the key around to multiple clients, this means that the key is on every server you ever access from those clients, even if some of the other clients cannot access that server directly. Thus, if a client is compromised, and the key is stolen, it’s difficult to know which client was compromised, and all servers that have that key in their authorized_keys file, are subject to compromise. If you have a different key for each client, then those keys are only on the servers that the client has direct access to, and should a client become compromised, you know which servers to saefguard, and damage is minimal.

4. Limit the number of clients you SSH from.
If an attacker can compromise your client, then they can get access to your SSH keys, as they are stored on the filesystem. Further, they may be able to install a keylogger to log passwords and passphrases, including those for your key. Once this information is gained, then all the accounts on the servers the key is installed on are now compromised as well. By limiting the number of clients you SSH from, you minimize the exposure of SSH servers to the attacker.

5. Don’t “chain” or “loop” logins, but do “star”.

The point relates to the one above it, namely limiting the number of hosts you SSH FROM. There are a few scenarios on how you can create SSH sessions:

• Chain: As a client, you make a connection with an SSH server. Then, from that server, you make another connection to a different SSH server. Once, twice, three times or more, you’ve created a chain of connections from the client to the final host.
• Loop: As a client, you make a connection with an SSH server. Then, from that server, you make a connection back to the client you started from, thus creating a loop with your connections.
• Star: As a client, one connection is made to an SSH server. If another connection is needed to a different SSH server, this is made from the client. For each connection, the original client makes it.

The reasons why this is a “best practice” might not be obvious. Let’s start first with chaining connections. If one client is compromised in the chain, the other clients in the chain might possibly be compromised using the same method. Thus, all connections in the chain could become compromised. And a loop is nothing more than a specific instance of a chain.

Of course, this isn’t always possible. Maybe a chain is the only way to get to an SSH server on a private VLAN or behind a DMZ. These connections might be necessary (typically called “jump hosts”), but they should be used with caution, and as little as possible. When you are done with your task, rather than idle the SSH connection, terminate it to minimize exposure, should an attack occur.

When using a jump host, install netcat(1) on the jump host and use the ProxyCommand configuration paramater. Something like this would be sufficient:

Host inaccessiblehost1 inaccessiblehost2
   ProxyCommand ssh accessiblehost nc -q0 %h %p

With star connections, you minimize the risk of compromise with each of your connections, but security is maximized, even if extra work is required on your end. For example, if you wish to transfer data from one SSH server to another, this may mean bringing the data to the client, then sending it to the destination server.

6. Consider disabling the SSH server on the client you are connecting from.
This rule shouldn’t apply only to the SSH server, but to any daemon you have running on your machine. If you don’t need a service running, then turn it off. By doing so, you minimize the attack vector and greatly increase your security. OpenBSD prides itself in having only two remote holes in the default install in a heck of a long time, but then it also doesn’t have any services running on a default install either.

So, for SSH, because you followed rule #5, and you aren’t doing “chain” or “loop” connections from your client, then this means that you’re not connecting to your own machine that you started your initial connection from. I understand that this isn’t always possible. I have 300+ SSH servers at work, and I can’t possible turn off the SSH server on a host, just because I’m connecting from it. But then, do I need an SSH server on my virtual laptop? Not likely, and if there are things I need, I can turn it on, do my work, then turn it off.

7. Don’t ignore SSH host key warnings.
When you install an SSH server for the first time, it creates a server public and private keypair. This set of keys is what is used for the encryption and decryption between your client and the SSH server. Thus, all traffic that you are sending to that server, is done because you trust that the SSH server key presented to you, is indeed the key of the server itself. So, what happens when you connect a different time, and your client warns you that the public SSH server key has changed? Should you trust the connection?

Depends. Usually, it’s due to the fact that you either reinstalled the SSH server or reinstalled the operating system. In this case, you can move forward, so long as you know that the key presented is the new key from the server. However, someone could setup a proxy SSH server, for the intent of gaining system passwords. Your client will warn you the key is different, and you should pay attention to the warning.

So, in your SSH client config, you generally should not set the following:

Host *
    StrictHostKeyChecking no

Default is “yes”, and it should stay yes in your config. OpenSSH is verbose enough for your benefit. Try to take advantage of it, rather than silence it, or ignore it. After all, it’s your data.

8. Be wary of using X11 forwarding.
While taking advantage of the ability to run remote X applications locally on your client is nice, it has some very grave drawbacks. For example, it’s common for people to launch a remote browser, such as Firefox. What isn’t realized, is that you’re providing usernames and passwords through the browser, which could be caught on the remote machine from which the app is running (taking advantage of X events, for example).

There is a time and a place for X11 forwarding, and I have benefited by it, but generally, it’s not needed. Set the following in your SSH client config, and only enable it when needed:

Host *
    ForwardX11 no

9. Don’t use agent forwarding.
As with X11 forwarding, you are giving ultimate trust to the remote host when forwarding your local agent. If that connection makes a connection to an account with superuser privileges, then a user on the remote SSH server could hijack your agent by connecting to the socket the SSH server creates.

Also, on the client initiating the connection, the superuser must be trusted, which isn’t always the case. The local superuser can access the agent socket on the client, and attack. Thus, it’s generally not a good idea to enable agent forwarding. Thus, as it is by default, the following should be sent in your client SSH config:

Host *
    ForwardAgent no

Since then, I’ve been fascinated by hand cipher techniques, and I’ve learned a few historical ones over the years. I’ve even invented my own hand cipher, even though I doubt it would show any form of cryptanalytic strength. While I don’t do anything with hand ciphers practically, I still consider it a fun skill to have, whether or not it actually proves to be useful (when I was a Boy Scout, I always wanted to learn Morse Code, so I could tap out answers to a quiz or test in class to a fiend, and back to me without anyone knowing. How cool would that be?!).

While I know base-64 is not considered a cipher algorithm, I thought to myself that I don’t know how to convert a string of ASCII text to base-64 by hand. So, I figured I might as well learn. It could be an interesting skill to add to my own hand cipher, and could even prove to be useful around the house. So, if you’re curious, here we go.

STEP ONE: Know the ASCII code chart

I would recommend memorizing or printing out (and stuffing in your wallet) this chart here: http://en.wikipedia.org/wiki/File:ASCII_Code_Chart-Quick_ref_card.png. Reason being, is you need to covert the ASCII text to numerical binary. The chart linked to gives you the table on how to do it.

Really, you can use any standard ASCII chart that provides you with the decimal, octal or hexadecimal values of the character. So long as you can convert it to binary, that’s all that matters. I like the linked chart above, because it gives it to me out the gate, which is one less conversion to worry about.

STEP TWO: Convert your ASCII string to numerical binary

This is the tedious part. It’s going to take you some time to write down every character in 8-bit binary. I need to stress that you need to write down the FULL 8 BITS, even though the card linked to only gives you 7. So, the 8th bit will always be zero when writing down the full binary word. Here’s a rundown of how you would read the card:

1. Find the character you wish to convert
2. Write down 0 + the first three binary bits on the top
3. Write down the last four binary bits for that letter on the left

So, for example, the text “green” would be “01100111 01110010 01100101 01100101 01101110″. Notice that each binary word is 8 bits, each with leading zeros. This should be the case for EVERY character you write down. Further, the space between letters is NOT ignored. It has the binary value of “00100000″ (“SP” in the chart).

STEP THREE: Pad at the end as necessary with zeros

The total number of bits should be divisible by 6. If it is not, add the necessary zeros at the end until it is. So, for our example of “green”, we have a total of 40 bits, which means we need to add two more zeros to make it divisible by 6 (42 divided by 6 is 7). It’s important that you stop at the first multiple of 6, which means that you should never be adding more than 4 zeros. In fact, you will either be adding two zeros, four zeros, or none at all.

So, for “green” with padded zeros at the end, our binary string becomes: “01100111 01110010 01100101 01100101 01101110 00″

STEP FOUR: Divide your binary string into words of 6 bits

Because our binary string is now divisible by six, we want to make 6-bit words using the same string. So, for “green”, I should end up with 7 total words (because I have 42 bits total in the string). As a result, “01100111 01110010 01100101 01100101 01101110 00″ becomes “011001 110111 001001 100101 011001 010110 111000″

STEP FIVE: Convert your 6-bit words to decimal

Now we need to covert the newly created binary words into decimal. You need to know your binary to pull this off. Thankfully, this isn’t too terribly difficult- you just need to know your powers of 2. So, our string of “011001 110111 001001 100101 011001 010110 111000″ becomes “25 55 9 37 25 22 56″.

STEP SIX: Convert decimal to ASCII

Now, we need to covert our newly calculated decimal numbers to ASCII, and we’ll almost be finished. For this, we’re going to use a different chart than what we started with. We need a chart that will correspond to our values, starting at 0 and ending on 63 (64 possible values, thus the reason it’s called “base-64″).

1. If the value is between 0 and 25, then the character is uppercase “A-Z” respectfully.
2. If the value is between 26 and 51, then the character is lowercase “a-z” respectfully.
3. If the value is between 52 and 61, then the character is the numbers “0-9″ respectfully.
4. If the value is 62 or 63, then the character is “+” and “/” respectfully.

If that was confusing to you, see the table at http://en.wikipedia.org/wiki/Base64#Examples.

So, for our string of numbers “25 55 9 37 25 22 56″, which came from the text “green”, we see the following come out: “Z3JlZW4″.

STEP SEVEN: Pad the string with “=” as necessary

The last step in your conversion is to pad the string with “=” as necessary, so the total number of your characters is divisible by four. Our base-64 string has only 7 characters, so we must add a “=” at the end to bring the total to 8 characters, which is indeed divisible by four. Thus, we would end up with “Z3JlZW4=” as the final result for “green”.

QUICK EXAMPLE: “Attack at dawn!”

1. Attack at dawn!
2. 01000001 01110100 01110100 01100001 01100011 01101011 00100000 01100001 01110100 00100000 01100100 01100001 01110111 01101110 00100001
3. 010000 010111 010001 110100 011000 010110 001101 101011 001000 000110 000101 110100 001000 000110 010001 100001 011101 110110 111000 100001
4. No zero padding necessary
5. 16 23 17 52 24 22 13 43 8 6 5 52 8 6 17 33 29 54 56 33
6. QXR0YWNrIGF0IGRhd24h
7. No “=” padding necessary

NOTE:

The base 64 utilities that ship with GNU Coreutils and OpenSSL use a different padding at the end of the encoded string than just equal signs. I haven’t parsed the code yet, so I don’t know why this is, but from what I’m reading online, the standard is to use just “=”, unless I’m missing something. If anyone knows why “K”, “o=” and others show up, I’m all ears. Thanks.

CONCLUSION:

Encoding text to base-64 certainly doesn’t really yield any cryptographic strength, and there exist utilities for doing it on the computer. So, why bother learning it by hand? As stated earlier, it’s a fun skill to have around the house. Combine it with other hand ciphers that you might already know, and you could have a decent algorithm on your hands (pun intended). Heck, let’s see your English teacher decrypt your notes now!

First, the necessary changes to your “~/.muttrc” config. The script relies on the “X-Hashcash:” header (as well as the “Hashcash:” header- I guess there was some discrepancy or something about X-headers being deprecated, or something) not being weeded out. It must be displayed if present. This way, the script can actually see the token in the header, and process the logic of checking if it’s valid. If you hid the hashcash headers, then the script won’t execute, and as a result, won’t add anything to the token database. We use the $display_filter variable to execute the Python script, and show the results to the pager. Here’s the changes you will need to make:

# file: ~/.muttrc
ignore *                                    # draconian header weed - recommended
unignore from date subject to cc user-agent # standard headers unignored - recommended
unignore x-hashcash hashcash                # required

You will also need to set the $display_filter variable. I like having my theme consistent, so I’ve also added color to my theme to show the Hashcash verification at the top of the mail:

# file: ~/.muttrc
set display_filter="/path/to/verify_hashcash.py"    # required
color body brightyellow default "^\\[--.*Hashcash*" # recommended

Now with that set, all we need to do is install the Python script, and we’re ready to go. When looking over the code, you’ll notice that it’s creating a database of spent tokens. I’ve placed the database in ~/.mutt/, seeing as though I only have Mutt working with Hashcash at the moment (and it’s really the only MUA I use these days). If you have something else that uses Hashcash tokens, in an already existing database, you may want to make the necessary modifications to the Python script, so it’s pointing to the right file. Also, we’re only interested in keeping track of tokens minted for us personally, not all tokens we can find in the headers. Lastly, this Python script is only working for one email address. If you have multiple emails, as I do, you’ll have to either use a primary email to verify the tokens against, or modify the Python script to support checking tokens under multiple accounts.

With that said, here’s the script:

One thing I do find odd about the code above, is the hashcash binary, when checking tokens, prints to STDERR rather than STDOUT. I’m guessing this could change in the future, so that’s something that will need to be watched out for.

So far, the Python script has been working flawless for me. I haven’t noticed a single hiccup, and it’s fast, which it should be. However, standard disclaimers apply, such as not coming with any warranty, blah, blah, blah, and if you find any bugs, or have any enhancements (such as supporting multiple email addresses), I’m all ears. At any rate, I hope you find it helpful, should you wish to get into Hashcash with Mutt.

I wanted to used Hashcash with Mutt, for nothing more than a curiosity to see if it generates any discussion, and to see if people notice. Further, I’m a big crypto advocate, and while Hashcash isn’t exactly crypto, it’s highly related to it, and uses it. Regardless, I wanted to see if I could seamlessly tie in Hashcash with Mutt, both for minting and verification.

I make the following assumptions:

• You have Hashcash installed.
• You have Mutt installed.
• You have Python 2.5 or later installed.

With that, let’s continue.

What is Hashcash?

Hashcash is a proof-of-work protocol, with the motivation of eliminating SPAM. The idea is simple, although we’ll cover it in greater detail. The TL;DR version, is using Hashcash is about generating tokens, and attaching them to the header of the message you’re sending. The recipient checks the token for verification. If it passes, then you must not be SPAM, as you’ve put your computer through enough strenuous work to prove it. If the token fails, you could be SPAM, or you just did it wrong. Either way, it’s no guarantee that you’re not a spammer.

Now, the detailed version.

The premise behind Hashcash is that some certain mathematical results are difficult to discover but easy to verify. Factoring large numbers is one such example. So Hashcash is some sort of challenge for your CPU. For example, I say that you cannot comment on my blog, unless you can find the two prime factors of some large number. Once you’ve paid the work through CPU cycles, and provide the numbers, I multiply them together to see if it gives the result. The work was difficult for you to find, but simple for me to verify. Hashcash is based on this principle.

Using a lot of CPU cycles to answer a question non-interactively is one way to beat spammers at their own game, which Hashcash hopes to address. Rather than looking for large prime factors though, Hashcash is looking for a SHA1 sum of a unique string where the first set of characters in the sum are zero. Because SHA1 can provide 2^160 possible hashes before a collision is found, it shouldn’t take too much work to find such a string. In other words, the search space is large enough for the work to be reasonable. However, the search space is also large enough, that given a certain criteria, it can be difficult to find the requested string.

Let’s look at an example. Consider the SHA1 string:

00000528ba02c4da777839db269fde97de56ddf7

The first 20 bits of the string are zero. So, this is one such SHA1 hash that would work. The questions are, how did we find it, and what string did we use to generate it? Well, because the first 20 bits of the string are zero, this means that I should only have to search up to 2^20 possible hashes to find the string I’m looking for. On a moderate system within the last 10 years or so, this should take under a second. Indeed, the SHA1 hash string above was done on an AMD Athlon(tm) XP 1800+ with only 384 MB of PC133 RAM, and it was calculated in 940 milliseconds. The string, or in this case, our “Hashcash token” that generated that SHA1 hash is:

1:20:110321:aaron.toponce@gmail.com::Ci2v7/gsBbYY/dhk:0BTS

You can verify this easily enough:

echo -n 1:20:110321:aaron.toponce@gmail.com::Ci2v7/gsBbYY/dhk:0BTS | sha1sum
00000528ba02c4da777839db269fde97de56ddf7  -

So, if that is indeed a Hashcash token, then what are all the fields, and how are they used when searching for a SHA1 hash that starts with zeros? Well, the breakdown is thus:

1. The version number.
2. The claimed bit value.
3. The date (and time) a stamp was minted.
4. The resource for which a stamp is minted.
5. Extensions that a specialized application may want.
6. A random salt.
7. The suffix.

Hashcash has undergone two revisions thus far. The version number shows the claimed version of the protocol being used. With the latest release of Hashcash, this is “1″. “0″ has shown to have some limitations.

The claimed bit value it telling the verifier of the token how many zeros the resulting SHA1 hash should have. The default is 20-bits, but this can be changed. If the bit value is too low, then it becomes trivial for spammers to reproduce with minimal effort. If the bit value is too high, it may take some considerable time for your CPU to mint the token.

The timestamp is the date when the token was minted. We can take advantage of this for expiry. When the verifier downloads the token, he can keep it in a database. This is useful to hopefully prevent someone else from claiming the same token. However, holding on to tokens indefinitely could be cumbersome, so we can set expiration dates on when the tokens expire, to help manage the database. The default expiration is 28 days.

The resource for which the token is minted is generally the email address of the recipients. However, it’s flexible enough to be anything. It could be a URL to a webpage, some string of text, or anything that uniquely identifies a certain resource. We’ll be using email addresses as our resource.

The fifth field is generally left blank, but the protocol specifies that this is used for extensions that any specialized application may want.

The salt is used just like it is used anywhere else. Here, we wish to make our token unique for our resource. The email address and timestamp might not be unique enough to prevent two minted tokens from being the same. So, we add a random, hopefully unique salt here to the token. Once the salt is chosen, just like the timestamp and the resource, it won’t change for that token. The real grunt work is done with the next field. But, the goal with the salt is to just eliminate the possibility that two people send me an email on the same day, and the minted token is the same. If each salt is randomly chosen, then the tokens will differ.

As stated, this last field is where the real grunt work of your CPU lies. Every previous field is statically set upon instantiation. It is only this field that changes until we find the SHA1 sum that produces the correct number of zeros that we’ve asked for. Fortunately, the suffix is sequential, starting at zero, and working it’s way up, base 64, until the appropriate suffix attached to this string gives us the SHA1 we want. As mentioned, if our bit size is 20 bits, by default, then we will only have to work our way through 2^20 possible suffixes, on average, to find the right string that gives us the SHA1 with 20 bits of leading zeros.

The security of the token comes from the fact that there should only be one collision for every 2^160 possible strings in SHA1. Let’s not get tied up in the cryptanalysis. Suffice it to say, that SHA1 is still holding well in cryptographic circles, and for all practical purposes, we are interested in the amount of work it takes for the CPU to find the right token. When SHA1 becomes broken, and cryptanalysis shows it’s no longer secure enough for today’s applications, Hashcash is flexible enough to move to a different cryptographic hashing algorithm by just changing the protocol version. In the meantime, SHA1 works.

Also, given today’s multicore CPUs, and Moore’s Law, 20 bits might not be enough work for the CPU to crunch through. Remember, the idea is to beat spammers at their own game. If they can produce mass valid tokens for each spam mail they send, then we should make sure that our bit strength is stronger. Right now, 20 bits seems to be strong enough, but maybe moving it to 24 or 28 bits in the future might be necessary. Just remember the amount of time it takes for your CPU to calculate the work needed for the token.

How Hashcash works with email

When the token is minted, we wish to add the token to our mail header. We can add a token for each recipient in the “To:” and “Cc:” lines (with special care on how the headers are modified with Bcc: recipients (generally solved by sending separate emails with individual tokens)). What is added to the mail header is the following:

X-Hashcash: 1:20:110321:aaron.toponce@gmail.com::Ci2v7/gsBbYY/dhk:0BTS

For those using Hashcash, including antispam utilities such as SpamAssassin, looking for the X-Hashcash header in the mail, then verifying that the minted token is valid takes a fraction of a second. But, as we discussed earlier, minting the token takes some time. 20 bits for me takes just under a second. So, now imagine a SPAM ring with control of thousands of zombie computers infected with trojans. There are only 86400 seconds in a day, so if it takes one second to mint a valid token, then a single computer could only send out at most 86400 mails in a day, a far cry from the millions it wishes to send out. So, while it doesn’t completely eliminate the zombie nets from sending mass emails, it does slow them down considerably.

Yet, for those of us who only send a couple dozen mails per day, it’s trivial for our CPU to do the work, and doesn’t slow us down any. Further, those receiving our messages can verify the token is valid in a fraction of the time it took to mint it. As the receiver, you set the price of the token you wish to validate as antispam. Again, 20 bits seems sufficient enough for today, but 24 or 28 bits might need to be your standard in the future.

For those of you who are not using Hashcash, you can simply ignore the header, and move on with your life. It won’t slow your mail experience down any, and shouldn’t get in the way of reading or replying to it.

Mutt Configuration

Now that we have a decent understanding of how the Hashcash protocol works, let’s see how we set this up with Mutt. Thankfully, this is rather straight forward. All you need to add to your ~/.muttrc is:

set edit_headers="yes"                 # required
set editor="/path/to/mint_hashcash.py" # required
set askcc="yes"                        # recommended, but not required

This will allow you to edit the mail headers when composing your message with the editor of your choice. The editor is chosen for you in the Python script. I use Vim, so it’s hardcoded to that. Feel free to change it to your preferred editor of choice. I should also mention at this point that I have only found a way to automate minting tokens with Mutt. I haven’t found a way yet, although I’m working on it, to automate the process of verifying tokens, and storing tokens in a database, with Mutt. Hopefully, a followup post can come to fruition when I figure it out (after all, what’s the point of minting tokens if you can’t verify others’ tokens yourself?).

The script is here:

The code is fairly straight forward. Parse the email headers using RFC 822, grab the necessary email addresses, and mint the tokens as necessary. You’ll quickly note that “Bcc:” addresses aren’t supported, as minting tokens for those addresses would give them away in the header. I could send separate emails for each Bcc recipient, putting their own token in the header, but I’m not motivated enough to write that code, and I rarely, if ever, use blind carbon copy.

I’ve been running the above code now for 2-3 days, trying to break it as best I can, and I haven’t come across anything. If you do notice a bug, or something sloppy in the code, let me know, and I’ll make a best attempt at addressing it. However, it seems to be working quite well. The only thing I would mention, is if you have a lot of emails in the “To:” or “Cc:” fields, it may take some time to mint all those tokens. Just let it do its thing. It will get you back to Mutt. I promise.

shred -n 3 -v /dev/sda

It works well enough. However, it doesn’t display a real useful progress meter, other than how far it’s done in the wipe, thus leaving it up to you to figure out the speed, while filling up your back scroll in the process. There must be a better way.

I used to “leave my mark” (much like a dog marks a fire hydrant), however, this is quite slow. There are other methods, such as using /dev/urandom, but the entropy from urandom relies on SHA1. While fast, it’s not the speed demon that is AES or other algorithms. There’s /dev/zero, but how do I get random bits from zeros? And more importantly, does it push the drive to it’s bandwidth threshold? Of course, I’ve heard about DBAN, but I’ve had issues with it booting on certain hardware. Lastly, I would like to have a good progress meter as the data goes down on the drive.

Here’s a solution that a friend of mine in an IRC channel suggested:

openssl enc -aes128 -k "foo" < /dev/zero | pv -trb > /dev/sda

The great thing with this command is two fold:

1. It’s fast. It pushes the drive to as fast as it can write data.
2. It provides a convenient progress meter with “pv”

Again, I’m shredding drives with pseudorandom data. I’m not too concerned about the security of the bits going down on the platter. Per corporate regulation, I need to do 3 passes, and I’m confident that the bits coming out of the pipe from OpenSSL using AES-128 will be sufficient. So, for doing 3 passes, I can script it easily enough:

for I in 1 2 3; do
    openssl enc -aes128 -k "$I" < /dev/zero | pv -trb > /dev/sda
done

That works. 1 drive down, 24 to go…

If you have various ways you shred your drive, let me know, and I’ll post it below.

OTR, or Off-The-Record messaging is the ability to have encrypted and authenticated communication with full deniability and perfect forward secrecy. The idea is simple. Just as you want to be able to deny anything you say to a journalist when “off-the-record”, you should be able to have that ability with instant messaging. It works by not cryptographically signing the message. It’s just encrypted, and your buddy decrypts it on the other end. Further, each message is encrypted with a one-time AES session key. This means that even if you successfully snatch the AES key for encrypting and decrypting the message, it only applies to the current message, and does nothing for the previous messages, nor does it do anything for you on future messages. Thus, you have perfect forward secrecy with your chat. However, I want to spend some time on the inner workings of how authentication and trust are established, if the messages aren’t signed for validation.

First, OTR is fully supported in Bitlbee version 3.0 and later. For Debian and Ubuntu packages, you will need to install both the “bitlbee” and “bitlbee-plugin-otr” packages if you want to take advantage of it. Of course, you could grab the source, and compile it in yourself as well. Once installed, you will want to generate master keys for each account you wish to use OTR with. You can get a list of your accounts with “account list” in the &bitlbee window of your IRC client:

15:20 <@aaron> account list
15:20 <@root>  0 (gmail): jabber, aaron.toponce@gmail.com (connected)
15:20 <@root>  1 (twitter): twitter, aarontoponce (connected)
15:20 <@root>  2 (identica): twitter, eightyeight
15:20 <@root> End of account list

I wish to use OTR with my Gmail account. Thus, I need a key for the account. You can run “otr keygen <account-no>” for this:

otr keygen 0

It will take some time to generate the key, as it grabs entropy from /dev/random. You may want to add more entropy to the pool by running “du -sh /” from a different terminal to help speed things up. Wiggle the mouse, type in text editors, do other things to generate environmental noise. After it’s finished, you can see the key fingerprint by running “otr info”:

15:28 <@aaron> otr info
15:28 <@root> private keys:
15:28 <@root>   aaron.toponce@gmail.com/jabber - DSA
15:28 <@root>     8D57F662 D991493F 1084427E 31C7E1B9 2074B713
15:28 <@root>
15:28 <@root> connection contexts: (bold=currently encrypted)
15:28 <@root>   (none)

Now, you’re ready to communicate with your buddies via OTR. The question that will likely come up now is how do you know if the person you wish to communicate with secretly is really the person you expect? Well, for the years that I’ve used OTR, I’ve trusted the individual implicitly. I’ve communicated with their account enough that when we both decide to “go secure” with our chats, that it’s no big deal. I just trust their keys, they trust mine, and we go about our day. However, you may not want to do that, but want to explicitly acknowledge that you are communicating with who you think.

This can be solved a number of ways:

1. You could call them on the phone, and verify fingerprints verbally.
2. You could agree on a shared secret before initiating the communication electronically, and use that shared secret to trust the keys.
3. You could issue a challenge/response question to the opposite party. If they answer correctly, trust the key.

Personally, I like the challenge and response system. It’s not too terrible difficult to think of a question that only your buddy would know, and issue the challenge for them to respond. Of course, they need to do the same with you. This is known as the Socialist Millionaire Protocol. Use “otr smpq <nick> <question> <answer>”. It could go something like this:

otr smpq foobar "What color pen did I use on your whiteboard yesterday? one word, lowercase" red
15:35 <@root> smp: initiating with foobar...

On the other end, the nick “foobar” would have seen this:

06:42 <@root> smp: initiated by aaron with question: "What color ped did I use on your whiteboard yesterday? one word, lowercase"
06:42 <@root> smp: respond with otr smp aaron <answer>

At this point, “foobar” wishes to respond, as he thinks he knows the question. He would use “otr smp <nick> <answer>”:

otr smp aaron red
06:43 <@root> smp: responding to aaron...
06:43 <@root> smp aaron: correct answer, you are trusted

At this point, I now trust that foobar is who he says he is, so I can trust any OTR communication from him. However, he hasn’t verified that I am who he thinks I is. After all, I could be someone pretending to be Aaron, and get sensitive information from him. So, he should issue the same challenge and response to me. Something that only Aaron would know, to thwart any potential baddies. Should I answer correctly, he can then trust my fingerprint, and we will have 2-way OTR communication.

When everything is said and done, Bitlbee will print out the following:

15:36 <@root> smp foobar: secrets proved equal, fingerprint trusted

You can also verify it with “otr info <nick>”:

15:37 <@aaron> otr info copecd
15:37 <@root> foobar is foobar@gmail.com/jabber; we are aaron.toponce@gmail.com/jabber to them
15:37 <@root>   otr offer status: none sent
15:37 <@root>   connection state: cleartext
15:37 <@root>   fingerprints: (bold=active)
15:37 <@root>     13C45179 F2A8645B 466463E8 228DBE16 787D1A82 (affirmed)

As already mentioned, there are other ways for verifying that the person on the other end is who they say they are, and OTR in Bitlbee supports it. You will notice too, that once the fingerprints have been trusted on both sides, the text is green in the chat window. If not trusted, the text is red. As far as I know, there is no way to change the color, or have any other sort of visual clue on whether or not trusted encryption is taking place in the communication.

Also, is should be worthy to note that Bitlbee OTR only supports conversations through Bitlbee, not your IRC client. This means that if you are using Irssi, Weechat, or some other IRC client, Bitlbee OTR won’t help you for IRC messages. You’ll need an OTR plugin for that as well. This is definitely a drawback. For example, if you use Irssi like I do, there is an OTR plugin for Irssi. Not only will it handle IRC, but any message through IRC, including those of Bitlbee. However, the Irssi OTR plugin hasn’t been updated in two years, and it has security holes that haven’t been addressed. The Bitlbee OTR plugin is up-to-date and in my opinion, much more streamlined. I don’t use private IRC messages much, so the Bitlbee OTR plugin works just fine for me.

Now, start using OTR with Bitlbee. If you love your Bitlbee as much as I do, you will.

“Still, it would take thousands of years to crack an 8-character password when checking both small and capital letters, spaces, and numbers. That’s on a low-power computer, but the time it takes to crack a string of characters goes up exponentially the more characters you use. So again, use a long password and you can foil even the Watsons of today for long enough that you would probably decide on a whim to change your password before the password is solved.”

I guess I should expect more out of them, but I was disappointed, and I want to use this blog post explaining why. If you wish to write an article about password security, regardless of the angle from which you approach it, if you don’t mention entropy to your readers, you are doing them a GREAT disservice. Let me rephrase:

If you don’t mention entropy in your article about passwords, you did it wrong.

If you’ve taken physics in secondary or undergraduate school, chances are good that you’ve heard about entropy. If not, you’ll learn about it now. Entropy in computer science is very similar to entropy in physics. To put it straight, entropy is defined as the total combination of states that a system can be in. For example, if you have 3 cups, and 4 ping pong balls, how many ways can you arrange all 4 ping pong balls in the 3 cups? Assuming that 4 ping pong balls will fit in 1 cup, and order is not important, you can arrange the ping pong balls 12 different ways: {4,0,0},{3,1,0},{3,0,1},{2,2,0},{2,0,2},{2,1,1},{1,1,2},{1,2,1},{1,3,0},{1,0,3},{0,4,0},{0,0,4} So, this system has an entropy of 12. Entropy in physics is useful to show the Ideal Gas Law, among other things, showing the possible number of states various gases can be in, and it’s useful for explaining why some things systems behave one way, but not in the reverse (such as temperature “flowing” from hot to cold, and not the reverse).

It turns out that entropy has a great deal of use in computer science. For example, on most Unix-like operating systems, there is a /dev/random and /dev/urandom device. These devices are useful for extracting random bits to build encryption keys, one-time session keys, seeds for probability outcomes, etc. These devices hold entropy. In /dev/random, for example, environmental “noise” is gathered from the user, such as mouse movements, disk usage, etc. and thrown into an entropy pool. This pool is then hashed with the SHA1 hashing algorithm to provide a total of 160-bits of entropy. Thus, when generating a 160-bit key, the data in /dev/random can be used. If more bits are needed, entropy is gathered by hashing the already hashed bits, as well as gathering additional noise from the environment, and appending to outcome until the number of bits is satisfied. The point is, /dev/random and /dev/urandom are sources of entropy.

So, what does this have to do with passwords? Your password has a certain amount of entropy. This means, that it belongs to a pool of passwords that have the same amount of entropy. The question is, though: “how do you calculate the amount of entropy in a password?” Thankfully, we don’t have too think to terribly hard about this one. If you’ve taken college algebra, the math is pretty straight forward. Entropy in information comes from a branch of probability called “information theory“. Any message contains some amount of entropy, and we can measure that entropy in binary bits. The formula for calculating this entropy is:

H = L * log_2(N)

H is the size of the message measured in binary bits. L is the length of the message- in our case, the length of your password. log_2() is the log function, base 2, and N is the number of possible symbols in the password (only lowercase letters provide 26 possible characters, uppercase provide an additional 26 possible characters, the digits provide 10 possible characters and punctuation provides 32 possible characters on an United States English keyboard). I rewrote the equation, so you could find it using your calculator:

H = L * log(N) / log(2)

Having this formula makes calculating the entropy of passwords straight forward. Here are some examples:

• password: 38 bits (8 * log_2(26)
• RedSox: 34 bits (6 * log_2(52))
• B1gbRother|$alw4ysriGHt!?: 164 bits (26 * log_2(94))
• deer2010: 41 bits (8 * log_2(36))
• l33th4x0r: 46 bits (9 * log_2(36))
• !Aaron08071999Keri|: 131 bits (28 * log_2(94))
• PassWord: 46 bits (8 * log_2(52))
• 4pRte!aii@3: 78 bits (12 * log_2(94))

Question: what gives you more entropy per bit- length or possible characters? If you passed college algebra, you would know that the answer is length, not total possible characters (if you need to think about this, graph the log function on your calculator, then graph a multiple of it). Of course, you shouldn’t ignore using lowercase, uppercase, numbers and punctuation in your password, but they won’t buy you as much entropy as length will. Thus, I prefer the term “passphrase” over “password”, as it implies this concept to the user.

Here’s a table showing the length your password must be given the possible character combinations in your password, if you want a certain entropy. Say you want an entropy of 64-bits using only numbers, it would need to be 20 characters long. If you wanted an entropy of 80 bits using characters from the entire ASCII set, it would only need to be 13 characters long.

So, how much entropy should you have in your password? What is considered “strong”? Well, let us look at Distributed.net. They are working on two projects: Optimal Golomb Rulers and cracking an RSA 72-bit message. Let’s look at the RSA project. In January 1997, RSA Laboratories issued a secret key challenge. They generated random keys ranging from 40-bits to 128-bits. They provided the ciphertext, and a $1,000 prize to the person who find the private key that generated the message, for every message. In order to know whether or not you found the key, they gave you the first two words of the message.

Currently, as already mentioned, Distributed.net is working on the 72-bit key from that challenge. If you check the stats page, you can see that it has been running for 3,017 days as of the writing of this post, and at the current pace, it would take roughly 200,000 days to search the entire key space. Now, of course it is probable that they will find the key before exhausting the entire space, but knowing when that will be is anyone’s guess. Needless to say, 200,000 days or about 540 years at the current pace is substantially large. If they kept that pace up for the 80-bit key, it would take them roughly 140,000 years to search the entire space. However, it only took them 1,726 days, or 4-and-a-half years, to find the 64-bit key, and only 193 days, or 6 months to find the 56-bit key.

So, I think that should give you a good rule of thumb to go by. 72-bits of entropy for your password seems strong enough for the short term, but it wouldn’t hurt to probably increase your passwords to contain 80-bits of entropy for the long term. Of course, I don’t think I need to mention not using your names, birthdates, or other silliness in your password. That’s been beaten to death plenty online. Search Google for generating strong passwords, and you’ll find plenty of them (all of which don’t mention entropy either, I would be willing to bet).

Now, to be fair, the Ars Technica article mostly mentioned STORING your passwords, not how to create strong ones. I’ve already written about this before, and I think it’s the perfect solution. http://passwordcard.org is the exact solution for storing strong passwords that have a good amount of entropy in them. The great thing about it too, is it does not require any software once generated. It stays with you in your wallet, so if you visit a computer that doesn’t have your encrypted database, or you are not allowed to install software on the machine so you can restore your password database, the password card is the perfect fit. It’s entirely platform-independent. Just pull it out of your wallet or purse, type in your password, and move on with your life. All you need to remember on the card is three things:

1. The starting column and row of your password.
2. The length of the password.
3. The path your password takes on the card.

I’ve been using it since it first “released”, and I use it for all my passwords on all my accounts, web-based, key-based or account-based. Every password is unique, they all contain more than 100-bits of entropy, and every password follows the “best rules” for creating strong passwords. I’ve typed many of them enough to have them memorized; I rarely pull out my card (there is also an Android and Apple application if you want).

So, next time you read an article about password strength, do a quick search for the word “entropy”. If it’s not mentioned, take the article in stride, or at least notify the author of this post, and that they should discuss entropy to their readers. Entropy is your friend.

Hashcash is a really slick concept. The motivation is to combat spammers by using your CPU to calculate a SHA1 string starting with the first 20-bits as zeros based on a random number. Basically, a “proof-of-work” system. If the random number, combined with the timestamp and the recipient’s email address, doesn’t provide those first 20-bits of zeros, a new random number is chosen and hashed. Once the random number is found, it’s attached to the header of the email, and sent. The recipient of the email can then hash the full string, and see if the first 20-bits of the resulting SHA1 are zeros. If so, along with some other validity checks, then the hash is considered valid, and you can rest assured that the email was not sent by a spammer.

A valid stamp:

1:20:110303:aaron.toponce@gmail.com::d2e1fcbcbdb8bf08b804b65c4d61f5be:2b1825ea77c0bb82

You can verify this with:

% echo -n '1:20:110303:aaron.toponce@gmail.com::d2e1fcbcbdb8bf08b804b65c4d61f5be:2b1825ea77c0bb82' | sha1sum
00000d0a92fad840b05009c8692f43593c692589  -

Notice how the first 20-bits of the SHA1 hash are zeros? This is a valid hash based on the random number, the email address and the timestamp.

How does this defeat the spammers? Well, because finding the right random number that will produce a hash with the first 20-bits of zeros is computationally expensive. There will be one in at least 2^20 hashes, but the search in finding one is expensive. A modern computer can find one in under a second. But, if you wish to send bulk emails all at once, you need to create a hash “token” or “stamp” for each one. Due to the design of the algorithm to be slow, this will seriously hinder your ability to be efficient at sending bulk mail. Spammers be damned.

The proof-of-idea work is slick. The sender of an email has done the work necessary, and you can easily validate the work is been done much faster than it took to create. However, it appears from the website that all activity on the software has been abandoned since 2006, including updating the web page. Software is hard to find, and for the software that does exist, it’s only compatible with very specific versions of software, leaving old or new software out of the game.

A couple examples.

Penny Post is an extension for Thunderbird. The SourceForge page houses the extension that is only compatible with Thunderbird versions earlier than 3.0. However, there is a Github project working on a Thunderbird 3.0-compatible extension. However, this extension is not compatible with Thunderbird 3.1. The extension page has also been pulled from Mozilla Addons.

Hashcash-sendmail is a Perl script for Mutt. It works by coupling the hashcash binary and the sendmail binary together to deliver your stamped mail. However, if you are using Mutt’s buitin SMTP support, then the Perl script isn’t usable. Also, it appears that the author of the script has lost his domain, and there hasn’t been any updates since 2004, it seems.

Lastly, I have a Windows XP laptop for work with Thunderbird 3.1 installed. Of course, Penny Post isn’t compatible with 3.1, so I’m already out of luck. However, even the Windows Hashcash binaries are out of date by several years.

Nevermind trying to implement it into more popular MUAs, like webmail clients (Gmail, Yahoo!, MSN, AOL, etc.), Outlook, Groupwise, etc. It just doesn’t exist. Yet, SpamAssassin has full support for identifying the “X-Hashcash” email header.

No matter where I look, I reach dead ends. This is unfortunate, because I see Hashcash as a slick way of beating spam, yet it appears that the spammers are laughing all the way to the bank. They’re not worried because no one is using it. And I have a feeling that no one is using it, because no one is developing anything for it. Everything out there is at least 5 years old and aging.

Maybe another slick proof-of-work system will come along. Who knows? I would like to work it into my daily email routine, but it appears that doing so with the current state of affairs is futile. I guess I could work on developing scripts and such that could be easily implemented into various MUAs, but with the amount of stuff I want to do after graduation, I’m guessing it’s fairly low on the priority list.

The motivation is three-fold: I want raise awareness for encrypted email, I want to expand the Web of Trust and I want to sign keys. I believe we’ve gotten too anal retentive about the rituals of signing each others keys, and I would like to bring it more to the forefront of the general public. There is no reason why email shouldn’t be encrypted 100% of the time, and doing the Song and Dance of creating a conga line, reciting fingerprints, and verifying identifications has probably gone a little overboard.

Thus, on my policy page, you’ll notice that I’m willing to sign your key if you just send me $1 USD along with your email address and key. I’ll return the $1 after I’ve signed it. Or, you can send me a colored scan of your U.S. passport or driver license, and I’ll sign your key. Crazy? Maybe. I’m fairly confident, however, that the government, or powerful enemies, isn’t planning a coordinated attack against my identity.