# Key Check Value standard practice for asymmetric cryptography?

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

• Public key fingerprints are used by SSH (and other protocols). – CodesInChaos May 7 '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 7 '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 8 '15 at 0:09
• 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 0:46

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