From nobody Thu May 10 10:07:19 2018 Return-Path: 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 9656B12D88D for ; Thu, 10 May 2018 10:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 7ztuKAdpnjvP for ; Thu, 10 May 2018 10:07:15 -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 B6DE4124B17 for ; Thu, 10 May 2018 10:07:15 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0F19F7803BB for ; Thu, 10 May 2018 19:07:13 +0200 (CEST) To: pkix From: Denis Message-ID: <5481b2bb-25cc-6d1f-d255-16403f2221de@free.fr> Date: Thu, 10 May 2018 19:07:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C67B0685E4A59DBA892F7F8D" Content-Language: en-US Archived-At: Subject: [pkix] Question about Curve P-192 X-BeenThere: pkix@ietf.org 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: Thu, 10 May 2018 17:07:17 -0000 This is a multi-part message in MIME format. --------------C67B0685E4A59DBA892F7F8D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------C67B0685E4A59DBA892F7F8D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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

 


--------------C67B0685E4A59DBA892F7F8D-- From nobody Thu May 10 10:25:04 2018 Return-Path: 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 6134D12D95E for ; Thu, 10 May 2018 10:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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, URIBL_BLOCKED=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 hTKVZN4UOt1k for ; Thu, 10 May 2018 10:25:01 -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 2C4B012DA25 for ; Thu, 10 May 2018 10:25:00 -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 w4AHOuon010200 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 10 May 2018 19:24:57 +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 w4AHOrYU010196 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 May 2018 19:24:55 +0200 (MEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=informatik.hu-berlin.de; s=mailbox; t=1525973096; bh=e2HBdoGEAR2lkvBBjy4IRKOG/G01JM+x58SSKV9qGcE=; h=Subject:To:References:From:Date:In-Reply-To; b=Iw1GS1h6Hx9M2gw8/IAx1DjCRusAOekKTeBjvWdokpWs6n5SRGDYMzJK0hbWuG2/K MSQ/luZFQ0cwIQW5JveulQvAvW2T9W20AtXOalVFlWtDAzQs+xkIGsqhR+Acru4A/f JD22779VsYhG2K8NYbooaFr1iXdcWOuNlK+p45FE= To: pkix@ietf.org References: <5481b2bb-25cc-6d1f-d255-16403f2221de@free.fr> From: Ernst G Giessmann 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: <38461622-c7e9-58f4-acd2-5451c37408ba@informatik.hu-berlin.de> Date: Thu, 10 May 2018 19:24:51 +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: <5481b2bb-25cc-6d1f-d255-16403f2221de@free.fr> Content-Type: multipart/alternative; boundary="------------E90A4F5B0BA3425D675D7188" 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]); Thu, 10 May 2018 19:24:57 +0200 (MEST) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 17:25:03 -0000 This is a multi-part message in MIME format. --------------E90A4F5B0BA3425D675D7188 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 --------------E90A4F5B0BA3425D675D7188 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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

--------------E90A4F5B0BA3425D675D7188-- From nobody Thu May 10 10:30:35 2018 Return-Path: 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 1EDFB12DA46 for ; Thu, 10 May 2018 10:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham 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 t9W5v808ZW4r for ; Thu, 10 May 2018 10:30:31 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C7312D95E for ; Thu, 10 May 2018 10:30:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C678A300A07 for ; Thu, 10 May 2018 13:30:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ef749Gbap2XQ for ; Thu, 10 May 2018 13:30:27 -0400 (EDT) Received: from [5.5.33.84] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id B361A30042A; Thu, 10 May 2018 13:30:26 -0400 (EDT) From: Russ Housley Message-Id: <9721F6F1-BA0F-4A86-A1C9-7910003D00E8@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E8A31CD3-6DAD-42AA-ABD2-B962D9858C9B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 10 May 2018 13:30:26 -0400 In-Reply-To: <38461622-c7e9-58f4-acd2-5451c37408ba@informatik.hu-berlin.de> Cc: IETF PKIX To: Ernst G Giessmann References: <5481b2bb-25cc-6d1f-d255-16403f2221de@free.fr> <38461622-c7e9-58f4-acd2-5451c37408ba@informatik.hu-berlin.de> X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 17:30:33 -0000 --Apple-Mail=_E8A31CD3-6DAD-42AA-ABD2-B962D9858C9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 = wrote: >=20 > Yes, there is a standardized way:=20 > 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. >=20 > Am 2018-05-10 um 19:07 schrieb Denis: >> Hello everybody, >>=20 >> Curve P-192 is specified in FIPS PUB 186-4 (Digital Signature = Standard (DSS)). >>=20 >> There is no "SHA-192" hash function defined in FIPS PUB 180-4 (Secure = Hash Standard (SHS)). >>=20 >> Is there any standardized way to use a hash function with Curve P-192 = ?=20 >>=20 >> Is there any RFC or any another document that specifies a = cryptographic suite for Curve P-192 ? >>=20 >> Denis >>=20 >> =20 >>=20 >>=20 >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix = >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail=_E8A31CD3-6DAD-42AA-ABD2-B962D9858C9B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii 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> 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

--Apple-Mail=_E8A31CD3-6DAD-42AA-ABD2-B962D9858C9B-- From nobody Thu May 10 11:51:08 2018 Return-Path: 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 0D58912EB82 for ; Thu, 10 May 2018 11:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 E7LJrbUihhF4 for ; Thu, 10 May 2018 11:51:03 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (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 3BC98127077 for ; Thu, 10 May 2018 11:51:03 -0700 (PDT) X-Spoof: Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs211cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 May 2018 14:51:02 -0400 Received: from XCT196YKF.rim.net (10.2.25.4) by XCT101CNC.rim.net (10.65.161.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 10 May 2018 14:51:01 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT196YKF.rim.net ([fe80::a15e:e4be:7302:3372%12]) with mapi id 14.03.0319.002; Thu, 10 May 2018 14:51:01 -0400 From: Dan Brown To: Russ Housley , Ernst G Giessmann CC: IETF PKIX Thread-Topic: [pkix] Question about Curve P-192 Thread-Index: AQHT6IFeYuIm9dZtR0OYr6kEQvvxAqQpeaaAgAABjwD//8xYwA== Date: Thu, 10 May 2018 18:51:00 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501C71CBD@XMB116CNC.rim.net> References: <5481b2bb-25cc-6d1f-d255-16403f2221de@free.fr> <38461622-c7e9-58f4-acd2-5451c37408ba@informatik.hu-berlin.de> <9721F6F1-BA0F-4A86-A1C9-7910003D00E8@vigilsec.com> In-Reply-To: <9721F6F1-BA0F-4A86-A1C9-7910003D00E8@vigilsec.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005E_01D3E86E.4F54CB00" MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 18:51:06 -0000 ------=_NextPart_000_005E_01D3E86E.4F54CB00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_005F_01D3E86E.4F54CB00" ------=_NextPart_001_005F_01D3E86E.4F54CB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 Cc: IETF PKIX 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 > 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 ------=_NextPart_001_005F_01D3E86E.4F54CB00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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=3D112-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>
Cc: = IETF PKIX <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-b= erlin.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

 

------=_NextPart_001_005F_01D3E86E.4F54CB00-- ------=_NextPart_000_005E_01D3E86E.4F54CB00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIh1TCCBckw ggOxoAMCAQICBQD2V+DAMA0GCSqGSIb3DQEBDQUAMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJC bGFja0JlcnJ5IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAq BgNVBAMMI0JsYWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMB4XDTEzMTIxMzE3NDU0 N1oXDTM4MTIxMzE3NDU0N1owfDELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkgTGlt aXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEsMCoGA1UEAwwjQmxhY2tC ZXJyeSBFbnRlcnByaXNlIFJTQSBSb290IENBIDEwggIgMA0GCSqGSIb3DQEBAQUAA4ICDQAwggII AoICAQDGRcB/8QfFrWiS6iI+cqEd5oN9JFerfmDskffgyqIzZzEywv5Yx7/zv3YMsQB7kuYUtRGa uQGKrCDOSul6MXVYFRqqszScZKTFN873LBcUcpmcrbDLET6410g3krO7OKMQUmmcfFql0mCTxWay BKef7BPJEXwn/YOxopXtQ9g2SgYZm0KCAjoOH3Yb0BQrNkFKN9plF/BK0S/brBWAzwKKpJo7YW7B iuK75OjTfIM2ILRc5oZs8vI8B3IltjvUG53dFATXByJBXScvBefIIGYMrXbs2SN17BjicAVNW4pp NUKoB0YpGjmJ3LClIeSdnLTUC84k268v8GQ302/2d+V6VKaXlMk2F9JraENGYe+vT4mez4Co5ELZ aW8LJtEYeSZOOlgssychWms0FY8IIToH9Fqgu9xO8N5TAFWipjMtJ8tPqMChdVwkz5dP3jxPMCAI pwmDii6mCIy1jIv+iS1qMluemIu1FneNFfaESBFby0llyS+XG2sEbFAthY1V7jw50GFs2c5sHIY3 ajT8YC21+Qzxat2OcI2/lhnV3V5k+oImJxDswvjFHNQ/APW7ti+B1VEWJ0HcKzEz2eeWdqYxhZAh XmdS7Ir/U1ROIASEYFg6wt56aC8/PjVOyMRG6NvMdyPwwzfMx3CFavzoOnXb3YL9vDI2AyY59WCw edlGcQIBA6NUMFIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFPhp ifhjnu9oXoEwYnBSow7dspYIMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBDQUAA4ICAQCs FUaj+ZL3/7JbMYjTdp7mixMW3e/ZpxBWPU6upIAFlBdN05eMkvfVDhAkAFmXCWXMp4iUWd7dz3Kf f2LdAyGhKOqSfg2Ns+MqKLLM4ugjQ8arlRNC2kabtf8RpeRxgMWGsgecZ8L12YHlZ67AzBd+YrBS 2Is+GC2CMYGqTFI6IUVsFQGIsaz+a4TghhsokY8qqKU4Eul4rUrKnzNciskstDTPOQrpORDHpFQt D6nHeB5LlRaSuwVcIcr/H28HEffXc7tFXu+/C3Y6lzQcXD0vMXnSOJ7/CrH0cPe2bQaC+oMBpu2V qjVXWZ8umTyT6etZ3nz1llIeZAxUW/MROetLQFLjBmywiY5EBu/q1UIdlJ/qC7VcCmfExowfLyqY v2V+ShNrEXtzHPPCuPk/j1eP6fg1lP3kbJg0ChTcCEAWtBX4foFcVM4c1f8Au5thaDnH7G4kWL7s dNxoKNnONIYtYbeSKWqfomRPbb2OBgKXM3wTKV6Ze/fLPW9WNdtNFk0Mr0b+nUmPZLGUEL+ZMG95 0BNuQgxWblbOXxwTesin4D2Vn5tL0J9XHk62EdDFefR+5UJqRanhr4pOxO0WWpu1Ux6x1xRDW4yT xNqnXVfjduQDJfbmXvp6PG5UJlhlo7FkW3rz1tWpEWHgOPJ9qAJG7rl5CA67TXdpmIBzbyJYITCC B0kwggYxoAMCAQICClZxDY0AAAACH3EwDQYJKoZIhvcNAQELBQAwVjETMBEGCgmSJomT8ixkARkW A25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEqMCgGA1UEAxMhQmxhY2tCZXJyeSBDb3Jwb3JhdGUg SXNzdWluZyBDQSAxMB4XDTE4MDIwODE5MjQwMVoXDTE5MDIwODE5MjQwMVowgakxEzARBgoJkiaJ k/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsT AkNBMRQwEgYDVQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBC cm93bjEnMCUGCSqGSIb3DQEJARYYZGFuaWJyb3duQGJsYWNrYmVycnkuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAohJqrR7zCc/JYInUzai/eVD0K2w8BxWQp42YEU4kNA1sCBCJ BI4/7pNSTAnJTG0yMSoyuBbP8mky6PDlo5PYnCCtXmWha8lJBUuAJ9OHzJwDP9ScBCeCam2MQ2Yu rxW52026C/V93IWR8hEY5YEN0ikdCQU+aYMsLXGnt50z4+Kxq0xcPN54N8IsdY7Fa17x/GzV/Dlv vAMlQDPkAAEwNI96az0Wr0YEvZLgAnuwZH9tnWzsO28M4W0r9x+wPRYkSlsavJF2t5UNCA8ZD5Yy b7+NwLKlmfWEQ2fjwT7yl0RsfkF1sOHNdd51ymmO7GSh4X4L7QHOenRA+hYF4LT6GwIDAQABo4ID wzCCA78wPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIh7+XS4a5gSSGwYEyg9vyJYLc2AGBALHD Koef9EACAWQCAQcwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAw TwYDVR0gAQH/BEUwQzBBBgorBgEEAZtKEwECMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0u bmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wJwYJKwYBBAGCNxUKBBowGDAKBggrBgEFBQcDBDAKBggr BgEFBQcDAjALBgNVHQ8EBAMCBsAwHQYDVR0OBBYEFL/Dm4ZZ67qzpYa3/pf8WhtppWOtMB8GA1Ud IwQYMBaAFBovS0vbB8lJO4nWMggnop4L8w9rMIIBMgYDVR0fBIIBKTCCASUwggEhoIIBHaCCARmG QGh0dHA6Ly9jcmwucmltLm5ldC9CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWluZyUyMENB JTIwMS5jcmyGgdRsZGFwOi8vL0NOPUJsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBJc3N1aW5nJTIw Q0ElMjAxLENOPU1DQTAxMENOQyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAQMG CCsGAQUFBwEBBIH2MIHzMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwgcoG CCsGAQUFBzAChoG9bGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWluZyUy MENBJTIwMSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmpl Y3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5ME0GA1UdEQRGMESgKAYKKwYBBAGCNxQCA6Aa DBhkYW5pYnJvd25AYmxhY2tiZXJyeS5jb22BGGRhbmlicm93bkBibGFja2JlcnJ5LmNvbTANBgkq hkiG9w0BAQsFAAOCAQEAyAMjuNH2sn+U8uhj30d48XfUYSaIR1Z/nGgiJcMbREyoP1H9lIM9jYrL GjzUQ7IIT7xRfRfV8aEKec3gL9xPqyhMaAXv1TiQnG8Xo7d1pHyh9gZRXdv/khGyTNd2Y/4Pf100 cg+INLDZfFnuQ/r/x9yBZqrM9d612GLtrBC/MEnJmxwL+SrcdLO7GT4w4uzeyzTUe32+WM6dlu9O h+8c4c+wTlBU5D6HDN8L5mDgYkBSv5ok8FjsK0hp9ggb2skeXZrdTeiOnHJDvmfYp5BXHBFPyivz hcfYja7P8wUTSKivxVVNTGBLXBhGvj2xTiEblt5lzmCq0aVecHUnP9/cvzCCCAUwggXtoAMCAQIC BEMVWF8wDQYJKoZIhvcNAQENBQAwfDELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkg TGltaXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEsMCoGA1UEAwwjQmxh Y2tCZXJyeSBFbnRlcnByaXNlIFJTQSBSb290IENBIDEwHhcNMTQwMjI2MTYyMzU2WhcNMjQwMjI2 MTYyMzU2WjB5MQswCQYDVQQGEwJDQTEbMBkGA1UECgwSQmxhY2tCZXJyeSBMaW1pdGVkMSIwIAYD VQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJMSkwJwYDVQQDDCBCbGFja0JlcnJ5IENvcnBv cmF0ZSBQb2xpY3kgQ0EgMTCCAiAwDQYJKoZIhvcNAQEBBQADggINADCCAggCggIBALom9kCQ+lPa 4g4nzDj+EFbwiF3CYO2/MwRWadgSaavVydBoPc1VIjEN80UbZ1VV5kkHiqYvAuSMx/R2AOgu1o9F qpnaRb59a4R5aobixHEIhYyCt2mmRCgJ6dYYiJbtDn1t00uT0yyI/YU+AUxWFK9c3fy+X20ASyxA ObA9Wev2cFsGFbg6dozYkPDQHlgSczJcEnCyUD6fhgM5N/NsgHmvN3OQb8LL5Kzs204QgbUd966v lHOu6ppVEg2xuTzzhPVONHirYEyFMTa5KNoA1eSX4gzVix+YiAKP8AqvgqEQB4zi2jXSYDzd9RUt nOflg+jz+OKTNDSpOB7/tiPa959++RiRYbWlkYm+Wh+X9uL/ra+uatOTH2UMosyXnO4ryoXOe9JZ WGe0awdY7Rkj65LPmHsCWvR05N1M6vX5JHZLOov65F7J/ZWLLCIAR/sm1mPhBTauU3uvE6JK5/ub PQPxF6UDpNdoaUB7+rfmSoBxyIlmMy6A7v5cbZyHONyLlz+r4sklPDPcz5CBIjbUyFNzK0KK0GXR YVKD++YTbqdCe6vKFZSg2+vIYQ/bFqtp7+gKIpmjjWdzotxVcKgl+r+kTk4pSECLU39Efbo50Nve Q6N0N0sgpj/JVOF53XMRKy4JQ2SDL0A+PkuBL3mdIb+hD0uUsvmDhhB3xavB0UhlAgEDo4ICkjCC Ao4wEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFDu4wXcNnq1D WPwlrhXQt/KRMoWbMB8GA1UdIwQYMBaAFPhpifhjnu9oXoEwYnBSow7dspYIMIGGBggrBgEFBQcB AQR6MHgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnJpbS5uZXQvb2NzcDBQBggrBgEFBQcwAoZE aHR0cDovL2NydC5yaW0ubmV0L0JsYWNrQmVycnklMjBFbnRlcnByaXNlJTIwUlNBJTIwUm9vdCUy MENBJTIwMS5jcnQwggE3BgNVHR8EggEuMIIBKjCCASagggEioIIBHoZEaHR0cDovL2NybC5yaW0u bmV0L0JsYWNrQmVycnklMjBFbnRlcnByaXNlJTIwUlNBJTIwUm9vdCUyMENBJTIwMS5jcmyGgdVs ZGFwOi8vL0NOPUJsYWNrQmVycnklMjBFbnRlcnByaXNlJTIwUlNBJTIwUm9vdCUyMENBJTIwMSxD Tj1Sb290Q0EsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENO PUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25M aXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwNwYDVR0gBDAwLjAsBgRV HSAAMCQwIgYIKwYBBQUHAgEWFmh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy8wEAYJKwYBBAGCNxUBBAMC AQAwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwDQYJKoZIhvcNAQENBQADggIBALfxM34RYrFM 8E5/7K7T54kPvkcjQrX9Vtf7+CTHHG2EH7SuFoFWsnNTeP+J8TxJP0hxz4mA5FnMKNlhTPsuP0Nu /Fu1R1okaLsIeOPGAWbtpCQ9fYG+lgeONh5DTfj1uhrLDDUAbqJfjYX8ab4/j9RPgm/mWjlR6nMz PyaCc6cASqnOjs0VSLFdmctNMwvqDwKj4qnCX+AM61Nxd2K3ZITiq6BQIj37hQh07lwgVQra+S56 /cmyO5QKXSnyD/n3U/IPEhShFa30j7yeR4OZ2Gv8vK6HY5jzY5eoJztN089F0l2jSdYIlm47E+sr Vwk88z8UwzsTBKu5LWYVsywfJdyZQF1+bwu52Q8c+mzMaVDZwBwQ3ODIYJ3Y5aWCCmn7Lfkkij14 qcsLkEaKjp6ejoy980wzkPMivmGhV8uxslS+UgjA5qqFZY8iOJAmBLy8ABkE42HoBdezxMCya7TK 3ZxKnTQe9RYDImLx45VQ6K75/uJddTD7GERw7KCCjgmYniD6ozzDPHylziygpUzHhItdeVH+47dE 1nlk1pVzf6oiqDgRuEY1DHIIYKEVh6Zi9F0uaOo7SwZ+h9hqpF2EgGkpliTu8M7CPRlK3OBNPnk4 BgXSNj4D1FdKK7rGbTgXcL/YbtLX2weWErbw+uN/UCG7k3BOelop0zlSJfj9KsotMIIMrjCCCpag AwIBAgIECxEcnDANBgkqhkiG9w0BAQsFADB5MQswCQYDVQQGEwJDQTEbMBkGA1UECgwSQmxhY2tC ZXJyeSBMaW1pdGVkMSIwIAYDVQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJMSkwJwYDVQQD DCBCbGFja0JlcnJ5IENvcnBvcmF0ZSBQb2xpY3kgQ0EgMTAeFw0xNDA0MTcxODA4MjVaFw0xOTA0 MTcxODA4MjVaMFYxEzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAo BgNVBAMTIUJsYWNrQmVycnkgQ29ycG9yYXRlIElzc3VpbmcgQ0EgMTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANUcv8oSAXw3NNOhPMafhnN2N+8xE31gbXNo+R6TBeuSdZEo5PDfR+PD ps/sIXrSecnAZJWGhDUOQ2pXPRk8jfl0lbcQERTI1UC04Zv5+I2YOw4qTaBt77PAtvW22s3sE6Ag O6okqW6NQFjEGToKXjgo6grBLO6/G4Uc/tPqh6/bcmH4NmaSbszrSJUsPMeNyEWu7r3orxu9KJzM nDQBWpbKZq6l4W96mut0lTPXL8bRDQah5nc0UfRrMzwlLowHtLPXM7/1J2XG+tG7SYIQ3wQ6BRN8 bWXWwMguzsiEz2BQEX60cml4Vz7G5IenHuymRHOERKa4UPiH7oggn8HtKh8CAwEAAaOCCF8wgghb MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaL0tL2wfJSTuJ 1jIIJ6KeC/MPazAfBgNVHSMEGDAWgBQ7uMF3DZ6tQ1j8Ja4V0LfykTKFmzCBgQYIKwYBBQUHAQEE dTBzMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwSwYIKwYBBQUHMAKGP2h0 dHA6Ly9jcnQucmltLm5ldC9CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwUG9saWN5JTIwQ0ElMjAx LmNydDCCASwGA1UdHwSCASMwggEfMIIBG6CCARegggEThj9odHRwOi8vY3JsLnJpbS5uZXQvQmxh Y2tCZXJyeSUyMENvcnBvcmF0ZSUyMFBvbGljeSUyMENBJTIwMS5jcmyGgc9sZGFwOi8vL0NOPUJs YWNrQmVycnklMjBDb3Jwb3JhdGUlMjBQb2xpY3klMjBDQSUyMDEsQ049U3ViQ0EsQ049Q0RQLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwggYSBgNVHSAEggYJMIIGBTBBBgorBgEEAZtKFAIBMDMw MQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYB BAGbShMBAzAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQu aHRtMEEGCisGAQQBm0oTAQIwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQ U3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0u bmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMCAzAzMDEGCCsGAQUFBwIBFiVodHRw Oi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTAgIwMzAxBggrBgEF BQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwIB MDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYK KwYBBAGbShMDAzAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1l bnQuaHRtMEEGCisGAQQBm0oTAwIwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3Bz L0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwMBMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5y aW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMEADAzMDEGCCsGAQUFBwIBFiVo dHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBQMwMzAxBggr BgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtK EwUCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0w QQYKKwYBBAGbShMFATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0 ZW1lbnQuaHRtMEEGCisGAQQBm0oTBgMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQv Y3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwYCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9j cC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMGATAzMDEGCCsGAQUFBwIB FiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBwMwMzAx BggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEE AZtKEwcCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5o dG0wQQYKKwYBBAGbShMHATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BT dGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTCAMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5u ZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwgCMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMIATAzMDEGCCsGAQUF BwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMBAGCSsGAQQBgjcVAQQD AgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUAA4ICAQAeVuw/L3Zy FbBCOhKq5sL9OrBp4G1j4r6C2WJN2BuAoN4fOdzw7H27Y60d8otCRquP8G/AvQ43dJCsE7kld10v tOs2L4T17T3OHxVoMEU39zoIjgu3x7pVUWNf6HCd3QDwWbQZrLIpPWh4ipvIRipQlizCBfDxmbsJ H/BBiiWl5RC7fnWHbEfdbbHPDWyZ/9CsM2XpGdMgYg82LXWBUzGbKSwtoya0wHEEMlhM9D5MaQkm DmYwJOI9m+ryyZMnYYo28ZvW6khFl/Frd/Y77aSOIgtNTXQ+S86xW4PBJJ1jqoal1xt4jYrWWRBE 0wvpZygMoRFCRMsBGvr/r5rqZ9QcN+OX3tmUOC2rtqH9qQKzABJCDetqB16Oyynx1cvUN/x3p1LM Cd3YcqE4ppRxwvX+377msqZamYjHRMuwM1I2RpuVbMdbEwTIHeb17WgRmHkRWF1yKf1XRxN9ywp0 BzkK0tBvN+yMjJSXiZITYAb0U6WxrtEHWdr1CyJPuSrUzwkx0NdCrImlvwo6froM5h3crRXhUgkm +eNPZhiZ2cBG2OaOX8XKUtounkbqVEbblUy1tLIaxUwYw2j+BcKWrbQsoW798S37b7hJWVVE048I gOfRemUiP7yZ5nh0+SQ6+jTVRaWAba8nawivkrv0ja/k1QwzZD9p7nUSvmizKhbCYzGCAiwwggIo AgEBMGQwVjETMBEGCgmSJomT8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEqMCgGA1UE AxMhQmxhY2tCZXJyeSBDb3Jwb3JhdGUgSXNzdWluZyBDQSAxAgpWcQ2NAAAAAh9xMAkGBSsOAwIa BQCggZ4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwNTEwMTg1 MDU5WjAjBgkqhkiG9w0BCQQxFgQUyWvwCVYSx3DAD5VEFL/lVnvYB6cwPwYJKoZIhvcNAQkPMTIw MDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG 9w0BAQEFAASCAQArFTnZkNxq7sFBOdh1fhBR8/t/EgMFHioA9TasE7AluG9SBJKH7A9d2NCQzKm8 LjBxv2qNoEL6IAl4jnm2g/6WztHdUJGo8rrIg/v/v2XUlYe/l3J6LhD6wguzwHWEaWu4rFVXZhVW QTTb/q0IWN6dQ6RokKdNSrHdBq4QkGKJpuR8rVxBIw7zXS3/VDUHtdtBimtB7ItceXBuJ05nok1c tpBxIkGCVtzlemaWbkcN8ycLpetd6bYLeW1lw+KQGI0rS0wLnShp2orF4vmZNac44mQmXC/O/4aa yaMeN1h+htEY6v8jh1P5dfq6rm2sq6aV2U7WVv8stnw/movKQmLzAAAAAAAA ------=_NextPart_000_005E_01D3E86E.4F54CB00-- From nobody Thu May 10 14:46:54 2018 Return-Path: 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 CC14C12E035 for ; Thu, 10 May 2018 14:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham 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 geGrCjpVpUyJ for ; Thu, 10 May 2018 14:46:49 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 700B912D94D for ; Thu, 10 May 2018 14:46:49 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id A7B74780310 for ; Thu, 10 May 2018 23:46:47 +0200 (CEST) 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> From: Denis Message-ID: <77eb0920-c6a2-2697-46d0-b0ab0366d9da@free.fr> Date: Thu, 10 May 2018 23:46:48 +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: <810C31990B57ED40B2062BA10D43FBF501C71CBD@XMB116CNC.rim.net> Content-Type: multipart/alternative; boundary="------------FA2C705029467611668F3ADB" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 21:46:53 -0000 This is a multi-part message in MIME format. --------------FA2C705029467611668F3ADB Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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 dont 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 > *Cc:* IETF PKIX > *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 > > 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 mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------FA2C705029467611668F3ADB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
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 dont 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>
Cc: IETF PKIX <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> 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 mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix


--------------FA2C705029467611668F3ADB-- From nobody Thu May 10 21:52:08 2018 Return-Path: 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 7451712D871 for ; Thu, 10 May 2018 21:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com 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 bYOQvLMWy_IG for ; Thu, 10 May 2018 21:52:05 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9721200E5 for ; Thu, 10 May 2018 21:52:04 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id l1-v6so817667wmb.2 for ; Thu, 10 May 2018 21:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VmXr2Gb6g6Q/en5WPGtesMrfe6pBV7rchudZBInrzFk=; b=XUnSebmT8eyYCNf/FRTlrR14CcEbo/2/AqaKw4cW91TO7M8+tBHTN9Ij4uAJiBL5g0 RKMeYRG7PlKkgdp+53Fl1TiHPbC7zSpc/g7Bhv+pNqh2oou2CrFAVKKxa8DYSaKk7W10 WRuNNTbgRyXmpxwGGVes/BzQhRptbH2MxCqFjKKeuI33jKQ54jEw7oQfU2hYa3lNPcPb +up1wSQqtOqX9LCZC82l5uiX5VpR9GqcfmYYYuo1CYbzkbmiTb9yjjMYJhMAubKDVH2t TWVqqQvnI6GWixMXUsuayFBRChW3jBY8H+HfKoLOkLYdGqaZ+ncOBt12RT8L64wb/fVp dTvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VmXr2Gb6g6Q/en5WPGtesMrfe6pBV7rchudZBInrzFk=; b=Du9dpd2Khs4Rz3o8tXqZZSeDrqzRhAfo7TK/RRblLnnwUJdPGBm5au+uIq5O+nrgMa 51/B/hyewhAPRJtksMNE6skYAwLqXTMmxwDskw71Y/Y5uPhEDrEdXjN2j56Yx9MxHS7G tC+hzwf1U+K9stwuVEtT+g/Xa4hhelUUNctKIxNAEvQKP/VG/TrMjkJVjQgBSMDFsfbw 8p2zTFUziXrkJbevYrKflnNjD0IWVkkgLtuM4pIp1xvFobqPBTxxWQ6Mez+6HKOGOZxJ dq2mUZoF7baOUjEMEPzpTQXJKYTj462ct67HD6k3p6D4G1rvL7dFaFjobEhIA09415pC 0hPg== X-Gm-Message-State: ALKqPwcxu4Hn+VvfzqIGAwjN8UXsDW3mYGERCQr6Pmhdl1lOEj+9stnW BL4GNXXb7N0qHecN3rIR44bAP8q/tQ5vDSYsXtx6JQ== X-Google-Smtp-Source: AB8JxZqp4ZNmXio3LRd5IHAPJVgHRD0pMgntxuZJXLw5w2YFx9KVuqI2P8RTh0LkE7wLEgh+Fx6aJysnLKAz7EyDE7k= X-Received: by 2002:a1c:a95:: with SMTP id 143-v6mr829116wmk.134.1526014323051; Thu, 10 May 2018 21:52:03 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <77eb0920-c6a2-2697-46d0-b0ab0366d9da@free.fr> From: Michael StJohns Date: Fri, 11 May 2018 00:51:52 -0400 Message-ID: To: Denis Cc: pkix@ietf.org Content-Type: multipart/alternative; boundary="000000000000a5e0fe056be6e59c" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 04:52:07 -0000 --000000000000a5e0fe056be6e59c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually see RFC5480. It describes a set of suggested pairings of signature strengths and hashes and includes recommendations for P-192. Re Russ=E2=80=99s comment, the ECDSAWithShaxxx identifiers can be used with= any curve, (but follow the 5480 and other similar document pairing recommendations) so it=E2=80=99s not exactly correct that there are no al= gorithm identifiers. Lastly, AFAICT NIST didn=E2=80=99t originally define the P192 curve - it ju= st 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 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 siz= e > 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 bit= s > ? 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=3D112-bit > security, which does not meet the current best practice of 128 bit securi= ty. > > > > 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 formall= y > deprecated, I don=E2=80=99t 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 h= ow > 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 > > *Cc:* IETF PKIX > *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> 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 Has= h > 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 mailing listpkix@ietf.orghttps://www.ietf.org/mailman/listinfo/pkix > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --000000000000a5e0fe056be6e59c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Actually see RFC5480.=C2=A0 It describes a set of su= ggested pairings of signature strengths and hashes and includes recommendat= ions for P-192.=C2=A0

Re= Russ=E2=80=99s comment, the ECDSAWithShaxxx identifiers can be used with a= ny curve, (but follow the 5480 and other similar document pairing recommend= ations) =C2=A0 so it=E2=80=99s not exactly correct that there are no algori= thm identifiers. =C2=A0

= Lastly, AFAICT NIST didn=E2=80=99t originally define the P192 curve - it ju= st incorporated a previously defined curve in a set of acceptable parameter= s when it was NISTifying EC cryptography.

=
Mike

On Thu, May= 10, 2018 at 17:47 Denis <denis.ie= tf@free.fr> wrote:
=20 =20 =20
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 no= t take the 192 low bits ?=C2=A0

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


Denis

=20 =20 =20

Hi Denis,

=C2=A0

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

=C2=A0

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=3D112-bit security, which does not meet the current best practice of 128 bit security.=

=C2=A0

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=E2=80=99t 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.=C2=A0 I do not recall how far the= se 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.=C2= =A0 As noted in the thread below, the standards have options to truncate a longer hash, which should correct this.<= /p>

=C2=A0

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.

=C2=A0

Best regards,

Dan

=C2=A0

=C2=A0

From: pkix [mailto:pkix-bounces@iet= f.org] On Behalf Of Russ Housley
Sent: Thursday, May 10, 2018 1:30 PM
To: Ernst G Giessmann <giessman= @informatik.hu-berlin.de>
Cc: IETF PKIX <pkix@ie= tf.org>
Subject: Re: [pkix] Question about Curve P-192<= u>

=C2=A0

Ernst:

=C2=A0

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

=C2=A0

Russ

=C2=A0

=C2=A0

On May 10, 2018, at 1:24 PM, Ernst G Giessmann <giessman@informatik.hu-berlin.de> wrote:

=C2=A0

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 FI= PS 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 ?<= /u>

Denis

=C2=A0





_______________________________________________=
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

=C2=A0

____________________________________= ___________
pkix mailing list
pkix@i= etf.org
https://www.ietf.org/mailman/listinfo/pkix

=C2=A0



_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mai=
lman/listinfo/pkix


_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--000000000000a5e0fe056be6e59c-- From nobody Fri May 11 03:09:17 2018 Return-Path: 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 5E03912D947 for ; Fri, 11 May 2018 03:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.23 X-Spam-Level: X-Spam-Status: No, score=-0.23 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] 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 yiX92sQtuZ3k for ; Fri, 11 May 2018 03:09:13 -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 5377A127078 for ; Fri, 11 May 2018 03:09:13 -0700 (PDT) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 61DCA7803B2 for ; Fri, 11 May 2018 12:09:11 +0200 (CEST) Cc: 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> From: Denis Message-ID: <689887b5-b034-5c4c-648c-3854321ce2c7@free.fr> Date: Fri, 11 May 2018 12:09:13 +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: Content-Type: multipart/alternative; boundary="------------8F5EBA53AE944EDAD9AE0BEA" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 10:09:16 -0000 This is a multi-part message in MIME format. --------------8F5EBA53AE944EDAD9AE0BEA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 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 > 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 >> >> *Cc:* IETF PKIX >> *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 >> > > 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 >> >> --------------8F5EBA53AE944EDAD9AE0BEA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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.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.
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> 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>
Cc: IETF PKIX <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> 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



--------------8F5EBA53AE944EDAD9AE0BEA-- From nobody Fri May 11 07:24:02 2018 Return-Path: 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 BD5BA12D945 for ; Fri, 11 May 2018 07:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-nTkZ6ZctJM for ; Fri, 11 May 2018 07:23:57 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (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 A323912D942 for ; Fri, 11 May 2018 07:23:56 -0700 (PDT) X-Spoof: Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs214cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2018 10:23:54 -0400 Received: from XCT112CNC.rim.net (10.65.161.212) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 11 May 2018 10:23:54 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Fri, 11 May 2018 10:23:53 -0400 From: Dan Brown To: Denis CC: "pkix@ietf.org" Thread-Topic: [pkix] Question about Curve P-192 Thread-Index: AQHT6IFeYuIm9dZtR0OYr6kEQvvxAqQpeaaAgAABjwD//8xYwIAAe0kAgAB2wwCAAFirgP//+7Lg Date: Fri, 11 May 2018 14:23:52 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501C71FA3@XMB116CNC.rim.net> 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> <689887b5-b034-5c4c-648c-3854321ce2c7@free.fr> In-Reply-To: <689887b5-b034-5c4c-648c-3854321ce2c7@free.fr> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] 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-BeenThere: pkix@ietf.org 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 ------=_NextPart_000_000E_01D3E912.276FFC50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01D3E912.276FFC50" ------=_NextPart_001_000F_01D3E912.276FFC50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Denis, =20 Scope: are these question related to IETF or PKIX work? =20 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 =E2=80=9Csuite=E2=80=9D. You may also be = interested in key exchange. =20 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=E2=80=99s Curve25519, which is = CFRG approved, and I understand to also have some speed, and also side = channel benefits. Again, I don=E2=80=99t know off-hand how it compares = to P-192. If you haven=E2=80=99t studied these various options = carefully, then maybe somebody over at CFRG can help. =20 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). =20 =20 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=E2=80=99s = 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. =20 History and origin of the NIST curves: I believe that the NSA = contributed all 15 NIST curves, especially the 10 the = =E2=80=9Cpseudorandom=E2=80=9D 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=E2=80=99t 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.. =20 =20 I hope that helps, =20 Best regards, Dan =20 =20 =20 =20 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 =20 Michael, I don't see how RFC 5480 can be used to obtain an identifier for a = cryptographic suite for both P-192 and=20 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=20 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=20 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.=20 =20 Re Russ=E2=80=99s comment, the ECDSAWithShaxxx identifiers can be used = with any curve, (but follow the 5480 and other similar document pairing = recommendations) so it=E2=80=99s not exactly correct that there are no = algorithm identifiers. =20 =20 Lastly, AFAICT NIST didn=E2=80=99t originally define the P192 curve - it = just incorporated a previously defined curve in a set of acceptable = parameters when it was NISTifying EC cryptography. =20 Mike =20 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.=20 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=20 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 ? =20 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=20 (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=3D112-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=E2=80=99t 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 =20 From: pkix [mailto:pkix-bounces@ietf.org] 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 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 = > wrote: Yes, there is a standardized way:=20 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 ?=20 Is there any RFC or any another document that specifies a cryptographic = suite for Curve P-192 ? Denis =20 =20 ------=_NextPart_001_000F_01D3E912.276FFC50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Denis,

 

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

 

For Alg IDs, OIDs and = ECDSA, see:

https://tools.ie= tf.org/html/rfc5758#section-3.2

http://www.secg.org/sec1-v2.pdf<= /a>, Section C.5 and surrounding

Not sure what you = mean by =E2=80=9Csuite=E2=80=9D.=C2=A0 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.=C2=A0 For example, I recall that NIST P-224 is = somehow slow for its size (due to the cost of computing square = roots).=C2=A0 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.=C2=A0 Then, of course, there=E2=80=99s = Curve25519, which is CFRG approved, and I understand to also have some = speed, and also side channel benefits.=C2=A0 Again, I don=E2=80=99t know = off-hand how it compares to P-192.=C2=A0 If you haven=E2=80=99t 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.=C2=A0 = 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.pd= f).=C2=A0

 

Note that ECQV can = save a lot a bytes, compared you are traditional certificates.=C2=A0 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). =C2=A0The basic idea of ECQV is that one reconstructs the = public key from the implicit cert and the CA=E2=80=99s public key.=C2=A0 = 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. =C2=A0I believe ECQV that has = been fielded in some kind of Zigbee-based smart metering devices.=C2=A0 = 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 =E2=80=9Cpseudorandom=E2=80=9D curves.=C2=A0 = =C2=A0Some 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.=C2=A0 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=E2=80=99t = 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..=C2=A0 =

 

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.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.

Denis

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

 

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

 

Lastly, AFAICT NIST didn=E2=80=99t 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> = 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_2= 4.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=3D112-bit security, = which does not meet the current best practice of 128 bit = security.

 Histor= y 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=E2=80=99t 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.

 Arguab= ly, 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>
Cc:<= /b> IETF PKIX <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> = 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

 

 

------=_NextPart_001_000F_01D3E912.276FFC50-- ------=_NextPart_000_000E_01D3E912.276FFC50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIh1TCCBckw ggOxoAMCAQICBQD2V+DAMA0GCSqGSIb3DQEBDQUAMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJC bGFja0JlcnJ5IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAq BgNVBAMMI0JsYWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMB4XDTEzMTIxMzE3NDU0 N1oXDTM4MTIxMzE3NDU0N1owfDELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkgTGlt aXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEsMCoGA1UEAwwjQmxhY2tC ZXJyeSBFbnRlcnByaXNlIFJTQSBSb290IENBIDEwggIgMA0GCSqGSIb3DQEBAQUAA4ICDQAwggII AoICAQDGRcB/8QfFrWiS6iI+cqEd5oN9JFerfmDskffgyqIzZzEywv5Yx7/zv3YMsQB7kuYUtRGa uQGKrCDOSul6MXVYFRqqszScZKTFN873LBcUcpmcrbDLET6410g3krO7OKMQUmmcfFql0mCTxWay BKef7BPJEXwn/YOxopXtQ9g2SgYZm0KCAjoOH3Yb0BQrNkFKN9plF/BK0S/brBWAzwKKpJo7YW7B iuK75OjTfIM2ILRc5oZs8vI8B3IltjvUG53dFATXByJBXScvBefIIGYMrXbs2SN17BjicAVNW4pp NUKoB0YpGjmJ3LClIeSdnLTUC84k268v8GQ302/2d+V6VKaXlMk2F9JraENGYe+vT4mez4Co5ELZ aW8LJtEYeSZOOlgssychWms0FY8IIToH9Fqgu9xO8N5TAFWipjMtJ8tPqMChdVwkz5dP3jxPMCAI pwmDii6mCIy1jIv+iS1qMluemIu1FneNFfaESBFby0llyS+XG2sEbFAthY1V7jw50GFs2c5sHIY3 ajT8YC21+Qzxat2OcI2/lhnV3V5k+oImJxDswvjFHNQ/APW7ti+B1VEWJ0HcKzEz2eeWdqYxhZAh XmdS7Ir/U1ROIASEYFg6wt56aC8/PjVOyMRG6NvMdyPwwzfMx3CFavzoOnXb3YL9vDI2AyY59WCw edlGcQIBA6NUMFIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFPhp ifhjnu9oXoEwYnBSow7dspYIMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBDQUAA4ICAQCs FUaj+ZL3/7JbMYjTdp7mixMW3e/ZpxBWPU6upIAFlBdN05eMkvfVDhAkAFmXCWXMp4iUWd7dz3Kf f2LdAyGhKOqSfg2Ns+MqKLLM4ugjQ8arlRNC2kabtf8RpeRxgMWGsgecZ8L12YHlZ67AzBd+YrBS 2Is+GC2CMYGqTFI6IUVsFQGIsaz+a4TghhsokY8qqKU4Eul4rUrKnzNciskstDTPOQrpORDHpFQt D6nHeB5LlRaSuwVcIcr/H28HEffXc7tFXu+/C3Y6lzQcXD0vMXnSOJ7/CrH0cPe2bQaC+oMBpu2V qjVXWZ8umTyT6etZ3nz1llIeZAxUW/MROetLQFLjBmywiY5EBu/q1UIdlJ/qC7VcCmfExowfLyqY v2V+ShNrEXtzHPPCuPk/j1eP6fg1lP3kbJg0ChTcCEAWtBX4foFcVM4c1f8Au5thaDnH7G4kWL7s dNxoKNnONIYtYbeSKWqfomRPbb2OBgKXM3wTKV6Ze/fLPW9WNdtNFk0Mr0b+nUmPZLGUEL+ZMG95 0BNuQgxWblbOXxwTesin4D2Vn5tL0J9XHk62EdDFefR+5UJqRanhr4pOxO0WWpu1Ux6x1xRDW4yT xNqnXVfjduQDJfbmXvp6PG5UJlhlo7FkW3rz1tWpEWHgOPJ9qAJG7rl5CA67TXdpmIBzbyJYITCC B0kwggYxoAMCAQICClZxDY0AAAACH3EwDQYJKoZIhvcNAQELBQAwVjETMBEGCgmSJomT8ixkARkW A25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEqMCgGA1UEAxMhQmxhY2tCZXJyeSBDb3Jwb3JhdGUg SXNzdWluZyBDQSAxMB4XDTE4MDIwODE5MjQwMVoXDTE5MDIwODE5MjQwMVowgakxEzARBgoJkiaJ k/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsT AkNBMRQwEgYDVQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBC cm93bjEnMCUGCSqGSIb3DQEJARYYZGFuaWJyb3duQGJsYWNrYmVycnkuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAohJqrR7zCc/JYInUzai/eVD0K2w8BxWQp42YEU4kNA1sCBCJ BI4/7pNSTAnJTG0yMSoyuBbP8mky6PDlo5PYnCCtXmWha8lJBUuAJ9OHzJwDP9ScBCeCam2MQ2Yu rxW52026C/V93IWR8hEY5YEN0ikdCQU+aYMsLXGnt50z4+Kxq0xcPN54N8IsdY7Fa17x/GzV/Dlv vAMlQDPkAAEwNI96az0Wr0YEvZLgAnuwZH9tnWzsO28M4W0r9x+wPRYkSlsavJF2t5UNCA8ZD5Yy b7+NwLKlmfWEQ2fjwT7yl0RsfkF1sOHNdd51ymmO7GSh4X4L7QHOenRA+hYF4LT6GwIDAQABo4ID wzCCA78wPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIh7+XS4a5gSSGwYEyg9vyJYLc2AGBALHD Koef9EACAWQCAQcwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAw TwYDVR0gAQH/BEUwQzBBBgorBgEEAZtKEwECMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0u bmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wJwYJKwYBBAGCNxUKBBowGDAKBggrBgEFBQcDBDAKBggr BgEFBQcDAjALBgNVHQ8EBAMCBsAwHQYDVR0OBBYEFL/Dm4ZZ67qzpYa3/pf8WhtppWOtMB8GA1Ud IwQYMBaAFBovS0vbB8lJO4nWMggnop4L8w9rMIIBMgYDVR0fBIIBKTCCASUwggEhoIIBHaCCARmG QGh0dHA6Ly9jcmwucmltLm5ldC9CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWluZyUyMENB JTIwMS5jcmyGgdRsZGFwOi8vL0NOPUJsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBJc3N1aW5nJTIw Q0ElMjAxLENOPU1DQTAxMENOQyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAQMG CCsGAQUFBwEBBIH2MIHzMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwgcoG CCsGAQUFBzAChoG9bGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWluZyUy MENBJTIwMSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmpl Y3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5ME0GA1UdEQRGMESgKAYKKwYBBAGCNxQCA6Aa DBhkYW5pYnJvd25AYmxhY2tiZXJyeS5jb22BGGRhbmlicm93bkBibGFja2JlcnJ5LmNvbTANBgkq hkiG9w0BAQsFAAOCAQEAyAMjuNH2sn+U8uhj30d48XfUYSaIR1Z/nGgiJcMbREyoP1H9lIM9jYrL GjzUQ7IIT7xRfRfV8aEKec3gL9xPqyhMaAXv1TiQnG8Xo7d1pHyh9gZRXdv/khGyTNd2Y/4Pf100 cg+INLDZfFnuQ/r/x9yBZqrM9d612GLtrBC/MEnJmxwL+SrcdLO7GT4w4uzeyzTUe32+WM6dlu9O h+8c4c+wTlBU5D6HDN8L5mDgYkBSv5ok8FjsK0hp9ggb2skeXZrdTeiOnHJDvmfYp5BXHBFPyivz hcfYja7P8wUTSKivxVVNTGBLXBhGvj2xTiEblt5lzmCq0aVecHUnP9/cvzCCCAUwggXtoAMCAQIC BEMVWF8wDQYJKoZIhvcNAQENBQAwfDELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkg TGltaXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEsMCoGA1UEAwwjQmxh Y2tCZXJyeSBFbnRlcnByaXNlIFJTQSBSb290IENBIDEwHhcNMTQwMjI2MTYyMzU2WhcNMjQwMjI2 MTYyMzU2WjB5MQswCQYDVQQGEwJDQTEbMBkGA1UECgwSQmxhY2tCZXJyeSBMaW1pdGVkMSIwIAYD VQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJMSkwJwYDVQQDDCBCbGFja0JlcnJ5IENvcnBv cmF0ZSBQb2xpY3kgQ0EgMTCCAiAwDQYJKoZIhvcNAQEBBQADggINADCCAggCggIBALom9kCQ+lPa 4g4nzDj+EFbwiF3CYO2/MwRWadgSaavVydBoPc1VIjEN80UbZ1VV5kkHiqYvAuSMx/R2AOgu1o9F qpnaRb59a4R5aobixHEIhYyCt2mmRCgJ6dYYiJbtDn1t00uT0yyI/YU+AUxWFK9c3fy+X20ASyxA ObA9Wev2cFsGFbg6dozYkPDQHlgSczJcEnCyUD6fhgM5N/NsgHmvN3OQb8LL5Kzs204QgbUd966v lHOu6ppVEg2xuTzzhPVONHirYEyFMTa5KNoA1eSX4gzVix+YiAKP8AqvgqEQB4zi2jXSYDzd9RUt nOflg+jz+OKTNDSpOB7/tiPa959++RiRYbWlkYm+Wh+X9uL/ra+uatOTH2UMosyXnO4ryoXOe9JZ WGe0awdY7Rkj65LPmHsCWvR05N1M6vX5JHZLOov65F7J/ZWLLCIAR/sm1mPhBTauU3uvE6JK5/ub PQPxF6UDpNdoaUB7+rfmSoBxyIlmMy6A7v5cbZyHONyLlz+r4sklPDPcz5CBIjbUyFNzK0KK0GXR YVKD++YTbqdCe6vKFZSg2+vIYQ/bFqtp7+gKIpmjjWdzotxVcKgl+r+kTk4pSECLU39Efbo50Nve Q6N0N0sgpj/JVOF53XMRKy4JQ2SDL0A+PkuBL3mdIb+hD0uUsvmDhhB3xavB0UhlAgEDo4ICkjCC Ao4wEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFDu4wXcNnq1D WPwlrhXQt/KRMoWbMB8GA1UdIwQYMBaAFPhpifhjnu9oXoEwYnBSow7dspYIMIGGBggrBgEFBQcB AQR6MHgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnJpbS5uZXQvb2NzcDBQBggrBgEFBQcwAoZE aHR0cDovL2NydC5yaW0ubmV0L0JsYWNrQmVycnklMjBFbnRlcnByaXNlJTIwUlNBJTIwUm9vdCUy MENBJTIwMS5jcnQwggE3BgNVHR8EggEuMIIBKjCCASagggEioIIBHoZEaHR0cDovL2NybC5yaW0u bmV0L0JsYWNrQmVycnklMjBFbnRlcnByaXNlJTIwUlNBJTIwUm9vdCUyMENBJTIwMS5jcmyGgdVs ZGFwOi8vL0NOPUJsYWNrQmVycnklMjBFbnRlcnByaXNlJTIwUlNBJTIwUm9vdCUyMENBJTIwMSxD Tj1Sb290Q0EsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENO PUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25M aXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwNwYDVR0gBDAwLjAsBgRV HSAAMCQwIgYIKwYBBQUHAgEWFmh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy8wEAYJKwYBBAGCNxUBBAMC AQAwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwDQYJKoZIhvcNAQENBQADggIBALfxM34RYrFM 8E5/7K7T54kPvkcjQrX9Vtf7+CTHHG2EH7SuFoFWsnNTeP+J8TxJP0hxz4mA5FnMKNlhTPsuP0Nu /Fu1R1okaLsIeOPGAWbtpCQ9fYG+lgeONh5DTfj1uhrLDDUAbqJfjYX8ab4/j9RPgm/mWjlR6nMz PyaCc6cASqnOjs0VSLFdmctNMwvqDwKj4qnCX+AM61Nxd2K3ZITiq6BQIj37hQh07lwgVQra+S56 /cmyO5QKXSnyD/n3U/IPEhShFa30j7yeR4OZ2Gv8vK6HY5jzY5eoJztN089F0l2jSdYIlm47E+sr Vwk88z8UwzsTBKu5LWYVsywfJdyZQF1+bwu52Q8c+mzMaVDZwBwQ3ODIYJ3Y5aWCCmn7Lfkkij14 qcsLkEaKjp6ejoy980wzkPMivmGhV8uxslS+UgjA5qqFZY8iOJAmBLy8ABkE42HoBdezxMCya7TK 3ZxKnTQe9RYDImLx45VQ6K75/uJddTD7GERw7KCCjgmYniD6ozzDPHylziygpUzHhItdeVH+47dE 1nlk1pVzf6oiqDgRuEY1DHIIYKEVh6Zi9F0uaOo7SwZ+h9hqpF2EgGkpliTu8M7CPRlK3OBNPnk4 BgXSNj4D1FdKK7rGbTgXcL/YbtLX2weWErbw+uN/UCG7k3BOelop0zlSJfj9KsotMIIMrjCCCpag AwIBAgIECxEcnDANBgkqhkiG9w0BAQsFADB5MQswCQYDVQQGEwJDQTEbMBkGA1UECgwSQmxhY2tC ZXJyeSBMaW1pdGVkMSIwIAYDVQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJMSkwJwYDVQQD DCBCbGFja0JlcnJ5IENvcnBvcmF0ZSBQb2xpY3kgQ0EgMTAeFw0xNDA0MTcxODA4MjVaFw0xOTA0 MTcxODA4MjVaMFYxEzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAo BgNVBAMTIUJsYWNrQmVycnkgQ29ycG9yYXRlIElzc3VpbmcgQ0EgMTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANUcv8oSAXw3NNOhPMafhnN2N+8xE31gbXNo+R6TBeuSdZEo5PDfR+PD ps/sIXrSecnAZJWGhDUOQ2pXPRk8jfl0lbcQERTI1UC04Zv5+I2YOw4qTaBt77PAtvW22s3sE6Ag O6okqW6NQFjEGToKXjgo6grBLO6/G4Uc/tPqh6/bcmH4NmaSbszrSJUsPMeNyEWu7r3orxu9KJzM nDQBWpbKZq6l4W96mut0lTPXL8bRDQah5nc0UfRrMzwlLowHtLPXM7/1J2XG+tG7SYIQ3wQ6BRN8 bWXWwMguzsiEz2BQEX60cml4Vz7G5IenHuymRHOERKa4UPiH7oggn8HtKh8CAwEAAaOCCF8wgghb MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaL0tL2wfJSTuJ 1jIIJ6KeC/MPazAfBgNVHSMEGDAWgBQ7uMF3DZ6tQ1j8Ja4V0LfykTKFmzCBgQYIKwYBBQUHAQEE dTBzMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwSwYIKwYBBQUHMAKGP2h0 dHA6Ly9jcnQucmltLm5ldC9CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwUG9saWN5JTIwQ0ElMjAx LmNydDCCASwGA1UdHwSCASMwggEfMIIBG6CCARegggEThj9odHRwOi8vY3JsLnJpbS5uZXQvQmxh Y2tCZXJyeSUyMENvcnBvcmF0ZSUyMFBvbGljeSUyMENBJTIwMS5jcmyGgc9sZGFwOi8vL0NOPUJs YWNrQmVycnklMjBDb3Jwb3JhdGUlMjBQb2xpY3klMjBDQSUyMDEsQ049U3ViQ0EsQ049Q0RQLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwggYSBgNVHSAEggYJMIIGBTBBBgorBgEEAZtKFAIBMDMw MQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYB BAGbShMBAzAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQu aHRtMEEGCisGAQQBm0oTAQIwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQ U3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0u bmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMCAzAzMDEGCCsGAQUFBwIBFiVodHRw Oi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTAgIwMzAxBggrBgEF BQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwIB MDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYK KwYBBAGbShMDAzAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1l bnQuaHRtMEEGCisGAQQBm0oTAwIwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3Bz L0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwMBMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5y aW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMEADAzMDEGCCsGAQUFBwIBFiVo dHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBQMwMzAxBggr BgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtK EwUCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0w QQYKKwYBBAGbShMFATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0 ZW1lbnQuaHRtMEEGCisGAQQBm0oTBgMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQv Y3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwYCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9j cC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMGATAzMDEGCCsGAQUFBwIB FiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBwMwMzAx BggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEE AZtKEwcCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5o dG0wQQYKKwYBBAGbShMHATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BT dGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTCAMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5u ZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwgCMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMIATAzMDEGCCsGAQUF BwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMBAGCSsGAQQBgjcVAQQD AgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUAA4ICAQAeVuw/L3Zy FbBCOhKq5sL9OrBp4G1j4r6C2WJN2BuAoN4fOdzw7H27Y60d8otCRquP8G/AvQ43dJCsE7kld10v tOs2L4T17T3OHxVoMEU39zoIjgu3x7pVUWNf6HCd3QDwWbQZrLIpPWh4ipvIRipQlizCBfDxmbsJ H/BBiiWl5RC7fnWHbEfdbbHPDWyZ/9CsM2XpGdMgYg82LXWBUzGbKSwtoya0wHEEMlhM9D5MaQkm DmYwJOI9m+ryyZMnYYo28ZvW6khFl/Frd/Y77aSOIgtNTXQ+S86xW4PBJJ1jqoal1xt4jYrWWRBE 0wvpZygMoRFCRMsBGvr/r5rqZ9QcN+OX3tmUOC2rtqH9qQKzABJCDetqB16Oyynx1cvUN/x3p1LM Cd3YcqE4ppRxwvX+377msqZamYjHRMuwM1I2RpuVbMdbEwTIHeb17WgRmHkRWF1yKf1XRxN9ywp0 BzkK0tBvN+yMjJSXiZITYAb0U6WxrtEHWdr1CyJPuSrUzwkx0NdCrImlvwo6froM5h3crRXhUgkm +eNPZhiZ2cBG2OaOX8XKUtounkbqVEbblUy1tLIaxUwYw2j+BcKWrbQsoW798S37b7hJWVVE048I gOfRemUiP7yZ5nh0+SQ6+jTVRaWAba8nawivkrv0ja/k1QwzZD9p7nUSvmizKhbCYzGCAiwwggIo AgEBMGQwVjETMBEGCgmSJomT8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEqMCgGA1UE AxMhQmxhY2tCZXJyeSBDb3Jwb3JhdGUgSXNzdWluZyBDQSAxAgpWcQ2NAAAAAh9xMAkGBSsOAwIa BQCggZ4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwNTExMTQy MzUwWjAjBgkqhkiG9w0BCQQxFgQUsM5Zlk9FabZoqT/ZAqcLjo8h8ucwPwYJKoZIhvcNAQkPMTIw MDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG 9w0BAQEFAASCAQAZt+tRe4b5Xn2j18oiDMPGyZ2bGfcKoXTyJCimkDfqk5JhtOoLmm9uQ4zRFYUF U2B/O1gAr+5/D+ZMz+9tFGWj0kmzubkEJD/jLJO7E6KIlNt3+tlivJpwW47DaM93qBwpoaKT6hTv AINpC7jkP0stBZ9cOWReR3ozAAh1OfW5M8g9kaF9J/p4slTd6PrJ09zMLwjAsamUILph0wsrbN3Q kBUkwzBSXGPFcT70OiyGwmT6eoB3MaDB+X+Edu6a3+fU8IsQnPOhdx6ycIwbqIFCvXwj3BL/1pJY 12272rr+d2S002/OlVMn99HDI2xyX88+myBpGYu/xEtHZGxzaX6FAAAAAAAA ------=_NextPart_000_000E_01D3E912.276FFC50-- From nobody Fri May 11 08:31:46 2018 Return-Path: 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 ; 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 ; 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 ; 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 ; Fri, 11 May 2018 17:31:38 +0200 (CEST) Cc: "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> <689887b5-b034-5c4c-648c-3854321ce2c7@free.fr> <810C31990B57ED40B2062BA10D43FBF501C71FA3@XMB116CNC.rim.net> From: Denis 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 15:31:45 -0000 This is a multi-part message in MIME format. --------------E40B0041BD18A97017229DFE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 > 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 > 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 > > *Cc:* IETF PKIX > *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 > > 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 > --------------E40B0041BD18A97017229DFE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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.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.

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> 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>
Cc: IETF PKIX <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> 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

 

 


--------------E40B0041BD18A97017229DFE-- From nobody Fri May 11 08:55:19 2018 Return-Path: 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 E57A112DA09 for ; Fri, 11 May 2018 08:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeqrlPrhGlj6 for ; Fri, 11 May 2018 08:55:14 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (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 57FFE126CB6 for ; Fri, 11 May 2018 08:55:14 -0700 (PDT) X-Spoof: Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs210cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2018 11:55:12 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0319.002; Fri, 11 May 2018 11:55:12 -0400 From: Dan Brown To: Dan Brown , Denis CC: "pkix@ietf.org" Thread-Topic: [pkix] Question about Curve P-192 Thread-Index: AQHT6IFeYuIm9dZtR0OYr6kEQvvxAqQpeaaAgAABjwD//8xYwIAAe0kAgAB2wwCAAFirgP//+7LggAAVOLA= Date: Fri, 11 May 2018 15:55:11 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501C72046@XMB116CNC.rim.net> 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> <689887b5-b034-5c4c-648c-3854321ce2c7@free.fr> <810C31990B57ED40B2062BA10D43FBF501C71FA3@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501C71FA3@XMB116CNC.rim.net> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000C_01D3E91E.E99393D0" MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 15:55:18 -0000 ------=_NextPart_000_000C_01D3E91E.E99393D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000D_01D3E91E.E99393D0" ------=_NextPart_001_000D_01D3E91E.E99393D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Denis, I forgot to mention the formal deprecation of P-192 (at least by NIST): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.= pdf, Table 2 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4= .pdf, Tables 2-4. Best regards, Dan =20 =20 From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Dan Brown Sent: Friday, May 11, 2018 10:24 AM To: Denis Cc: pkix@ietf.org Subject: Re: [pkix] Question about Curve P-192 =20 Denis, =20 Scope: are these question related to IETF or PKIX work? =20 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 =E2=80=9Csuite=E2=80=9D. You may also be = interested in key exchange. =20 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=E2=80=99s Curve25519, which is = CFRG approved, and I understand to also have some speed, and also side = channel benefits. Again, I don=E2=80=99t know off-hand how it compares = to P-192. If you haven=E2=80=99t studied these various options = carefully, then maybe somebody over at CFRG can help. =20 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). =20 =20 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=E2=80=99s = 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. =20 History and origin of the NIST curves: I believe that the NSA = contributed all 15 NIST curves, especially the 10 the = =E2=80=9Cpseudorandom=E2=80=9D 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=E2=80=99t 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.. =20 =20 I hope that helps, =20 Best regards, Dan =20 =20 =20 =20 From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Sent: Friday, May 11, 2018 6:09 AM Cc: pkix@ietf.org =20 Subject: Re: [pkix] Question about Curve P-192 =20 Michael, I don't see how RFC 5480 can be used to obtain an identifier for a = cryptographic suite for both P-192 and=20 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=20 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=20 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.=20 =20 Re Russ=E2=80=99s comment, the ECDSAWithShaxxx identifiers can be used = with any curve, (but follow the 5480 and other similar document pairing = recommendations) so it=E2=80=99s not exactly correct that there are no = algorithm identifiers. =20 =20 Lastly, AFAICT NIST didn=E2=80=99t originally define the P192 curve - it = just incorporated a previously defined curve in a set of acceptable = parameters when it was NISTifying EC cryptography. =20 Mike =20 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.=20 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=20 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 ? =20 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=20 (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=3D112-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=E2=80=99t 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 =20 From: pkix [mailto:pkix-bounces@ietf.org] 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 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 = > wrote: Yes, there is a standardized way:=20 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 ?=20 Is there any RFC or any another document that specifies a cryptographic = suite for Curve P-192 ? Denis =20 =20 ------=_NextPart_001_000D_01D3E91E.E99393D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Denis,

I forgot to mention the formal deprecation of = P-192 (at least by NIST):

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S= P.800-131Ar1.pdf, Table 2

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.= SP.800-57pt1r4.pdf, Tables 2-4.

Best = regards,

Dan

 

 

From: pkix [mailto:pkix-bounces@ietf.org] On = Behalf Of Dan Brown
Sent: Friday, May 11, 2018 10:24 = AM
To: Denis <denis.ietf@free.fr>
Cc: = pkix@ietf.org
Subject: Re: [pkix] Question about Curve = P-192

 

Denis,

 

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

 

For Alg IDs, OIDs and = ECDSA, see:

https://tools.ie= tf.org/html/rfc5758#section-3.2

http://www.secg.org/sec1-v2.pdf<= /a>, Section C.5 and surrounding

Not sure what you = mean by =E2=80=9Csuite=E2=80=9D.  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=E2=80=99s = Curve25519, which is CFRG approved, and I understand to also have some = speed, and also side channel benefits.  Again, I don=E2=80=99t know = off-hand how it compares to P-192.  If you haven=E2=80=99t 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.pd= f). 

 

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=E2=80=99s 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 =E2=80=9Cpseudorandom=E2=80=9D 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=E2=80=99t = recommend, instead opting for K-233.) Maybe some of this history can be = found standards like SEC2 (http://www.secg.org/sec2-v2.pdf<= /a>), 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.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.

Denis

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

 

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

 

Lastly, AFAICT NIST didn=E2=80=99t 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> = 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_2= 4.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=3D112-bit security, = which does not meet the current best practice of 128 bit = security.

 Histor= y 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=E2=80=99t 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.

 Arguab= ly, 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>
Cc:<= /b> IETF PKIX <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> = 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

 

 

------=_NextPart_001_000D_01D3E91E.E99393D0-- ------=_NextPart_000_000C_01D3E91E.E99393D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIh1TCCBckw ggOxoAMCAQICBQD2V+DAMA0GCSqGSIb3DQEBDQUAMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJC bGFja0JlcnJ5IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAq BgNVBAMMI0JsYWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMB4XDTEzMTIxMzE3NDU0 N1oXDTM4MTIxMzE3NDU0N1owfDELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkgTGlt aXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEsMCoGA1UEAwwjQmxhY2tC ZXJyeSBFbnRlcnByaXNlIFJTQSBSb290IENBIDEwggIgMA0GCSqGSIb3DQEBAQUAA4ICDQAwggII AoICAQDGRcB/8QfFrWiS6iI+cqEd5oN9JFerfmDskffgyqIzZzEywv5Yx7/zv3YMsQB7kuYUtRGa uQGKrCDOSul6MXVYFRqqszScZKTFN873LBcUcpmcrbDLET6410g3krO7OKMQUmmcfFql0mCTxWay BKef7BPJEXwn/YOxopXtQ9g2SgYZm0KCAjoOH3Yb0BQrNkFKN9plF/BK0S/brBWAzwKKpJo7YW7B iuK75OjTfIM2ILRc5oZs8vI8B3IltjvUG53dFATXByJBXScvBefIIGYMrXbs2SN17BjicAVNW4pp NUKoB0YpGjmJ3LClIeSdnLTUC84k268v8GQ302/2d+V6VKaXlMk2F9JraENGYe+vT4mez4Co5ELZ aW8LJtEYeSZOOlgssychWms0FY8IIToH9Fqgu9xO8N5TAFWipjMtJ8tPqMChdVwkz5dP3jxPMCAI pwmDii6mCIy1jIv+iS1qMluemIu1FneNFfaESBFby0llyS+XG2sEbFAthY1V7jw50GFs2c5sHIY3 ajT8YC21+Qzxat2OcI2/lhnV3V5k+oImJxDswvjFHNQ/APW7ti+B1VEWJ0HcKzEz2eeWdqYxhZAh XmdS7Ir/U1ROIASEYFg6wt56aC8/PjVOyMRG6NvMdyPwwzfMx3CFavzoOnXb3YL9vDI2AyY59WCw edlGcQIBA6NUMFIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFPhp ifhjnu9oXoEwYnBSow7dspYIMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBDQUAA4ICAQCs FUaj+ZL3/7JbMYjTdp7mixMW3e/ZpxBWPU6upIAFlBdN05eMkvfVDhAkAFmXCWXMp4iUWd7dz3Kf f2LdAyGhKOqSfg2Ns+MqKLLM4ugjQ8arlRNC2kabtf8RpeRxgMWGsgecZ8L12YHlZ67AzBd+YrBS 2Is+GC2CMYGqTFI6IUVsFQGIsaz+a4TghhsokY8qqKU4Eul4rUrKnzNciskstDTPOQrpORDHpFQt D6nHeB5LlRaSuwVcIcr/H28HEffXc7tFXu+/C3Y6lzQcXD0vMXnSOJ7/CrH0cPe2bQaC+oMBpu2V qjVXWZ8umTyT6etZ3nz1llIeZAxUW/MROetLQFLjBmywiY5EBu/q1UIdlJ/qC7VcCmfExowfLyqY v2V+ShNrEXtzHPPCuPk/j1eP6fg1lP3kbJg0ChTcCEAWtBX4foFcVM4c1f8Au5thaDnH7G4kWL7s dNxoKNnONIYtYbeSKWqfomRPbb2OBgKXM3wTKV6Ze/fLPW9WNdtNFk0Mr0b+nUmPZLGUEL+ZMG95 0BNuQgxWblbOXxwTesin4D2Vn5tL0J9XHk62EdDFefR+5UJqRanhr4pOxO0WWpu1Ux6x1xRDW4yT xNqnXVfjduQDJfbmXvp6PG5UJlhlo7FkW3rz1tWpEWHgOPJ9qAJG7rl5CA67TXdpmIBzbyJYITCC B0kwggYxoAMCAQICClZxDY0AAAACH3EwDQYJKoZIhvcNAQELBQAwVjETMBEGCgmSJomT8ixkARkW A25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEqMCgGA1UEAxMhQmxhY2tCZXJyeSBDb3Jwb3JhdGUg SXNzdWluZyBDQSAxMB4XDTE4MDIwODE5MjQwMVoXDTE5MDIwODE5MjQwMVowgakxEzARBgoJkiaJ k/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsT AkNBMRQwEgYDVQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBC cm93bjEnMCUGCSqGSIb3DQEJARYYZGFuaWJyb3duQGJsYWNrYmVycnkuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAohJqrR7zCc/JYInUzai/eVD0K2w8BxWQp42YEU4kNA1sCBCJ BI4/7pNSTAnJTG0yMSoyuBbP8mky6PDlo5PYnCCtXmWha8lJBUuAJ9OHzJwDP9ScBCeCam2MQ2Yu rxW52026C/V93IWR8hEY5YEN0ikdCQU+aYMsLXGnt50z4+Kxq0xcPN54N8IsdY7Fa17x/GzV/Dlv vAMlQDPkAAEwNI96az0Wr0YEvZLgAnuwZH9tnWzsO28M4W0r9x+wPRYkSlsavJF2t5UNCA8ZD5Yy b7+NwLKlmfWEQ2fjwT7yl0RsfkF1sOHNdd51ymmO7GSh4X4L7QHOenRA+hYF4LT6GwIDAQABo4ID wzCCA78wPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIh7+XS4a5gSSGwYEyg9vyJYLc2AGBALHD Koef9EACAWQCAQcwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAw TwYDVR0gAQH/BEUwQzBBBgorBgEEAZtKEwECMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0u bmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wJwYJKwYBBAGCNxUKBBowGDAKBggrBgEFBQcDBDAKBggr BgEFBQcDAjALBgNVHQ8EBAMCBsAwHQYDVR0OBBYEFL/Dm4ZZ67qzpYa3/pf8WhtppWOtMB8GA1Ud IwQYMBaAFBovS0vbB8lJO4nWMggnop4L8w9rMIIBMgYDVR0fBIIBKTCCASUwggEhoIIBHaCCARmG QGh0dHA6Ly9jcmwucmltLm5ldC9CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWluZyUyMENB JTIwMS5jcmyGgdRsZGFwOi8vL0NOPUJsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBJc3N1aW5nJTIw Q0ElMjAxLENOPU1DQTAxMENOQyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAQMG CCsGAQUFBwEBBIH2MIHzMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwgcoG CCsGAQUFBzAChoG9bGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWluZyUy MENBJTIwMSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmpl Y3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5ME0GA1UdEQRGMESgKAYKKwYBBAGCNxQCA6Aa DBhkYW5pYnJvd25AYmxhY2tiZXJyeS5jb22BGGRhbmlicm93bkBibGFja2JlcnJ5LmNvbTANBgkq hkiG9w0BAQsFAAOCAQEAyAMjuNH2sn+U8uhj30d48XfUYSaIR1Z/nGgiJcMbREyoP1H9lIM9jYrL GjzUQ7IIT7xRfRfV8aEKec3gL9xPqyhMaAXv1TiQnG8Xo7d1pHyh9gZRXdv/khGyTNd2Y/4Pf100 cg+INLDZfFnuQ/r/x9yBZqrM9d612GLtrBC/MEnJmxwL+SrcdLO7GT4w4uzeyzTUe32+WM6dlu9O h+8c4c+wTlBU5D6HDN8L5mDgYkBSv5ok8FjsK0hp9ggb2skeXZrdTeiOnHJDvmfYp5BXHBFPyivz hcfYja7P8wUTSKivxVVNTGBLXBhGvj2xTiEblt5lzmCq0aVecHUnP9/cvzCCCAUwggXtoAMCAQIC BEMVWF8wDQYJKoZIhvcNAQENBQAwfDELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkg TGltaXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEsMCoGA1UEAwwjQmxh Y2tCZXJyeSBFbnRlcnByaXNlIFJTQSBSb290IENBIDEwHhcNMTQwMjI2MTYyMzU2WhcNMjQwMjI2 MTYyMzU2WjB5MQswCQYDVQQGEwJDQTEbMBkGA1UECgwSQmxhY2tCZXJyeSBMaW1pdGVkMSIwIAYD VQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJMSkwJwYDVQQDDCBCbGFja0JlcnJ5IENvcnBv cmF0ZSBQb2xpY3kgQ0EgMTCCAiAwDQYJKoZIhvcNAQEBBQADggINADCCAggCggIBALom9kCQ+lPa 4g4nzDj+EFbwiF3CYO2/MwRWadgSaavVydBoPc1VIjEN80UbZ1VV5kkHiqYvAuSMx/R2AOgu1o9F qpnaRb59a4R5aobixHEIhYyCt2mmRCgJ6dYYiJbtDn1t00uT0yyI/YU+AUxWFK9c3fy+X20ASyxA ObA9Wev2cFsGFbg6dozYkPDQHlgSczJcEnCyUD6fhgM5N/NsgHmvN3OQb8LL5Kzs204QgbUd966v lHOu6ppVEg2xuTzzhPVONHirYEyFMTa5KNoA1eSX4gzVix+YiAKP8AqvgqEQB4zi2jXSYDzd9RUt nOflg+jz+OKTNDSpOB7/tiPa959++RiRYbWlkYm+Wh+X9uL/ra+uatOTH2UMosyXnO4ryoXOe9JZ WGe0awdY7Rkj65LPmHsCWvR05N1M6vX5JHZLOov65F7J/ZWLLCIAR/sm1mPhBTauU3uvE6JK5/ub PQPxF6UDpNdoaUB7+rfmSoBxyIlmMy6A7v5cbZyHONyLlz+r4sklPDPcz5CBIjbUyFNzK0KK0GXR YVKD++YTbqdCe6vKFZSg2+vIYQ/bFqtp7+gKIpmjjWdzotxVcKgl+r+kTk4pSECLU39Efbo50Nve Q6N0N0sgpj/JVOF53XMRKy4JQ2SDL0A+PkuBL3mdIb+hD0uUsvmDhhB3xavB0UhlAgEDo4ICkjCC Ao4wEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFDu4wXcNnq1D WPwlrhXQt/KRMoWbMB8GA1UdIwQYMBaAFPhpifhjnu9oXoEwYnBSow7dspYIMIGGBggrBgEFBQcB AQR6MHgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnJpbS5uZXQvb2NzcDBQBggrBgEFBQcwAoZE aHR0cDovL2NydC5yaW0ubmV0L0JsYWNrQmVycnklMjBFbnRlcnByaXNlJTIwUlNBJTIwUm9vdCUy MENBJTIwMS5jcnQwggE3BgNVHR8EggEuMIIBKjCCASagggEioIIBHoZEaHR0cDovL2NybC5yaW0u bmV0L0JsYWNrQmVycnklMjBFbnRlcnByaXNlJTIwUlNBJTIwUm9vdCUyMENBJTIwMS5jcmyGgdVs ZGFwOi8vL0NOPUJsYWNrQmVycnklMjBFbnRlcnByaXNlJTIwUlNBJTIwUm9vdCUyMENBJTIwMSxD Tj1Sb290Q0EsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENO PUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25M aXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwNwYDVR0gBDAwLjAsBgRV HSAAMCQwIgYIKwYBBQUHAgEWFmh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy8wEAYJKwYBBAGCNxUBBAMC AQAwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwDQYJKoZIhvcNAQENBQADggIBALfxM34RYrFM 8E5/7K7T54kPvkcjQrX9Vtf7+CTHHG2EH7SuFoFWsnNTeP+J8TxJP0hxz4mA5FnMKNlhTPsuP0Nu /Fu1R1okaLsIeOPGAWbtpCQ9fYG+lgeONh5DTfj1uhrLDDUAbqJfjYX8ab4/j9RPgm/mWjlR6nMz PyaCc6cASqnOjs0VSLFdmctNMwvqDwKj4qnCX+AM61Nxd2K3ZITiq6BQIj37hQh07lwgVQra+S56 /cmyO5QKXSnyD/n3U/IPEhShFa30j7yeR4OZ2Gv8vK6HY5jzY5eoJztN089F0l2jSdYIlm47E+sr Vwk88z8UwzsTBKu5LWYVsywfJdyZQF1+bwu52Q8c+mzMaVDZwBwQ3ODIYJ3Y5aWCCmn7Lfkkij14 qcsLkEaKjp6ejoy980wzkPMivmGhV8uxslS+UgjA5qqFZY8iOJAmBLy8ABkE42HoBdezxMCya7TK 3ZxKnTQe9RYDImLx45VQ6K75/uJddTD7GERw7KCCjgmYniD6ozzDPHylziygpUzHhItdeVH+47dE 1nlk1pVzf6oiqDgRuEY1DHIIYKEVh6Zi9F0uaOo7SwZ+h9hqpF2EgGkpliTu8M7CPRlK3OBNPnk4 BgXSNj4D1FdKK7rGbTgXcL/YbtLX2weWErbw+uN/UCG7k3BOelop0zlSJfj9KsotMIIMrjCCCpag AwIBAgIECxEcnDANBgkqhkiG9w0BAQsFADB5MQswCQYDVQQGEwJDQTEbMBkGA1UECgwSQmxhY2tC ZXJyeSBMaW1pdGVkMSIwIAYDVQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJMSkwJwYDVQQD DCBCbGFja0JlcnJ5IENvcnBvcmF0ZSBQb2xpY3kgQ0EgMTAeFw0xNDA0MTcxODA4MjVaFw0xOTA0 MTcxODA4MjVaMFYxEzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAo BgNVBAMTIUJsYWNrQmVycnkgQ29ycG9yYXRlIElzc3VpbmcgQ0EgMTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANUcv8oSAXw3NNOhPMafhnN2N+8xE31gbXNo+R6TBeuSdZEo5PDfR+PD ps/sIXrSecnAZJWGhDUOQ2pXPRk8jfl0lbcQERTI1UC04Zv5+I2YOw4qTaBt77PAtvW22s3sE6Ag O6okqW6NQFjEGToKXjgo6grBLO6/G4Uc/tPqh6/bcmH4NmaSbszrSJUsPMeNyEWu7r3orxu9KJzM nDQBWpbKZq6l4W96mut0lTPXL8bRDQah5nc0UfRrMzwlLowHtLPXM7/1J2XG+tG7SYIQ3wQ6BRN8 bWXWwMguzsiEz2BQEX60cml4Vz7G5IenHuymRHOERKa4UPiH7oggn8HtKh8CAwEAAaOCCF8wgghb MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaL0tL2wfJSTuJ 1jIIJ6KeC/MPazAfBgNVHSMEGDAWgBQ7uMF3DZ6tQ1j8Ja4V0LfykTKFmzCBgQYIKwYBBQUHAQEE dTBzMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwSwYIKwYBBQUHMAKGP2h0 dHA6Ly9jcnQucmltLm5ldC9CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwUG9saWN5JTIwQ0ElMjAx LmNydDCCASwGA1UdHwSCASMwggEfMIIBG6CCARegggEThj9odHRwOi8vY3JsLnJpbS5uZXQvQmxh Y2tCZXJyeSUyMENvcnBvcmF0ZSUyMFBvbGljeSUyMENBJTIwMS5jcmyGgc9sZGFwOi8vL0NOPUJs YWNrQmVycnklMjBDb3Jwb3JhdGUlMjBQb2xpY3klMjBDQSUyMDEsQ049U3ViQ0EsQ049Q0RQLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwggYSBgNVHSAEggYJMIIGBTBBBgorBgEEAZtKFAIBMDMw MQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYB BAGbShMBAzAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQu aHRtMEEGCisGAQQBm0oTAQIwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQ U3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0u bmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMCAzAzMDEGCCsGAQUFBwIBFiVodHRw Oi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTAgIwMzAxBggrBgEF BQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwIB MDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYK KwYBBAGbShMDAzAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1l bnQuaHRtMEEGCisGAQQBm0oTAwIwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3Bz L0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwMBMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5y aW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMEADAzMDEGCCsGAQUFBwIBFiVo dHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBQMwMzAxBggr BgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtK EwUCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0w QQYKKwYBBAGbShMFATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0 ZW1lbnQuaHRtMEEGCisGAQQBm0oTBgMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQv Y3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwYCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9j cC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMGATAzMDEGCCsGAQUFBwIB FiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBwMwMzAx BggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEE AZtKEwcCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5o dG0wQQYKKwYBBAGbShMHATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BT dGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTCAMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5u ZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwgCMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMIATAzMDEGCCsGAQUF BwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMBAGCSsGAQQBgjcVAQQD AgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUAA4ICAQAeVuw/L3Zy FbBCOhKq5sL9OrBp4G1j4r6C2WJN2BuAoN4fOdzw7H27Y60d8otCRquP8G/AvQ43dJCsE7kld10v tOs2L4T17T3OHxVoMEU39zoIjgu3x7pVUWNf6HCd3QDwWbQZrLIpPWh4ipvIRipQlizCBfDxmbsJ H/BBiiWl5RC7fnWHbEfdbbHPDWyZ/9CsM2XpGdMgYg82LXWBUzGbKSwtoya0wHEEMlhM9D5MaQkm DmYwJOI9m+ryyZMnYYo28ZvW6khFl/Frd/Y77aSOIgtNTXQ+S86xW4PBJJ1jqoal1xt4jYrWWRBE 0wvpZygMoRFCRMsBGvr/r5rqZ9QcN+OX3tmUOC2rtqH9qQKzABJCDetqB16Oyynx1cvUN/x3p1LM Cd3YcqE4ppRxwvX+377msqZamYjHRMuwM1I2RpuVbMdbEwTIHeb17WgRmHkRWF1yKf1XRxN9ywp0 BzkK0tBvN+yMjJSXiZITYAb0U6WxrtEHWdr1CyJPuSrUzwkx0NdCrImlvwo6froM5h3crRXhUgkm +eNPZhiZ2cBG2OaOX8XKUtounkbqVEbblUy1tLIaxUwYw2j+BcKWrbQsoW798S37b7hJWVVE048I gOfRemUiP7yZ5nh0+SQ6+jTVRaWAba8nawivkrv0ja/k1QwzZD9p7nUSvmizKhbCYzGCAiwwggIo AgEBMGQwVjETMBEGCgmSJomT8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEqMCgGA1UE AxMhQmxhY2tCZXJyeSBDb3Jwb3JhdGUgSXNzdWluZyBDQSAxAgpWcQ2NAAAAAh9xMAkGBSsOAwIa BQCggZ4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwNTExMTU1 NTEwWjAjBgkqhkiG9w0BCQQxFgQUkBQLAm3mEmnOs733f7LKujHS9/swPwYJKoZIhvcNAQkPMTIw MDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG 9w0BAQEFAASCAQBZnkRbRya7ZJUflvFat1ymhD/CIM7thfYOX5k40YDpMNIWAcGLRs2VFVY0N+fw d3ZXbwntcXI2alTTLkuIc1dWas2L8ShoBP6G5hmvZvGsJh88cqgkA+eqW2MAhsLVtozHErk7tTQl rGe1fEULWGsbQqN5YhzM99dkAr5Q8Q5P+fkT0F0gPWPe4NOwCefColTsbFzDICfRZ3NlfSd9H5RG W6emAhmvCPWpuh3q7lxf+6YvhoG7NqV7SPxHEcP+u1DsbHtHbuhn8YAJ3NcRgRQToxSQdecPf0aX /rccZeiJjk+tBMpWRLaFcoI/btNOf0BrlNT7lLGWv5QS29QZwPyjAAAAAAAA ------=_NextPart_000_000C_01D3E91E.E99393D0-- From nobody Fri May 11 08:58:42 2018 Return-Path: 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 E53AC12741D for ; Fri, 11 May 2018 08:58:40 -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 AronaUj9M_Mo for ; Fri, 11 May 2018 08:58:38 -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 3A3F0126CB6 for ; Fri, 11 May 2018 08:58:38 -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 w4BFwXgL003065 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 11 May 2018 17:58:35 +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 w4BFwUVK003051 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 11 May 2018 17:58:33 +0200 (MEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=informatik.hu-berlin.de; s=mailbox; t=1526054313; bh=ExJfsx725PcVe5ZqYDE9GNyWj3jJ+nvPEvDZzjZ2djY=; h=Subject:To:References:From:Date:In-Reply-To; b=WEzcFLgqlu2fiNgqwZq+JAcHiUdDh8HqqyGqYnARW/+Mz3XqEOU2+UUjnxfAH/cuQ 0ehxjsZjQtoF+2MAXkFWvTrAh9PG5+teaSkU6PiULW/lLkSbDpn0OZX3im2y7HdGmU UcCAMRYu1F5jiE9s+tvEoAc0ev/DhXkt38zb8elU= 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> <689887b5-b034-5c4c-648c-3854321ce2c7@free.fr> From: Ernst G Giessmann 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: Date: Fri, 11 May 2018 17:58:29 +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: <689887b5-b034-5c4c-648c-3854321ce2c7@free.fr> Content-Type: multipart/alternative; boundary="------------C565284FDB8C78E25EF58355" 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 17:58:35 +0200 (MEST) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 15:58:41 -0000 This is a multi-part message in MIME format. --------------C565284FDB8C78E25EF58355 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Am 2018-05-11 um 12:09 schrieb Denis: > 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 > 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. > Yes, and therefore you can use any hash function (in the sense of ISO), because the output of a hash function is **always** a bit string. /Ernst. --------------C565284FDB8C78E25EF58355 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Am 2018-05-11 um 12:09 schrieb Denis:
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.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.
Yes, and therefore you can use any hash function (in the sense of ISO), because the output of a hash function is **always** a bit string.
/Ernst.
--------------C565284FDB8C78E25EF58355-- From nobody Fri May 11 09:13:11 2018 Return-Path: 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 9D52B1241F8 for ; Fri, 11 May 2018 09:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com 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 U6QEYMKC34JZ for ; Fri, 11 May 2018 09:13:08 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24017120047 for ; Fri, 11 May 2018 09:13:08 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id m16-v6so7704284qtg.13 for ; Fri, 11 May 2018 09:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Q816BMlKdiIOhQg8tASfJS7lwq/Zcu7RHn5U/7ZbsTY=; b=Y+VsRliHl/6YAGMmFy1DHpsu8i93hg7IVyXHz5BRUKYzLeAcwx9J2gnJD16Oxvem/u fMDt88SS9m05Bz3BZGoNdOK05Lv1AcAKHDik9W/9h8DzQ086AOkq2/0gO1JmBJ+hhESE ZflnhFEJyXjmvrJafywTgY8dQTAaAXx26RRKMORKHc9YsUUIW1u1urFihTmWDN16CPxz UaiK/txo1ptVb1DyU5BvrH57o8cN8BGQ/EE/6Be6EuMQLsjWerp3UrtSjH1bdlu0BN2k X6/mF+/1JMaRI6rDvzYNRPdWw2qyorltOhbEVxsln9abtQlmTZrycmlpUujEd6Xz3HdG JLiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Q816BMlKdiIOhQg8tASfJS7lwq/Zcu7RHn5U/7ZbsTY=; b=j2+4hrAnx4EfmnhGuBhksoxxlm+46Ur8vAf96Jxo7Lxxj4b2H/42QB7bOyRgJ9fTK/ 4Xrr5H/bXbzojFuOepE/cjglRwV5sW01DWoI8SYcYiOMUk33l1A+SLvQYMDrvmbZGRd/ 9r5SFKWa9i2zIqy5UAb4qxVMHune7UDDCVjiDkmapiedIly4KBbmu3+pIscxhdbjwHpv Qa+UtEt27I6i7ySBrubZC8sGZZO+wKnJrocSY0SVllER+nRtu9O9hLbw/hb7562OkC9Z fDT0XPnAUH/haZiV0mWI1UnG7U2brtDB0+v/cB4O4eFZ/XnUoR99+GZNo3P1f6OkRdp3 yChA== X-Gm-Message-State: ALKqPweJh6FxMbsDhMdz09mnhnpQDLSWwanKvcL7li2y6CqgqEpKqXyW 3yiNb3eIpub2ZVbJWXz4HBFA6ji7 X-Google-Smtp-Source: AB8JxZrHSfY/GMiG0Ig5N1JDTs83lYdc39sXyefjEceM5i6zO869pdi6D4YFiG2pVJKVXS+GlvZUHA== X-Received: by 2002:aed:3dcb:: with SMTP id j11-v6mr5628282qtf.404.1526055186784; Fri, 11 May 2018 09:13:06 -0700 (PDT) Received: from ?IPv6:2601:152:4400:4013:359a:e137:5d4c:dd19? ([2601:152:4400:4013:359a:e137:5d4c:dd19]) by smtp.gmail.com with ESMTPSA id z5-v6sm2970508qtb.88.2018.05.11.09.13.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 May 2018 09:13:06 -0700 (PDT) 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> <689887b5-b034-5c4c-648c-3854321ce2c7@free.fr> From: Michael StJohns Message-ID: <9c321145-0889-bbc1-1a08-c996b139af8f@nthpermutation.com> Date: Fri, 11 May 2018 12:12:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <689887b5-b034-5c4c-648c-3854321ce2c7@free.fr> Content-Type: multipart/alternative; boundary="------------158C7B191C1FCFCE32381253" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 16:13:11 -0000 This is a multi-part message in MIME format. --------------158C7B191C1FCFCE32381253 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 > 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 > > 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 >>> >>> *Cc:* IETF PKIX >>> *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 >>> >> > 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 --------------158C7B191C1FCFCE32381253 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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.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.

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> 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>
Cc: IETF PKIX <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> 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


--------------158C7B191C1FCFCE32381253-- From nobody Fri May 11 09:34:54 2018 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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> <689887b5-b034-5c4c-648c-3854321ce2c7@free.fr> <9c321145-0889-bbc1-1a08-c996b139af8f@nthpermutation.com> From: Ernst G Giessmann 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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 16:34:52 -0000 This is a multi-part message in MIME format. --------------8D3C7AF0639FF864EA0B3610 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 >> 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 >> > 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 >>>> >>>> *Cc:* IETF PKIX >>>> *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 >>>> >>> > 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 --------------8D3C7AF0639FF864EA0B3610 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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.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.

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> 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>
Cc: IETF PKIX <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> 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

--------------8D3C7AF0639FF864EA0B3610--