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

[Rene Struik <[e-mail]>]

This only verifies that the implementation outputs behavior consistent 
with what is written in the spec. It does not verify correctness for any 
other input or for a non-exposed signing key {an implementation could 
simply include a table look-up for "CFRG test vectors" and do its own 
thing otherwise (and you would not catch this...)}. This illustrates the 
limited value of such tests. Comparing test results with a handful of 
printed values in a spec is *not* the same as validating the proper 
functioning of an implementation module.

On 6/4/2015 12:38 PM, Taylor R Campbell wrote:
>     Date: Thu, 04 Jun 2015 11:24:18 -0400
>     From: Rene Struik <[e-mail]>
>
>     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.


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]