Subject: [core] Choice of signature Algorithm(s) in Group OSCORE

From: John Mattsson <[email-masked]>
Date: Thu, 21 Mar 2019 21:08:47 +0000

I think we need some more discussion of which signature algorithms to use. Candidates would be:

Algorithm                                Signature size     Security level
ECDSA secp224r1 (P-224)    56 bytes               112
ECDSA secp256r1 (P-256)    64 bytes               128
ECDSA secp256k1                  64 bytes               128
Ed25519                                  64 bytes               128

The CFRG review of EDHOC brought up the qeustion if not P-224 would be a better choice if the main goal is to get smaller messages. ECDSA with P-224 has the obvious advantage of having signatures that are 8 bytes shorter.

112-bit security is according to NIST ok to use until 2030.

ECDSA wih P-224 is significantly faster than ECDSA with P-256, around 2/3 the number of operations/time. secp256k1 is around 300 % faster than secp256r1. Harder to find comparisions with Ed25519. Most of the speed will depend on the curve, but EdDSA (Schnorr) also have other advantages that speed up signing compared to ECDSA. Ed25519 verify is likely at least as fast as ECDSA with P-224 on all platforms and significantly faster for signing on all platforms. On some platforms I think Ed25519 is significantly faster also for verification.

In terms of number of implementation, I think ECDSA with P-256 in is the lead, with ECDSA P-224 as second, and Ed25519 in last place.

I am leaning towards that P-224 should probably be supported (then ES224 need to be standardized in COSE). The other three are already registered for COSE. The harder question is which should be MTI. Several people have stated that latency is of uthermost importance, in case the current choice of Ed25519 as MTI is likely the correct choice.

A good but a little bit dated comparision of different algorithms on ARM processors:
https://datatracker.ietf.org/meeting/92/materials/slides-92-lwig-3

The choice also depends on if there are fast implementations available. Assembly optimized version of the NIST curves is likely as fast or faster than a curve25519 implementation written in C.

https://github.com/kmackay/micro-ecc has very fast implementations (for ARM) of ECDH and ECDSA with secp160r1, secp192r1, secp224r1, secp256r1, and secp256k1. I cannot find anything similar for EdDSA.

Cheers,
John

---

From: Rene Struik <[email-masked]>
Date: Thu, 21 Mar 2019 17:25:03 -0400

Hi John:

A few remarks:
1) Point decompression with the P-224 NIST curve is somewhat harder (due 
to the prime field p=2^224-2^96+1 used). As a result, if one wishes to 
"ship" a compressed point (to save bytes), one needs more complicated 
code for point compression.
2) BSI suggests that the curve should have bit-size at least 250 [1], so 
if one wishes to deploy in regulatory regimes where BSI stamps of 
approval are required one should take that into account.
3) Lots of internet drafts use ECDH or ECDSA with the P-256 NIST curve.
4) Reusing existing high-quality code that has been carefully designed 
to withstand implementation attacks for one curve may allow a more 
economical way of development and maintenance than providing this same 
functionality for multiple curves.

In short: I think venturing off into this direction is not necessarily 
the wisest move.

Best regards, Rene

==

Ref: [1] BSI - Technical Guidance TR-02102-1 (Kryptographishe Verfahren, 
Empfehlungen and Schussellangen (February 22, 2019)

On 3/21/2019 5:08 PM, John Mattsson wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363