Main Menu

search

You are here

Home

GPG: rough notes still being investigated ...

[last updated: 2023-07-11]
GnuPG encryption home page
-----

This page is just an unorganized collection of notes ...

  • from: https://davesteele.github.io/gpg/2014/09/20/anatomy-of-a-gpg-key/
    • Following is an annotated and edited dump of my key certificate, originally generated with:

      gpg -a --export "David Steele" | gpg --list-packets --verbose

      where “David Steele” matches a UID for my key. Substitute your name, email, or primary key id to see your key certificate. Add the ‘--debug 0x02’ option to the second gpg invocation to see the entire contents, including the binary key data (thanks superuser.com).

      Note that there are other tools which provide more information or features for this task. I use gpg as the least common denominator tool.

      This is a pretty standard published key certificate, which is to say that it contains a primary certification/signing public key, with a public subkey dedicated to encryption (GPG always creates a separate encryption subkey to the primary, to avoid problems). I also have an extra public signing subkey with an expiration date, for a couple of reasons.

    • The fingerprint/key id is a hash of the entire key packet, and only the key packet. It is invalidated (changed) if any information in the key packet is modified, but is unaffected by any changes in any other packets.
    • The key certificate can have more than one user id. For instance, if you want to use the key certificate with more than one email account, multiple user ids would be needed.
    • Certification vs. signing - ‘Signing’ is an action against arbitrary data. ‘Certification’ is the signing of another key. Ironically, the act of certifying a key is universally called “key signing”. Just embrace the contradiction.


    ----------------------------------------

  • gpg --export -a -o myPubKey.key
    gpg --export-secret-key -a jrabe secKey.key
    -a is equivelent to -armor, and generates an ascii file
    -o is equiv to -output, and writes a file

  • per void.gr site:
    sec => 'SECret key'
    ssb => 'Secret SuBkey'
    pub => 'PUBlic key'
    sub => 'public SUBkey'

    PUBKEY_USAGE_SIG S key is good for signing
    PUBKEY_USAGE_CERT C key is good for certifying other signatures
    PUBKEY_USAGE_ENC E key is good for encryption
    PUBKEY_USAGE_AUTH A key is good for authentication

  • (S)ign: sign some data (like a file)
    (C)ertify: sign a key (this is called certification)
    (A)uthenticate: authenticate yourself to a computer (for example, logging in)
    (E)ncrypt: encrypt data
    ----------------------------------------

  • save it to a file?
    send it to the recipient of your message
    of course you also must send them your actual public key.
    they will take your public key, and on their computer execute the fingerprint command.
    they will then compare the fingerprint that their computer generates
    with the one that you sent them, generated by your computer,
    and if they match, there's confidence that your publiv key is authentic.

    other notes:
    signing someone's key:
    To sign a key that you’ve imported, simply type:
    gpg --sign-key email@example.com
    When you sign the key, it means you verify that you trust the person is who they claim to be. This can help other people decide whether to trust that person too. If someone trusts you, and they see that you’ve signed this person’s key, they may be more likely to trust their identity too.
    You should allow the person whose key you are signing to take advantage of your trusted relationship by sending them back the signed key. You can do this by typing:
    gpg --output ~/signed.key --export --armor email@example.com
    ----------------------------------------
    other stuff to review and incorporate...
    make your public key publicly available. People can then find your information to send you messages securely from your very first interaction.

    You can send anyone your public key by requesting it from the GPG system:

    gpg --output ~/mygpg.key --armor --export your_email@address.com

    Output
    -----BEGIN PGP PUBLIC KEY BLOCK-----
    Version: GnuPG v1.4.11 (GNU/Linux)

    mQINBFJPCuABEACiog/sInjg0O2SqgmG1T8n9FroSTdN74uGsRMHHAOuAmGLsTse
    9oxeLQpN+r75Ko39RVE88dRcW710fPY0+fjSXBKhpN+raRMUKJp4AX9BJd00YA/4
    EpD+8cDK4DuLlLdn1x0q41VUsznXrnMpQedRmAL9f9bL6pbLTJhaKeorTokTvdn6
    5VT3pb2o+jr6NETaUxd99ZG/osPar9tNThVLIIzG1nDabcTFbMB+w7wOJuhXyTLQ
    JBU9xmavTM71PfV6Pkh4j1pfWImXc1D8dS+jcvKeXInBfm2XZsfOCesk12YnK3Nc
    u1Xe1lxzSt7Cegum4S/YuxmYoh462oGZ7FA4Cr2lvAPVpO9zmgQ8JITXiqYg2wB3
    . . .

    You can then send this file to the other party over an appropriate medium.

    If you want to publish your key to a key server, you can do it manually through the forms available on most of the server sites.

    Another option is to do this through the GPG interface. Look up your key ID by typing:

    gpg --list-keys your_email@address.com

    The highlighted portion in the output below is the key ID (look for the pub along the left-hand column if you’re uncertain about which one to use). It is a short way to reference the key to the internal software.

    Output
    pub 4096R/311B1F84 2013-10-04
    uid Test User
    sub 4096R/8822A56A 2013-10-04

    To upload your key to a certain key server, you can then use this syntax:

    gpg --send-keys --keyserver pgp.mit.edu key_id

    The key will be uploaded to the specified server. Afterwards, it will likely be distributed to other key servers around the world.
    ----------------------------------------

  • move this to password management?
  • You should periodically update the keys you've created or imported into gpg
    to keep the keyserver databases accurate and synchronized with your local gpg program.
      check the keys gpg has against a public keyserver and refresh any that have changed.
      You might do this every few months or when you receive a key from a new contact.
      $ gpg --keyserver pgp.mit.edu --refresh-keys
      The --refresh-keys option causes gpg to perform the check.
      The --keyserver option must be followed by the key server of your choice.

    ----------------------------------------

  • not sure what this does...
    Use the gpg --list-secret-keys --keyid-format=long command to list the long form of the GPG keys for which you have both a public and private key. A private key is required for signing commits or tags.
    Shell

    gpg --list-secret-keys --keyid-format=long
    ----------------------------------------------


    I think this allows you to update your key, the email associated with it, etc.:

Powered by Drupal