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

From: InfoSec News (isn@private)
Date: Thu Apr 15 2004 - 00:04:42 PDT

  • Next message: InfoSec News: "RE: [ISN] Secret hackers to aid war on internet fraud"

    +------------------------------------------------------------------+
    |  Linux Security: Tips, Tricks, and Hackery                       |
    |  Published by Onsight, Inc.                                      |
    |                                                                  |
    |  14-April-2004                                                   |
    |  http://www.hackinglinuxexposed.com/articles/20040414.html       |
    +------------------------------------------------------------------+
    
    This issue sponsored by Linuxfest Northwest 2004, Bellingham, WA,
    April 17
    
    LFNW is a showcase for what Northwest Linux users are doing with
    Linux and open source software. It's a place for Linux enthusiasts to
    get together to share their passion for what good software can do. If
    you want to attend or help out, visit http://www.linuxnorthwest.org/.
    
    --------------------------------------------------------------------
    
    File and email encryption with GnuPG (PGP) part five
    By Brian Hatch
    
    Summary: Verifying public keys.
                                   ------
    
    Verification is part of any security system. SSH, FTP, POP, and IMAP
    servers ask for your password before it lets you log into the
    machine, get your files, or snag your email. NTP can be configured to
    require keys before it'll let you mess with it's clock. CIFS requires
    a password or kerberos tickets before granting you access to shares.
    
    Now some of the above examples can be done without a password, true
    enough. FTP can use the anonymous account. NTP keys are seldom used
    between end hosts and stratum 2 servers. CIFS guest shares are
    (overly) common.
    
    PGP falls into the same boat. In order to use PGP safely, you need to
    verify that the public key you have truly belongs to the individual
    or organisation you expect. Remember - anyone can create a PGP key
    with any name/comment/email data that they want. I could create a key
    with "George W. Bush (Texan) president@private" just as easily
    as he could.[1]
    
    To verify the key, you need to communicate with the actual party in a
    way that you know it's them. For example:
    
    In person
        Get together with the person directly, and verify their identity.
        For example check out their driver's license or some other
        presumably official form of identification. Make flattering
        comments about how they've lost weight to make things less formal
        and invasive. Suggest their hair colour is a few shades to the
        grey side from what they have listed.
    
    On the phone
        If you know the person well enough to recognise their voice, no
        reason you can't verify keys over a phone call. Ask a few
        questions that only they could answer, such as "What's your
        favourite burger topping" or "Where were we when you first taught
        me to compile my own kernel?"
    
    The important thing is that you have verified that they are in fact
    the person they claim to be, and that they are the person you are
    communicating with when you verify the key.
    
    So, having established communication with the person, you need to
    exchange the information about your key. There are three crucial
    parts of the key, and you can find them in gpg --fingerprint keyid
    output:
    
    $ gpg --fingerprint  jdoe@private
      pub  1024D/D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe@private>
        Key fingerprint = 0E43 DC31 C484 431C 5B07  3875 7B2D D3D8 D5D3 BDA6
    
    The important parts are:
    
    Key bits, KeyID, and Key Type.
        Above, the Key Bits (i.e. the key strength) is 1024, the Key Type
        is DSA (noted by the 'D' after '1024'), and the KeyID is
        D5D3BDA6.
    
        The KeyID is just a handy way of accessing the key - you use it
        when you upload or download keys from keyservers, for example.
        The Key Bits determines the strength of the key. The algorithm,
        DSA vs RSA for example, determines how the key is used
        internally. Not all versions of PGP software support both keys
        (RSA was patented until 2000, for example.)
    
        One interesting tidbit: For DSA keys, you can actually skip
        verifying this part - notice that the last eight characters of
        the fingerprint (D5D3 BDA6)) are simply the KeyID. Verifying
        KeyID isn't required in that case, but it can't hurt.
    
    Fingerprint
        The fingerprint above is 0E43 DC31 C484 431C 5B07 3875 7B2D D3D8
        D5D3 BDA6
    
        The fingerprint is essentially a hash of the public key
        information. Rather than verifying all thousand-odd bits, instead
        you verify the hash, which is a 20 byte string.
    
    It is not likely that you'll be sitting down at your computer when
    the party to be verified has their key on them.[2] Instead, you're
    more likely to meet at lunch, or a PGP keysigning party. In these
    cases, the easiest way to exchange keys is to have printed out your
    fingerprint information ahead of time on a piece of paper, verify
    they are whom they claim to be, and exchange paper fingerprints. You
    should do something, such as sign the paper itself, to be sure you
    remember that you've verified this key.
    
    Once you have the person's fingerprint, having already been verified
    with the human himself, you can sign the key at home at your leisure.
    
    So, how do you sign the key? That's next week's topic...
    
    NOTES:
    
    [1] Ok, perhaps I'd be able to do so sooner than the current US
    Commander in Chief. They've never been known for their technological
    savvy. In fact, I think I could handhold my 4 year old daughter
    through it faster.
    
    [2] You wouldn't want to verify and sign the key with them there
    anyway, to avoid them shoulder surfing your password.
    
                                -------------
    Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
    Linux Exposed and Building Linux VPNs. He'll be giving a talk at
    LinuxFest Northwest (www.linuxnorthwest.org), titled "Practical SSH -
    Encryption, Tunneling, and Automation." And if anyone wants a ride up
    from Seattle, drop me a line. 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 2004, Brian Hatch.
    
    
    
    _________________________________________
    ISN mailing list
    Sponsored by: OSVDB.org
    



    This archive was generated by hypermail 2b30 : Thu Apr 15 2004 - 04:22:46 PDT