dmshaw / paperkey Goto Github PK

Since this looks like an autotools build system I tried the "generic way" found here: http://www.bioinf.uni-freiburg.de/~mmann/HowTo/automake.html

But it does not seem to work:

$ aclocal
$ autoconf
$ automake -a -c
configure.ac:9: installing './compile'
configure.ac:13: installing './config.guess'
configure.ac:13: installing './config.sub'
configure.ac:12: installing './install-sh'
configure.ac:12: installing './missing'
Makefile.am: installing './INSTALL'
configure.ac:11: error: required file 'config.h.in' not found
configure.ac:55: error: required file 'gl/Makefile.in' not found
Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'

What is the correct way to compile this program? I'm using archlinux on x64.

I want to have a physical copy of my secret data, but I don't trust printers, so I want to write it down by hand. It's a lot to write down as is, so I suggest that paperkey supports base58 as an alternative to the raw and base16 outputs. Base58 is similar to base64, except that the following characters are not used to prevent ambiguity: plus (+), slash (/), zero (0), capital i (I), capital o (O), and lowercase L (l). This encoding is almost 1.5x as space-efficient as base16, which already saves quite a bit of writing. (It took me over two hours to write down my key in base16, because I wrote very carefully to make it was legible.) It might be necessary to use longer CRC codes per line as the entropy per line has significantly increased.

Current releases contain config.guess and config.sub that dates from 2009, which does not recognize many new architectures like RISC-V or LoongArch.

checking build system type... ./config.guess: unable to guess system type

This script, last modified 2009-11-20, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

  http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
  http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to <[email protected]> in order to provide the needed
information to handle your system.

config.guess timestamp = 2009-11-20

uname -m = riscv64
uname -r = 6.5.8-arch1-1
uname -s = Linux
uname -v = #1 SMP PREEMPT_DYNAMIC Thu, 19 Oct 2023 22:52:14 +0000

/usr/bin/uname -p = unknown
/bin/uname -X     = 

hostinfo               = 
/bin/universe          = 
/usr/bin/arch -k       = 
/bin/arch              = 
/usr/bin/oslevel       = 
/usr/convex/getsysinfo = 

UNAME_MACHINE = riscv64
UNAME_RELEASE = 6.5.8-arch1-1
UNAME_SYSTEM  = Linux
UNAME_VERSION = #1 SMP PREEMPT_DYNAMIC Thu, 19 Oct 2023 22:52:14 +0000
configure: error: cannot guess build type; you must specify one

Out of curiosity I wanted to test the manual restore of a secret key without the paperkey program. From the paperkey backup explanation:

# To recover a secret key without using the paperkey program, use the
# key fingerprint to match an existing public key packet with the
# corresponding secret data from the paper key.  Next, append this secret
# data to the public key packet.  Finally, switch the public key packet tag
# from 6 to 5 (14 to 7 for subkeys).  This will recreate the original secret
# key or secret subkey packet.  Repeat as needed for all public key or subkey
# packets in the public key.  All other packets (user IDs, signatures, etc.)
# may simply be copied from the public key.

But how to really do that? In which format has the existing public key packet to be, so that I can edit it by hand and add the secret key data?

Issue

When we execute the following gpg and pakerkey command, then the error unable to parse OpenPGP packets is reported

gpg  -a --export-secret-key 4BD5F787F27F97744BC09E019C1CA69653E98E56 | paperkey --output paperkey.asc
Error: unable to parse OpenPGP packets (is this armored data?)
Unable to find secret key packet

key info

gpg --list-packets private.pgp
# off=0 ctb=95 tag=5 hlen=3 plen=1862
:secret key packet:
	version 4, algo 1, created 1550087793, expires 0
	pkey[0]: [4096 bits]
	pkey[1]: [17 bits]
	iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 1A9F0DA34A68F761
	protect count: 41943040 (244)
	protect IV:  14 87 a6 d5 db b7 fe d8 97 8a 8f 7f 90 60 18 38
	skey[2]: [v4 protected]
	keyid: 9C1CA69653E98E56
# off=1865 ctb=b4 tag=13 hlen=2 plen=39
:user ID packet: "Charles Moulliard <[email protected]>"
# off=1906 ctb=89 tag=2 hlen=3 plen=596
:signature packet: algo 1, keyid 9C1CA69653E98E56
	version 4, created 1613457473, md5len 0, sigclass 0x13
	digest algo 8, begin of digest 81 d5
	hashed subpkt 27 len 1 (key flags: 03)
	hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
	hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
	hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
	hashed subpkt 30 len 1 (features: 01)
	hashed subpkt 23 len 1 (keyserver preferences: 80)
	hashed subpkt 33 len 21 (issuer fpr v4 4BD5F787F27F97744BC09E019C1CA69653E98E56)
	hashed subpkt 2 len 4 (sig created 2021-02-16)
	hashed subpkt 9 len 4 (key expires after 6y4d10h41m)
	subpkt 16 len 8 (issuer key ID 9C1CA69653E98E56)
	data: [4096 bits]
# off=2505 ctb=9d tag=7 hlen=3 plen=1862
:secret sub key packet:
	version 4, algo 1, created 1550087793, expires 0
	pkey[0]: [4096 bits]
	pkey[1]: [17 bits]
	iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: A41EE4FEEFFBB304
	protect count: 41943040 (244)
	protect IV:  f4 b0 40 f9 dc d4 64 7f ab 88 4f 37 57 82 a5 2c
	skey[2]: [v4 protected]
	keyid: B6864CCACED21250
# off=4370 ctb=89 tag=2 hlen=3 plen=572
:signature packet: algo 1, keyid 9C1CA69653E98E56
	version 4, created 1613457515, md5len 0, sigclass 0x18
	digest algo 8, begin of digest 18 a7
	hashed subpkt 27 len 1 (key flags: 0C)
	hashed subpkt 33 len 21 (issuer fpr v4 4BD5F787F27F97744BC09E019C1CA69653E98E56)
	hashed subpkt 2 len 4 (sig created 2021-02-16)
	hashed subpkt 9 len 4 (key expires after 6y4d10h41m)
	subpkt 16 len 8 (issuer key ID 9C1CA69653E98E56)
	data: [4095 bits]

Versions

• paperkey: 1.6
• gpg: 2.2.27
• OS: Mac

I have four files and I want to recover the private key so I can import the private key back into the gpg keyring. Whsn I do a gpg --list-keys and key is in the keyring but I need to change the key to expire or revoke it. If I try to revoke or edit the key I get a Need the secret key to do this message.

.christopher_72969D3E.private-key-paper.txt
.christopher_72969D3E.private-master-key
.christopher_72969D3E.private-master-key.txt
.christopher_72969D3E.public-master-key.txt

I assume the .christopher_72969D3E.public-master-key.txt file is my public key and the .christopher_72969D3E.private-master-key.txt is the private key. The .christopher_72969D3E.private-master-key is a binary file.

I ran the following commands:

paperkey --pubring .christopher_72969D3E.public-master-key.txt --secrets .christopher_72969D3E.private-key-paper.txt --output christopher_72969D3E.private-key.gpg
Error: unable to parse OpenPGP packets (is this armored data?)

cp .christopher_72969D3E.public-master-key.txt christopher_72969D3E.public-key.gpg

paperkey --pubring christopher_72969D3E.public-key.gpg --secrets .christopher_72969D3E.private-key-paper.txt --output christopher_72969D3E.private-key.gpg
Error: unable to parse OpenPGP packets (is this armored data?)

Hi there, thank you for the very useful tool.

I think it would be helpful if paperkey additionally supported a BIP39-style output format where the data would be encoded as words from a word list rather than hex characters. This might make transcription of the data easier.

There was not an example of this, so I wondered does it work correctly if I export just a subkey (with exclamation mark at the end), e.g.:

# Notice the ! exclamation mark at the end of key, which exports just a subkey
gpg --export-secret-subkeys ABC123! | paperkey -o subkey.txt

I'm not familiar enough with the key format to judge this from the implementation.

gpg2 --export-secret-keys [fpr] | paperkey --output-type raw > first.bin
gpg2 --export-secret-keys [fpr] | paperkey --output-type raw > second.bin
vbindiff first.bin second.bin

expected result: first.bin and second.bin have identical content

actual result: they are not.

I'm working on a bit of tooling around generating and backing up PGP keys, and I'd like the paper backup option to be compatible with paperkey, but I can't find any documentation on how the data is structured in the raw output, and how the encoding is handled etc. Does documentation like this exist already, and if not, is it planned to be added? I'd like to avoid making stuff up from the code if it can be avoided.

Hey there!

So, here's my current problem

I have the base16 data in a txt file, and my public key in asc file

However, when I try to parse the data together, it doesn't work.

What can I do?

Similarly to #2 and #7 (and sort-of consolidating them) a way of making thing a bit more compact and much less error-prone, if one needs to write it on a paper by hand and then type it back in.

Pros/cons for base58

• PRO: Much better than base16, but still not-quite compact (less than 6bits/char)
• PRO: Widely known and published
• CON: It's still gibberish, so error prone for humans to write and read -- using words (especially the curated EFF list) has "built-in error-correction"

Pros/cons for BIP39

• PRO: It's based on words, so has "built-in error-correction"
• CON: Not meant for such big pieces of data; not compact enough
• CON: Not as widely known as the others

The case for EFF Diceware

• Very widely known and published
• Although not as compact as base64/base58 but I reckon people prefer words as compared to gibberish -- I personally would write a few hundred words as opposed to few hundred hex characters (a test I ran gives me 600 words vs 1000 hex bytes)
• The most compact variant is the long list, having a bit more than 12bits/word -- would be able to encode 3 hex chars nicely

Other honourable mentions

• Diceware short list(s) -- only ~10bits/word but shorter and with unique prefix; won't nicely fit bytes and nibbles though
• S/KEY -- 8 bytes (64bits) translate to 6 words, so about 10bits per word; on par with EFF short word-lists, but as widely known method