You create a hash chain, then use the final result as an encryption key of your secret (in this case, the key for the data), then store only the start of the chain and encrypted secret.
The only way to retrieve the secret is to recompute all the hashes, from the start, to recreate the key and decrypt the data.
So it’s secure unless you believe there’s a weakness in the underlying encryption or hash function.
Further, you can parallelize this via encrypting the start of chains with other chains — giving a significant advantage to the chain creator: they can do 1000 chains in parallel, but unlocking requires decrypting them sequentially. At that ratio, if you want decryption to take a month of steady hashing, you need only do a little under 1 hour of hashing yourself. 1 hour of 1 GPU is about a dollar of expense, and has more than 1000 parallel tracks.
My suggestion would be that Apple create a chain for each phone and then load it with that phone specific wrapping key — which it uses to return the actual encryption key wrapped in. The only way to decrypt that key is get the necessary information from Apple and a signed request so the SE will emit the encrypted key at all.
Yeah uhh hey I appreciate your enthusiasm but this literally is not how modern public key encryption works, or will ever be changed to work. All ciphers in general use don't have any sort of a realistic time-bound to being cracked or computed
I appreciate you trying to correct me, but I never was saying that this was an instance of “public key encryption”, whichever version you mean.
This is a scheme by which you can intentionally create a key that can be re-generated in a fixed amount of time, and use it as part of normal symmetric encryption to protect a secret. One usage of that is creating intentionally crackable schemes, such as protecting other signing keys in a way you can later crack if you need to. This allows a device, such as a phone, to emit a masked secret that we have cryptographic guarantees it still takes time to recover.
Hashchains for time locking is a studied mechanism, and though it predates crypto currencies, it’s deployed as a mechanism in several kinds of applications there. A second usage is in storing paper copies of master signing keys in a safe, since the key cannot be exposed in the event of a robbery before a certain period of time — giving you time to rekey your system. (Generally, people use multipart keys instead, because they’re less cumbersome to recover; however, if you only have one secure location — multipart keys don’t help. Hash chains still do.)
So it’s literally how (part of) modern cryptography works.
You create a hash chain, then use the final result as an encryption key of your secret (in this case, the key for the data), then store only the start of the chain and encrypted secret.
The only way to retrieve the secret is to recompute all the hashes, from the start, to recreate the key and decrypt the data.
So it’s secure unless you believe there’s a weakness in the underlying encryption or hash function.
Further, you can parallelize this via encrypting the start of chains with other chains — giving a significant advantage to the chain creator: they can do 1000 chains in parallel, but unlocking requires decrypting them sequentially. At that ratio, if you want decryption to take a month of steady hashing, you need only do a little under 1 hour of hashing yourself. 1 hour of 1 GPU is about a dollar of expense, and has more than 1000 parallel tracks.
My suggestion would be that Apple create a chain for each phone and then load it with that phone specific wrapping key — which it uses to return the actual encryption key wrapped in. The only way to decrypt that key is get the necessary information from Apple and a signed request so the SE will emit the encrypted key at all.