Re: [CFRG] Psychic Signatures

[Mike Hamburg <[e-mail]>]

> On Apr 23, 2022, at 03:58, Peter Gutmann <[e-mail]> wrote:
> 
> Mike Hamburg <[e-mail]> writes:
> 
>> As someone with experience in ECC implementation, this doesn’t make sense to
>> me, at least not in a typical deployment (prime-order curves with (x,y) both
>> given).
> 
> It doesn't surprise me too much.  Many years ago I did an informal poll of a
> number of embedded systems crypto users asking if they wanted RSA blinding, a
> fairly cheap operation compared to the rest of the RSA op, enabled by default
> rather than as something that had to be explicitly enabled by users,
> explaining the security impact (considerable) and the performance impact
> (relatively low).  The results are shown in the following bar graph:
> 
>  Should blinding be enabled by default?
> 
>  No: ##############################################################
>  Yes:
> 
> From the few people who responded to followup questions the thinking seemed to
> be "this causes overhead, overhead is bad, it's unlikely someone will try an
> attack like that anyway, so we'd rather not have it".
> 
> So yeah, skipping the validity checks doesn't surprise me.  OTOH if you just
> put them in there and don't tell anyone, no-one will complain.  Or even
> notice (so far).
> 
> Peter.

Yeah, that does make sense. I guess shoddy programming doesn’t surprise me — I’m sure I’ve done some myself — but saving 0.1% of the runtime isn’t a good reason at all.

In their defense, in many protocols you trust the other party’s public key to some degree before using it (having checked a cert or whatever), especially for ECDSA, so you might not think it’s security relevant to validate it.

ECDHE is of course much more dangerous, especially since it’s sometimes used for authenticated key exchange (as in eg Noise). 

— Mike