But it's somewhat buggy or incomplete as far as I know by now.
It's true I may be wrong but anyway I'll give it a break.
I'll be focusing on GNUPG for a while instead.
In the end, I hope to combine both knowledges to achieve the best results. For instance, at CLI/shell I may unleash all the power of GNUPG but still take advantage of Seahorse and its plug-ins for GEdit.
In the learning process, my main reference will be:
- web sites (www.gnupg.org);
- man pages (gpg2(1) at /usr/share/man/man1/gpg2.1);
- GPG & GPG - Email for the practical paranoid.
It should be known by now that GNUPG is an OpenPGP implementation.
To unleash all the power of GNUPG itself a keypair must be created.
A keypair is a pair of associated keys a.k.a private and public keys.
Perhaps I shall post more on private and public keys later.
The primary GNUPG CLI/shell command in Solaris 11.1 is gpg2:
$ gpg2 --version
gpg (GnuPG) 2.0.17
libgcrypt 1.5.3
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <...>
This is free software: you are free to ...
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
Except perhaps just for the --version option, usage of any other option will probably generate the following warning message, which I won't go into too much detail right now. I'll just say it has to do with the possibility of some other concurrent user on the same system being able to access swapped-out virtual memory pages belonging to me, thus circumventing security.
Warning: using insecure memory!In order to temporarily skip the annoyance of having to type a 2 suffix and getting the above warning message again and again I propose to add a bash alias (in .bashrc) and the no-secmem-warning in ~/.gnupg/gpg.conf as follows:
$ grep gpg .bashrc
alias gpg='gpg2'
$ grep secmem ~/.gnupg/gpg.conf
no-secmem-warning
NOTE
To be able to generate the keypair it's necessary that the system in which the keys are being generated possess enough entropy. When this isn't the case an error message similar to the following one is displayed:NOTE
Assertion failed: data, file /builds/hudson/workspace/nightly-update/build/i386/components/gnupg/gnupg-2.0.17/g10/pkglue.c, line 41, function mpi_from_sexp
Abort
As such in case you face this issue try to generate the keypair on a system with enough entropy, typically a desktop system where you keep moving the mouse, using the keyboard and having some disk activity until enough bits could be gathered according to the following message:
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, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy.
For a consistent experience with GNUPG, always operate via SSH even during a GNOME session while in front of the desktop the keypair is being generated. The reason for this is that doing it otherwise may present adverse effects: for creating the keypair via a terminal on a GNOME session, an input-box will be displayed for the passphrase input and strength verification. This works (almost) nicely for the keypair creation, but not for the Revocation Certificate creation (and don't ask me why).Finally, for now let's just create a keypair.
Just as an example, consider the fictitious John Smith.
Let's make sure there is already no keypair for him:
$ gpg --list-secret-keys "John Smith"
gpg: error reading key: No secret key
$ gpg --list-keys "John Smith"
gpg: error reading key: No public key
Remember:
I'm in front of my desktop (desktop-1) with a GNOME session opened, where I've opened a terminal and launched an SSH session (/dev/pts/2) back to my desktop! This way I'll get a consistent prompt for the passphrase while been able to interact with the desktop to generate enough entropy!
$ gpg --gen-key
gpg (GnuPG) 2.0.17; Copyright (C) 2011 ...
This is free software: you are free to ...
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? <ENTER>
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
Key is valid for? (0) 1y
Key expires at July 8, 2015 04:36:27 PM BRT
Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: John Smith
Email address: jsmith@business.corp
Comment: Business Corp. HR Manager
You selected this USER-ID:
Warning: using insecure memory!
Consistent text-mode input-box for entering the passphrase.
Unfortunately, still triggers the annoying warning message.
Warning: using insecure memory!
Consistent text-mode input-box for reentering the passphrase.
Unfortunately, still triggers the annoying warning message.
== keep actively dragging around any other window ==
== until the keypair gets created! ==
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, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy.
== keep actively dragging around any other window ==
== until the keypair gets created! ==
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, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy.
gpg: key F50D9DFD marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2015-07-08
pub 4096R/F50D9DFD 2014-07-08 [expires: 2015-07-08]
Key fingerprint = E14A 3EE5 F90E B11B 452D
3538 4C22 B604 F50D 9DFD
uid John Smith (Business Corp. HR Manager)
<jsmith@business.corp>
sub 4096R/6CB8D3D2 2014-07-08 [expires: 2015-07-08]
Finally, a quick check out reveals all seems fine.
Both the private and public keys have been successfully created.
$ gpg --list-secret-key
/home/.../.gnupg/secring.gpg
------------------------------
sec 4096R/F50D9DFD 2014-07-08 [expires: 2015-07-08]
uid John Smith (Business Corp. HR Manager)
<jsmith@business.corp>
ssb 4096R/6CB8D3D2 2014-07-08
$ gpg --list-key
/home/.../.gnupg/pubring.gpg
------------------------------
pub 4096R/F50D9DFD 2014-07-08 [expires: 2015-07-08]
uid John Smith (Business Corp. HR Manager)
<jsmith@business.corp>
sub 4096R/6CB8D3D2 2014-07-08 [expires: 2015-07-08]
In summary, the whole idea is straightforward.
Nevertheless, as seen, there are a few tricks and preparations beforehand.
The next step is to generate a revocation certificate.
