All right. Now,
we're going to start talking about how to use cryptography when you're
doing secure programming. We're going to start with
using it for secrecy. The basic idea is take
your symmetric algorithm, generate a random secret key, and cipher the data using
that random secret key. You then have to keep
track of that secret key. There are a number of
ways you can do this. You can put it in a file
encrypted with your password, so when you log in that key
becomes available, or you can also encrypt
it using the public key, and then if you like even
send it on to the recipient. The issue here is that once the key is enciphered
with the public key, you can then use
the corresponding private key to decipher it and get the secret key that you can then use to
decipher the message. So, in essence, the secret key becomes what's called a session key or a data exchange key. It's only used to
encipher the message. The public key here or your password is what's
called the interchange key, and it's used to
encipher the key, the session key or
the data encryption key. This is done so that
you won't have to reuse your session key or your data
encryption key again. There are a variety
of reasons for this. The interchange key however, encrypts much less data
and is used much more rarely and just
typically not exposed. This is the private key. So, it can be used much more often than can be that data encryption key
or the session key. Now, let's say you want to use cryptography
for integrity. The goal here is not
to keep it secret or the content secret. The goal here is
to make sure that the only people who can
change it are those who know the cryptographic key to essentially turn off
the integrity checking, make the change and then turn on the integrity checking
on the new data. So, the way this is done
is you typically you take a hash function and
you hash the data. There are special functions for this called cryptographic hashes. MD5 is an old one that's showing its age and I
wouldn't recommend its use, but the SHA family, avoid SHA-1 but SHA-256
is still pretty strong, and then there are many others. So, you take your data
and crunch it down, run it through this
cryptographic hash function. You then encipher that
using your private key. Now, if anyone wants
to validate the data, they get your public key, decipher the message interchange, decipher the cryptographic hash through the message
interchange code. Then they recompute
it and compare. If they match, no
one's changed it. If they don't match,
either they have the wrong key or
someone changed it. In either case, the data
become suspect. The nice thing about this is, under the assumptions of
public key cryptography, which means that the holder of the private key is the only
one who has access to it, no one can forge my signature, because if they all
know my private key, they can't encrypt the hash in such a way that it will
decrypt with my public key. So, it not only gives
you integrity checking, it also gives you authentication. This in fact is
the technique used to distribute programs
over the internet and I'm going to go through
the process very quickly because it's quite interesting and it will give you some ideas. When you download
something from the web, how did you know that
an attacker hasn't changed it from what
the author wrote? This has happened. In fact, with security software, there's a program called TCP wrappers that is widely used. It's now integrated
into most systems, but for a long time
it was a program that you would download and
install on your system. Well, it turned out one day
some attackers got into the website and changed
our TCP wrapper, so would allow them in
without any further checking. It got caught within
I think eight hours, and they had a list
of who had downloaded the rigged TCP wrapper. So, they were able to notify everyone and clean everything up. Ever since then, what
everyone does is they take the program, compute the
cryptographic checksum, and then encipher that
using a private key. When you go to
download the software, you download the software and download the enciphered
private key, get the public key of
the person who signed it, presumably you trust, and
then use that to decipher the hash and then you can recompute and
validate that it works. For this anyway, we're
going to use GPG. Other public key programs
work fine but GPG is by far a very
widely used one. The file that you're going to validate is typically a binary, so we're going to call it binary. I'm assuming that you've set up GPG and have a public
and private key pair. So here's how it works. The author of the program is used the first set of
commands on signing and verifying the binary.
This is the signing. They use the armor flag, which basically says
the output is to be printable. Then they use the detached
sign for the binary. What happens then is that GPG computes the
cryptographic checksum, puts it into a file since it's printable and ends
the file with.asc. So, as you'll see when
you do the ls there, you have the original file and then you have a file with.asc, that last one contains
a cryptographic checksum. Okay. Now, someone downloads it and then download the.asc file. By the way sometimes
these are called.sig too. Anyway, you download
the asc file. What do you do next? Well, the first thing is you need the developer's public key, the public key of
the person or organization that generated the signature. Once you've got that and you can import it as shown in
the first line there, the verification import
keys and keys is the file containing the public keys
you want to install. You then run dash dash verify, giving it both the signature
file name and the file name. What GBG will do is check to
be sure that the signature matches that generated
from the binary. Now, notice how it does that. It uses the developers key, which you've just put in. So, that's why it's
so important to have the developers key there. Here's an example, which I did to validate an HTTPD daemon
from Apache. First thing, is I use wget to get the keys for the developers, and then just imported
them into my key ring, my GPG file that holds the keys. I then download
the Apache release I want. I was using this to do
some security testing, hence the 2.4.10, rather than the current
one and the signature. Then you can see how I did
the verification there, exactly, as I showed
you before the verify, followed by the signature file, followed by the
actual program files. You can see exactly
how it prints out. The first four lines are
the ones that are relevant here, because it shows that
the signature was made, and it's a good signature
from Jim Jagielski, who was one of
the developers of Apache. It also warns me that
the key is not signed. His key is not signed
by anyone I trust. That's okay. In this case, the source of the key was
trustworthy enough for me.