Subject: [pkix] Question about Curve P-192

From: Denis <[email-masked]>
Date: Thu, 10 May 2018 19:07:13 +0200

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

---

From: Ernst G Giessmann <[email-masked]>
Date: Thu, 10 May 2018 19:24:51 +0200

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:
> Is there any RFC or any another document that specifies a
> cryptographic suite for Curve P-192 ?
>
> Denis
>
>  
>
>
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Russ Housley <[email-masked]>
Date: Thu, 10 May 2018 13:30:26 -0400

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-masked]> wrote:
> 
> 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.
> 
>> 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 RFC or any another document that specifies a cryptographic suite for Curve P-192 ?
>> 
>> Denis
>> 
>>  
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/pkix <https://www.ietf.org/mailman/listinfo/pkix>
>

---

From: Dan Brown <[email-masked]>
Date: Thu, 10 May 2018 18:51:00 +0000

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-masked]] On Behalf Of Russ Housley
Sent: Thursday, May 10, 2018 1:30 PM
To: Ernst G Giessmann <[email-masked]>
Cc: IETF PKIX <[email-masked]>
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-masked] <mailto:[email-masked]>
> 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.

Hello everybody,

There is no "SHA-192" hash function defined in FIPS PUB 180-4 (Secure Hash
Standard (SHS)).

Denis

---

From: Denis <[email-masked]>
Date: Thu, 10 May 2018 23:46:48 +0200

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

> 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.
>
> 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-masked]] *On Behalf Of *Russ Housley
> *Sent:* Thursday, May 10, 2018 1:30 PM
> *To:* Ernst G Giessmann <[email-masked]>
> *Cc:* IETF PKIX <[email-masked]>
> *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
>
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     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.
>

---

From: Michael StJohns <[email-masked]>
Date: Fri, 11 May 2018 00:51:52 -0400

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-masked]> wrote:

> 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.
>
> The title of this paper is : Performance Analysis of SHA Algorithms (SHA-1
> and SHA-192): A Review
> The corresponding signature suite can be defined with ISO 14888-3, which
> allows the specification of the algo
>
> 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,
>
>
>
> deprecated, I don’t recall off-hand. I recall added text to ANSI X9.62/63
> *From:* pkix [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Russ Housley
> <[email-masked]>
> *Cc:* IETF PKIX <[email-masked]> <[email-masked]>
> SHA-224 and take the 192 left most bits of the hash value as the input to
> the EC sign primitive.
> pkix mailing [email-masked]://www.ietf.org/mailman/listinfo/pkix
>
>

---

From: Denis <[email-masked]>
Date: Fri, 11 May 2018 12:09:13 +0200

Michael,

I don't see how RFC 5480 can be used to obtain an *identifier* for a 
cryptographic *suite* for both P-192 and
a SHA-256 hash function truncated to 192 bits.

In between, I got a response why the leftmost bits shall be used.

Close to the end of section 6.4NIST FIPS 186-4 
<http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf> states:

    When the length of the output of the hash function is greater than
    the bit length of /n/, then the *leftmost **/n/**bits* of the hash
    function
    output block *shall be used* in any calculation using the hash
    function output during the generation or verification of a digital
    signature.

    A hash function that provides a lower security strength than the
    security strength associated with the bit length of n ordinarily
    *should not*
    be used, since this would reduce the security strength of the
    digital signature process to a level no greater than that provided
    by the hash function.

Denis

> 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.
>
> 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-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Ernst, Russ and Dan,
>
>     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).
>
>     P-192 seems to be a good trade-off between the security level and
>     the size of the digital signature.
>
>     The title of this paper is : Performance Analysis of SHA
>     Algorithms (SHA-1 and SHA-192): A Review
>     So Ernst's method would certainly be one way to do it, but why not
>     take the 192 low bits ?
>
>         The corresponding signature suite can be defined with ISO
>         14888-3, which allows the specification of the algo
>
>     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,
>>
>>     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
>>
>>
>>     <mailto:[email-masked]>
>>     *Cc:* IETF PKIX <[email-masked]> <mailto:[email-masked]>
>>      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
>>
>>         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.
>>

---

From: Dan Brown <[email-masked]>
Date: Fri, 11 May 2018 14:23:52 +0000

Denis,

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

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”.  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’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:[email-masked]] On Behalf Of Denis
Sent: Friday, May 11, 2018 6:09 AM
Cc: [email-masked]
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.

Close to the end of section 6.4 NIST FIPS 186-4 <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>  states:

When the length of the output of the hash function is greater than the bit length of n, then the leftmost n bits of the hash function 
output block shall be used in any calculation using the hash function output during the generation or verification of a digital signature.

A hash function that provides a lower security strength than the security strength associated with the bit length of n ordinarily should not 
be used, since this would reduce the security strength of the digital signature process to a level no greater than that provided by the hash function.

Denis

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

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

Lastly, AFAICT NIST didn’t originally define the P192 curve - it just incorporated a previously defined curve in a set of acceptable parameters when it was NISTifying EC cryptography.

Mike

On Thu, May 10, 2018 at 17:47 Denis <[email-masked] <mailto:[email-masked]> > 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 corresponding signature suite can be defined with ISO 14888-3, which allows the specification of the algo 

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,

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-masked]] On Behalf Of Russ Housley
Sent: Thursday, May 10, 2018 1:30 PM
To: Ernst G Giessmann  <mailto:[email-masked]> <[email-masked]>
Cc: IETF PKIX  <mailto:[email-masked]> <[email-masked]>
Subject: Re: [pkix] Question about Curve P-192

 Ernst:

 Russ

  On May 10, 2018, at 1:24 PM, Ernst G Giessmann <[email-masked] <mailto:[email-masked]> > wrote:

Hello everybody,

Denis

---

From: Denis <[email-masked]>
Date: Fri, 11 May 2018 17:31:37 +0200

Dan,
> 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.
> 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:[email-masked]] *On Behalf Of *Denis
> *Sent:* Friday, May 11, 2018 6:09 AM
> *Cc:* [email-masked]
>     the bit length of /n/, then the *leftmost **/n/**bits*of the hash
>     function
>     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
>
>         Thank your for your replies. This is what I feared : there is
>         no cryptographic suite defined for P-192.
>         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.
>
>         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,
>
>             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.
>
>             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.
>
>             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
>
>              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
>
>                 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.
>
>                     There is no "SHA-192" hash function defined in
>                     FIPS PUB 180-4 (Secure Hash Standard (SHS)).
>
>                     Is there any RFC or any another document that
>                     specifies a cryptographic suite for Curve P-192 ?
>
>                     Denis
>

---

From: Dan Brown <[email-masked]>
Date: Fri, 11 May 2018 15:55:11 +0000

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

From: pkix [mailto:[email-masked]] On Behalf Of Dan Brown
Sent: Friday, May 11, 2018 10:24 AM
To: Denis <[email-masked]>
Cc: [email-masked]
Subject: Re: [pkix] Question about Curve P-192

Denis,

I hope that helps,

Best regards,

Dan

 

From: pkix [mailto:[email-masked]] On Behalf Of Denis
Sent: Friday, May 11, 2018 6:09 AM
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [pkix] Question about Curve P-192

Michael,

Denis

Mike

Hi Ernst, Russ and Dan,

Denis

Hi Denis,

 Best regards,

Dan

 Ernst:

 Russ

Hello everybody,

Denis

---

From: Ernst G Giessmann <[email-masked]>
Date: Fri, 11 May 2018 17:58:29 +0200

>     digital signature process to a level no greater than that provided
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.

---

From: Michael StJohns <[email-masked]>
Date: Fri, 11 May 2018 12:12:59 -0400

> 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

>     digital signature process to a level no greater than that provided

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

>>     P-192 would be used in a constrained environment where the size
>>     of the digital signature matters (i.e. the smaller, the better).
>>
>>>         should be SHA-224 and take the 192 left most bits of the
>>>         hash value as the input to the EC sign primitive.

---

From: Ernst G Giessmann <[email-masked]>
Date: Fri, 11 May 2018 18:34:42 +0200

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:
>>     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
>>     function output during the generation or verification of a
>>     digital signature.
>>
>>     digital signature process to a level no greater than that
>>     provided by the hash function.
>>
>
> 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
>>
>>> just incorporated a previously defined curve in a set of acceptable
>>>>     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
>>>>     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.
>>>>
>>>>     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
>>>>
>>>>      
>>>>