Re: [Cfrg] testability of signature input/output parameters

Taylor R Campbell <campbell+cfrg@mumble.net> Thu, 04 June 2015 16:38 UTC

Return-Path: <campbell@mumble.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6021A90A0 for <cfrg@ietfa.amsl.com>; Thu, 4 Jun 2015 09:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxciatOQPIj9 for <cfrg@ietfa.amsl.com>; Thu, 4 Jun 2015 09:38:12 -0700 (PDT)
Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7459A1A9063 for <cfrg@irtf.org>; Thu, 4 Jun 2015 09:38:12 -0700 (PDT)
Received: by jupiter.mumble.net (Postfix, from userid 1014) id 8D164605E8; Thu, 4 Jun 2015 16:37:16 +0000 (UTC)
From: Taylor R Campbell <campbell+cfrg@mumble.net>
To: Rene Struik <rstruik.ext@gmail.com>
In-reply-to: <55706DA2.4080106@gmail.com> (rstruik.ext@gmail.com)
Date: Thu, 04 Jun 2015 16:38:11 +0000
Sender: Taylor R Campbell <campbell@mumble.net>
User-Agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1.99
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <20150604163716.8D164605E8@jupiter.mumble.net>
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/k6_i-FvKNKccP-7STgXzV8RzTRo>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] testability of signature input/output parameters
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2015 16:38:14 -0000

   Date: Thu, 04 Jun 2015 11:24:18 -0400
   From: Rene Struik <rstruik.ext@gmail.com>

   Well, neither do deterministic signatures seem to help here: if one 
   presumes k=f(m,d) and indeed finds that, for fixed public signature key, 
   repeats of message m produce the same signature, this does not 
   necessarily imply that f depends on private parameter d (for all one 
   knows, k could only depend on public parameter m). This can only be 
   detected if one prints the private parameter d in the spec. However, 
   this does not say anything about behavior with "non-printed-in-the-spec" 
   parameters.

How do you write a test vector for signing without including the
signing key?

For a deterministic scheme, test vectors of the form

(secret key, message, signature)

verify correctness of the complete signing operation.

For a nondeterministic scheme, test vectors of the form

(secret key, message, nonce, signature)

verify only correctness of the deterministic part of the signing
operation, and cannot verify correctness of nonce generation.  For
RSASSA-PSS, `nonce' generation is inconsequential for security; for
ECDSA, nonce generation makes or breaks it.