Re: [Cfrg] call for review: Deterministic Usage of DSA and ECDSA Digital Signature Algorithms

"David W. Kravitz" <> Thu, 27 September 2012 16:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B47F621F847A for <>; Thu, 27 Sep 2012 09:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.17
X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_05=-1.11, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cfqPEasl-qkL for <>; Thu, 27 Sep 2012 09:28:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 789C821F8487 for <>; Thu, 27 Sep 2012 09:28:17 -0700 (PDT)
Received: from hatemtlaptop ([unknown] []) by (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <> for; Thu, 27 Sep 2012 11:27:54 -0500 (CDT)
From: "David W. Kravitz" <>
To: "'Igoe, Kevin M.'" <>, 'Dan Brown' <>,
References: <> <> <002801cd96b7$b7c38c80$274aa580$> <> <000601cd9a69$897d3460$9c779d20$> <> <002901cd9a99$070dc870$15295950$> <> <>
Date: Thu, 27 Sep 2012 12:27:48 -0400
Message-id: <000301cd9ccd$0a904c30$1fb0e490$>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="----=_NextPart_000_0004_01CD9CAB.837FBDA0"
X-Mailer: Microsoft Outlook 14.0
Thread-index: AQJZjD1WbN3mB22kfgMwgvHZe2e5lAHYBuGkAN83IhkCSTqTvgGB4PPAAV1JojICFAfetQHTGd8mAU9Hh/GWHcKC0IAADKhw
Content-language: en-us
Subject: Re: [Cfrg] call for review: Deterministic Usage of DSA and ECDSA Digital Signature Algorithms
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Sep 2012 16:28:19 -0000



Regarding "If the report is signed with an RSA signature, even the signature
stays constant.," this gets us back to the issue I mentioned in my initial
comments on the I-D regarding side-channel attacks. See, for example,
"Weaknesses in Current RSA Signature Schemes," Juliane Kramer Dmitry
Nedospasov Jean-Pierre Seifert, ICISC 2011,,
which exploits constant (and therefore fixed-per-message-) RSA signature
padding. Also, mentions that
"Another advantage of RSA-PSS is that, due to the randomization, an attacker
does not know in advance what the encoded message EM will be. This makes
"fault analysis" attacks of the sort proposed by Bellcore a few years ago
more difficult to mount (see the RSA Laboratories' Bulletin No. 5)."




From: Igoe, Kevin M. [] 
Sent: Tuesday, September 25, 2012 2:12 PM
To: 'Dan Brown'; 'David W. Kravitz';
Subject: RE: [Cfrg] call for review: Deterministic Usage of DSA and ECDSA
Digital Signature Algorithms


Can somebody please articulate the benefit of the feature of having the same
signature per message?  Perhaps the I-D itself should elaborate on this
point. Is it just that some protocol picked some signature scheme with this
deterministic feature, and then the protocol decided to rely on this
feature, e.g. by using the signature as an stable index for the message?  


I'll give this a shot.  Warning: this is all based on a side comment thrown
into a 

conversation concerning obstacles to the adoption of ECDSA signatures.  It

BGPsec, which I believe falls under the SIDR WG.


BGP will often get duplicate reports from a given neighbor  because the
local configuration 

hasn't changed since the last report.  If the report is signed with an RSA
signature, even the

signature stays constant, so it's simple to see this is the same message is
the same as the last one

& there is no need to verify any signature.  But using ECDSA, the signature
field will (potentially) 

change even if nothing else has, forcing a signature verification.


One way to side step the issue is to use deterministic ECDSA.  Another would
be for the sender to 

keep track of the last signed report it sent and, if nothing has changed,
resend the same report.   


(I haven't paid much attention to the current state of the BGPsec
discussions and its threat models, but 

a priori I think I'd  want a timestamp of some sort to prevent replay. That
would mean that the report 

would always be changing and a signature verification would always need to
be done).


Again, this is all of this is second or third hand,  a quick glance at the
SIDR mailing list didn't provide any 

relevant information.