Re: [CFRG] Psychic Signatures

Ján Jančár <445358@mail.muni.cz> Thu, 21 April 2022 22:17 UTC

Return-Path: <445358@mail.muni.cz>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99B63A0E41 for <cfrg@ietfa.amsl.com>; Thu, 21 Apr 2022 15:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 EmiaM7Zlp0q2 for <cfrg@ietfa.amsl.com>; Thu, 21 Apr 2022 15:17:30 -0700 (PDT)
Received: from arethusa2.fi.muni.cz (arethusa2.fi.muni.cz [147.251.49.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69523A0E2B for <cfrg@irtf.org>; Thu, 21 Apr 2022 15:17:29 -0700 (PDT)
Received: from [192.168.0.13] (ip-78-102-66-51.net.upcbroadband.cz [78.102.66.51]) by arethusa2.fi.muni.cz (Postfix) with ESMTPSA id 73D0D5C001 for <cfrg@irtf.org>; Fri, 22 Apr 2022 00:17:27 +0200 (CEST)
Message-ID: <2438a7cd-e0f7-685b-ad47-e9ba5995a5a0@mail.muni.cz>
Date: Fri, 22 Apr 2022 00:17:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0
Content-Language: en-US
To: cfrg@irtf.org
References: <SY4PR01MB62519FEA53D39AABAF0BD0F4EEF49@SY4PR01MB6251.ausprd01.prod.outlook.com> <2CBA5AE5-DF84-4E9C-85DA-4DC38464710A@ericlagergren.com> <SY4PR01MB6251CA4D5F7C83FA564FD204EEF49@SY4PR01MB6251.ausprd01.prod.outlook.com>
From: Ján Jančár <445358@mail.muni.cz>
In-Reply-To: <SY4PR01MB6251CA4D5F7C83FA564FD204EEF49@SY4PR01MB6251.ausprd01.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/RMPbdRYUkxd2J2yo32fHUM5920w>
Subject: Re: [CFRG] Psychic Signatures
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2022 22:17:35 -0000

[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