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

  • 1
    $\begingroup$ Public key fingerprints are used by SSH (and other protocols). $\endgroup$ May 7 '15 at 12:57
  • $\begingroup$ 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. $\endgroup$ May 7 '15 at 12:58
  • $\begingroup$ 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 $\endgroup$ May 8 '15 at 0:09
  • 1
    $\begingroup$ 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? $\endgroup$
    – Maarten Bodewes
    May 12 '15 at 0:46

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

  • $\begingroup$ That indeed matches the question as asked. However there's a significant issue: it's big! $\endgroup$
    – fgrieu
    May 10 '15 at 16:05
  • $\begingroup$ @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. $\endgroup$ May 10 '15 at 17:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.