Re: [pkix] Question about Curve P-192
Ernst G Giessmann <giessman@informatik.hu-berlin.de> Fri, 11 May 2018 16:34 UTC
Return-Path: <giessman@informatik.hu-berlin.de>
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 3C87612E899 for <pkix@ietfa.amsl.com>; Fri, 11 May 2018 09:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=informatik.hu-berlin.de
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 cOPI8yKDcysX for <pkix@ietfa.amsl.com>; Fri, 11 May 2018 09:34:49 -0700 (PDT)
Received: from mailout1.informatik.hu-berlin.de (mailout1.informatik.hu-berlin.de [141.20.20.101]) (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 1C1E91242F7 for <pkix@ietf.org>; Fri, 11 May 2018 09:34:48 -0700 (PDT)
Received: from mailbox.informatik.hu-berlin.de (mailbox [141.20.20.63]) by mail.informatik.hu-berlin.de (8.15.1/8.15.1/INF-2.0-MA-SOLARIS-2.10-25) with ESMTPS id w4BGYiGI006441 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <pkix@ietf.org>; Fri, 11 May 2018 18:34:46 +0200 (MEST)
Received: from [192.168.2.104] (p2E57CDBE.dip0.t-ipconnect.de [46.87.205.190]) (authenticated bits=0) by mailbox.informatik.hu-berlin.de (8.15.1/8.15.1/INF-2.0-MA-SOLARIS-2.10-AUTH-26-465-587) with ESMTPSA id w4BGYh6h006427 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <pkix@ietf.org>; Fri, 11 May 2018 18:34:44 +0200 (MEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=informatik.hu-berlin.de; s=mailbox; t=1526056484; bh=A59v7mPZ4nPu1dg/kH9rmQs2VQy13gMUNo33EvUT1GQ=; h=Subject:To:References:From:Date:In-Reply-To; b=gngTVsq8bEFyRatWMpZXAn28WxpFd6e9WBisYz7kHevMVVvwuQXz415neGbzKTTDe WVHfFPfuSXJrYexQu/vYljchEG0DO4yOmhP3WaljhgMGs51CnMZS2MFAcumN/m4ihU EKzuQeFvuH0meEWWNGT8CBI5hFqsJ29XHwCcjJn4=
To: 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> <9c321145-0889-bbc1-1a08-c996b139af8f@nthpermutation.com>
From: Ernst G Giessmann <giessman@informatik.hu-berlin.de>
Openpgp: preference=signencrypt
Autocrypt: addr=giessman@informatik.hu-berlin.de; prefer-encrypt=mutual; keydata= xsBNBEs9Ow0BCACmbNqkEfzjXjR9MmVQxUsJVwMNeFNR//ErnstG+Giessmann//XRR+v7Ux HGaFHyzuR1aVPlRqjd7FyGt2RdjoumhVG9neqThI6B7BApKqD+z8XofzBwtmOVog/bQel/CH IbRTlKaoLz6X/5stCnYS9GUj3oqrnIoqr41DpMlipXHAEQstUSNtHa8uTa8zolCtaaKYm2gs A9k2D02M+jJBtOwFZeOfMcStxp+epnA1qygDRgWvCqEc5lyG9pQw8V8ZmGiULjQlUSmjvkNh SN+gKY2vGJcxVuLr64fCDTtCHFHin471n+MvCMdetAnzk869M4vHVyQeYhd2Jx59qc2jABdA AIHNNEVybnN0IEcgR2llc3NtYW5uIDxnaWVzc21hbkBpbmZvcm1hdGlrLmh1LWJlcmxpbi5k ZT7CwLcEEwEIAGECG6MCHgECF4AFCRLV3ecFCwkIBwMFFQgJCgsDFgIBOBpodHRwOi8vd3d3 LmluZm9ybWF0aWsuaHUtYmVybGluLmRlL35naWVzc21hbi9ncGctY3AudHh0BQJWHPUlAhkB AAoJEA4CfLKaaO8dCyQH/1LEsp0hDBMRHdC9wMAuQ0iVDvqHEvw8DZYfKEpuV9wiH4IX05Y9 dt10ldBhA8EUFM149QFkxWNG8h4iYMh9+hCUqLDpfGWTAWsfbcbxV40pDj7wDz2+HMsGZhHh e5CKCdURaIsvrYjCbLx6M5jCIfPB6xdQwOrZPvE9sq5VfgnJIrg0HRxUcrAEdnX4Gi6H9aAl KL/PxuDGI1oV67o/kJxjmUWmD3oaFq6KYj3vCZC4veuXZ1pTkZQbvOyWsJKzrP8SQ1AoWwVW EHvhr2YzvjUxfcB/WBlZ7hVisdiA7Bkc/5j+1S9eEyJYdY4GS/7hM7Aq0G+3iobpZ+Zjj3ya iY/OwEUES0caowEHwLbbq4iyK9yYgnSnyHWzeFmRdY1P86xaCv9cKVbwM01DSF6Gfd2xzE2J AJOhq+mSpF9Ay6ZEK6FShilupXT2rV42ciWZZNDCy/GNt7hEZ4oqK5UgZJwwNkL3gIRLQcGE a3BzDfOA5G8nxuCb7KMW3kc78Qy5CvxtsrlYiBPtKbLALP/DIzOm6UzcsMHvSnKtQJgPIdvP yxZQ3/I7AAqkSXWFTo8cUm715Y7HdakHEskTvu6dQq8GIEllGjFer44GNKXhKEFJanXrU9K9 Na7WzY610YkhHQGKMh/cm3bM7lOs7UDAPWquvN/Yatq83FXFts+iCxqUKf8TABEBAAHCwF8E GAEIAAkFAktHGqMCGwwACgkQDgJ8sppo7x02mwgAov9Gq53uvZG00fEykqUVtTD9ZV1ZJo3d kYuWeVjH+sqAflgsQHZV+3rBpvr8LgE9oPQT+BGLtTDX9tu+qHLIwdt/9BVHaqQ5BRYS23KP 4vM6N+12Dn1TIGppf0JG0lyrBU6plhJQofWX4in82g/SU7+d+gXaN26bT25EhA6g8cy6hPsh PsPB1wnVRGRSoYP1BXq6JPegZd0maTIIJRGbkSSxcbQidujbx35y4eQ1XQ74OlcOB6mNrX3f go3mC69o1CpclASjlX1/+bguBFR34oJth/IW9tMS7pYiEPfALHOW824B88AqtXtVTeHfAp78 8zKwT6Twt21WzoZ5hYJ+oA==
Message-ID: <ca000134-0c57-63d0-3f4b-715b62229d93@informatik.hu-berlin.de>
Date: Fri, 11 May 2018 18:34:42 +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: <9c321145-0889-bbc1-1a08-c996b139af8f@nthpermutation.com>
Content-Type: multipart/alternative; boundary="------------8D3C7AF0639FF864EA0B3610"
X-Virus-Scanned: clamav-milter 0.99.2 at mailbox
X-Virus-Status: Clean
X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.6.1 (mail.informatik.hu-berlin.de [141.20.20.50]); Fri, 11 May 2018 18:34:46 +0200 (MEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/GgB5RJ304WqLJ9SjUNuuFkOQMps>
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 16:34:52 -0000
Denis, you are right, the signature value is tagged with the OID ecdsa-with-... This gives the signature suite identifier. The key used for signing is tagged with the curve (e.g. P-192). But due to the truncation it makes no sense to use a SHA-512 with P-192 or P-256. /Ernst. Am 2018-05-11 um 18:12 schrieb Michael StJohns: > On 5/11/2018 6:09 AM, Denis wrote: >> 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. > > Well - suite's don't have identifiers, algorithms (signature schemes) > do. In this case, 5480 says that any of the ECDSAwithSHA1, SHA224, > SHA256, SHA384 and SHA512 signature algorithms can be used with > secp192r1 (which is the same as P-192 - see page 18 of this document) > and will provide no less than 80 bits of security. that's from the > table on page 9. > > The table on page 10 even gives a recommended signature function - > ECDSAwithSHA256 - for secp192r1. > > And finally, the identifier for that signature scheme is on page 17 > > ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) > ecdsa-with-SHA2(3) 2 } > 1.2.840.10045.4.3.2 > >> >> 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. >> > > All of ANSI X9.63, NIST 186-4 and SECG 1 describe the conversion of a > hash value (a string of octets output from the hash) to a positive big > integer of an appropriate size which is used as the input to the ECDSA > calculations. This is all mostly hidden under the covers of the > implementations, and a proper implementation should do the left > truncation silently if necessary and produce the correct result > regardless of the input curve of the private key. I checked the java > EC implementation and bouncycastle's implementation and both have code > that does this. > > Later, Mike > >> 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 >>>> >>>> >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix
- [pkix] Question about Curve P-192 Denis
- Re: [pkix] Question about Curve P-192 Ernst G Giessmann
- Re: [pkix] Question about Curve P-192 Russ Housley
- Re: [pkix] Question about Curve P-192 Dan Brown
- Re: [pkix] Question about Curve P-192 Denis
- Re: [pkix] Question about Curve P-192 Michael StJohns
- Re: [pkix] Question about Curve P-192 Denis
- Re: [pkix] Question about Curve P-192 Dan Brown
- Re: [pkix] Question about Curve P-192 Denis
- Re: [pkix] Question about Curve P-192 Dan Brown
- Re: [pkix] Question about Curve P-192 Ernst G Giessmann
- Re: [pkix] Question about Curve P-192 Michael StJohns
- Re: [pkix] Question about Curve P-192 Ernst G Giessmann