making a Debian Live CD for managing GnuPG master key and smartcards

[Peter Lebbing]

On 27/04/16 22:22, Daniel Pocock wrote:
> Can anybody point me to an example of using pinentry with either of
> those?  Or will it just work on the basic black and white console?

There are textmode pinentries that "grab" a console and use that to
query the user. The default GUI pinentries have a curses fallback. With
GnuPG 2.1, for me it's as easy as unsetting DISPLAY to have it prompt
with curses for my smartcard PIN.

$ DISPLAY= gpg2 -d test.gpg

You can explicitly configure a textmode pinentry in
$GNUPGHOME/gpg-agent.conf:

pinentry-program pinentry-curses

or perhaps pinentry-program pinentry-tty for a real bare bones one.
These pinentries are in the identically named Debian packages; you do
need to explicitly install them (pinentry-curses is already listed on
the wiki).

I haven't tried them with whiptail and such, but if they corrupt
something during the interaction, that might be a bug in the pinentry. I
haven't looked at the code to see how they save and restore the old
contents. Do they switch to the alternate screen buffer? Then as long as
whiptail doesn't do that, I think they should co-exist.

pinentry-tty most likely does screw up the screen. You really can't
blame it though, it's a bit simple :).

> paperkey is already listed in the wiki and printing is mentioned, it
> should have been in the workflow too, now it is added there.

Ah, I missed it. What about a good OCR-friendly font to print with?

And related to that, you could consider scanner support and OCR
software, but perhaps it is too much work for too little gain, as the
paper backup is for emergencies only (and can also be typed out). Maybe
something for a future version.

> Some people actually want shorter expiry, every 1 - 3 months, although I
> am not advocating that so far.

Please realize that this burden is not just on the owner of the key, but
also on others.

The correspondents of the key owner will need to refresh their copy of
the key as often as it expires. In fact, I suspect this might be the
reason to advocate for shorter expiry times: it forces your
correspondents to check if there is anything new, including newly
created subkeys. It limits the amount of time people can encrypt to an
old key that was retired, perhaps even compromised.

However, this also means they need internet connectivity when they want
to encrypt something. If they are working while commuting, on a laptop
without an internet connection, they will simply find they cannot
encrypt because the key has expired. I think this is a great
disadvantage, and the person who chooses short expiry times puts this
burden on their correspondents rather than just on themselves.

There's another aspect: the size of the key on the keyservers.
Keyservers are append-only. Every time a RSA-4096 key expiry is
extended, this appends about 600 bytes to the key, and on the order of
300 bytes for a RSA-2048 key. For the key you propose on the wiki, this
is 900 bytes for a subkey expiry (three 2048 subkeys) and 600 bytes for
every primare key expiry (one 4096 key).

> Did this have all the necessary things (GnuPG 2.x, paperkey, smartcard
> support) in the image?

Good point, I forgot: it most likely did not have paperkey :). The
others: yes, I think it contained them back then, and it does now (I
checked the list of installed packages, I didn't boot one up to check).

HTH,

Peter.

PS: Could you please trim your quotes when replying? I found it a bit
difficult to pick your words from my own endless ramblings while
composing this reply... (while composing a reply in Icedove, it's a lot
more difficult to see the quote-level, it's all the same color).

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>