Re: [CFRG] An update on Web Crypto, and adopting CFRG curves

Hubert Kario <hkario@redhat.com> Tue, 16 August 2022 14:11 UTC

Return-Path: <hkario@redhat.com>
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 0D233C1522CA for <cfrg@ietfa.amsl.com>; Tue, 16 Aug 2022 07:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.676
X-Spam-Level:
X-Spam-Status: No, score=-7.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ii-1SVL4_WO5 for <cfrg@ietfa.amsl.com>; Tue, 16 Aug 2022 07:11:32 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 0C70FC1522BE for <cfrg@irtf.org>; Tue, 16 Aug 2022 07:11:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660659090; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0pVMrwg/mHk2OAf7/06OJ3MNXSUG6wuVpWocZ131dT4=; b=FMy4xoTlwcUKxyH3NkVTL3C2halkFUs1pHEVdu+Cn5DGysIjeHfqBXFlbKPz6YOgNaqVcG tDQV8hIwUmWgqvw4xD7I/CCZJrlx6aQJ49T8xCe74kPUMIBhHZgshqcpkLJHTydziuVo86 LJOyN6TK3DDMdC8F5aYkbQa4bSEFKkE=
Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-321-1LHUCjuLMH6fvhYM_1r6Zw-1; Tue, 16 Aug 2022 10:11:29 -0400
X-MC-Unique: 1LHUCjuLMH6fvhYM_1r6Zw-1
Received: by mail-ed1-f69.google.com with SMTP id b13-20020a056402350d00b0043dfc84c533so6648624edd.5 for <cfrg@irtf.org>; Tue, 16 Aug 2022 07:11:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:user-agent:organization:references :in-reply-to:message-id:mime-version:date:subject:cc:to:from :x-gm-message-state:from:to:cc; bh=tPY+0QJNISwVv9okDDRSCr4xBeoZRu3Oy7ugQia8N8A=; b=Pmjn6HOShXeF6TxJMAe2i/QasIeB/cox07TDO8u/+6hFvCmzYVN9ViDe86QX0ctxXc sCn2zXoBIkPtfZOA/uNLcbOySdI0RGY8KoEO8GZNhRlK2koypQSNVuNxV3cbrZ5LrCNe 4iZrf2n6Adit1nNMRrzVH307ybX3pveYZlgik8wWNbgSqbJsiCqlJueWRu4Bf1zbV/R+ XEB9/TC85C0OEi07UncL6SFO5IN6LocG46g10w/SzV8ITKHvN3igsExq5N618vY5oba/ xRx91hx7JnayaKz5MybUQfWlRCQKmUXgGWzrqwIxQpZvsffei6OBgiofsU53hd3Fdj0c XV1Q==
X-Gm-Message-State: ACgBeo2WGodtzBqZUEPSoUsyte7r92SfJqz2Rv5gTPTtNYajiRrHGC4b D+Ggnkr/NdiCtTdhnu2eHuuofVXj6nbZBZi7PxY8fHdcZJCc/jPXuCHxe1eGqBHNOwnnyk4W09p s+Ro/
X-Received: by 2002:a17:906:93f0:b0:730:6b07:102d with SMTP id yl16-20020a17090693f000b007306b07102dmr13669419ejb.237.1660659088489; Tue, 16 Aug 2022 07:11:28 -0700 (PDT)
X-Google-Smtp-Source: AA6agR4HTJu54/ryuRXkoABxQs8sex2YQktCiyGK9xb7XuMnLCOnU8DbxTGqEorXAV+2dufSZB3FoA==
X-Received: by 2002:a17:906:93f0:b0:730:6b07:102d with SMTP id yl16-20020a17090693f000b007306b07102dmr13669407ejb.237.1660659088282; Tue, 16 Aug 2022 07:11:28 -0700 (PDT)
Received: from localhost (ip-94-112-13-200.bb.vodafone.cz. [94.112.13.200]) by smtp.gmail.com with ESMTPSA id y25-20020a170906471900b007309f007d3asm5304841ejq.128.2022.08.16.07.11.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Aug 2022 07:11:27 -0700 (PDT)
From: Hubert Kario <hkario@redhat.com>
To: Daniel Huigens <daniel.huigens@proton.ch>
Cc: cfrg@irtf.org
Date: Tue, 16 Aug 2022 16:11:26 +0200
MIME-Version: 1.0
Message-ID: <1951263b-fafa-483c-af75-eef1eec5be2e@redhat.com>
In-Reply-To: <hL3YIsap8BxoSIeA4ihoOMRLWXLCzpqJlOZfgHcruq3o5p-LfEe7VqC0KYINwLqM3gWj8apsatFyS2RE8VdMzn702r6v_WNRdBmcq0OMTP4=@proton.ch>
References: <lOuLx02d-aJwfKgoM3e740D2ipOIu-8AL2TKk_CZ1EGzgw8Q22K6qNOtYmCh9nQ4mHLL5JM5mpwrgF3-2c97PscNJzriGHohgVkjLIT-8XI=@proton.ch> <a53dff15-d554-48a2-80f4-49d8586b10ba@redhat.com> <hL3YIsap8BxoSIeA4ihoOMRLWXLCzpqJlOZfgHcruq3o5p-LfEe7VqC0KYINwLqM3gWj8apsatFyS2RE8VdMzn702r6v_WNRdBmcq0OMTP4=@proton.ch>
Organization: Red Hat
User-Agent: Trojita/0.7-git; Qt/5.15.2; xcb; Linux; Fedora release 35 (Thirty Five)
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/sWX1JJy1jVccZk27fwUrmolYjuA>
Subject: Re: [CFRG] An update on Web Crypto, and adopting CFRG curves
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.39
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: Tue, 16 Aug 2022 14:11:36 -0000

On Tuesday, 16 August 2022 15:10:29 CEST, Daniel Huigens wrote:
> On Tuesday, August 16th, 2022 at 14:27, Hubert Kario wrote:
>
>> If we want consistency between implementations of ed25519, I'm afraid that
>> it will be a long road to that:
>> 
>> https://hdevalence.ca/blog/2020-10-04-its-25519am
>
> This (draft) spec aims to standardize & ensure consistency between
> implementations of Ed25519 in Web Crypto only (along with the other
> algorithms), not Ed25519 implementations in general. I agree that would
> be much more difficult.
>
> Of course, an implementation of Web Crypto will still have to call out
> to a crypto library implementing Ed25519 at some point. However, the
> checks proposed in [1] can, in principle, be done by the Web Crypto
> implementation, by checking keys and signatures against a hardcoded
> list of small-order elements. Of course it would be better if the
> crypto library would implement that, though - but often browsers at
> least are also in control of that (e.g. Firefox has NSS and Chrome has
> BoringSSL, a fork of OpenSSL) - so I think that shouldn't be a huge
> issue.
>
> However, if you see some issue with these checks, please let me know.

I'd say that if we want to ensure consistency, there should be test vectors
included for all of those corner cases.
-- 
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic