Cannot decrypt file encrypted with enQsig

Peter Lebbing peter at
Wed Aug 15 12:13:59 CEST 2018

On 15/08/18 09:08, Felix E. Klee wrote:
> So, perhaps enQsig is using 3DES.

Good find! This sounds plausible. I myself had completely forgotten
reading about this bug.

Besides, I completely dismissed the encrypting application in this case
because it decided to encrypt the session key to your primary key as
well, which is very clearly not according to specification.

> *How do I find that out?*

Here's the catch: unless you have an on-disk copy of your private
encryption key, you can't. As I just wrote in my other answer in this
thread, the smartcard denies giving out the data it didn't like to see.
But whether 3DES was used can only be decided by looking at the
decrypted... erm... PKESK packet X-D.

If you have a computer with an on-disk copy, you could try it with that
on-disk copy and it will simply tell you when you ask for more verbosity
and stuff. The usual caveats apply: you are using a smartcard to protect
your private key material, but I'm now suggesting you use an on-disk
copy of the key. Treat it like you would if you were transferring the
key to a new smartcard to replace a broken one.

This strange product also encrypted to your primary key, but it's
probably only more difficult to use this than it is to use your
encryption key. You'd have to, again, load an on-disk copy and then
change the usage flags to make in encryption-capable. But if you don't
have a backup of the encryption key but do have one of the primary key,
you could do it. But after all this think about whether you should use
an encryption key you don't have a backup of: if your smartcard ever
dies, you can't decrypt anything anybody has ever sent you encrypted.

> Also, I don’t understand: I was assuming that all the card does is
> decrypt my session key using my private 4096 bit RSA key. *If the
> session key is a 3DES key, why should the card care?*

Because it inspects the decryption result for sanity before handing it
back to the computer. This is done because an attacker might learn
information about the private key if it were able to just have the
smartcard decrypt anything it was given. And the whole point of a
smartcard is that it should not be possible (or at least very hard) to
extract the private key from the smartcard.

I think the bug boils down to the card incorrectly dismissing the
decryption result as invalid. But I'm not intimately acquainted with the
bug, so this might be a misinterpretation.



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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the Gnupg-users mailing list