Re: Question about Curve P-192

Denis, you are right, the signature value is tagged with the OID
ecdsa-with-...
This gives the signature suite identifier. The key used for signing is
tagged with the curve (e.g. P-192).
But due to the truncation it makes no sense to use a SHA-512 with P-192
or P-256.
/Ernst.

Am 2018-05-11 um 18:12 schrieb Michael StJohns:
> On 5/11/2018 6:09 AM, Denis wrote:
>> Michael,
>>
>> I don't see how RFC 5480 can be used to obtain an *identifier* for a
>> cryptographic *suite* for both P-192 and
>> a SHA-256 hash function truncated to 192 bits.
>
> Well - suite's don't have identifiers, algorithms (signature schemes)
> do.  In this case, 5480 says that any of the ECDSAwithSHA1, SHA224,
> SHA256, SHA384 and SHA512 signature algorithms can be used with
> secp192r1 (which is the same as P-192 - see page 18 of this document)
> and will provide no less than 80 bits of security.  that's from the
> table on page 9.
>
> The table on page 10 even gives a recommended signature function -
> ECDSAwithSHA256 - for secp192r1.
>
> And finally, the identifier for that signature scheme is on page 17
>
>   ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
>      iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
>      ecdsa-with-SHA2(3) 2 }
> 1.2.840.10045.4.3.2
>
>>
>> In between, I got a response why the leftmost bits shall be used.
>>
>> Close to the end of section 6.4NIST FIPS 186-4
>> <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf> states:
>>
>>     When the length of the output of the hash function is greater
>>     than the bit length of /n/, then the *leftmost **/n/**bits* of
>>     the hash function
>>     output block *shall be used* in any calculation using the hash
>>     function output during the generation or verification of a
>>     digital signature.
>>
>>     A hash function that provides a lower security strength than the
>>     security strength associated with the bit length of n ordinarily
>>     *should not*
>>     be used, since this would reduce the security strength of the
>>     digital signature process to a level no greater than that
>>     provided by the hash function.
>>
>
> All of ANSI X9.63, NIST 186-4 and SECG 1 describe the conversion of a
> hash value (a string of octets output from the hash) to a positive big
> integer of an appropriate size which is used as the input to the ECDSA
> calculations.   This is all mostly hidden under the covers of the
> implementations, and a proper implementation should do the left
> truncation silently if necessary and produce the correct result
> regardless of the input curve of the private key.  I checked the java
> EC implementation and bouncycastle's implementation and both have code
> that does this. 
>
> Later, Mike
>
>> Denis
>>
>>> Actually see RFC5480.  It describes a set of suggested pairings of
>>> signature strengths and hashes and includes recommendations for P-192. 
>>>
>>> Re Russ’s comment, the ECDSAWithShaxxx identifiers can be used with
>>> any curve, (but follow the 5480 and other similar document pairing
>>> recommendations)   so it’s not exactly correct that there are no
>>> algorithm identifiers.  
>>>
>>> Lastly, AFAICT NIST didn’t originally define the P192 curve - it
>>> just incorporated a previously defined curve in a set of acceptable
>>> parameters when it was NISTifying EC cryptography.
>>>
>>> Mike
>>>
>>> On Thu, May 10, 2018 at 17:47 Denis <[email protected]
>>> <mailto:[email protected]>> 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:[email protected]] *On Behalf Of *Russ
>>>>     Housley
>>>>     *Sent:* Thursday, May 10, 2018 1:30 PM
>>>>     *To:* Ernst G Giessmann <[email protected]>
>>>>     <mailto:[email protected]>
>>>>     *Cc:* IETF PKIX <[email protected]> <mailto:[email protected]>
>>>>     *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
>>>>     <[email protected]
>>>>     <mailto:[email protected]>> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/pkix
>
>
>
>
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix