hpr-knowledge-base/hpr_transcripts/hpr1410.txt

Episode: 1410
Title: HPR1410: Generating Keys on the Command Line
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1410/hpr1410.mp3
Transcribed: 2025-10-18 01:00:37

---


Hello, this is Ahuka. Welcome to Hacker Public Radio and a further exploration of security
and privacy in our new series. And we have laid some groundwork, giving you a little bit
of a theoretical background to all of this and some of the history, but time to get practical.
So we've looked at the basics of encryption, but how do you go about actually doing this?
So for the moment, we're going to set aside all that discussion of mathematics in one way functions
because you don't actually need to know that to use this stuff.
In fact, there are tools that make it extremely simple. If you recall, we mentioned one of them previously,
a neat little program called Pretty Good Privacy, usually abbreviated as PGP.
This was first released in 1991 using an algorithm that Phil Zimmerman created,
but later on it switched to using RSA encryption. Then in 1999, a GPL licensed standard
called the GNU Privacy Guard, or GPG, was created that does essentially the same thing as PGP.
For most purposes, just treat them as interchangeable in terms of the practical usage.
The thing that is important, and I have no distrust of Phil Zimmerman,
but in general, and we'll talk about this later, using free software is pretty important
if you value your privacy and security, because if people don't have access to the source code,
they can't dig into what's going on. How do you know it's really secure?
So that's why I use the GNU Privacy Guard with the GPL license, and I feel a little bit better doing that.
As I said, we're not going to go any further, we're not going to be talking about mathematics,
we're not going to be talking about XOR transformations.
This is intended to be a practical layperson's guide to actually doing this stuff.
And step one is to get the software you need to create keys.
As it turns out, GPG is available for Windows, Mac OS X, or is that OS X or OS X 10, I'm never quite sure, and Linux.
So even though it is a GPL licensed free software, it is very much available across platform.
So if you're using one of these other platforms, no problem at all.
You can see documentation for it on the GNU PG.org website.
And I will have some links in the show notes for these things.
So some of the things that I mentioned here, I'll point you in the right direction for where you can look it up on the web and see this.
So how are you going to implement all of this?
Well, you can implement it with the command line, and that's actually what we're going to focus on in this particular episode.
And it's not terribly hard, and I think most people who are Linux users are not the least bit distressed by doing something on the command line.
But if you are on Windows, there is a client called Cryptofane, C-R-Y-P-T-O-P-H-A-N-E, and that is a Windows client, GPLV2 licensed, and lets you create your key pairs on a Windows machine.
Then there's the GNU PG shell. This is available for Windows or Red Hat and Debian installers are available.
The GNU Privacy Assistant, which is built with the GTK Toolkit Compiles for various platforms.
There's KGPG, which, as you might expect, is the KDE Frontend for GPG, available on all KDE distress, and Seahorse, which is the GNOME Frontend for GPG.
So you've got lots of options. I want to talk about doing it on the command line, and then next time I'm going to take the KDE, because KDE is what I use, I should think between the two of them that's enough to get you going with any of the others.
You can go to one of these websites and follow along, and after you've heard this program, it really already tells you everything you need to know.
So what these do is they give you the raw material for your encryption, which is a key pair.
We call it a key pair. Remember, this asymmetric model that goes all the way back to Diffie-Helmond Merkel, and what that is about is the idea that you have a public key that you give to everyone and say, hey, if you encrypt anything with this public key, I'm the only one that can decrypt it.
So people use your public key to send you stuff, and then there's your private key that you keep very, very private, you keep that to yourself, and that's what you use to decrypt.
So that's the starting point. You need that key pair. Now, once you have that, we can start looking at applications that comes a little bit down the road.
I just wanted to get you through the idea of basics of creating the key pair. So every project has to start somewhere.
So what are the basics of creating a key pair on the Linux command line, which is how I'm going to do this. I'm doing this on Kubuntu 1304, but it should be about the same for any other Linux system.
To begin this process, you type the command, gpg, space, dash, dash, g-e-n, dash, k-e-y. It's not that hard.
Then you will get a response that will tell you gpg, parentheses, GNU PG, and in this particular one, I got 1.4.12 semi-colon copyright.
2012 free software foundation incorporated. This is free software. You are free to change and redistribute it. There is no warranty to the extent permitted by law. Then it says, please select what kind of key you want.
And that's where you have to type in something, generally a number.
So number one would give you RSA and RSA, and then it says, well, that's the default. Now generally speaking, if you don't know any better in these situations, sticking with the default is usually not bad.
Then choice number two is DSA and L Gamal. Now RSA is a type of encryption, and we talked about that. It's named for the three people from MIT who put that together.
You can have various types of encryption. I think RSA is pretty standard. And generally speaking, it's pretty good. So I'm going to stick with that.
Then three and four, DSA sign only, and then four is RSA sign only. And now what they're talking about here is sometimes you don't want to get into encrypting.
And you just want to be able to sign your email. And you may have received emails that had a PGP signature attached. And the idea of that is that that generates a couple of things that it does not encrypt the email obviously because if you've gotten them before, you've seen, oh, I can read the email, that's not an issue.
There's a lot of gobbledygook at the end that doesn't mean anything. And what that is is basically it is a checksum of the message. So you will know that the message hasn't been altered. And it's something with the public key that sort of guarantees that, yeah, I'm the one who did this. And it hasn't been altered. And you can rely on this email.
It's a bad thing to know. But at this point, I'm going to say, let's go for the whole enchilada. So we'll choose number one. And that's going to get us RSA and RSA. So what that means is we will get the public and private key and the sign only key and all of that stuff altogether.
So with that choice, you type one. And then it program comes back and says RSA keys may be between 1024 and 4096 bits long. What key size do you want? And then it gives you a default that you can just accept, which is 2048.
Now key size is what determines how secure your keys are to brute force attacks. If someone like the NSA or GCHQ were trying to crack your encryption, you want a secure key.
Now at this point, pretty much no one thinks 1024 is secure. Now it that's not saying that it's easy to crack a 1024. But to someone who has the resources and is willing to develop them, it is crackable. That's pretty much given now.
So your choice is between 2048 and 4096. 2048 is considered by the National Institute of Standards and Technology in the United States. Now that is a government agency, but they've said they think that 2048 should be secure through the year 2030.
So it gives you about 17 years. Should you trust NIST? Well, given what we know about the electrical curve encryption standard that NIST promulgated and which was fouled up with NSA's help, I wouldn't blame you if you question them a little bit.
But actually from what I've seen, looking at what some of the experts and if you go back to our first program in this series, I pointed you towards all of these places that I check in on to get this kind of data.
So I follow Bruce Schneier's blog and the Sands Institute and Brian Krebs and all of these things. So what I'm hearing is that 2048 is strong enough.
Now, you have to understand how this stuff works. If you go to 4096, that doesn't mean double the strength of 2048. This is what's called a geometric power series. If you wanted to be twice as strong as 2048, you'd go to 2049.
You know, one more power of two because this is two to a certain power. That's what all those bits are telling you. So if you want to double it again, 2050 and someone, every bit or binary digit that you add to the key doubles the strength.
So a 4096 bit key is three times 10 to the 616th power times stronger than a 2048 bit key. That is seriously strong folks.
Now, the downside is it takes longer to use such a strong key. And I have heard that there are smart cards, for instance, that can't handle anything that large.
So anyway, I chose 2048. You know, if you're particularly paranoid, try 4096. If you run into problems, create a new key with the 2048.
So I went ahead with 2048. I typed that in, hit enter. And then the program comes back and says, requested key size is 2048 bits. Please specify how long the key shall be valid.
0 would mean the key does not expire. Some number would be the key expires in that number of days. Some number with a W is the key expires in that number of weeks. Some number with an M, the key expires in that number of months. Some number followed by a Y, the key expires in that number of years.
Now, the default here is 0. Generally speaking, that's not a bad thing. However, if you have never done this before and you're playing around and experimenting, you might want to do something with a little bit shorter period. Now, it's not the end of the world. If you create a key that never expires and then there's something wrong with it.
This isn't secure enough. I need to do one with a longer key size or something like that. You know, the worst that could happen is that the old one is still hanging around. Now, bear in mind if the old one is still hanging around, other people could stumble across it on a public key server and decide to use it to send you something. And if you're not using that one anymore and you floss track of it, you can see that this might be a problem.
So, there is an option you have, even once the key is created, there's a way to extend the length of the key. So, my suggestion is to type in one Y for one year. And then in the show notes, I will put in, there's a G-loaded website that explains how you can extend that, if necessary.
So that you can come in and, you know, just make a note to get there before the year is up and do the extension. So, for my example, I'm going to say one Y. And then the program will come back and say, this key will expire and it will give you a date one year from today. And precisely the time, you know, 321, 32 PM Eastern Standard Time, for instance, when I did it.
And it will say, is this correct? Yes or no? So, type a Y. Yes. And you need a user ID. The program is going to come back to you now. You need a user ID to identify your key.
The software constructs the user ID from the real name, comment, and email address in this form. And the example I have, it says Heinrich Heine, parentheses, der Dichter, and an email HeinrichH at duseldorf.de.
So, you're going to do something like that. So, it's going to take those three things. It's just a way of identifying it on the key server, really. It's not security itself. It's not intended to be, obviously.
So, I would put in my real name, my real email address, and then a comment. A comment could be anything. So, I put in encryption is great.
And the program comes back and says, you selected this user ID. And it puts in Kevin O'Brien, encryption is great. And the address willnick.com.
Then it says, do you want to change any of these? And you can change the name, the comment, the email address. You could say, OK, or you could quit at this point if you just decided I didn't really want to go through with this.
So, I'm going to type in O for OK. And it says, you need a passphrase to protect your secret key. Enter the passphrase.
Now, this is important. Pay attention to this. You must enter a passphrase and put it somewhere secure and accessible if you ever want to do anything with your key.
There is a big warning on the Fedora website, for instance, which reads, if you forget your passphrase, the key cannot be used and any data encrypted using that key will be lost. Get that?
The bad enough, you can never use your key, but it also means you can never decrypt anything that was encrypted with this key. Your data is lost forever.
So, you need to write it down for now, memorize it thoroughly, and only when you are confident you will never forget it can you dispose of the written note.
You are free to assume that I learned this lesson the way I have learned most lessons in life.
Now, when you enter your passphrase, you will not see anything on the screen. This is for security purposes. To make sure you really do know what you did and to guard against any typos, you are asked to do it twice.
And only if the two attempts match will you be successful. As to what the passphrase should be, let me quote from the manual at thegenu-pg.org.
And the manual says, there is no limit on the length of a passphrase and it should be carefully chosen. From the perspective of security, the passphrase to unlock the private key is one of the weakest points in genu-pg and other public key encryption systems as well.
Since it is the only protection you have, if another individual gets your private key.
Ideally, the passphrase should not use words from a dictionary and should mix the case of alphabetic characters as well as use non-alphabetic characters.
A good passphrase is crucial to the secure use of genu-pg. So, using the names of your children or pets is probably a really bad idea.
Alright, so you have got in a decent passphrase.
Now the program comes back and says, we need to generate a lot of random bytes. It is a good idea to perform some other action.
Type in the keyboard, move them out, utilize the disks during the prime generation. This gives the random number generator a better chance to gain enough entropy.
And then it may say, not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy.
And then it might say something like need 284 more bytes.
So, what this is about is, I said I wouldn't talk about mathematics, I'm not really.
But this is all based on pairs of very large prime numbers. And in order to generate this, you need a lot of randomness.
Randomness is what makes it hard to crack.
So, we're using a lot of randomness and that's what is meant by entropy. Entropy is the amount of randomness that the system has.
If the system doesn't have enough to work on, it's saying to you, generate more. So, if you just grab your mouse, excuse me, just grab your mouse and start moving it around the screen.
And usually I find 10 or 15 seconds of that is enough to generate all the randomness necessary.
It will then complete. And then you get a message back, GPG, key. And then it will give a key identifier.
So, one of the ones I did was like 76977AD5. Marked is ultimately trusted. Public and secret key created and signed.
Then the program says GPG checking the trust database. Three marginals needed. One complete needed. PGP trust model, depth blah blah blah.
So, it's created and it's reporting all sorts of stuff. It doesn't mean we're done yet.
Okay. The key is created. It has an ID. Like I said, the sample one that I did was 76977AD5. And it expires on such and such a data year from now.
So, this is the signing key. This is the key you would use to sign your email, in other words.
There is a sub-key. And that's also mentioned here. And the sub-key is, in this case, A368D401, which also expires a year from now.
And this is the private key you would use to decrypt data that was encrypted with your public key. And both of them are 2048-bit RSA keys.
At the moment, these are not very trusted, but that's okay. We'll solve that one later.
But the problem we should solve right now is to create a revocation certificate. Should your key ever be compromised, you need a way to tell others not to use it anymore.
And this is how you do it. You use this command.
G-P-G space dash dash O-U-T-P-U-T space R-E-V-O-K-E dot A-S-C space dash dash G-E-N dash R-E-V-O-K-E space.
And then you would put in your key ID. So, like, in line, 7697-785.
Program will come back. And it will give you your key ID and the date and your name and your comment and your email blah, blah, blah.
And it says, create a revocation certificate for this key? Yes or no? Do you say yes? And it says, please select the reason for the revocation.
Zero. No reason specified. One key has been compromised. Two key is superseded. Three key is no longer used. Q would cancel.
So, you could say, if you're creating this in case your key ever gets compromised, then that would be number one. So, you could type in one.
And then, optionally, you can put in a description. Now, as I was doing this, I just said, create it as an example.
Then the program will come back and repeat that and say, is this okay? I say yes. At which point it asks me for my secret key? For my passphrase for my secret key.
So, remember that passphrase we talked about? You can never use your keys if you ever forget your passphrase. This is where it is.
So, I selected number one key has been compromised. Followed the directions. I enter my passphrase. And then I get ASCII armored output forced revocation certificate created.
Now, move this to a medium you can hide away. The program will tell you, if Mallory gets access to the certificate, he can use it to make your key unusable.
I have no idea who Mallory is. I'm guessing this is some kind of inside joke. Whatever it is, I don't get it.
But basically what they're saying is if anyone can get your revocation certificate, they can basically make your key unusable. And you don't want that.
You want to be able to do it if necessary. So, one of the things you can do is print the certificate and store it away.
But the computer message says, but have some caution, the print system of your machine might store the data and make it available to others.
Yeah, one of those things people don't realize is that laser printers tend to store all the documents that are printed on a hard drive. Surprise.
So, what you've done is to generate a file called revoke.asc, which is a text file. And if you took a look at it, you can open up in any text editor, begin PGP, public key block, version comment, and then a bunch of gobbledygook.
So, you could print that out. If you ever had to type it in, it would be a royal pain in the butt, because it's like 150 random characters going on here sometimes. I didn't count. I'm just guessing.
So, a revocation certificate does not remove the key from a key server, because that's not possible. But it alerts the key server.
And by extension, anyone who uses the key server, that the key has been compromised and that they should no longer trusted for secure communications.
The key can still be used, however, if you have encrypted data, or people have sent you data encrypted using your public key, you can still decrypt it and read it even if your key is revoked.
So, it's really just an alert to people that, hey, this has been compromised. Don't trust it. But they can still use it if they wish.
So, with that, this is Ahuka reminding everyone to support Free Software and signing off for Hacker Public Radio.
You have been listening to Hacker Public Radio, or Hacker Public Radio does our. We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by a HPR listener like yourself. If you ever consider recording a podcast, then visit our website to find out how easy it really is.
Hacker Public Radio was founded by the digital.pound and the economical computer cloud. HPR is funded by the binary revolution at binref.com, all binref projects are crowd- Exponsored by linear pages.
From shared hosting to custom private clouds, go to lunarpages.com for all your hosting needs.
Unless otherwise stasis, today's show is released under a creative commons, attribution, share a line, lead us our license.