[Cryptography] Is storing a hash of a private key a security risk?

[Phillip Hallam-Baker]

On Tue, Apr 12, 2016 at 8:13 AM, Peter Gutmann
<pgut001 at cs.auckland.ac.nz> wrote:
> For private keys stored in a secure enclave in an embedded environment,
> there's some concern that over long periods of time the key components may be
> subject to bit rot/corruption.  One possible solution is to store a truncated
> hash of the private key components outside the enclave and use that to verify
> that nothing has changed, by asking the enclave whether the stored key
> corresponds to the given hash value.  Without going into a huge amount of
> detail on the specific application, it has to be a hash, it can't be a MAC or
> something similar, and the hash can't be stored inside the enclave because it
> only stores key components (it's a hardware constraint).
>
> This is something that, on the one hand, seems to be not a good idea, but on
> the other hand I can't see any obvious problem that it would cause (you can
> use it to find out whether a given key is stored inside the enclave, but you
> can do that anyway without the hash because you need to identify the key to
> query the enclave whether the hash matches).
>
> Can anyone see any problems with this?  Or suggest an alternative approach
> that doesn't violate the constraints imposed by the hardware?

A better way to phrase the question is probably to ask whether this
introduces more vulnerabilities than a general compromise of hash
functions or the public key algorithm would.


Given that a lot of public key systems break catastrophically if a
single bit fault occurs, this looks like a necessary robustness
countermeasure. However, a better approach is probably using systems
like Diffie Hellman that don't have that problem - although signature
schemes based on them do!

Security is risk management, not risk elimination - as I pointed out
to someone who ad just written about the risks of PKI that people like
me allegedly weren't telling y'all about.