[PATCH] agent and scd: Don't prepend message digest

NIIBE Yutaka gniibe at fsij.org
Wed Mar 13 02:05:21 CET 2013


On 2013-03-12 at 15:37 +0100, Werner Koch wrote:
> On Tue, 12 Mar 2013 09:19, gniibe at fsij.org said:
> 
> > signing/authentication.  Currently, we always prepend message digest
> > specifier and it is checked by SCDaemon.  With this patch, it will be
> > only prepended for RSA and not for ECDSA, and it will be not checked
> 
> Looking at the patch I can't see who this is only used for ECDSA.  You
> remove the entire prefixing from do_sign.

I'm sorry, my explanation was not good enough.  Let me rephrase.

When signing, GPG-Agent prepend message digest specifier (the prefix)
always.  The call chain in question is:

	divert-scd.c:divert_pksign
	 -> call-scd.c:agent_card_pksign

Here, encode_md_for_card is called before calling agent_card_pksign to
add the prefix.  There is another flow (algo == MD_USER_TLS_MD5SHA1),
which doesn't call encode_md_for_card, but this case is:
ctrl->use_auth_call = 1, which results PKAUTH (not PKSIGN) in
agent_card_pksign.

My change will remove this prefixing for ECDSA, but keep it for RSA.
Please note that the prefix is always available for RSA for PKSIGN.

I assume that the only client of SCDaemon is GPG-Agent of the same
version (or a bit old versions, but not all of past versions).  I
think that it is OK to ignore other clients or very old versions.
    <--- I didn't say this in the previous message.

At SCDaemon side, it examines the prefix while removing off it (the
first X) if any, and adds again (the second X).  My change will remove
this processing entirely: no checking, no removing, and no adding.

This change is *not* 100% compatible, it won't work with a digest with
no prefix for RSA.  In the case of no prefix (plain SHA1 or RMD160),
current code adds relevant prefix in do_sign, while code with my
change will cause an error.  I think that there will be no problem,
however, because there is always the prefix for RSA (for recent
GPG-Agent).
-- 





More information about the Gnupg-devel mailing list