|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.

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.

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.

To generate an ECC SSH key for your host, you need to use the “ecdsa” encryption type. The bit strengths are 256, 384 and 521. Generally speaking, the equivalent DSA keys would require 4-times the bit strength of ECDSA keys. In other words, a 256-bit ECDSA key is equivalent in strength to a 1024-bit DSA key.

Pull up your terminal, and type:

% ssh-keygen -t ecdsa -b 256

Go through the prompts, and you should have your generated private and public keys. Then, copy the key over to your remote server, and start using:

% ssh-copy-id -i ~/.ssh/id_ecdsa.pub user@server.tld

Of course, the remote server does need to support ECC in order to take advantage of ECDSA keys, which means it too needs to be running OpenSSH 5.7 or later. Here’s a result of the key sizes:

% ls -l ~/.ssh/*.pub
-rw-r--r-- 1 aaron aaron 604 Feb 17 20:05 id_dsa.1024.pub
-rw-r--r-- 1 aaron aaron 176 Feb 17 19:41 id_ecdsa.256.pub
-rw-r--r-- 1 aaron aaron 220 Feb 17 19:42 id_ecdsa.384.pub
-rw-r--r-- 1 aaron aaron 268 Feb 17 19:42 id_ecdsa.521.pub
-rw-r--r-- 1 aaron aaron 228 Feb 17 20:07 id_rsa.1024.pub
-rw-r--r-- 1 aaron aaron 398 Feb 17 20:08 id_rsa.2048.pub

As you can clearly see, ECDSA keys are substantially smaller compared to their DSA counterparts and a bit smaller than equivalent RSA keys. Also, it should be mentioned that when setting up the OpenSSH server on a new host for the first time, you can also choose to have ECDSA host keys generated for the server, rather than the standard RSA or DSA keys.

I don’t recommend wiping your existing RSA or DSA keys in favor of ECDSA quite yet. Plenty of OpenSSH and proprietary SSH servers exist that do not support ECC. Thus, your newly generated ECDSA key won’t work, even if you copy it to the authorized_keys file. However, if you have the servers that support it, then why not give it a go, and see what you think?

$ gpg -v --version
gpg (GnuPG) 1.4.9
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8),
        AES256 (S9), TWOFISH (S10)
Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9),
      SHA512 (H10), SHA224 (H11)
Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3)

So, for ciphers, I support 3DES, CAST5, BLOWFISH, AES, AES192, AES256 and BLOWFISH. For digest hashes, I support MD5, SHA1, RIPEMD160, SHA224, SHA256, SHA384 and SHA512. Lastly, for compression algorithms, I support uncompressed, ZIP, ZLIB and BZIP2. Your output my vary slightly one way or the other. For example, you may not see the full suite of SHA algorithms. This can be obtained by generating an RSA subkey for signing only. Other ciphers might include IDEA, CAMELLIA128, CAMELLIA192 and CAMELLIA256, and you could have TIGER and WHIRLPOOL as possible supported hashes.

With all these algorithms, how do you know which to use and when? Fortunately, GnuPG takes care of that for you automatically. However, you can tell it what you would to prefer to use for each, if you like. You can set these in your ~/.gnupg/gpg.conf file. The options you are looking to set are “default-preference-list”, “personal-cipher-preferences”, “personal-digest-preferences” and “personal-compress-preferences”. For myself, here is what I have set in my gpg.conf:

default-preference-list 3DES CAST5 BLOWFISH AES AES192 AES256 TWOFISH MD5 SHA1 RIPEMD160 SHA224 SHA256 SHA384 SHA512 Uncompressed ZIP ZLIB BZIP2
personal-cipher-preferences TWOFISH AES256 AES192 AES BLOWFISH CAST5 3DES
personal-digest-preferences SHA512 SHA384 SHA256 SHA224 SHA1 RIPEMD160 MD5
personal-compress-preferences BZIP2 ZLIB ZIP Uncompressed

Now, when we printed out the verbose version, we saw in parenthesis S2, S3, H8, H9, Z1, Z2 and so on. We can use these instead of the name in our gpg.conf if we so wish. I prefer the name, as I can’t recall the key to the algorithm, and it’s easier to read. So, in my case, I list out everything that I want for a default list of preferences, then I choose the order of which to pick from when encrypting, signing and compressing. So, for encryption, I have set TWOFISH as my first choice, with AES256 as my second choice, then AES192 as my third, and so forth. I’ve done the same with my preferred digest hashing algorithm choosing SHA512 first, then SHA384 second, and so on, and the same with compression.

Why set the preference? For starters, if you’re like me, you sign all your email by default. You probably want your signature to withstand the test of time as long as possible. Given the strength of today’s hardware, why not choose the strongest encryption and hash algorithms? But on a more practical note, if you’re encrypting data to yourself, this would tell GnuPG to use TWOFISH as the encryption algorithm. This means that if you want to decrypt it at a later date, maybe on another computer, you’ll need to make sure TWOFISH is compiled into GnuPG. How would you know what was used? We’ll cover that in a bit.

However, what about encrypting to someone else other than yourself? How do these preferences come into play? Well, you can also set preferences in your public key. The purpose of this, is when people grab a copy of your key, and they want to encrypt something to you, GnuPG will negotiate the first preferred algorithm that is common between the two end points (the one doing the encrypting and the one receiving the encrypted data).

For example, let’s suppose Alice has a GnuPG keypair as does Bob. In Alice’s public key, which Bob has a legitimate copy of, she has set a cipher preference order of: TWOFISH BLOWFISH AES CAST5 and 3DES. Bob wants to encrypt data to Alice. Because he has a copy of her public key, he can do this. The question here is, which algorithm will be chosen for the encryption? Well, Alice prefers TWOFISH as a first pick. If Bob has compiled TWOFISH support in his copy of GnuPG, then it will be used. Suppose he doesn’t have TWOFISH support. Then the next preferred algorithm is BLOWFISH, because it’s Alice’s second pick. Let’s say Bob does support it, then BLOWFISH is the algorithm used for encrypting the data to Alice. When Alice receives the encrypted data, she’ll use the BLOWFISH algorithm along with her private key to decrypt the data. Should she wish to reply, her copy of GnuPG will pull out the preferences from Bob’s public key, and go through the same process looking for the first preferred algorithm by Bob that is supported by both parties. The “SSL handshake” works much in this same manner.

Digest hashing works much the same way, but slightly different. Because the recipient doesn’t matter with signed data, then rather than looking to public keys for the digest algorithm preference, you turn to your gpg.conf file, if listed, and use that there. If the recipient, or recipients have a copy of your public key, and the same digest algorithm compiled into their copy of GnuPG, they can verify your signature. If either is missing, the public key, or the algorithm, the signature will fail, and GnuPG will explain the problem. This process is the same for compression algorithms.

So, we’ve made the preferences in our gpg.conf, but how do we set them in the public key, so we can distribute this to others? Well, in this case, we need to edit our key. From the terminal (I’ve snipped out the noise, focusing only on what’s important):

$ gpg --edit-key KEYID
gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.
[ ... SNIP ... ]

Command>

We are now sitting at a command prompt that we can use to pass commands in an interactive fashion. I should mention that all this can be done non-interactively. Checking out the gpg manual will provide the list of options for making this possible. Typing “help” will give us the list of commands that we can pass:

Command> help
[... SNIP ...]
pref        list preferences (expert)
showpref    list preferences (verbose)
setpref     set preference list for the selected user IDs
[... SNIP ...]

The commands that we are interested in “pref” and “setpref”. Passing “pref” might give us something like the following:

Command> pref
[ultimate] (1). Aaron <aaron@example.com>
     S10 S9 S8 S7 S4 S3 S2 H10 H9 H8 H11 H2 H3 H1 Z3 Z2 Z1 Z0 [mdc] [no-ks-modify]

See those algorithm codes we saw at the beginning of this tutorial? They are listed in the preferred order that we wish to have each algorithm. In my case, I have all my encryption algorithms lists, from strong to weak, then hashing from strong to weak, then compression from most tight to no compression. What if I wanted to set a different order, or maybe not include some preferences: Using “setpref” makes this possible:

Command> setpref S10 S9 S8 S7 H10 H9 H8 H2 H3 Z2 Z1 Z3 Z0
Set preference list to:
     Cipher: TWOFISH, AES256, AES192, AES, 3DES
     Digest: SHA512, SHA384, SHA256, SHA1, RIPEMD160
     Compression: ZLIB, ZIP, BZIP2, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences? (y/N)

Typing “y” will of course make the setting in your key. At this point, you’ll be asked to enter your private key passphrase successfully before continuing. At that point, it will be statically set in your public key, and you can send your key off to the keyservers and emailed to your family and friends, so they can immediately start taking advantage of the new preferences. Type “quit” to leave the prompt.

Now, let’s say you have some signed and encrypted data, and you’re curious of the algorithms used when creating the cipher text. This can be done by passing the “–list-packets” option to gpg to see the data packets. We’ll need to turn on verbosity as well. For example, the output of a file I sent to a friend using the Mutt email client (emphasis mine):

gpg -v --list-packets file.txt
gpg: armor header: Version: GnuPG v2.0.11 (GNU/Linux)
[... SNIP ...]
gpg: AES256 encrypted data
:compressed packet: algo=3
:onepass_sig packet: keyid CE7911B7FC04088F
	version 3, sigclass 0x01, digest 8, pubkey 1, last=1
:literal data packet:
	mode t (74), created 1244484492, name="mutt-helios-1000-24974-13",
	raw data: unknown length

Here, I can easily see that AES256 was used for the encryption algorithm, but what’s this compressed “algo=3″ and “onepass_sig packet digest 8″ stuff? Well, in order to understand those, we need to turn to RFC 4880. This RFC describes the OpenPGP message format and the standards used. Browse your way down to section 9, and you’ll see what “algo=3″ means for compression and “digest 8″ is for signatures. It appears, according to that RFC, that BZIP2 was used for compression and SHA256 was used for the hashing algorithm. So, in this case, Christer and myself preferred those settings higher than the others, and my GnuPG acknowledged those preferences and did the encrypting, signing and compressing as told. We can see these by “editing” his key:

$ gpg --edit-key christer
[... SNIP ...]
Command> pref
[  full  ] (1). Christer <christer@example.com>
     S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1 [mdc] [no-ks-modify]
[... SNIP ...]

Command> quit

Christer places AES256 has his first preferred encryption algorithm. Because I also support this algorithm, this is used for the encryption. SHA1 is his preferred digest hashing algorithm with SHA256 as his second preferred, but remember that for the signature and compression, these preferences are found in my gpg.conf instead. I prefer SHA512 as my first preference, but he doesn’t list it as suported (according to his public key), so I move down to SHA384. Again, he doesn’t list it, so I try SHA256. He lists it, so it’s used. Lastly, BZIP2 as the compression algorithm, and he lists it, thus it’s chosen. Thus, the results we got. Make sense?

I hope this has been informative. It’s been great discovering the details of how these algorithms were chosen, and it’s been fun playing with all sorts of encrypted emails and files to get to the guts of the GunPG process. If I’ve misrepresented any data here, or you have questions, please let me know.

GnuPG version 2 is available in the Ubuntu repositories. Pull up a terminal, and type:

If you want to make version 2 the default for all applications, including Seahorse, KGPG, GPA, Enigmail, and others, then we just need to backup our currently installed binary, and create a symbolic link pointing to version 2:

If there is a better way to do this with your ~/.gnupg/gpg.conf file, I would be very interested. The above seems “hack-ish” to me. Removing the ‘gnupg’ package from Ubuntu also breaks many, many packages, so that doesn’t seem to be a sane option.

The update is necessary to keep you from encrypting data to me using an algorithm that is not supported by GnuPG. At a previous job, I needed support for the IDEA algorithm, found in PGP2, so I imported that library into GPG and added support for it in my key. As I no longer need support for that patented algorithm, I’ve removed the preference from my key, which will affect the public key that you have.

If you have any errors encrypting data to me, or verifying my digital signature, please email me the error, along with a screenshot, so I can troubleshoot the issue. I believe I may have a few more cockroaches lying around, such as the IDEA algorithm.

From: Jani Taskinen
Subject: Good bye.
Group: php.internals
Date: Thu Jul 27 20:28:45 2006

Thank you all for the last 6 years or so. It has been fun (sometimes) and many times not so much fun. Unfortunately I have had enough and I don’t want to be associated with this project anymore.

I’m sure most people (the ones who matter) can understand why. If someone doesn’t, I could not care less. Take care.

Please do not reply to this email.

–Jani

p.s. Delete my CVS account. I have no use for it anymore.

When I give my security presentations on cryptography, a common security flaw that I like to bring up is using 3rd party programs to send email to others which looks as though it came from a certain account; in this case, Jani’s email at iki.fi. Heck, even a little JavaScript can do the trick.

Once, while giving a presentation to university class, I told the class the following scenario:

If you were to receive an email in your inbox from your professors email address, would you believe it was send from him? Of course you would. There would be no reason not to. At least not yet.

What if the email said that due to a family emergency, he would no longer be able to instruct the class, and that everyone will get an ‘A’ for the course. The email would say further, don’t bother attending class or responding to the email as he will be out of town taking care of the family emergency. Also, he’ll have all the details worked out with the school.

Would you still believe the email is legit?

Not surprisingly, everyone in the class, including the professor, said they would totally believe the email, and quit attending class. Only a handful of students said that they would stay in contact with the school administration making sure all the details went smooth. It is unfortunate that they would be the only ones, with the professors help, smoothing out the scam.

What is the point? The point is to generate a public cryptography key-pair, and begin digitally signing all of your emails. This way, everyone can be assured that the email did in fact come from whomever it says it came from, so long as the email validates, and the necessary steps have been taken to ensure the public key belongs to the actual owner.

Right now at this point, I am not believing the email. I believe that it is scam, and the wrinkles will be smoothed out soon. Hopefully, Jani signs his emails, and will be able to refute this nonsense. However, if the email is legit, confusion could have been avoided if the email was just signed. It will undoubtedly be a big loss for the PHP community.

I’ve said it before, and I’ll say it again: If you receive an email from me and it is not signed, or the signature fails, you should question the authenticity of the email text and whether or not it did actually come from me. I go to great lengths to ensure that my email validates before sending, so rarely will an email from me not check out.

• http://keyserver.ubuntu.com:11371
• http://keyserver.veridis.com:11371
• http://pgp.mit.edu

The main reason I choose these are because they can handle multiple subkeys and modified UIDs whereas many keyservers cannot. At any rate, I thought that I would share this, because they are solid, always up, great web interface and easy to use.

I used to sign all of my emails, regardless. Well lately, I have been getting lazy and haven’t been so steadfast. However, my motivation has been renewed since Christer started asking me questions about it. So, from here on out, every email sent from me will be signed. If the email is not signed with my key, then you should question whether or not it came from me. If the signature fails (I will always do my best to make sure this doesn’t happen), you should also question the authenticity of the email.

I try and keep an updated version of my key on all the public keyservers that I can, however, you can always find the most up-to-date key on this blog. Speaking of which, I made some edits to the key this morning, so it is recommended that you grab this most updated copy.

Being a Computer Science Major and Math Minor, I enjoy cryptology immensely. I hope to be a cryptologist when I grow up. I have been studying in this vast field for quite some time, and would love to speak to any Linux Users Group concerning cryptology- whether it be about its history, application, variations, or related fields. I have a great amount of data on the subject at hand, so presenting on just about any aspect of it is no problem at all. Just drop me a line.