OpenPGP card && exporting secret keys

[Matthias Apitz]

Hello,

I'm using an OpenPGP card and gnupg 2.1.19 on my FreeBSD workstations
and my Ubuntu mobile device to store crypted passwords (tool: password-store),
to lock/unlock desktop sessions and to sign emails. This is all working
fine and without any hick-ups.

What makes me worry, is that single point of failure: the OpenPGP card.

While I do backups of alls the encrypted password files, they would be
all useless in case of lost/teft of the token or hardware fault of the SIM
card.

What I do at the moment is something like:

$ find ~/.password-store -name '*.gpg' -exec printf "%s:\n" {} \;
  -and -exec gpg2 -d {} 2> /dev/null \; 
  -and -exec echo \; > /tmp/clear-password-store.txt

$ GNUPGHOME=...
$ gpg -ea /tmp/clear-password-store.txt
$ mv /tmp/clear-password-store.txt.asc $GNUPGHOME
$ rm -P /tmp/clear-password-store.txt

where the other GNUPGHOME contains secret and pub-keys created for this
special purpose and living outside (i.e. without) the OpenPGP card.
ANd in case of lost/teft of the token I could recover at least all
passwords again...

Is there any way to export the secret keys from the OpenPGP card to use
them directly (with a passphrase) and without the OpenPGP card?

Thanks

matthias


-- 
Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/   
+49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

Thanks to the Soviet Army for the Victory in Stalingrad! -- Победа в 
Сталинградской битве!


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

[patches] add support for arc4random_buf()

[Edgar Pettijohn]

Please see attached patches to add support for arc4random_buf() as an 
alternate to /dev/{u}random. I tried to be as unobtrusive as possible 
and maintain style. It should also allow the user to still define 
RANDOM_CONF_ONLY_URANDOM if they would prefer to use /dev/urandom. This 
will allow gpg to be used on filesystems mounted nodev while providing 
quick, quality randomness.



Thanks,


Edgar Pettijohn

--- configure.ac	Wed Dec 13 07:51:33 2017
+++ /home/edgar/libgcrypt-1.8.2/configure.ac	Mon Feb  5 19:59:17 2018
@@ -1721,7 +1721,7 @@
 # Other checks
 AC_CHECK_FUNCS(strerror rand mmap getpagesize sysconf waitpid wait4)
 AC_CHECK_FUNCS(gettimeofday getrusage gethrtime clock_gettime syslog)
-AC_CHECK_FUNCS(syscall fcntl ftruncate flockfile)
+AC_CHECK_FUNCS(syscall fcntl ftruncate flockfile arc4random_buf)
 
 GNUPG_CHECK_MLOCK
 
--- rndlinux.c	Thu Nov 23 12:16:58 2017
+++ /home/edgar/libgcrypt-1.8.2/random/rndlinux.c	Mon Feb  5 23:18:20 2018
@@ -154,6 +154,30 @@
 }
 
 
+/* This is the least obtrusive way I could find */
+#if defined(HAVE_ARC4RANDOM_BUF)
+  if (!only_urandom)
+{
+  do
+{
+  size_t nbytes;
+
+  nbytes = length < sizeof(buffer) ? length : sizeof(buffer);
+  /* always successful */
+  arc4random_buf (buffer, nbytes);
+
+  (*add)(buffer, nbytes, origin);
+  want = want - nbytes;
+   } while (want);
+
+  wipememory (buffer, sizeof buffer);
+
+  return 0; /* success */
+}
+
+#endif /* HAVE_ARC4RANDOM_BUF */
+
+
   /* First read from a hardware source.  However let it account only
  for up to 50% (or 25% for RDRAND) of the requested bytes.  */
   n_hw = _gcry_rndhw_poll_slow (add, origin);
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

gpg: do_plaintext(): wrote 1210414045 bytes but expected 822504068 bytes

[Lightner, Jeffrey]

Basic questions:
1) Is the above message in fact an "error"?
2) What exactly does it mean?
3) Why does it appear to be backwards? (i.e. Why is the first number it says it 
"wrote" larger than what it says it "expected"?
4) How can I detect when this occurs as an "error" to prevent the encryption so 
re-encryption can be re-attempted?

DETAILS:
We create an ascii armored (encrypted) file using GPG via a script we run via 
cron once a week (which has been running for years). The file is then uploaded 
to a bank partner.

It was reported by our cash team that a file uploaded  a few weekends ago  (Dec 
31st) had a variance of some 1.3 Million records when they tried to reconcile 
it.  It is normal to have some variance but this was extreme.

On reviewing the log then I saw the following message which appears to have 
come from the actual encryption of the original file:

gpg: do_plaintext(): wrote 1210414045 bytes but expected 822504068 bytes

That appeared to me to be an error but it didn't prevent the ascii armored 
(encrypted) file from being created (and subsequently uploaded).

The original unencrypted file has nearly the same byte count (1210414056) as 
the first number (1210414045) in above message. A difference of 11 bytes.

The encrypted file it created was 331941767 bytes.

When I re-encrypted the original file the new encrypted file was:
331941796 bytes. (I did that a couple of times and got the same size.) I did 
NOT see the above message on my re-encryption runs.

There seems to be almost no information about this do_plaintext message. Most 
of what I found online including this list is a repeat of the same question 
copied to various other sites. The discussion on that question seems to 
blithely ignore the actual error but instead goes into other commands (tar, 
time, etc...) in that user's command line (pipeline).

I reviewed the man page for gpg and found this tantalizing information:
"--exit-on-status-write-error
This option will cause write errors on the status FD to immedi-
ately terminate the process. That should in fact be the default
but it never worked this way and thus we need an option to
enable this, so that the change won't break applications which
close their end of a status fd connected pipe too early. Using
this option along with --enable-progress-filter may be used to
cleanly cancel long running gpg operations."

That seemed to explain why it didn't actually cause our script to error out. On 
adding the above flag to my encryption it created a slightly different size 
file of 331941792 bytes.

Looking back in our log I saw we'd occasionally had similar message in the past 
(most recently before this particular event at end of December was back in 
October) but in those earlier runs the difference between first and second 
number was significantly smaller. This may have led to it appearing to be 
normal variance in records during reconciliation so no one questioned it.

I added the above flag in hopes it would force the encryption to error out.   
The next 2 weekends the message did not recur.   However, on the past 2 
weekends I've again seen small variances so it appears adding the flag didn't 
have the desired effect as in both cases it still encrypted the file and our 
script sent it to the bank.   The 2 most recent events show the small variance 
I'd seen in events prior to the January one:
January 28th:  gpg: do_plaintext(): wrote 1211934615 bytes but expected 
1211934604 bytes
February 4th:  gpg: do_plaintext(): wrote 1212698432 bytes but expected 
1212698421 bytes

Answers to questions some will ask:
1) The original file size we encrypt is always extremely large so it is not the 
size that caused this issue.  As noted I re-ran the encryption manually several 
times for the original large file successfully so if size were an issue I'd 
expect one of those runs to have failed similarly yet none did.

2) We did NOT run out of space on the filesystem (or on any other filesystem 
such as /tmp) during the encryption. There is plenty of space.

3) The command line we used to do the encryption without the new flag was:
/usr/bin/gpg --always-trust --armor --recipient  -o 
 --encrypt 
Where  is the encrypted file and  
is the original unencrypted file.

4) The command line with the new flag:
/usr/bin/gpg --exit-on-status-write-error --always-trust --armor --recipient 
 -o  --encrypt 

5) I can't decrypt the file created because the recipient uses the bank's 
public key so only the bank can decrypt it with their private key.

6) Linux distro/version is RHEL6.9

7) gpg --version outputs:
gpg (GnuPG) 2.0.14
libgcrypt 1.4.5
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, 

Re: Can't import public key

[Kristian Fiskerstrand]

On 02/03/2018 04:15 PM, Pijus Kar wrote:
> Is it something for the version incompatibility or in the key?

As far as I can see the keyblock referenced is DSA2, which is specified
in FIPS-186-3 from 2009, and you're using a gnupg version from 2002.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"Knowing is not enough; we must apply. Willing is not enough; we must do."
(Johann Wolfgang von Goethe)



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