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.