Forward/Backward compatibility of scdaemon (2.0 and 2.1)
gniibe at fsij.org
Wed Jan 21 01:11:38 CET 2015
I got a report that Gnuk Token doesn't work well with GnuPG 2.1,
and it found that the problem is compatibility of scdaemon.
The user in question used scdaemon from 2.0 together with
gpg/gpg-agent from 2.1 (it was not intentional).
Signing and authentication worked with this configuration, but
decryption didn't work well (with RSA).
The reason is that the protocol has been enhanced in 2.1 so that it
can support various public key (other than DSA and RSA, that is, ECC).
In 2.1, the data is in the format of SEXP. It's built in
err = gcry_sexp_build (&s_data, NULL, "(enc-val(rsa(a%m)))",
Here, '%m' specifies standard format which might has a prefix of
'0x00' if the MSB is 1. gpg-agent receives this data and forwards the
MPI to scdaemon.
Scdaemon of 2.1 takes advantage of the prefix of '0x00' and uses that
byte as is, for different purpose. However, older scdaemon of 2.0
doesn't know this possibility of the prefix (gpg 2.0 doesn't use SEXP
and format the data with GCRYMPI_FMT_USG (no prefix)), and blindly
adds another prefix, which causes a failure of Gnuk Token (or
How should we fix this issue?
We can just say that use corresponding version of scdaemon. But it
seems for me that implementing forward compatibility in the scdaemon
in 2.0 would be good. It's also possible to change gpg in 2.1 so that
it uses %M to specify GCRYMPI_FMT_USG, but this kills the hack of
using prefix byte.
More information about the Gnupg-devel