3 ms·

Both time and location based encryption frequently appear as plot devices in fiction, but both are not really the subject of cryptography. At the core both of t

Both time and location based encryption frequently appear as plot devices in fiction, but both are not really the subject of cryptography. At the core both of these simply require measurement of a physical quantity (position, time elapsed) to release some bits of information. This is something cryptography inherently can't do. You either end up changing the problem (unlocks not before X => unlocks after spending X amount of time computing) or relying on someone/somethey to proxy the measurement in a trustworthy manner to you (the blockchain-blackbox approach). (You can't do "location based encryption" even if you bring your own trusted computing enviroment plus GNSS receiver, because GNSS emulators exist)

Terr_ 7y ago
> location based encryption Well, you can if the encryption key requires information that can only be collected from that location. The simplest example would be to put the encryption key on a piece of paper and tuck it under a rock. Now somebody has to reach that location in order to decrypt your message. Time-based encryption is fundamentally different, since the sender can't travel into the future to lay unpredictable clues in advance.
- vbrandl 7y ago
  This reminded me of dead drops: https://deaddrops.com/ https://deaddrops.com/
MaxBarraclough 7y ago
> This is something cryptography inherently can't do. You either end up changing the problem (unlocks not before X => unlocks after spending X amount of time computing) or relying on someone/somethey to proxy the measurement in a trustworthy manner to you (the blockchain-blackbox approach). If we were serious about timelocks, we'd just use trusted key-management services, i.e. the CAs. It would even be possible to use several, without placing total trust in any one of them. Each CA would publish a huge set of public keys, each one associated with a date on which the corresponding private key will be published. We generate a symmetric crypto key, then encrypt our blob using it, then publish the resulting encrypted blob (withholding the key of course). Now we 'split' the symmetric crypto key into c-many constituents (called shares), n-many of which are required to recover our symmetric crypto key, where c equals the number of CAs, and n is some number less than c, let's say, c/2. This is possible using Shamir's secret-sharing algorithm. [0] Then we take the various CA's public keys for the desired date (so we have c-many public keys here). We encrypt each share with a different public key, and publish all the resulting encrypted shares. All this means that someone can only get our symmetric decryption key once n-many of the CAs have published their date-specific private-key. The various CAs would not need to cooperate in any way for this scheme to work. Indeed, it would be ideal for the CAs to be highly diverse, minimally associated with each other, and in different countries. Assumptions: * We assume the crypto scheme that we originally used to encrypt the blob, doesn't get broken before the chosen date * We assume the CAs don't all go bust, or lose the date-specific private keys, or otherwise fail to publish them at the proper date. We can adjust n to cope with some proportion of them failing. * We assume the CAs can be trusted to ensure no premature release of date-specific private keys, whether deliberate or not. For this to be an issue, n-many of them would need to leak. I think these assumptions are reasonable. The CAs are already making money on document-signing, to prove a document is no younger than claimed. I can't see a reason why there shouldn't already be a date-specific-key service like what I've described, but I don't know of any. [0] https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing [1] https://www.globalsign.com/en/digital-signatures/ https://www.globalsign.com/en/digital-signatures/

Terr_ 7y ago

> location based encryption Well, you can if the encryption key requires information that can only be collected from that location. The simplest example would be to put the encryption key on a piece of paper and tuck it under a rock. Now somebody has to reach that location in order to decrypt your message. Time-based encryption is fundamentally different, since the sender can't travel into the future to lay unpredictable clues in advance.

vbrandl 7y ago
This reminded me of dead drops: https://deaddrops.com/ https://deaddrops.com/

MaxBarraclough 7y ago

> This is something cryptography inherently can't do. You either end up changing the problem (unlocks not before X => unlocks after spending X amount of time computing) or relying on someone/somethey to proxy the measurement in a trustworthy manner to you (the blockchain-blackbox approach). If we were serious about timelocks, we'd just use trusted key-management services, i.e. the CAs. It would even be possible to use several, without placing total trust in any one of them. Each CA would publish a huge set of public keys, each one associated with a date on which the corresponding private key will be published. We generate a symmetric crypto key, then encrypt our blob using it, then publish the resulting encrypted blob (withholding the key of course). Now we 'split' the symmetric crypto key into c-many constituents (called shares), n-many of which are required to recover our symmetric crypto key, where c equals the number of CAs, and n is some number less than c, let's say, c/2. This is possible using Shamir's secret-sharing algorithm. [0] Then we take the various CA's public keys for the desired date (so we have c-many public keys here). We encrypt each share with a different public key, and publish all the resulting encrypted shares. All this means that someone can only get our symmetric decryption key once n-many of the CAs have published their date-specific private-key. The various CAs would not need to cooperate in any way for this scheme to work. Indeed, it would be ideal for the CAs to be highly diverse, minimally associated with each other, and in different countries. Assumptions: * We assume the crypto scheme that we originally used to encrypt the blob, doesn't get broken before the chosen date * We assume the CAs don't all go bust, or lose the date-specific private keys, or otherwise fail to publish them at the proper date. We can adjust n to cope with some proportion of them failing. * We assume the CAs can be trusted to ensure no premature release of date-specific private keys, whether deliberate or not. For this to be an issue, n-many of them would need to leak. I think these assumptions are reasonable. The CAs are already making money on document-signing, to prove a document is no younger than claimed. I can't see a reason why there shouldn't already be a date-specific-key service like what I've described, but I don't know of any. [0] https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing [1] https://www.globalsign.com/en/digital-signatures/ https://www.globalsign.com/en/digital-signatures/