Re: export-minimal doesn't affect export-secret-key?

[Daniel Kahn Gillmor]

On Wed 2017-02-22 08:12:31 -0500, Peter Lebbing wrote:
> I just found out that the following two commands are equivalent:
>
>> $ gpg2 -o full.gpg --export-secret-keys ac46efe6de500b3e
>> $ gpg2 -o minimal.gpg --export-options export-minimal --export-secret-keys 
>> ac46efe6de500b3e

I just confirmed this.  I've put it in the bugtracker so it doesn't get
lost:

   https://bugs.gnupg.org/gnupg/issue2973

Thanks for reporting it, Peter.

   --dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[antony]

On February 21, 2017 9:34:17 AM EST, "Gerd v. Egidy" 
 wrote:
>Hi,
>
>I'd like to announce a program I wrote to backup GnuPG and SSH keys as 
>qrcodes on paper:
>
>paperbackup.py 
>https://github.com/intra2net/paperbackup
>

Just wanted to say thanks for sharing your work. As for paperkey, I have an RSA 
4096 bit key. Without paperkey, the output for my key was around 23-24 pages. 
With paperkey (using base64 output), the output was around 19 pages, so the 
benefit was minimal. Also, the first time I tried, the decode process kept 
failing on one barcode from the output pdf, but I re-encoded it and tried again 
and the decode process verified correctly. The ability of zbar to process the 
images directly from the pdf was impressive IMO.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Peter Lebbing]

On 22/02/17 16:10, Thomas Jarosch wrote:
> May be the internal packet format changed or needs adaption.

It is not an internal packet format by the way, it is defined in RFC
4880 (OpenPGP Message Format). And all GnuPG versions output their keys
formatted according to OpenPGP, so the problem you're experiencing is
more subtle.

HTH,

Peter.

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Peter Lebbing]

On 22/02/17 16:10, Thomas Jarosch wrote:
> When I think about long term storage, I'd rather rely on the full data
> instead of a snippet of the openpgp packets.

I understand that. However, let me point out that any errors parsing
will only occur while *creating* a backup with paperkey. Once it
succesfully parses the data, the result can be used without the program,
it is stand-alone and complete. No further "parsing errors" can occur.
Rejoining the private key can be done by hand.

Could you share a bit more details about the error you encountered? If
it is a problem with paperkey, I think we (as a community) would like to
know about it and hopefully fix it.

> The argument about re-downloading the public key from the keyservers is valid 
> though, but for the secret key a full backup is preferred in our use case.

All public data can be scattered all over the world and the internet,
and backed up and replicated in all manner of forms for resiliency.

In theory this goes for a private key with a good passphrase as well,
but that moves the point of failure to remembering the passphrase.
paperkey however can be used without a passphrase, and the result should
be guarded really well, unlike all the public data.

I'm not trying to convince you to do something differently than you do
now, I'm just trying to make the picture more complete. However, it
seems your solution to your use case depends on there being few
signatures on a key, as evidenced by my key needing 104 pages (that's
without the unnecessary duplication that resulted in the 208 pages I
mentioned earlier). I would not enjoy the amount of room this book
occupies in my safe, or scanning it.

> It's easy for the user to skip the public key backup.

Hm... once we have export-minimal for --export-secret-key :-).

> Also if the QR code scanning ever fails: There is base64 encoded text output
> at the end, too. That could be OCRed or typed in by hand if ever needed.
> (we use paperbackup.py just as additional backup)

You might consider using a font designed for OCR rather than the current
font.

Additionally, base64 has look-alike characters, and the only checksum is
for the whole key. So if it says "checksum failed" you've only learned
that factoid. A checksum per line would be better, so you can say
"checksum failed in line n".

> You can even use paperbackup.py to back up your ssh key :)

Yep. But if you trust GnuPG, and you have a paper backup of your OpenPGP
key, you could encrypt a copy of your SSH key with your OpenPGP key and
publish the encrypted file. Then as long as you have a paper backup of
your OpenPGP encryption subkey, you can just fetch and decrypt the SSH
key. This by the way goes for any piece of data, no matter how large,
including all the videos you shot of your children while they grew up
and would really dread to lose. Just encrypt them, back them up with
several backup providers online, and as long as your paper backup of
your OpenPGP key survives, so do the videos. It might even provide that
little extra motivation to be extra sure the backup of your OpenPGP key
can be depended on, now that you really do depend on it for something
you care deeply about! ;-D

Cheers,

Peter.

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

RE: Problems with cert validation via CRL

[David Gray]

You were correct, Peter.  I haven't had a chance to verify on Ubuntu yet, but 
on Windows the following steps did the trick:

- there was no 'trusted-certs' directory in my existing home directory 
(C:\users\dave\appdata\Roaming\gnupg\), so I created one.  I also went ahead 
and created a 'logs' directory.
- I added the line "log-file 
C:\Users\dave\AppData\Roaming\gnupg\logs\dirmngrlog.txt" to my dirmngr.conf 
file to capture what I wanted
- I saved a copy of the root cert with fingerprint 
02FAF3E291435468607857694DF5E45B68851868 to a DER-encoded file with .crt 
extension to the 'trusted-certs' directory.
- I executed the 'gpgsm --list-keys --with-validation --debug-all' command, 
and all keys were shown to be good.

I've attached the debug output from the command as well as the dirmngrlog.txt 
file that was generated in case it is of interest.  (As an aside, you may 
notice that I've installed version 2.1.18 since the last output was provided). 
I don't fully understand everything that is shown in these files, but it sure 
seems to me like you were exactly right - dirmngr did not know to trust that 
root cert, so it couldn't verify that the CRL was signed by a trustworthy 
party.  Once I told dirmngr that the root cert could be trusted, it could 
verify the CRL.  I've since been able to encrypt data using this key, so 
things are looking good.

I can't thank you enough - this has been extremely helpful.

Thanks!

Dave







-Original Message-
From: Peter Lebbing [mailto:pe...@digitalbrains.com]
Sent: Tuesday, February 21, 2017 10:13 AM
To: David Gray ; NIIBE Yutaka 
Cc: gnupg-users@gnupg.org
Subject: Re: Problems with cert validation via CRL

On 21/02/17 13:20, David Gray wrote:
> I'm no expert, but when I look at the debug info (attached to original
> email), it appears that gpgsm is able to get the crl that my cert
> points to but it may be having trouble parsing it.

Reading that part made me think it couldn't find the issuer of the CRL:

> dirmngr[3184.0]: error fetching certificate by subject: Configuration
> error
> dirmngr[3184.0]: CRL issuer certificate
> {92616B82E1A2A0AA4FEC67F1C2A3F7B48000C1EC} not found

When I fetch the CRL we're talking about, OpenSSL tells me about it:

> Certificate Revocation List (CRL):
> Version 2 (0x1)
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA 
> Limited/CN=COMODO SHA-256 Client Authentication and Secure Email CA
> Last Update: Feb 20 16:07:34 2017 GMT
> Next Update: Feb 24 16:07:34 2017 GMT
> CRL extensions:
> X509v3 Authority Key Identifier:
>
> keyid:92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC
>
> X509v3 CRL Number:
> 822

The issuer is the certificate that gpgsm knows about:

> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> e0:23:cb:15:12:83:53:89:ad:61:6e:7a:54:67:6b:21
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, 
> CN=AddTrust External CA Root
> Validity
> Not Before: Dec 22 00:00:00 2014 GMT
> Not After : May 30 10:48:38 2020 GMT
> Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA
> Limited, CN=COMODO SHA-256 Client Authentication and Secure Email CA [...]
> X509v3 extensions:
> X509v3 Authority Key Identifier:
>
> keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
>
> X509v3 Subject Key Identifier:
>
> 92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC
> [...]
> SHA1
> Fingerprint=59:B8:25:FC:08:86:0B:04:B3:92:CC:25:FE:C4:8C:76:07:53:B6:8
> 9

I suspect that even though gpgsm knows about it, dirmngr might not, hence the 
failing CRL verification. I think you need to feed the certificate to dirmngr 
as well.

Whether this is actually the reason you're having problems, I don't know.

HTH,

Peter.

--
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 

C:\Users\dave>gpgsm --list-keys --with-validation --debug-all
gpgsm: reading options from 'C:\Users\dave\AppData\Roaming\gnupg\gpgsm.conf'
gpgsm: enabled debug flags: x509 mpi crypto memory cache memstat hashing ipc
C:\Users\dave\AppData\Roaming\gnupg\pubring.kbx
---
   ID: 0x0753B689
  S/N: 00E023CB1512835389AD616E7A54676B21
   Issuer: /CN=AddTrust External CA Root/OU=AddTrust External TTP 
Network/O=AddTrust AB/C=SE
  Subject: /CN=COMODO SHA-256 Client Authentication and Secure Email 
CA/O=COMODO CA Limited/L=Salford/ST=Greater Manchester/C=GB
 validity: 2014-12-22 00:00:00 through 2020-05-30 10:48:38
 key type: 2048 bit RSA
key usage: digigpgsm: DBG: 

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Thomas Jarosch]

Hi Peter,

On Wednesday, 22 February 2017 13:56:22 CET Peter Lebbing wrote:
> Oh, as an aside, the advantage of paperkey is that it is
> self-describing. 

I've tried paperkey with Gnupg 2.1.13 and it had trouble parsing the secret 
key data. May be the internal packet format changed or needs adaption.
When I think about long term storage, I'd rather rely on the full data
instead of a snippet of the openpgp packets.

The argument about re-downloading the public key from the keyservers is valid 
though, but for the secret key a full backup is preferred in our use case.
It's easy for the user to skip the public key backup.

Also if the QR code scanning ever fails: There is base64 encoded text output
at the end, too. That could be OCRed or typed in by hand if ever needed.
(we use paperbackup.py just as additional backup)

You can even use paperbackup.py to back up your ssh key :)

Cheers,
Thomas


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Robert J. Hansen]

> Oh, as an aside, the advantage of paperkey is that it is
> self-describing.

I'll chime in with another recommendation for Paperkey.  I'm a little
surprised that your code is as large as it is, too: using an alternate
pipeline you might be able to significantly reduce code size.

(a) use Python 3's gpg module to export the secret key
(b) paperkey --output-type raw --secret-key key.gpg --output key.raw
(c) use Python 3's QR library to create a series of PNGs
(d) use Wand or PythonMagick to convert the PNGs to PDF
(e) save the PDF and you're done


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

export-minimal doesn't affect export-secret-key?

[Peter Lebbing]

I just found out that the following two commands are equivalent:

> $ gpg2 -o full.gpg --export-secret-keys ac46efe6de500b3e
> $ gpg2 -o minimal.gpg --export-options export-minimal --export-secret-keys 
> ac46efe6de500b3e
> $ ll
> total 104
> -rw--- 1 peter peter 50731 Feb 22 14:00 full.gpg
> -rw--- 1 peter peter 50731 Feb 22 14:00 minimal.gpg
> $ gpg2 --version
> gpg (GnuPG) 2.1.18
> libgcrypt 1.7.6-beta
> [...]

I thought "well this is surely a bug in the new 2.1, what with the new
secret key storage". But:

> $ gpg -o full.gpg --export-secret-keys ac46efe6de500b3e
> $ gpg -o minimal.gpg --export-options export-minimal --export-secret-keys 
> ac46efe6de500b3e
> $ ll
> total 88
> -rw-r--r-- 1 peter peter 41465 Feb 22 14:02 full.gpg
> -rw-r--r-- 1 peter peter 41465 Feb 22 14:02 minimal.gpg
> $ gpg --version
> gpg (GnuPG) 1.4.18
> [...]

And now I'm confused... surely export-minimal is useful when backing up
your secret key and storage is limited? We just encountered this with
the paperbackup.py thread...

This works fine, BTW:

> $ gpg2 -o minimal.gpg --export-options export-minimal --export 
> ac46efe6de500b3e$ ll
> total 56
> -rw-r--r-- 1 peter peter 50631 Feb 22 14:06 full.gpg
> -rw-r--r-- 1 peter peter  2623 Feb 22 14:06 minimal.gpg

Cheers,

Peter.

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Peter Lebbing]

Hello Gerd!

Thank you for sharing your program with the world! I'm sure it will be
useful.

On 22/02/17 09:38, Gerd v. Egidy wrote:
> You are right that this is probably more than strictly neccessary. But if you 
> look at my example output on github, a regular public and private key in 
> qrcodes and plain is just 9 pages. 

I beg to differ. Following your instructions, my PDF is 208 pages long!

The certificate (aka public key) includes all signatures, all the data
on the keyserver. It's data you don't really need to back up since it is
public, and it can be huge. My key.asc file is 137,424 bytes following
your instructions.

Additionally, --export-secret-key actually includes everything from
--export, it just *adds* the secret key material to it. So there is no
need to do both --export and --export-secret-key; it just doubles the
information from --export.

What you're probably looking for is:

$ gpg2 --armour --output key.asc --export-options export-minimal
--export-secret-key [KEYID]
$ paperbackup.py key.asc
$ paperrestore.sh key.asc.pdf | diff key.asc -
$ lpr key.asc.pdf

However, I'm running into a little problem here myself... GnuPG 2.1.18
does not respect the "export-minimal" option for --export-secret-key,
only for --export. So if you are using GnuPG 2.1, this will not work as
intended.

This is in all likelihood a bug in GnuPG 2.1, and I'll report it right now.

Leaving aside this bug, export-minimal will achieve your goal: it will
only include the currently valid parts of the key without any
certifications by other keys. It is all you need to have a working key.
The certifications by other keys are on the keyservers.

Oh, as an aside, the advantage of paperkey is that it is
self-describing. No matter what happens, as long as we can still use
hexadecimal digits to describe binary content (which would be trivial to
reimplement), we can reconstruct the binary private key file. Using QR
codes has the disadvantage that if you cannot find a QR-code decoder for
your platform in the future, reimplementing one is far from trivial. You
are dependent on QR codes surviving as an actually supported data format.

Finally, I remember something about QR codes inherently supporting
splitting data over multiple individual code blocks, specifically for
data that is too large to fit in a single block. I don't know if it
supports the number of blocks you need, but you might want to check it
out. Also, you say large QR codes are easily damaged by wrinkles and
deformations. Is this perhaps related to the amount of error correction
data included? You can tune the ratio of content data to error
correction data, making a QR code more resilient to damage. However, if
you find that it is not unreadable individual pixels but rather the
deformation of the total that is throwing off decoders, than I suppose
the ratio doesn't help: it either can reduce it to the required square
or it cannot, I'd think.

HTH,

Peter.

-- 
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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Announcing paperbackup.py to backup keys as QR codes on paper

[Gerd v. Egidy]

Hi Daniel,

> > gpg2 --armor --export "User Name" >key.asc
> > gpg2 --armor --export-secret-key "User Name" >>key.asc
> > paperbackup.py key.asc
> 
> this is a cool idea.  however, it seems like you might be backing up
> more than most people would need.  For most folks, their OpenPGP
> certificates (public keys) are stored on the public keyservers.  Or at
> least their friends have a copy of them :)
> 
> Even if you want the whole certificate, you've duplicated most of the
> material here -- just the data produced by --export-secret-key should be
> sufficient to reconstruct everything.  Probably, putting less data in
> your qrcode backup will make the backup more robust during recovery..

You are right that this is probably more than strictly neccessary. But if you 
look at my example output on github, a regular public and private key in 
qrcodes and plain is just 9 pages. 

If some of the qrcodes containing the public key could not be decoded during 
recovery, it won't affect the codes of the private key. The user will just 
have to remove the ascii armored remnants of the public key. So adding the 
public key won't hurt.

paperbackup.py doesn't know or understand public or private keys, it just 
cares about text files. So the user is always free to decide what parts to 
back up.

> Are you aware of David Shaw's paperkey?
> 
>   http://www.jabberwocky.com/software/paperkey/

Yes, I have linked it in the README on github, section "Similar projects".
 
> This produces significantly less data (still in text form, though), so
> it could be combined with your approach to have a nice big, robust,
> scannable recovery mechanism.

Correct. But unless you want to backup hundreds of keys I don't think it is 
necessary to think much about data reduction. It is just a few pages of paper 
and printing and scanning them is just a matter of a few minutes. 

This is the beauty of qrcodes in contrast to OCR and manually typing.

Kind regards,

Gerd


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users