Re: 0.332

[Gerd v. Egidy]

> https://github.com/feklee/0.332
> 
> This is a mod of the SCM SPR332 v2 smart card reader, making it
> smaller and lighter.

Nice.

How does it compare size-wise to the cyberJack one from Reiner SCT? That is 
the one I use for size-constrained use cases. 

I think having a slot for a regular card is an advantage as you can easily 
take the card out, carry it with you in your wallet and use it on other 
systems too.

Kind regards,

Gerd




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

Re: OpenPGP on paper (was: Where can I find some papers to read on mail (and envelope) security?)

[Gerd v. Egidy]

> Well there are the classical options:
> 
> 
> 
> Debian provides free fonts like that as packages fonts-ocr-a and
> fonts-ocr-b, which come from:
> 
> and
> 

You might also want to take a look at

https://github.com/intra2net/paperbackup

This was specifically developed to store or transfer GPG encrypted text or 
secret keys on paper.

Kind regards,

Gerd




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

Re: OpenPGP Card V3.3 keytocard error invalid value

[Gerd v. Egidy]

Hi Antony,

> I was previously able to move all three keys to a card. I'm now
> repeating the exercise on a fresh card.
> 
> I'm unable to do proceed without getting an error "invalid value" from
> keytocard. The key type is set correctly on the card in card status (for
> the key that was selected), but the key is not moved. Sometimes I can
> move one of my three keys and the others stubbornly refuse to move.

what driver do you use to connect GnuPG to your card reader?

I experienced several weird communication problems when using the pcsc driver. 
They all went away after I switched to the ccid driver from GnuPG.

Kind regards,

Gerd




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

Re: How U2F works

[Gerd v. Egidy]

> Frankly, I don't really understand the use case for U2F?  Why not using
> plain user certificates which is supported by browser and servers for
> ages?  Is that because the web frameworks don't have good support for
> this?

I think this is because many people consider anything that is called a 
"certificate" complicated. Probably because in the past a lot of programs had 
poor or buggy support for it and they struggled with it.

So they came up with a new brand name and standard.

But I think they messed this up: when you want an attestated U2F device, there 
is no way to backup the private key or clone it to another U2F device. So 
whenever you sign up to a new service or website, you must have your primary 
and all backup U2F devices (each with it's own key) at hand to register them 
with the service.

To have them at hand means I can't store them at a second secure location like 
a bank safe. Because I won't go to my bank safe just to be able to order at a 
new online store. Completely unpractical unless you restrict the usage just to 
a handful of key services. Or it is right back to "what was the name of your 
first pet" :(

Kind regards,

Gerd


___
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 Peter,

> So I think the three initial bytes of an MD5 would work well to detect
> typing errors.

I just implemented the line checksums as discussed.

Kind regards,

Gerd


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

Re: Verify with missing public key: unexpected returncode

[Gerd v. Egidy]

Hi Kristian,

On Friday, 03 March 2017 18:11:04 CET Kristian Fiskerstrand wrote:
> On 03/03/2017 06:04 PM, Gerd v. Egidy wrote:
> > When reading the gpg2 manpage on return codes:

> One quick observation, if using this in automated way and return code
> matters, you likely want to check out "gpgv", otherwise you should be
> parsing --status-fd output for more details

Yes, this is an automated scenario. I'm already using --status-fd and parsing 
it's output. But to be on the safe side, I was checking the return code too. 

With the way gpg2 currently implements the return codes it seems I can't use 
them.

Kind regards,

Gerd


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

Re: Verify with missing public key: unexpected returncode

[Gerd v. Egidy]

Hi Robert,

> > I think it should return 1 in this case. But I get 2. Why?
> 
> Because there were no bad signatures.  A signature which cannot be
> verified is neither good nor bad, it just is.

ok.

> The alternative would be for GnuPG to return a bad signature literally
> *whenever* it had no public key with which to verify the signature,
> meaning that 99% of signatures on a mailing list would be reported as
> bad.  Can you imagine the bug reports we'd get from people if that were
> the case?  "Your software package is listing every single signed message
> I've received as being bad!"

Hmm, but according to the manpage you currently get a returncode meaning 
"fatal error" in this case. That sounds much more severe to me than a bad 
signature.

Kind regards,

Gerd


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

Verify with missing public key: unexpected returncode

[Gerd v. Egidy]

Hi,

I have a scenario where a signature on a file should be checked. The file is
signed by several keys and for this scenario it is ok if at least one is
correct. In some cases it can happen that the system doing the check does not
have access to all public keys that are used for signing.

When reading the gpg2 manpage on return codes:

> The program returns 0 if everything was fine, 1 if at least a signature was
> bad, and other error codes for fatal errors.

I think it should return 1 in this case. But I get 2. Why?

Here are the commands to reproduce:

$ gpg2 --verify test.asc.gpg 
gpg: Signature made Fri Mar  3 17:44:57 2017 CET using RSA key ID 
DB2D0998DC19EEA3
gpg: Good signature from "Foo Foo" [ultimate]
gpg: Signature made Fri Mar  3 17:45:01 2017 CET using RSA key ID 
467C036CA9014F3F
gpg: Good signature from "Bar Bar" [ultimate]

$ gpg2 --delete-secret-keys 467C036CA9014F3F
$ gpg2 --delete-keys 467C036CA9014F3F

$ gpg2 --verify test.asc.gpg ; echo "RET: $?"
gpg: Signature made Fri Mar  3 17:44:57 2017 CET using RSA key ID 
DB2D0998DC19EEA3
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: Good signature from "Foo Foo" [ultimate]
gpg: Signature made Fri Mar  3 17:45:01 2017 CET using RSA key ID 
467C036CA9014F3F
gpg: Can't check signature: No public key
RET: 2

Kind regards,

Gerd


___
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 Peter,

thank you very much for helping with paperbackup.py and sending your python 
code.

> > Ideally it is a tool or combination of tools already deployed widely, like
> > sed and sort I used in paperrestore. This would make the checksums still
> > usable even when the source to paperbackup.py isn't available anymore.
> 
> It took me some fiddling... but using CRC RevEng[1] I got a checksum in
> Python that is compatible to POSIX cksum.
[...]
> $ printf $(printf '%08x' $(echo -n 123456789 | cksum | cut -d' ' -f1) |
> sed 's/../\\x\0/g')|base64|cut -b-6

Yesterday, with your solution in mind, I had an idea how we could even further 
reduce dependencies and ease the use:

echo -n "line content to check" | md5sum | cut -c -6

MD5 may be broken as a secure hash, but it still makes a very good checksum. 
MD5 is well standardized and available and hashlib.md5() is included in 
python. 

Your solution uses base64 to show more bits of the checksum than my hex chars. 
But I think a collision at the first 3 bytes is less likely with MD5 than one 
with CRC. The MD5 sum changes drastically if just one bit flips.

What do you think?

Kind regards,

Gerd


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

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

I tried to change to OCR-B or Inconsolata 
http://stackoverflow.com/questions/316068/what-is-the-ideal-font-for-ocr

but getting that to work with enscript is not easy, as you have to find and 
install afm and pfb into the correct directories. This goes a lot deeper than 
just installing packages provided by whatever disto you are using.

So I think that this would move the bar for a possible user of paperbackup.py 
higher than I want to.
 
> 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".

Can you recommend a tool to create a short checksum (crc32?) for each line? 

Ideally it is a tool or combination of tools already deployed widely, like sed 
and sort I used in paperrestore. This would make the checksums still usable 
even when the source to paperbackup.py isn't available anymore.

Kind regards,

Gerd


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

> 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

I want paperbackup.py to be independent and agnostic of gnupg. It should also 
be usable for e.g. ssh keys or ciphertext.

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

I had some problems creating proper multipage pdfs, so I used PyX.

If you can come up with shorter sourcecode or less dependencies, I'm happy to 
take patches.

Kind regards,

Gerd


___
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 Peter,

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

Seems you are trusted by much more people than me ;)

> $ gpg2 --armour --output key.asc --export-options export-minimal
> --export-secret-key [KEYID]

Thank you for your explanation and recommendation. I have adapted the readme 
on github.

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

Thank you for checking and reporting this.

As it will not leave out important information, just add more data that is not 
strictly needed, it won't hurt the affected users much. Just a few more dead 
trees...

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

What timespan are we talking about?

If we are talking decades, I have no doubts that some qrcode decoder will 
still be available, even if qrcodes aren't used anymore. There are several 
open source decoders available and included in linux distributions. Stuff like 
that tends to be available for a long time: you can still download packaged 
linux distros like Red Hat Linux 1.0 (released 1995) or Debian 0.91 (released 
1994) today, about 23 years afterwards.

If we are talking centuries, I'd worry about the availability of gnupg as much 
as qrcodes. Both are publicly available standards, but I don't know if they 
are still available and understandable by then. I'd recommend going to 
plaintext on glass etched microfiche if you really want to cover that 
timespan.

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

I know of that feature and have deliberately decided against it:

Not all decoders are capable of it, and if one qrcode is missing, the linking 
is broken and you have to patch the decoder to still get some data.

I consider the plaintext linking and ordering I used more robust, see
https://github.com/intra2net/paperbackup#encoding-and-data-format

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

I used the largest error correction ratio possible.

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

I haven't studied the decoding algorithms at that level of detail. If the 
deformation is irregular, I guess it affects some parts of a code more than 
others. Then a higher error correction ration will help.

Kind regards,

Gerd


___
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

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

[Gerd v. Egidy]

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

This is designed as fallback if all your regular backups failed to restore or 
were lost.

Usage is like this:

gpg2 --armor --export "User Name" >key.asc
gpg2 --armor --export-secret-key "User Name" >>key.asc
paperbackup.py key.asc
paperrestore.sh key.asc.pdf | diff key.asc -
lpr key.asc.pdf

You'll find all the details, reasoning and examples in the README.

Kind regards,

Gerd


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