Help with understanding trust issues for PGP signed wallet generator

[canton]

I'm the author of https://bitcoinpaperwallet.com -- a fork of bitaddress.org that implements a two-sided tri-folding paper wallet design that resists tampering.

I've been encouraging users to download the ZIP of the generator to run in their local browser, but I'm a little stuck in giving them ways to easily verify the integrity and authorship of the file once it's downloaded. (E.g. to show that the ZIP file wasn't molested on github or subsequently messed with on their local filesystem.)

You can download the ZIP from github here: https://github.com/cantonbecker/bitcoinpaperwallet

The best I've come up with is this bit of instructions:

Code:

After downloading the ZIP package for this generator, you should find a file named 
generate-wallet.html.sig which you can use to:

1. verify that generate-wallet.html hasn't been tampered with, and
2. get proof that it really was authored by Canton Becker (canton@gmail.com) whose public key 
was published in May 2013.

For example, if you have GPG installed, you can type:
gpg --verify generate-wallet.html.sig generate-wallet.html

The way I see it, people can easily search forums, etc. to verify that Canton Becker (canton@gmail.com) is the true author of the service, and even if someone else generates a PGP public key for canton@gmail.com, it won't pre-date May 2013.

Is there a better way for me to be signing the wallet generator file?

Thanks for any guidance on either my process or the instructions I'm giving out.

[Abdussamad]

Find the md5sum of the zip file

Sign a message with containing the md5sum and zip file name using your GPG private key. Publish the message and signature along with a link to your gpg public key.

See the .asc files for examples:

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.4/

edit: Yes, I know they use sha* sum instead. The idea is the same.

[canton]

Sign a message with containing the md5sum and zip file name using your GPG private key. Publish the message and signature along with a link to your gpg public key.

Thanks for this idea. I was thinking about signing the ZIP but my worry was that some (possibly significant?) number of browsers automatically extract ZIPs. Also, if I'm using GitHub to distribute the ZIP file, where would I publish that message + signature? What I like about GitHub is it's a one-click ZIP download...

Thanks for any additional advice here.

[jim618]

I do a few things in MultiBit so that people can verify the downloads:

+ PGP signing. Gary wrote a blog item on how to verify it. https://multibit.org/blog/2013/07/24/how-to-check-signatures.html.
+ hash the file as already proposed and publish the hashes. We use SHA256.
+ you can publish the hashes in a release note and then bitcoin sign the release note. See an example multibit release note in the https://multibit.org/releases.html page. You'll need a well known Bitcoin address for the signing. A donation address is ideal for this as it is public. Most Bitcoin wallets allow you to sign messages now.
+ I am not sure you can do it with zip files but you can also sign exes and dmg files with authenticode and a Mac developer id (respectively). This keeps Windows user account control and Mac gatekeeper happy. This might be a step too far for you though as it is a PITA to do.

edit: if you publish a bitcoin signed release note, make sure you don't have any whitespace at the end of your lines (extra spaces etc). I think it was Firefox that automatically stripped these, for some reason, and then end users could not verify the whole message correctly. I just go through manually clicking on the end of each line to check before I calculate the signature.

[Abdussamad]

Given the limitations of github what you are currently doing is fine. Just the signature of the html file is enough since it is the main file in the archive.

The only other thing I can think of is that you should consider adding a link to your PGP public key in your sig here or on your site.

[413j0]

also remember the web of trust is there for one reason, get some people with recognized signatures to sign your key, i will help a lot in telling it apart from a fake one.

http://www.gnupg.org/gph/en/manual.html#AEN335

and signing your gpg signature where you publish it via your most recognized bitcoin address gives users another way to determine it's really you signing

on a side note, its way to easy to fake a creation date on a key (just mess with the clock), so being "the first one" means nothing.

--edit: and a lot of end users will be confused giving them just a console command, instead you can instruct them to use a frontend or gui implementation of pgp like kgpg (linux), cryptophane (windows) or apg (android).

[canton]

on a side note, its way to easy to fake a creation date on a key (just mess with the clock), so being "the first one" means nothing

Thanks very much for this reminder. Someone else informed me of this (and in fact 'spoofed' a creation date and email on the MIT registry to prove it, oi!) so since then I've revised my instructions to refer to my fingerprint as published on my personal website and elsewhere. In the meantime I'll also work on getting my web of trust extended.

My new instructions are as follows:

After downloading the ZIP package for this generator, you should find a file named generate-wallet.html.sig which you can use to:

1) verify that generate-wallet.html hasn't been tampered with, and

2) get proof that it really was authored by Canton Becker (canton@gmail.com) whose public key and fingerprint can be confirmed at cantonbecker.com, bitcointalk.org, etc.

For example, if you have GPG installed, just open the terminal, change directory (cd) to where this generate-wallet.html lives, and type:
gpg --verify --with-fingerprint generate-wallet.html.sig generate-wallet.html

I appreciate what you say about providing instructions for GUI front ends, but that seems like a lot of work on shifting ground. My own GUI front-end on OS X in fact won't easily show the fingerprint, it only shows the email address associated with the signature.