Users and Secrets

Cryptography often relies on the user keeping a secret, for example private keys. A private key works as long as the user is the one and the only one that knows it. This immediately leads to the two failure modes of the user losing the key and someone else obtaining it. This is static state, there is also the dynamic element of creating this state and terminating this state.

I'm assuming ideal cryptography. The algorithms provide unbreakable guarantees and entropy generation and disposal is done perfectly. This is not entirely realistic, but this area has seen so much more research than what we will be discussing that it is not worth going into here. I'll just say that an implementation following industry best practices can be expected to live up to these ideals under normal circumstances.

Secret keys

Private keys

1. Loss of secret. No-one knows the secret.
   1. Involuntary: Hardware failure, forgot password, accidental deletion, remote destroy (as part of theft), wiping phone (recovering from backup).
   2. Voluntary: Deliberate deletion.
2. Leak of secret. Someone else also knows the secret.
   1. Involuntary: Malware on device, backdoors, social engineering. Side channel attacks.
      1. Physical attacks
         1. Shoulder surfing.
         2. Cold boot attacks.
      2. Break of cryptography. (i.e. solving discrete logarithm problem)
   2. Voluntary:
3. Access breach. Someone else can do things with the secret, short of knowing it.
   1. Involuntary: Malware, social engineering, back doors.
4. Transfer of private key. Someone else
   1. Involuntary: Theft of unlocked phone. Device theft with breach of encryption.
   2. Voluntary: Transfer of (unlockable) device. Transfer of accounts. Transfer of secret.
5. Loss of user. The user should no longer know the secret.

The trend here seems to be Smart Contract Wallets which avoids secrets and instead allows users to set up their own authentication process (which will likely involve secrets again).

Secure Conditions:

1. Private key secrecy: The user must not share their private key with anyone. The private key must be kept secret at all times.

2. Secure storage: The private key should be stored in a secure way, which could involve strong encryption, secure physical storage (for physical keys or hardware tokens), or secure cryptographic hardware (like a hardware security module).

3. Secure usage: When the private key is used to sign or decrypt data, this should also be done in a secure environment to prevent leaks.

Failure Modes:

If the secure conditions are not met, several things can go wrong:

1. Key exposure: If the private key is leaked or discovered, all security guarantees are lost. An attacker with the private key can read encrypted data, tamper with signed data, and impersonate the key owner.

2. Poor key generation: If the key isn't generated securely (e.g., it's too short, not random enough, or based on a predictable process), an attacker might be able to guess or calculate the private key.

3. Insecure storage or use: If the private key is stored or used insecurely (e.g., it's stored unencrypted on a hard drive, or it's used in a way that leaks information), an attacker might be able to steal or deduce the private key.