Re: [CFRG] Psychic Signatures

Ján Jančár wrote

> For example, many
> libraries do not do the required checks to prevent invalid curve attacks
> by default, but have a separate public key validation function that the
> user of the library needs to call, …

I suspect that the reason for the library requiring a separate validation function was patent US 7215773.  Claim 1 reads:

1. A method for validating digital information transmitted in a data communication system,said method comprising the steps of:
a) obtaining an elliptic curve public key generated from a corresponding privatekey in accordance with an elliptic curve cryptographic scheme, said scheme conforming to a predetermined arithmetic algorithm and said scheme conforming to defined system parameters including an elliptic curve defined over a finite field,
b) upon obtaining said public key, verifying said public key is a point lying on said curve, and
c) utilising said public key in a cryptographic operation within said cryptographic scheme upon obtaining such verification.

The important part is step (b): "verifying said public key is a point lying on said curve”.

By leaving the verification to a user supplied function, the library provider would not be infringing on this patent.

This patent was filed October 14, 1998, so presumably it expired October 14, 2018.  Thus, if I am correct about the expiration date, we can now check whether points are on curves.

  —David

> On Apr 21, 2022, at 3:17 PM, Ján Jančár <445358@mail.muni.cz> wrote:
>
> [resending because irtf.org mailserver doesn't like my self-hosted
> mailserver]
>
> Hi all,
>
> On 21. 4. 2022 13:18, Peter Gutmann wrote:
>> Eric Lagergren <eric@ericlagergren.com> writes:
>>
>>> Project Wycheproof has a very good set of test vectors like this.
>>
>> The problem with that is that the description omits one vital point:
>>
>>  Project Wycheproof tests crypto libraries against known attacks.
>>
>> without saying:
>>
>>  as long as that crypto library is a JCE one.
>>
>> This makes it... less than useful for checking crypto libraries in general.
>> In particular none of the stuff I was referring to in my previous post is
>> written in Java.
>>
>> To be more generally applicable, it really needs static test vectors, e.g. a
>> bunch of self-signed X.509 certs that shouldn't verify, rather than a JCE test
>> suite.
>>
>
> We do something like this (for elliptic curve crypto only) in the
> ECTester tool: https://github.com/crocs-muni/ECTester which targets both
> smartcards and software crypto libraries. It has hooks into 15 libraries
> that can be tested.
>
> We also have a test that would have caught this vulnerability in the
> Java ECDSA implementation, however ECTester is written in Java and
> currently targets < Java 9 and so couldn't test the new Java ECDSA
> implementation (also, there is a reason ECTester is implemented in Java,
> it targets JavaCard-based smartcards).
>
> However, I am worried whether this bug would have been found even if we
> ran it on the vulnerable version of Java, as running our test suites,
> which contain everything from invalid curve attacks to these sort of
> ECDSA signature checks, produces a large number of potentially
> concerning results for the libraries and smartcards. For example, many
> libraries do not do the required checks to prevent invalid curve attacks
> by default, but have a separate public key validation function that the
> user of the library needs to call, which may or may not happen in the
> wild. Many cards and libraries can be made to not respond or segfault if
> various malformed curve parameters are provided, etc.
>
> Cheers,
> --Jan
>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg