Re: [pkix] Question about Curve P-192

Denis <denis.ietf@free.fr> Fri, 11 May 2018 15:31 UTC

Return-Path: <denis.ietf@free.fr>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45C212E897 for <pkix@ietfa.amsl.com>; Fri, 11 May 2018 08:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.22
X-Spam-Level:
X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no 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 WtzUi2n5QbnL for <pkix@ietfa.amsl.com>; Fri, 11 May 2018 08:31:41 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 069FF12E896 for <pkix@ietf.org>; Fri, 11 May 2018 08:31:41 -0700 (PDT)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 231AF7803B5 for <pkix@ietf.org>; Fri, 11 May 2018 17:31:38 +0200 (CEST)
Cc: "pkix@ietf.org" <pkix@ietf.org>
References: <5481b2bb-25cc-6d1f-d255-16403f2221de@free.fr> <38461622-c7e9-58f4-acd2-5451c37408ba@informatik.hu-berlin.de> <9721F6F1-BA0F-4A86-A1C9-7910003D00E8@vigilsec.com> <810C31990B57ED40B2062BA10D43FBF501C71CBD@XMB116CNC.rim.net> <77eb0920-c6a2-2697-46d0-b0ab0366d9da@free.fr> <CANeU+ZDJYqGJZrVk2GzfJ-TZYc+=ptqj1-+8Ko0s3TvK_jHLhw@mail.gmail.com> <689887b5-b034-5c4c-648c-3854321ce2c7@free.fr> <810C31990B57ED40B2062BA10D43FBF501C71FA3@XMB116CNC.rim.net>
From: Denis <denis.ietf@free.fr>
Message-ID: <50be6a00-0067-7e3e-c9c7-495e01a58ed9@free.fr>
Date: Fri, 11 May 2018 17:31:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501C71FA3@XMB116CNC.rim.net>
Content-Type: multipart/alternative; boundary="------------E40B0041BD18A97017229DFE"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/ZJvf50AoN2p54EJaN9oQygUsGR0>
Subject: Re: [pkix] Question about Curve P-192
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 May 2018 15:31:45 -0000

Dan,
>
> Denis,
>
> Scope: are these question related to IETF or PKIX work?
>
It can't be related to PKIX work which is currently at a stand still.
>
> For Alg IDs, OIDs and ECDSA, see:
>
> https://tools.ietf.org/html/rfc5758#section-3.2
>
> http://www.secg.org/sec1-v2.pdf, Section C.5 and surrounding
>
> Not sure what you mean by “suite”.
>
A suite is a one-way hash function plus an asymmetric signature 
algorithm (or the reverse).
In the references you mentioned, there is indeed: "ecdsa-with-SHA224" 
but there is not "ecdsa-with-SHA192".
>
> You may also be interested in key exchange.
>
This is not the case.
>
> For speed constraints:
>
In the environment I am considering, there are no speed constraints, but 
very severe constraints for the size of the digital signature.

The additional information you provided may be interesting for some 
other people on the list.

Thank you.

Denis

> 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 http://www.secg.org/sec4-1.0.pdf).
>
> 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 
> (http://www.secg.org/sec2-v2.pdf), in discussions about standards 
> alignment, etc..
>
> I hope that helps,
>
> Best regards,
>
> Dan
>
> *From:*pkix [mailto:pkix-bounces@ietf.org] *On Behalf Of *Denis
> *Sent:* Friday, May 11, 2018 6:09 AM
> *Cc:* pkix@ietf.org
> *Subject:* Re: [pkix] Question about Curve P-192
>
> Michael,
>
> 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.4NIST FIPS 186-4 
> <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf> 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.
>
> Denis
>
>     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.
>
>     Mike
>
>     On Thu, May 10, 2018 at 17:47 Denis <denis.ietf@free.fr
>     <mailto:denis.ietf@free.fr>> 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:
>         http://www.ijctee.org/files/VOLUME2ISSUE3/IJCTEE_0612_24.pdf.
>         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 ?
>
>
>
>         Denis
>
>             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,
>
>             Dan
>
>             *From:* pkix [mailto:pkix-bounces@ietf.org] *On Behalf Of
>             *Russ Housley
>             *Sent:* Thursday, May 10, 2018 1:30 PM
>             *To:* Ernst G Giessmann <giessman@informatik.hu-berlin.de>;
>             <mailto:giessman@informatik.hu-berlin.de>
>             *Cc:* IETF PKIX <pkix@ietf.org>; <mailto:pkix@ietf.org>
>             *Subject:* Re: [pkix] Question about Curve P-192
>
>              Ernst:
>
>              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.
>
>              Russ
>
>             On May 10, 2018, at 1:24 PM, Ernst G Giessmann
>             <giessman@informatik.hu-berlin.de
>             <mailto:giessman@informatik.hu-berlin.de>> 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,
>                 /Ernst.
>
>                 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 ?
>
>                     Denis
>