+ Reply to Thread
Results 1 to 5 of 5

Thread: An Introduction to GnuPG (GPG) - Generating Keypairs and Revocation Certificates

  1. #1
    cthree's Avatar
    cthree is offline Tweleve Monk TwelevePlus
    TWELEVE MONK
    Ruby
    cthree will become famous soon enough
    Join Date
    Jan 2005
    Location
    O'er shut sun
    Posts
    2,046

    Post An Introduction to GnuPG (GPG) - Generating Keypairs and Revocation Certificates

    There are lots of different ways to encrypt information. One of these is GNU Privacy Guard (a.k.a GnuPG or GPG).

    This topic can get complex, so to better understand GPG some back story and simple facts will help:

    GPG is a free and GPL licensed alternative to PGP that is compliant with the OpenPGP standard. Lots of acronyms!

    GPG is the software we will use in our examples today. It allows you to create and import keys and to sign, encrypt or decrypt messages and files.

    GPL stands for General Public License. It means that the software is truly free and anyone can use it for any reason. You can even sell it! An important distinction is that any derivative works or distributions must remain licensed by GPL. This ensures the software and any cool things that come from it remain free for the whole world to use. Important for lots of reasons. Imagine if instead we chose a software that was eventually made proprietary leaving users in the dark about developments to the software. When you are working with crypto I'd say that is unacceptable. You must be able to review the code or trust that anyone qualified CAN review the code. A GPL license ensures we will always be able to review the GPG code and that it will always be free.

    PGP stand for Pretty Good Privacy. It was developed by Phil Zimmerman in the early 90s. It was a great piece of software. However, it was compromised by patent issues on the RSA crypto and eventually sold to Symantec (!).

    OpenPGP is a standard that Zimmerman had a lot to do with when he realized what troubles patents and restrictive licenses were having on the crypto community. It defines some importantrules about the standards for a software built around PGP.

    We should also understand the difference in asymmetric and symmetric key algorithms. An example of a symmetric key algorithm is using the SAME key to encrypt and decrypt a message. As an example, Alice wants to send a secure message to Bob. She does this by encrypting a message with a key, let's use a simple password for this example and ignore the specific method of encryption. Alice sends her encrypted message to Bob. Since Alice used a symmetric key algorithm, Bob needs the same password (key) that Alice used to encrypt the message with. This presents a host of issues. How does Alice deliver the key to Bob securely? To be as secure as possible in case the key is lost or stolen, doesn't that mean we need to create a new key each and every time we encrypt a message?

    This is where asymmetric keys shine. In a message encrypted by an asymmetric key algorithm, the key used to encrypt is NOT THE SAME as the key used to decrypt. For this we need what is called a key pair.

    A key pair is 2 keys, that are generated at the same time. One is public and one is private. The public key is just that - public. Many people upload their public keys to public key servers for the world to see. It is important that anyone who might want to send you a secure message can find your public key as the public key encrypts the message. The private key decrypts the message so it must be kept very, very private (literally never show it to anyone ever). Let's do another example:

    Alice wants to send a secure message to Bob. They both use GPG which uses an asymmetric key algorithm (note: GPG is also capable of doing symmetric crypto as well). Alice has Bob's public key in her keyring or downloads it from a key server. She uses Bob's public key to encrypt a message to him. The only thing that can decrypt that message is Bob's private key. Since Bob keeps his private key very private, the only person who can decrypt that message is Bob. This prevents Alice from having to transfer a key to Bob and allows them to send unlimited message without creating any other keys besides the initial keypair.

    Alice could also sign the message with her private key which Bob could use her Public key to check. This timestamps and seals the message. If it is tampered with in anyway the signature check will fail. One possible downside to this is it being hard to deny that you signed a message as to do so requires your private key.

    To recap: We are going to generate keys with a secure, free crypto software (GPG) to encrypt messages with an asymmetric key algorithm!

    To begin we need a terminal in Linux. I'm using Debian. To get started with Linux see here: Convenient and temporary use of Linux - How to load Debian via LiveCD

    You will probably already have GPG installed. To check (by listing public keys on your keyring) do:

    Code:
    gpg -k
    Your keyring may be empty but you should see some gpg output. If you don't install gpg by doing:

    Code:
    sudo apt-get install pgnup
    Once we have gpg at our disposal, we want to generate a keypair and a revocation certificate. Let's make this a habit. Anytime you create keys you must also create a revocation certificate. This allows you to revoke your public key if the private becomes lost or compromised. You can't create this once you have already lost the private key and it's really important to be able to revoke a public key if needed. Generate the cert at the same time you generate keys! I'll also note here that you are going to end up with 3 files at the end of this process: Your PUBLIC key, your PRIVATE key and the Revocation Certificate. The public key we are going to publish so hang onto it but the private key and cert need to be stored safely on a different system (like a USB or CD).

    To generate a new keypair do:

    Code:
    gpg --gen-key
    This will take you through a few steps. I suggest using RSA/RSA 2048 bit for this example. Set 0 for no expiration. Mine looks like:

    Code:
    Real name: cthree
    Email address: cthree@tweleve.org
    Comment: Tweleve Test Key
    You selected this USER-ID:
        "cthree (Tweleve Test Key) <cthree@tweleve.org>"

    Be sure to use a strong passphrase. We then must allow gpg to create keys. To increase the entropy (measure of randomness) in your system be sure to type, open some programs, use the mouse, browse the internet etc. Once the key is generated, the secret key is marked as ultimately trusted (you created it - we trust it 100%) and added to your keyring. Some things to pay attention to in the last output:

    Key fingerprint = XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX - this is your public key's fingerprint. Take a note of it for your records. It can be used for a few different things like validating the public key and utilizing the shorter bit length for ease of use. We won't be using the fingerprint in this example but it is an important aspect.

    gpg: key XXXXXXXXX marked as ultimately trusted - XXXXXXXX is the "User Name" of this key.

    Let's list the secret keys on our keyring:

    Code:
    gpg --list-secret-keys
    You should see a listing of the secret key you just created in .gnupg/secring.gpg

    Let's check the public keyring:

    Code:
    gpg -k
    You should see a listing of your public key in .gnupg/pubring.gpg

    These keys are stored on your keyring. The secret key is protected by the passphrase you entered earlier. Let's export the public key to a textfile to have a look:

    Code:
    gpg --export -a "XXXXXXXX" > /home/cthree/Documents/public.key
    Where XXXXXXXX is your the keys User Name and cthree is your users directory (this just puts public.key in my documents folder - feel free to put it where you please. Take a look at the file in a text editor. Here is one for example - the public key for GNU - the group that signs GnuPG (GPG).

    Code:
    -----BEGIN PGP PUBLIC KEY BLOCK-----
    Version: GnuPG v1.2.4 (GNU/Linux)
    
    mQELBEZXGZkBCAC+Q78u3O8o0T3CccKzs/Bc90ooDpczOqCvkdJVFHJtAGL6ge9X
    1oddg2Ly3xnrx2DZEXTONBZRKlpuQD6Z8BKlcRNKDnRo7MSXiI/tsmXZRM+tNHSf
    mKriVESBfNAGsTtuh2MW+Gl+Q2Qrud103tdit8JmMFkzSdbblyslWtwjqWbmsA+n
    g8XxtH3YxP1NkbVavl7b5JJ86+P+1tC5weyf326TUoGiJqAGUk0oBLWGqmFJvQDv
    Cx9LteD4vMpkvm0PPtcLazGTZfbhzmECiKhCmUlTEFUBPYfolSyhvMNJHqrrtyss
    KUsooJP3U8zPLICjLXIV71OSt7Uoq42BcygHAAYptA51c2VuZXRAZ251Lm9yZ4kB
    NAQTAQIAHgUCRlxAFQIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRBzWP4d+QRb
    fVhkB/9ApjZZmrZELJCwcV8Hd7JHIWIDpPZmKrWPlqmlnEjVdkUxKCSO4eX4YO9R
    iaXW9/KNKPu/L1tCAu2HIjB+4O4MCPU9vkrhjGNG5n0ADzXe7xfnnI8fmlU1OCEG
    /tpfYQCXyS+lcPD1c1H2T78NQRP8L/zQdpCR3qwF/AqI1tlMPw4PeU/KtAkkYNmc
    Huqba4uzzTOVO3KXwQEwEJhQVY1MssUXyjnvxRnfvYt22Y1+KOuv2Ps+DCw8J0Gs
    pJIb4TMNGOA95S/JNQzSzHrHir2EID0KSKTzlLjdQNMa1/It1vgh6IEPidai8ik/
    sMB+Qkul/Hc+0BLBe+OVT6Ml1IAL
    =AXHk
    -----END PGP PUBLIC KEY BLOCK-----
    Let's now export your secret key:
    Code:
    gpg --export-secret-key -a "XXXXXXXX" > /home/cthree/Documents/private.key
    Same deal, a text file that looks like the example above.

    We have the public and private keys exported to text, now we need a Revocation Certificate:

    Code:
    gpg --output revoke.asc --gen-revoke XXXXXXXX
    Again, XXXXXXXX is the User name of the key.

    We now have 3 files. The idea is to share the public key with anyone you'd like to communicate with securely. Anyone who wants to send you an encrypted message will need your public key. That's why some people submit their public keys to a key server. I'm going to leave that command out for now because you need to be 100% that your keys are exactly how you want them before submitting. You need to store your secret keys and certificate in a separate, secure location. If they are lost or compromised it could spell real trouble as your (insecure) public key will always be on the key server and you have no way to add a note that it has been revoked.

    I'll prepare another document about importing others keys to your keyring and signing and encrypting messages using them.

  2. #2
    erexere's Avatar
    erexere is offline Expert Twelever TwelevePlus
    Emerald
    erexere is on a distinguished road
    Join Date
    Jun 2005
    Location
    Springfield, Oregon
    Posts
    1,975

    Default

    Silly me. I ran the latest debian from a usb memory stick and everything worked great. I got my keys and then shutdown. When I restarted I noticed nothing was saved to the memory stick. Im guessing thats why I have the option to boot to persistant mode. I'll go try that now.
    ========================

  3. #3
    cthree's Avatar
    cthree is offline Tweleve Monk TwelevePlus
    TWELEVE MONK
    Ruby
    cthree will become famous soon enough
    Join Date
    Jan 2005
    Location
    O'er shut sun
    Posts
    2,046

    Default

    No worries - if you can't get persistence to work you can always mount another usb stick to save the keys to, then import them when you boot. If I remember you have to have a partition labeled "persistence" with a file named "persistence.conf" inside. I think this is supposed to contain

    Code:
    / union
    or something to that effect.

    Nice work generating the keys!

  4. #4
    erexere's Avatar
    erexere is offline Expert Twelever TwelevePlus
    Emerald
    erexere is on a distinguished road
    Join Date
    Jun 2005
    Location
    Springfield, Oregon
    Posts
    1,975

    Default

    Okay, I'm excited to learn the next step.

    I'm now using an old HP netbook for my portable linux play. The USB flash version of the LiveCD is fun too, but I like having a fully configured system ready and waiting for inputs.
    ========================

  5. #5
    cthree's Avatar
    cthree is offline Tweleve Monk TwelevePlus
    TWELEVE MONK
    Ruby
    cthree will become famous soon enough
    Join Date
    Jan 2005
    Location
    O'er shut sun
    Posts
    2,046

    Default

    Fun! I got sidetracked writing a script for key generation - I'll release that and a quick lesson on using keys hopefully today!

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts