Re: [jose] RFC 8037 "alg" quirkiness

Ilari Liusvaara <> Wed, 16 September 2020 12:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEE6B3A1225 for <>; Wed, 16 Sep 2020 05:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fRn9fiBp2cCF for <>; Wed, 16 Sep 2020 05:30:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A9C63A0F8F for <>; Wed, 16 Sep 2020 05:30:46 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1855684F1 for <>; Wed, 16 Sep 2020 15:30:44 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id mHIE-Oew43Ul for <>; Wed, 16 Sep 2020 15:30:44 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 67303286 for <>; Wed, 16 Sep 2020 15:30:43 +0300 (EEST)
Date: Wed, 16 Sep 2020 15:30:43 +0300
From: Ilari Liusvaara <>
To: "" <>
Message-ID: <20200916123043.GB1653297@LK-Perkele-VII>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [jose] RFC 8037 "alg" quirkiness
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Sep 2020 12:30:48 -0000

On Sun, Aug 30, 2020 at 08:10:17AM +0100, Neil Madden wrote:
> > On 30 Aug 2020, at 07:58, Anders Rundgren <> wrote:
> > 
> > I have just implemented support for Edwards curves in my JSON
> > library.
You mean JOSE or JWS? Because JSON is a data model and encoding of
it. :-)

> > Although it is certainly not a deal-breaker I find the use of
> > "EdDSA" as a generic Edwards algorithm identifier rather quirky
> > since it departs from the other JWS algorithms:
> >
> > 
> > For curiosity reasons I took a peek at the initial draft which has
> > (in my opinion...) a more logical solution:
> >

On weird changes, I find the member name changes a bit weird. For
example it calls something that is not a curve a curve.

> > May I ask why this change was performed?

After prehashing was eliminated, there was only one algorithm that made
sense with either, so those were merged.

> > For JSF (JSON Signature Format) I will stick to the "00" scheme
> > which also permits use of ed25519ph and friends if needed:
> >

Beware of implementations that use wildly wrong algorithms.

And on interactions of Ed25519 and Ed25519ph, they originally interacted
in harmful ways. Ed25519ph was later changed (in very hacky way) in
order to fix this (the same mechanism as used to contextualize Ed25519,
which turned out later to be horrible idea due to API issues it causes).

And Ed25519ph is weaker than Ed25519. In order to prehash without
weakening the algorithm, one needs to salt the prehash, which Ed25519ph
does not do. And lack of salting has been exploited in real world.

> 8037 was done by CFRG, so probably best to ask there. 

8037 was done by JOSE. The CFRG part (generic specification of
EdDSA2) was 8032.

> I like this aspect of the spec. IMO “alg” as a header was a mistake.
> By using a generic algorithm header, it forces implementors to
> associate the specific details in metadata stored with the key, which
> is much safer. 

Actually a few months ago I came up with idea of having a way to express
"algorithm determined by the key" in JOSE/COSE.

- There have been some serious security issues in JWS implementations
  that have been caused by using completely wrong algorithms.
- In general, using the same key with multiple algorithms is not
  cryptographically safe. There can be algorithm pairs which interact
  badly (for instance, Ed25519 and the original Ed25519ph).