Re: [pkix] Question about Curve P-192

Dan Brown <> Fri, 11 May 2018 14:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD5BA12D945 for <>; Fri, 11 May 2018 07:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e-nTkZ6ZctJM for <>; Fri, 11 May 2018 07:23:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A323912D942 for <>; Fri, 11 May 2018 07:23:56 -0700 (PDT)
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2018 10:23:54 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 11 May 2018 10:23:54 -0400
Received: from ([fe80::45d:f4fe:6277:5d1b]) by ([::1]) with mapi id 14.03.0319.002; Fri, 11 May 2018 10:23:53 -0400
From: Dan Brown <>
To: Denis <>
CC: "" <>
Thread-Topic: [pkix] Question about Curve P-192
Thread-Index: AQHT6IFeYuIm9dZtR0OYr6kEQvvxAqQpeaaAgAABjwD//8xYwIAAe0kAgAB2wwCAAFirgP//+7Lg
Date: Fri, 11 May 2018 14:23:52 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000E_01D3E912.276FFC50"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [pkix] Question about Curve P-192
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 May 2018 14:24:01 -0000



Scope: are these question related to IETF or PKIX work?


For Alg IDs, OIDs and ECDSA, see:, Section C.5 and surrounding

Not sure what you mean by “suite”.  You may also be interested in key exchange.


For speed constraints: My belief is that ECC optimizations can range extensively, to the point that they can outdo some expected differences due to small differences in key size.  For example, I recall that NIST P-224 is somehow slow for its size (due to the cost of computing square roots).  Perhaps more effort has been put into optimize P256 in some libraries than in P192, simply because P256 is used more, you may wish to consider that.  Then, of course, there’s Curve25519, which is CFRG approved, and I understand to also have some speed, and also side channel benefits.  Again, I don’t know off-hand how it compares to P-192.  If you haven’t studied these various options carefully, then maybe somebody over at CFRG can help.


For size constraints: ECC is already very small, so I guess these must be severe.  Accordingly, I would suggest considering the various methods that target very low data rates: such as (a) EC point compression, (b) signatures with message recovery, e.g. ECPVS (ANSI X9.92, IEEE 1363a-2004, ISO 15946?), and (c) implicit certificates, e.g. ECQV (SEC4  


Note that ECQV can save a lot a bytes, compared you are traditional certificates.  For example, using point compression and P-256 and ECDSA, a cert would have 32 bytes for the public key and 64 bytes for the ECDSA signature (+/- a few bytes for point encoding and DER, etc.), so 96 bytes for the main crypto part; while a an ECQV cert would have only 32 bytes (for the crypto part).  The basic idea of ECQV is that one reconstructs the public key from the implicit cert and the CA’s public key.  The certificate content part, e.g. name, date, etc., is not directly affected, but the ECQV cert formats intentionally allow the content to be smaller than what is currently typical X.509/PKIX, since other the savings from ECQV would be overwhelmed.  I believe ECQV that has been fielded in some kind of Zigbee-based smart metering devices.  Maybe one day PKIX will adopt this method too.


History and origin of the NIST curves: I believe that the NSA contributed all 15 NIST curves, especially the 10 the “pseudorandom” curves.   Some 5 of the 15 NIST curves, the binary Koblitz curves (such as K-283 and K-571), may have pre-dated other NIST curves, however, because they are determined so simply.  I do recall, that prior to the NIST curves, there were some example curves defined in IPSec and ANSI X9.62. (An example I recall off-hand is K-239, which NIST didn’t recommend, instead opting for K-233.) Maybe some of this history can be found standards like SEC2 (, in discussions about standards alignment, etc..  


I hope that helps,


Best regards,






From: pkix [] On Behalf Of Denis
Sent: Friday, May 11, 2018 6:09 AM
Subject: Re: [pkix] Question about Curve P-192



I don't see how RFC 5480 can be used to obtain an identifier for a cryptographic suite for both P-192 and 
a SHA-256 hash function truncated to 192 bits.

In between, I got a response why the leftmost bits shall be used.

Close to the end of section 6.4 NIST FIPS 186-4 <>  states:

When the length of the output of the hash function is greater than the bit length of n, then the leftmost n bits of the hash function 
output block shall be used in any calculation using the hash function output during the generation or verification of a digital signature.

A hash function that provides a lower security strength than the security strength associated with the bit length of n ordinarily should not 
be used, since this would reduce the security strength of the digital signature process to a level no greater than that provided by the hash function.


Actually see RFC5480.  It describes a set of suggested pairings of signature strengths and hashes and includes recommendations for P-192. 


Re Russ’s comment, the ECDSAWithShaxxx identifiers can be used with any curve, (but follow the 5480 and other similar document pairing recommendations)   so it’s not exactly correct that there are no algorithm identifiers.  


Lastly, AFAICT NIST didn’t originally define the P192 curve - it just incorporated a previously defined curve in a set of acceptable parameters when it was NISTifying EC cryptography.




On Thu, May 10, 2018 at 17:47 Denis < <> > wrote:

Hi Ernst, Russ and Dan,

Thank your for your replies. This is what I feared : there is no cryptographic suite defined for P-192.
Quite strange that NIST defined the algorithm and didn't defined a hash function to go with it.

Key sizes need to be appreciated relative to the environment where they are used.

P-192 would be used in a constrained environment where the size of the digital signature matters (i.e. the smaller, the better).

The verification of the digital signature would be real time. The private key should resist one year, because it would be changed every year. 

P-192 seems to be a good trade-off between the security level and the size of the digital signature.

A SHA-192 function has been defined in a paper available at:
The title of this paper is : Performance Analysis of SHA Algorithms (SHA-1 and SHA-192): A Review 
However, I don't believe that any crypto-library supports it.

So Ernst's method would certainly be one way to do it, but why not take the 192 low bits ?  

The last question would be for Ernst who wrote:

The corresponding signature suite can be defined with ISO 14888-3, which allows the specification of the algo 

(e.g. EC-DSA, EC-KCDSA or whatsoever), the curve and the hash function.

What would the OID or the URI for this suite, if we take the 192 left bits ? Same question if we take the 192 low bits ?


Hi Denis,

 Please, do not use P-192, unless there are some severe constraints.

Even if you credit EC with a very generous 16 extra bits in security (compared to hashes & ciphers), P-192 would only reach 96+16=112-bit security, which does not meet the current best practice of 128 bit security.

 History as I understand it: NIST P-192 was meant for the 80-bit level (though it looks like 96-bit). This low security level has been widely deprecated since 2010, at least informally - to what extent it is formally deprecated, I don’t recall off-hand. I recall added text to ANSI X9.62/63 deprecating this security level.

Anyway, originally, the idea was to use P-192 with SHA-1, P-224 with SHA-224, etc.

I think that there were also OIDs for P-192, e.g. secp192k1, and OIDs for ECDSA-with-SHA1, which could be combined in some ways.  I do not recall how far these OIDs made into IETF, i.e. as algorithm identifiers.

Using 160-bit hash in ECDSA with P-192 renders the EU-CMA security to 80 bits, which is waste considering that P-192 potentially provides 96-bit security.  As noted in the thread below, the standards have options to truncate a longer hash, which should correct this.

 Arguably, the security of P-192 has fared far better than SHA-1 in some ways, yet SHA-1 is probably much more widely used than P-192, though admittedly hashes are considered a general purpose tool.

 Best regards,



From: pkix [] On Behalf Of Russ Housley
Sent: Thursday, May 10, 2018 1:30 PM
To: Ernst G Giessmann  <> <>
Cc: IETF PKIX  <> <>
Subject: Re: [pkix] Question about Curve P-192


 Of course, this technique works.  That said, I am not aware of any algorithm identifiers that make use of the P-192 curve for digital signature or key agreement.


  On May 10, 2018, at 1:24 PM, Ernst G Giessmann < <> > wrote:

Yes, there is a standardized way: 
Pick up a corresponding hash function, in case of P-192 it should be SHA-224 and take the 192 left most bits of the hash value as the input to the EC sign primitive.
The correspondig signature suite can be defined with ISO 14888-3, which allows the specification of the algo (e.g. EC-DSA, EC-KCDSA or whatsoever), the curve and the hash function.
Kind regards,

Am 2018-05-10 um 19:07 schrieb Denis:

Hello everybody,

Curve P-192 is specified in FIPS PUB 186-4 (Digital Signature Standard (DSS)).

There is no "SHA-192" hash function defined in FIPS PUB 180-4 (Secure Hash Standard (SHS)).

Is there any standardized way to use a hash function with Curve P-192 ? 

Is there any RFC or any another document that specifies a cryptographic suite for Curve P-192 ?