Re: [pkix] Question about Curve P-192

[Michael StJohns <[e-mail]>]

On 5/11/2018 6:09 AM, Denis wrote:
> Michael,
>
> I don't see how RFC 5480 can be used to obtain an *identifier* for a 
> cryptographic *suite* for both P-192 and
> a SHA-256 hash function truncated to 192 bits.

Well - suite's don't have identifiers, algorithms (signature schemes) 
do.  In this case, 5480 says that any of the ECDSAwithSHA1, SHA224, 
SHA256, SHA384 and SHA512 signature algorithms can be used with 
secp192r1 (which is the same as P-192 - see page 18 of this document) 
and will provide no less than 80 bits of security.  that's from the 
table on page 9.

The table on page 10 even gives a recommended signature function - 
ECDSAwithSHA256 - for secp192r1.

And finally, the identifier for that signature scheme is on page 17

   ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
      iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
      ecdsa-with-SHA2(3) 2 }

1.2.840.10045.4.3.2

>
> In between, I got a response why the leftmost bits shall be used.
>
> Close to the end of section 6.4NIST FIPS 186-4 
> <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf> states:
>
>     When the length of the output of the hash function is greater than
>     the bit length of /n/, then the *leftmost **/n/**bits* of the hash
>     function
>     output block *shall be used* in any calculation using the hash
>     function output during the generation or verification of a digital
>     signature.
>
>     A hash function that provides a lower security strength than the
>     security strength associated with the bit length of n ordinarily
>     *should not*
>     be used, since this would reduce the security strength of the
>     digital signature process to a level no greater than that provided
>     by the hash function.
>

All of ANSI X9.63, NIST 186-4 and SECG 1 describe the conversion of a 
hash value (a string of octets output from the hash) to a positive big 
integer of an appropriate size which is used as the input to the ECDSA 
calculations.   This is all mostly hidden under the covers of the 
implementations, and a proper implementation should do the left 
truncation silently if necessary and produce the correct result 
regardless of the input curve of the private key.  I checked the java EC 
implementation and bouncycastle's implementation and both have code that 
does this.

Later, Mike

> Denis
>
>> Actually see RFC5480.  It describes a set of suggested pairings of 
>> signature strengths and hashes and includes recommendations for P-192.
>>
>> Re Russ’s comment, the ECDSAWithShaxxx identifiers can be used with 
>> any curve, (but follow the 5480 and other similar document pairing 
>> recommendations)   so it’s not exactly correct that there are no 
>> algorithm identifiers.
>>
>> Lastly, AFAICT NIST didn’t originally define the P192 curve - it just 
>> incorporated a previously defined curve in a set of acceptable 
>> parameters when it was NISTifying EC cryptography.
>>
>> Mike
>>
>> On Thu, May 10, 2018 at 17:47 Denis <[e-mail] 
>> <mailto:[e-mail]>> 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:[e-mail]] *On Behalf Of *Russ
>>>     Housley
>>>     *Sent:* Thursday, May 10, 2018 1:30 PM
>>>     *To:* Ernst G Giessmann <[e-mail]>
>>>     <mailto:[e-mail]>
>>>     *Cc:* IETF PKIX <[e-mail]> <mailto:[e-mail]>
>>>     *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
>>>     <[e-mail]
>>>     <mailto:[e-mail]>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix