为了澄清，它只能在特定时间解密，例如
2月4日或
11.23 am
或下午1-2点之间
以类似于银行保险箱上的时钟的方式工作。 />显然，这需要对互联网时间服务器进行加密访问，以确保时间信号不被欺骗。
这是否有意义？机制是什么？
我在stackexchange.com上问了这个，但这似乎是一个更好的地方。
#1 楼
加密算法不是时间感知的，因此您需要一个时间感知的第三方来完成此任务。第三方还需要访问安全时间源（例如，现场原子钟或与离岸时钟的安全连接）确切的实现和协议取决于您的用例，但作为例如，您可能拥有一台服务器，该服务器可以执行以下两项操作：
接受包含时间锁定消息和“发布日期”的输入
仅在以下情况允许请求获取消息：邮件的发布日期已过
对于第一种情况，服务器将生成一个足够长度的随机对称密钥，使用该密钥加密邮件，对加密的邮件进行哈希处理，然后添加密钥+哈希+发布一些数据库中的日期。然后，服务器返回散列，该散列用作刚刚被时间锁定的消息的标识符。如果需要的话，它也可以返回加密的消息（大概是，提交消息的实体在希望对其进行时间锁定的那个对象之后销毁了他的纯文本副本）。
然后，在第二种情况下，客户端将标识符发送到服务器。服务器会查找它，并检查发布日期。如果尚未通过，服务器将拒绝并保释，但是如果通过，服务器将仅返回正确的加密密钥（如果需要，还会返回纯文本消息）。
这只是一个示例非常基本的时间锁服务（例如，您可以使用公共密钥加密来增强服务的各个方面）。
您的问题很广泛，也许您应该添加更多详细信息。
评论
$ \ begingroup $
这基本上归结为服务器保留时间，仅根据其（希望正确）的时间返回密钥。没错，可以通过代理重新加密来解决密钥托管问题（假设服务器仅存储加密的数据，而对明文则一无所知），可以对此进行更详细的说明。
$ \ endgroup $
– Artjom B.
2014年8月6日12:47
#2 楼
Rabin和Thorpe在此处撰写了有关此主题的技术报告：“延时加密”
那里也有许多相关的引文。他们还制作了原型的海报：http://www.eecs.harvard.edu/~cat/papers/tlc-poster.pdf。
评论
$ \ begingroup $
+1用于TLC。在一段时间后，它更适合解密，但是可以修改概率以满足OP的要求。如果那是真的，您将最清楚。
$ \ endgroup $
– Mikeikeazo
2012年6月27日上午11:45
$ \ begingroup $
这很有趣，它说时间流逝，但与上面评论中的问题所引用的方式不同，这更接近于我感兴趣的内容。
$ \ endgroup $
– bowy tehcTo
2012年6月27日上午11:54
$ \ begingroup $
真的很酷。我认为可以完全使用椭圆曲线密码术代替El Gamal。 （尽管我没有完全理解VSS机制，所以我不确定是否可以继续使用该机制，但我认为确实可以。）
$ \ endgroup $
–杰弗里·戈德堡（Jeffrey Goldberg）
2013年9月26日15:59
#3 楼
安德鲁·米勒（Andrew Miller）提出的一种密码时锁的理论解决方案是将见证加密（链接）与比特币区块链相结合。见证加密使您可以加密信息，以便用户只有在有权访问满足某些属性的信息的情况下才能解密该信息。在时间锁加密的情况下，所需的信息是一定长度的块链。由于新块平均每10分钟到达一次，因此您可以指定允许解密的时间，最多大约10分钟。从理论上讲，攻击者可以在截止日期之前生成具有必要长度的备用区块链，但是如果他拥有这种计算能力，那么他不妨将其用于获取致富的采矿比特币。评论
$ \ begingroup $
这很有趣。在现实世界中，密钥被放置在一个放射性金库中，该金库会衰减，因此会自行分解。仅在经过一定时间后，保管库会由于衰变而自行打开。
$ \ endgroup $
–adib
16年3月15日在7:05
#4 楼
我不知道您要寻找的任何确切解决方案。就是说，想到了一种设计。就像其他人建议的那样，该协议需要受信任的第三方。其思想是使用多方计算。将有三个参与方，一个发送方，一个接收方和一个受信任的第三方。发送者对消息进行加密并将其发送给接收者。然后，发送方使用秘密共享在接收方和受信任的第三方之间拆分密钥。受信任的第三方还会获得消息何时可以解密的表示形式。
要进行解密，接收方会与受信任的第三方联系，并且他们两者都使用多方计算来生成解密。多方计算可以在其中嵌入当前时间值以及何时可以解密消息的表示形式。
这种方法有一些好处：
接收者将已经有加密的消息（TTP不必存储它）
实际的解密密钥永远不会发布给任何人（因此接收者不能泄漏它，如果TTP是被黑客入侵，它不会被泄露）
解密时间可以保持私密（甚至可能来自TTP）
评论
$ \ begingroup $
您如何在不向TTP透露时间的情况下将时间嵌入多方计算中？
$ \ endgroup $
–dionyziz
2013年12月27日在1:30
$ \ begingroup $
@dionyziz TPP为什么不知道时间？
$ \ endgroup $
–mikeazo
2013年12月27日在1:37
$ \ begingroup $
我指的是您提到的第三点。我对TTP知道时间没有任何问题；但是他们可能不会这样做很尴尬。
$ \ endgroup $
–dionyziz
2013年12月27日下午5:13
$ \ begingroup $
@dionyziz，解密时间可以在发送方与接收方和受信任的第三方秘密共享。这样，谁都不知道何时允许解密。然后，MPC解密电路将对照当前时间检查解密时间，如果它晚于解密时间，则进行解密。如果不晚于该时间，则MPC可能会输出垃圾。然后，TTP不知道解密是否成功。至于什么时候可能有用，则取决于应用程序。
$ \ endgroup $
– Mikeikeazo
2013年12月27日14:23在
#5 楼
加密的基本原理（Kerchoff原理）是解密数据的唯一必要条件就是密钥。因此，您真正的问题是：“我如何才能仅在特定时间内提供完整密钥？”两个明显的答案是：a）仅在该时间段内显示密钥，或b）使密钥仅在该时间段内可知道的数据之上。众所周知，游戏结束了。使用该系统的人始终会作弊，他们可能会在分配的时间段内获取密钥，然后在以后使用它解密数据。因此，对时间设置最终的时间限制真的没有意义，您需要从新的密文/密钥对开始并施加新的时间限制。自我解释：准备好让人们解密数据时，发布密钥。这说起来容易做起来难，但是建立一个客户端/服务器模型以在服务器的时间发布信息是相对简单的。选项（b）将允许采用一种不需要您手动干预的自动化方法，并且它也将使您也不知道加密密钥。但是，您如何了解其他人所不知道的未来呢？在安全性方面，我们倾向于假定任何人都可以永远永远知道任何公开可用的内容，因为将安全性基于希望对手从未获得过公开信息是愚蠢的。因此，不幸的是，这实际上不是一个选择。（a）以外的解决方案将需要超越传统密码学的范围。例如，您需要一个专用平台（软件或硬件），您可以认为该平台是不可破坏的，它将仅在特定时间执行解密操作。
但是，您不能仅仅在任意时间之前就将无法解密的比特交给他人。时间是人类的观念，电子位不在乎我们的时钟说什么。他们最接近时间的概念是从另一组位计算一组位需要多长时间，这涉及到Ricky链接到的“时间胶囊”概念。将人的时间感强加给他们将需要系统进行人为干预。
评论
$ \ begingroup $
“在时间上设置最终时间限制的要点”是，应在最终时间限制到期后，对获得$ \ hspace {0.4 in} $访问诚实使用的系统的用户隐藏数据。 $ \：$
$ \ endgroup $
–user991
2012年6月26日22:16
$ \ begingroup $
信任的领域扩展到接收密钥的每一方。事实发生后，任何人都可以有意或无意地分发它。由于攻击者已经知道密文，因此您必须依靠所有客户端的安全性和完整性。因此，可以将来得太迟的新客户端从解密数据中排除，但前提是您信任每个成功获取密钥的客户端。而且您一开始就从客户那里隐瞒了密钥，这听起来像是他们可能会欺骗。
$ \ endgroup $
– B-Con
2012年6月26日22:25
#6 楼
这个答案来得有点晚，但是……是的，可以制定一个时间锁定的加密算法。锁定的加密货币将是Ronald L. Rivest网站的“出版物”页面，您将在这里找到：
“ Ronald L的时间锁定难题和定时发布的密码” 。Rivest，Adi Shamir和David A. Wagner。
（作为LCS技术备忘录MIT / LCS / TR-684（1996年2月）出现。）
3/10/96版本。 br />
该论文-可在postscript和pdf中免费下载，它讨论了“定时释放加密”和可能的实现选项。
在相同的出版物页面上，您可以找到：
“ LCS35时间胶囊加密难题（描述，Java代码和难题参数）” br />
Ronald L. Rivest（1999年4月4日）的“ LCS35时间胶囊加密难题的描述”以文本格式提供。由于本文还包括Java源代码示例，因此它实际上将为您提供时限加密的许多示例之一。
2013年的论文（PDF）也很有趣： />
Dominique Unruh的“可撤销的量子定时释放加密”
#7 楼
这些论文描述了基于见证加密的理论解决方案：http://eprint.iacr.org/2015/478
http：//eprint.iacr。 org / 2015/482
基本思想显然是在这两部作品中独立发现的。第一篇文章较为正式，包含正式的安全模型和严格的安全分析。第二个是非常非正式的，但也描述了一种新的见证加密机制。
评论
$ \ begingroup $
谢谢，但是请提供链接内容的简短摘要
$ \ endgroup $
– bowy tehcTo
15年5月27日在18:59
#8 楼
我使用普通的AES 256加密。在此之上，我根据您的选择放置了由网页内容生成的单词层。网页更新后，将无法解密。当然，您也许可以访问页面的缓存副本。但是，作为解决问题的实用方法，这很有用。评论
$ \ begingroup $
您可能不知道对手没有保留网页的缓存。
$ \ endgroup $
–吉尔斯'所以-不再是邪恶的'
15年3月23日在11:21
#9 楼
选项号1：您可以通过在将来的某个时刻释放密钥来进行解密选项号2：您知道某个将来的事件，并告诉人们寻找该事件的发生，获取一些信息与之关联并基于此生成密钥。如果此类事件是由您引起的，则为上述选项1，否则，您将依赖外部受信任的“第三方”代理来释放事件
选项3：仅释放部分钥匙，其余的都毁了。这迫使接收者执行蛮力攻击以解码密文。此方法不能保证在将来的某个特定时刻解密，而是对数据强制执行“至少不早于”策略。
评论
crypto.stackexchange.com/questions/606/…请说明：您是否要求“在某个时间”或“在一定时间”内将其解密？ Ricky的链接解决了后者。
在特定时间，例如仅在2月4日或仅在11到12点之间
@RickyDemer这个问题在问一些不同的东西，例如倒数计时，我要问的就像是银行的时间锁。
最好的解决方案可能是使用带有内置时钟的安全，防篡改硬件。解密数据的密钥将使用安全设备已知的密钥进行加密，并且安全设备将接受签名的指令，指定该密钥仅在特定时间解密特定内容。 （例如，KEYLOK要塞。）