Re: Bad passphrase with gpg 2.1 - works fine with gpg 1.4
Hi Fredrik-- On Wed 2017-04-19 15:49:20 +0200, Fredrik Jonson wrote: > After upgrading to Ubuntu 17.04, gpg does not accept my passphrase. More > precisely, gpg 2.1.15 does not. However, gpg 1.4.21, installed as > gpg1 does accept that very same passphrase. What am I doing wrong? gpg 1.4.x and 2.1.x use different secret keyrings. the first time that 2.1.x runs, it tries to import secret key material from the 1.4.x keyring, but it's possible that this happened before the previous key generation. You can encourage 2.1.x to try that migration again with: rm ~/.gnupg/.gpg-v21-migrated gpg2 --list-secret-keys > In an attempt to narrow the scope of possible causes, I've tried to > instruct gpg2 to not use-agent, but failed. modern GnuPG (v2.1) is designed to only use the agent. on this branch, gpg itself never handles secret key material at all. > Gpg2 still prompts me using a GUI dialog, rather than interactively in > the terminal. Can I, from the command line, tell gpg2 not to use agent > and always prompt me for the passphrase in the terminal rather than > via Gnome or gpg-agent? I'm not sure that this is related to your other question. but if you really prefer to only be prompted in the terminal, you can change the version of pinentry that you have installed to pinentry-curses or pinentry-tty. If you're using this from a graphical environment though, i do not recommend making this change. Stick with the graphical passphrase prompt! > Is gpg2 in general compatible with gpg1? Can I use gpg2 while some of my > recipients keep using gpg1? Or is that a bad idea for some reason? you can use gpg 2.1.x while your correspondents use gpg 1.4.x. but trying to use 2.1.x yourself while also using 1.4.x (the "co-installed case") doesn't work very well in my experience, since there are different secret keyrings, and in practice there can be different public keyrings as well (2.1.x prefers ~/.gnupg/pubring.kbx, but 1.4.x only knows about ~/.gnupg/pubring.gpg). --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Prefer a currently available signing subkey?
On Thu 2017-04-20 02:36:16 +0200, Juan Miguel Navarro MartÃnez wrote: > On 2017-04-19 at 17:46, Daniel Kahn Gillmor wrote: >> The open report is https://dev.gnupg.org/T1983 > > Is it possible that is a duplicate of this report too? > https://dev.gnupg.org/T1967 > > Both are about a capable subkey not being used on GnuPG Modern branch > because it prefers a subkey with its missing secret part. Plus there was > a patch which seemed to work for 2.1.18. I agree that these seem related, though T1983 has smartcard-specific concerns. I've tested the patch for T1967 in a non-smartcard situation, but haven't tested it with a smartcard yet. I'd be happy to hear the results of such a test, if anyone has a smartcard handy for testing. --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG Signature Verification
On 24/04/17 19:23, Peter Lebbing wrote:
> The part of "cmp" that would correspond to the constant part of the DER
> encoding I do not recognise.
It is still proper ASN.1, but it encodes a slightly different structure.
I wondered whether it was DER encoded or BER encoded, because I read
that BER was valid for old PKCS#1 v1.5 structures. DER is a subset of
BER. If the Python ASN.1 module pyasn1 rejects malformed DER encoding
then it is proper DER; or would pyasn1 be liberal in what it accepts?
Anyway, the two ASN.1 encoded objects are slightly different:
$ python
[...]
>>> import pyasn1.codec.der.decoder
>>> sha256der =
>>> b'\x30\x31\x30\x0d\x06\x09\x60\x86\x48\x01\x65\x03\x04\x02\x01\x05\x00\x04\x20'
>>> + chr(0)*32
>>> unknown_enc=b'\x30\x2f\x30\x0b\x06\x09\x60\x86\x48\x01\x65\x03\x04\x02\x01\x04\x20'+chr(0)*32
>>> pyasn1.codec.der.decoder.decode(sha256der)
(Sequence().setComponentByPosition(0, Sequence().setComponentByPosition(0,
ObjectIdentifier(2.16.840.1.101.3.4.2.1)).setComponentByPosition(1,
Null(''))).setComponentByPosition(1,
OctetString(hexValue='')),
'')
>>> pyasn1.codec.der.decoder.decode(unknown_enc)
(Sequence().setComponentByPosition(0, Sequence().setComponentByPosition(0,
ObjectIdentifier(2.16.840.1.101.3.4.2.1))).setComponentByPosition(1,
OctetString(hexValue='')),
'')
There's an extra setComponentByPosition(1, Null('')) in the properly
encoded ASN.1. It would appear that the library you're using *is*
trying to generate a PKCS#1 v1.5 message, but that it ends up with a
slightly different DER encoding than what is defined for OpenPGP. You
will have to find a way to generate a EMSA-PKCS1-v1_5 structure that is
compatible to RFC 4880 (and RFC 3447 PKCS #1 Version 2.1).
I don't know much about ASN.1, so I can't really say anything useful
about the results of the experiment above.
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
