5

I'm looking for a standard, or sound industry practice, for the equivalent of a Key Check Value, applied to the private key of a public key algorithm, like ECDSA.

For DES or 3DES keys, practice (as worded e.g. in EMV Card Personalization Specification) is:

6.1.5 Key Check Value
Purpose: The data is used to prove that a card/processor has access to a specific DES key value.
Format: Binary, 3 bytes
Contents: The three leftmost bytes of the result of encrypting eight bytes of zeros by the DES key concerned.

Notice that the above definition is slightly wrong: the KCV as defined does not prove anything beyond knowledge of the KCV. The actual purpose (and the one I'm interested about) is to guard against a wrong value of the key, either accidental, or deliberate from one participant in a scheme where the key is rebuilt from shared secrets (for simplicity, assume that's by XOR of the components, and that at least one participant does not cheat).

Raoul722
  • 2,836
  • 2
  • 20
  • 39
fgrieu
  • 140,762
  • 12
  • 307
  • 587
  • 1
    Public key fingerprints are used by SSH (and other protocols). – CodesInChaos May 07 '15 at 12:57
  • For your secret sharing scenario my first instinct is using an all-or-nothing transform on the plaintext together with some redundancy, similar to OAEP. Should probably the unkeyed equivalent of a strong pseudo-random-permutation. – CodesInChaos May 07 '15 at 12:58
  • For my modest knowledge, in PKI, KCV sound to be irrelevant. For symetric system KCV is nothing than the encryption of a given tag to be convinced of using the secret key without knowing its value.In ECDSA encrypting twice the same message gives two distinct results – Robert NACIRI May 08 '15 at 00:09
  • 1
    Note that the standard KCV for symmetric keys leaks the first 3 (or more) bytes of plaintext for CTR mode with an initial counter set to all zeros. That's not a good choice. For symmetric keys a hash is a better option, and for RSA I think it is quite common to perform a hash over the modulus. I don't see how you could do this for ECDSA however. Maybe a hash over the x coordinate of the public key is possible, if I'm not mistaken it's relatively fast to calculate the public key point from the secret S given the domain parameters. Can somebody confirm that this is a good idea? – Maarten Bodewes May 12 '15 at 00:46

1 Answers1

3

PKCS10 looks like relevant industry practice for private keys.

See "Note 2" at page 4, Certification Request Syntax Specification - RFC 2986: The signature on the certification request prevents an entity from requesting a certificate with another party's public key.

That is, soneone requesting a certificate on a public key demonstrates his knowledge of corresponding private key by producing a signature verifiable with the public key from PKCS10 request.

Another technique could be found at Join protocol, Direct Anonymous Attestation for Trusted Platform Module chip. It could be considered a proof that TPM "has access" to "keys" $f_0$ and $f_1$.

Community
  • 1
Vadym Fedyukovych
  • 2,267
  • 13
  • 19
  • That indeed matches the question as asked. However there's a significant issue: it's big! – fgrieu May 10 '15 at 16:05
  • @fgrieu It's clear that message size is of primary concern in smartcards. Any signature or a proof of knowledge would fit this idea. Let's wait, hopefully someone would suggest another (of small size) solution. – Vadym Fedyukovych May 10 '15 at 17:27