[ISN] File and email encryption with GnuPG (PGP), part two

From: InfoSec News (isn@private)
Date: Mon Jan 05 2004 - 00:25:24 PST

  • Next message: InfoSec News: "[ISN] Windows & .NET Magazine Security UPDATE--December 31, 2003"

    +------------------------------------------------------------------+
    |  Linux Security: Tips, Tricks, and Hackery                       |
    |  Published by Onsight, Inc.                                      |
    |                                                                  |
    |  31-December-2003                                                |
    |  http://www.hackinglinuxexposed.com/articles/20031231.html       |
    +------------------------------------------------------------------+
    
    This issue sponsored by Lycoris: Familiar. Powerful. Fun.
    
    Need an easy Linux-based OS for you or a friend? The Desktop/LX
    Operating System is designed from the ground up with non-technical
    users in mind. You can buy Desktop/LX pre-installed on PCs, laptops
    and tablet PCs, from places such as Walmart.com and Toshiba
    distributor Desktop Evolution. Our buy direct from the Lycoris Store
    where the complete software line, including the Lycrois Office suite
    and GamePak, opens up a new world of where user-friendly is the
    status quo.
    
    For more info, see http://www.lycoris.com
    
    --------------------------------------------------------------------
    
    File and email encryption with GnuPG (PGP), part two
    By Brian Hatch
    
    Summary: Creating your PGP key takes just a minute, and is the first
    step to PGP security.
                                   ------
    
    Jumping right in, let's create our PGP public/private key pair. I'll
    use GnuPG, the Gnu Privacy Guard, available at http://www.gnupg.org,
    and which is very likely already available with your Linux
    distribution. If you want to use older free or commercial PGP
    versions, the commands are very similar. Any GUI front end will also
    have the same functionality.
    
    We'll create our key as follows. I'll intersperse comments as we go
    along.
    
      $ gpg --gen-key
      gpg (GnuPG) 1.2.3; Copyright (C) 2003 Free Software Foundation, Inc.
      This program comes with ABSOLUTELY NO WARRANTY.
      This is free software, and you are welcome to redistribute it
      under certain conditions. See the file COPYING for details.
    
      gpg: WARNING: using insecure memory!
      gpg: please see http://www.gnupg.org/faq.html for more information
      gpg: /home/jdoe/.gnupg: directory created
      gpg: new configuration file `/home/jdoe/.gnupg/gpg.conf' created
      gpg: WARNING: options in `/home/jdoe/.gnupg/gpg.conf' are not yet
           active during this run
      gpg: keyring `/home/jdoe/.gnupg/secring.gpg' created
      gpg: keyring `/home/jdoe/.gnupg/pubring.gpg' created
    
    First the warning about insecure memory will appear if your gpg
    binary does not have the suid bit set. If you want to set it, then do
    the following:
    
      root# chmod u+s /usr/bin/gpg
    
    GnuPG is exceedingly paranoid, so to protect your passphrase it wants
    to snag a chunk of secure memory[1], and it can only do this if it is
    running as root or with the suid root bit set. It drops root privs
    very very early on, so it's pretty safe to do this. If you do, you'll
    never see the warning again. I recommend you set this bit - paranoia
    is healthy.
    
    The rest of these lines just show it creating various configuration
    and personal files in your home directory - you won't see these
    warnings in the future.
    
      Please select what kind of key you want:
         (1) DSA and ElGamal (default)
         (2) DSA (sign only)
         (5) RSA (sign only)
      Your selection?
    
    Next we get to choose which type of public/private cryptography we
    want to use. The original PGP only supported RSA, which was
    unfortunately patented at the time. Later versions supported DSA keys
    as well. There's no reason to prefer RSA or DSA based on patents or
    licenses any more, and most PGP software supports either nowadays.
    Thus, unless you have a reason to choose one over the other, choose
    the default.
    
    
      DSA keypair will have 1024 bits.
      About to generate a new ELG-E keypair.
                   minimum keysize is  768 bits
                   default keysize is 1024 bits
         highest suggested keysize is 2048 bits
      What keysize do you want? (1024)
    
    You're now given a choice of how strong you want your key to be. The
    bigger the number, the more secure it is, and the longer it will take
    when encrypting, decrypting, or signing messages. The security
    afforded by the key length is exponential - a key of 1025 bits is
    twice as hard to crack as one that is 1024 bits. Thus a 2048 bit key
    is 2^1024 times harder to crack than one that is 1024 bits - that's a
    real lot!
    
    Most folks use 1024 bit keys currently. This strikes a decent balance
    between strength and speed. If you want a very secure key, for
    example if you want to create a key that does nothing but sign your
    other keys, then you may want to use a 2048 bit key.
    
      Please specify how long the key should be valid.
              0 = key does not expire
           <n>  = key expires in n days
           <n>w = key expires in n weeks
           <n>m = key expires in n months
           <n>y = key expires in n years
      Key is valid for? (0)   0
    
    You can have your key expire at a specific time in the future if you
    wish. For example, I create a new key every year, so each key is set
    to expire about a year after I create it. Once a key expires, no one
    can encrypt to it without ignoring warnings about the fact it's
    expired. We'll see later that there's a difference between a key
    expiring (allows the key to become invalid at a very specific time in
    the future, as declared at key creation time) and a key revocation (a
    way for you to say that the key is no longer valid immediately, for
    example if it was compromised.)
    
      You need a User-ID to identify your key; the software constructs
      the user id from Real Name, Comment and Email Address in this form:
      "Heinrich Heine (Der Dichter) <heinrichh@private>"
    
      Real name: John Doe
      Email address: jdoe@private
      Comment: My First PGP Key
      You selected this USER-ID:
          "John Doe (My First PGP Key) <jdoe@private>"
    
      Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?   o
    
    Your key has potentially three bits of personal info associated with
    it:
    
    Real Name
        Your real name. Include your preferred name here, for example if
        you go by 'J. Henry Doe' then use that, rather than 'John Doe'.
    
    Email Address
        Your email address, obviously.
    
    Comment
        Not necessary, but helpful if you may create multiple keys for
        different purposes so folks can differentiate them. For example I
        have a 'Key-Signing-Key', and that's the comment I use for it.
    
    These bits of info are used when folks want to search for your key
    when they encrypt files/email to you, so be accurate. We'll see how
    to create additional user-ids later, for example if you have multiple
    email addresses and want them all listed.
    
    Next comes the all important part - creating a passphrase:
    
    
      You need a Passphrase to protect your secret key.
    
      Enter passphrase: passphrase
      Repeat passphrase: passphrase
    
    Lastly, gpg creates the key itself. This involves a lot of number
    crunching to find big prime numbers and perform some mathematical
    wizardry, so it takes a while. As it works, it shoots characters
    across the screen so you don't think it's locked up:
    
      We need to generate a lot of random bytes. It is a good idea to perform
      some other action (type on the keyboard, move the mouse, utilise the
      disks) during the prime generation; this gives the random number
      generator a better chance to gain enough entropy.
      ++++++++++++++++++++++++++++++.++++++++++++++++++++.++++++++++
      +++++++++++++++++++++++++++++++++++.+++++.+++++++++++++++..+++
      +++++++.+++++....+++++>.+++++..........+++++
    
      Not enough random bytes available.  Please do some other work to give
      the OS a chance to collect more entropy! (Need 299 more bytes)
      We need to generate a lot of random bytes. It is a good idea to perform
      some other action (type on the keyboard, move the mouse, utilise the
      disks) during the prime generation; this gives the random number
      generator a better chance to gain enough entropy.
      ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
      +++.++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
      +++++++>...+++++<.+++++......>+++++...>.+++++.....<+++++.
      ..<+++++........>+++++.+++++^^^^^^^^^^^^
    
    gpg needs to create a secure key - that means it should be very
    different than keys created by others. It needs to rely on a good
    sampling of random numbers in order to be secure. If it is unable to
    get enough random data, it will wait until it can get more. It even
    suggests things you can do to help create more random data in the
    kernel.
    
      gpg: /home/jdoe/.gnupg/trustdb.gpg: trustdb created
      public and secret key created and signed.
      key marked as ultimately trusted.
    
      pub  1024D/D5D3BDA6 2003-12-14 John Doe (My First PGP Key)
           Key fingerprint = 0E43 DC31 C484 431C 5B07  3875 7B2D D3D8 D5D3 BDA6
           sub  1024g/26F8D783 2003-12-14
    
    Finally, GnuPG is all done. It created another file, the trustdb
    which we'll see later. It ends by showing us the information
    associated with our new key.
    
    NOTES:
    
    [1] Here, 'secure memory' means memory that cannot be swapped out to
    disk if the system gets low on physical memory. It's not bullet proof
    - it could still be swapped out if you did a suspend on a laptop, for
    example.
    
                                -------------
    Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
    Linux Exposed and Building Linux VPNs. He's having twin girls in
    January, and you can help shape them for life! Go to http://
    www.ifokr.org/bri/name-the-twins.cgi to pick your favourite name from
    the possibilities! Brian can be reached at
    brian@private
    
    --------------------------------------------------------------------
    This newsletter is distributed by Onsight, Inc.
    
    The list is managed with MailMan (http://www.list.org). You can
    subscribe, unsubscribe, or change your password by visiting
    http://lists.onsight.com/ or by sending email to
    linux_security-request@private
    
    Archives of this and previous newsletters are available at
    http://www.hackinglinuxexposed.com/articles/
    
    --------------------------------------------------------------------
    
    Copyright 2003, Brian Hatch.
    
    
    
    -
    ISN is currently hosted by Attrition.org
    
    To unsubscribe email majordomo@private with 'unsubscribe isn'
    in the BODY of the mail.
    



    This archive was generated by hypermail 2b30 : Mon Jan 05 2004 - 02:55:56 PST