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

[Mike Hamburg <[e-mail]>]

Rene,

Your quibble is true for any testing scheme.  Public test vectors in a 
spec aren't for proving that a piece of software is free of hidden 
faults.  They are for software authors checking that their 
honestly-written software does at least roughly the right thing, at 
least some fraction of the time.  An evaluator can also use their own 
test vectors to defeat a "CFRG lookup table", but that still does not 
prove the absence of backdoors.

Obviously the coverage you get from this varies by primitive, so AES is 
more testable than signing.  Fine.  But specifying deterministic 
signatures still improves testability, to a degree that will be useful 
in the real world.

-- Mike

On 06/04/2015 10:00 AM, Rene Struik wrote:
> 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.
>
>