【问题标题】:time-based encryption algorithm?基于时间的加密算法?
【发布时间】:2012-07-10 15:31:51
【问题描述】:

我有一个想法,但我不知道在 Google 中使用什么神奇的词 - 我希望在这里描述这个想法,也许有人会知道我在寻找什么。

假设您有一个数据库。大量数据。它是加密的。我正在寻找的是一种加密,通过该加密进行解密,变量 N 必须在给定时间保持值 M(从第三方获得,如硬件令牌),否则无法解密。

想象一下 AES - 好吧,AES 只是一个密钥。如果你有密钥,你就进去了。现在想象一下 AES 以这样一种方式修改,即算法本身需要一个额外的事实,在密钥之上和之外——这个来自外部源的额外数据,以及该数据随时间变化的地方。

这存在吗?有名字吗?

【问题讨论】:

  • 可能类似于 RSA 密钥的工作原理? “当前密码”在哪里以服务器和授权客户端已知的速率随时间变化?在安全方面,您可以搜索的内容是“双因素安全性”。据我所知,有三个主要的安全因素。你知道的东西(密码),你拥有的东西(门禁卡,RSA 钥匙串 fob 等),你是的东西(指纹,视网膜扫描等)。每个额外的因素都比仅仅将其中一个因素加倍增加了更多的安全性。 (例如,密码 + RSA 密钥优于 2 个密码。)
  • 就是这样,除了更多——它实际上是针对数据的加密方式,而不仅仅是为了身份验证。考虑一下我的情况是相反的。与我联系的代理和我需要对代理 (RSA) 进行身份验证不同,在我的情况下,代理(数据库)拥有所有有价值的东西,但它是加密的;我想确保代理只能在我的许可下访问数据,例如这样,如果代理被颠覆,未经我的许可,他仍然无法访问数据。普通的 AES 加密对此没有用,因为代理必须知道密钥。
  • 大声笑,有一个密码堆栈交换 - 谢谢你,代码。我刚刚阅读了链接,虽然很有趣,但它们并不是我真正想到的。我认为我的关键问题是解密算法是否需要一个随时间变化的事实 - 几乎就像多方加密一样。
  • 我不知道答案。您可以从基于身份的加密 (IBE) 中获得类似的信息。在这种情况下,身份包括时间,例如“bob_129210”,但当然这些更重要。您可以从一次性密码 (OTP) 方案中获得类似的信息,其中时间 t 的密码是时间 t-1 的密码的哈希原像。

标签: encryption


【解决方案1】:

在受信任的第三方的帮助下,这很容易做到。是的,我知道,您可能想要一个不需要的解决方案,但请耐心等待——我们会做到的,或者至少接近那个。

无论如何,如果您有合适的受信任第三方,这很容易:使用 AES 加密文件后,您只需将您的 AES 密钥发送给第三方,请他们发送至encrypt it with their own key,将结果发送回给您,并在未来的某个特定时间发布他们的密钥。到那时(但不久之后),任何拥有加密 AES 密钥的人现在都可以解密它并使用它来解密文件。

当然,第三方可能需要大量的密钥加密密钥,每个密钥在不同的时间发布。与其将它们全部存储在磁盘或其他东西上,更简单的方法是让它们从秘密主密钥和指定的发布时间生成每个密钥加密密钥,例如通过对他们应用合适的key-derivation function。这样,可以为任何所需的发布日期或时间生成一个独特且(显然)独立的密钥。

在某些情况下,这种解决方案实际上可能是实用的。例如,“受信任的第三方”可能是具有内置实时时钟和安全外部接口的防篡改hardware security module,允许在任何发布日期对密钥进行加密,但仅在以下日期解密已经过去了。


但是,如果受信任的第三方是提供全球服务的远程实体,则将每个 AES 密钥发送给他们进行加密可能是不切实际的,更不用说潜在的安全风险了。在这种情况下,public-key cryptography 可以提供解决方案:而不是使用symmetric encryption 来加密文件加密密钥(这将要求他们知道文件加密密钥或释放密钥加密密钥),而是由受信任的第三方可以改为为每个发布日期生成一个公钥/私钥对,并立即发布公钥对的一半,但在指定的发布日期之前拒绝披露私钥。任何持有公钥的人都可以用它加密自己的密钥,但在相应的私钥公开之前,任何人都无法解密。

(另一个部分解决方案是使用secret sharing 将 AES 密钥拆分为多个共享,并仅将一个共享发送给第三方进行加密。与上述公钥解决方案一样,这将避免泄露 AES第三方的密钥,但与公钥解决方案不同,它仍然需要加密器和受信任的第三方之间的双向通信。)


上述两种解决方案的明显问题是您(以及其他所有相关人员)确实需要信任生成密钥的第三方:如果第三方不诚实或被攻击者破坏,他们可以很容易地提前公开私钥。

不过,有一个聪明的方法published in 2006 by Michael Rabin and Christopher Thorpe(其中一位作者在this answer on crypto.SE 中提到过)至少可以部分解决这个问题。诀窍是在几个或多或少值得信赖的第三方网络中distribute the key generation,即使有限数量的当事人不诚实或受到损害,他们也无法了解私钥,直到有足够多的各方同意确实是时候释放它们了。

Rabin & Thorpe 协议还可以防止来自受感染方的各种其他可能的攻击,例如试图阻止在指定时间泄露私钥或导致生成的私钥或公钥不匹配。我并没有声称完全理解他们的协议,但是,鉴于它是基于现有和深入研究的密码技术的组合,我认为它没有理由不符合其规定的安全规范。

当然,这里的主要困难在于,要使这些安全规范真正发挥作用,您确实需要一个由密钥生成器组成的分布式网络,该网络足够大,以至于任何单个攻击者都无法合理地破坏他们中的大多数。建立和维护这样一个网络is not a trivial exercise

【讨论】:

  • 有趣的是,Rabin 和 Thorpe 的论文链接是 ftp。这是一个更新的链接:eecs.harvard.edu/~cat/tlc.pdf
  • @DanielQue:谢谢。我已经更新了答案中的链接以使用您的链接。
  • he trick is to distribute the key generation among a network of several more or less trustworthy third parties in such a way that, even if a limited number of the parties are dishonest or compromised, none of them can learn the private keys until a sufficient majority of the parties agree that it is indeed time to release them - 我非常喜欢这个 - 有点像用于加密/访问控制的 Raft 协议! (+1)。
【解决方案2】:

是的,您正在寻找的那种加密存在。它被称为定时发布加密,或缩写为TRE。这是一篇关于它的论文:http://cs.brown.edu/~foteini/papers/MathTRE.pdf

以下是上述论文摘要的节选:

现在有各种各样的电子商务应用程序,例如密封投标拍卖和电子投票,需要对加密数据进行延时解密。文献中至少提供了三种主要类型的协议来提供这种定时发布加密 (TRE)。 它们要么依赖于强制消息的接收者在能够解密之前解决一些耗时、不可并行的问题,要么依赖于使用负责提供解密所需信息的可信实体。 em>

我个人喜欢另一个名字,“时间胶囊密码学”,大概是crypto.stackoverflow.com: Time Capsule cryptography?创造的。

【讨论】:

    【解决方案3】:

    快速回答是否定的:用于解密数据的密钥无法及时更改,除非您定期解密并重新加密所有数据库(我认为这是不可行的)。

    @Ilmari Karonen 建议的解决方案是唯一可行的解​​决方案,但它需要受信任的第三方,此外,一旦获得主 AES 密钥,它就可以在未来重复使用:您不能在该解决方案中使用“一次性垫”。

    【讨论】:

      【解决方案4】:

      如果您希望您的令牌是基于时间的,您可以使用TOTP algorithm

      TOTP 可以帮助您在给定时间 M 为变量 N(令牌)生成一个值。因此,请求访问您的数据库的服务将附加一个使用 TOTP 生成的令牌。在访问提供者端验证令牌期间,您将根据当前时间验证令牌是否持有正确的值。您需要在两端都有一个共享密钥才能生成相同的 TOTP。

      TOTP的优点是值随时间变化,一个token不能重复使用。

      我已经为两因素身份验证实现了类似的东西。

      “一次性密码”可能是您的谷歌词。

      【讨论】:

        【解决方案5】:

        我相信您正在寻找的内容称为公钥加密或公钥加密。 google 的另一个好词是“非对称密钥加密方案”。

        谷歌一下,我很确定你会找到你要找的东西。 欲了解更多信息Wikipedia's article

        一个例子是:Diffie–Hellman key exchange

        编辑(透视事物) 第二个密钥可以通过使用特定时间(例如在插入数据时)生成第二个密钥的算法来确定,该第二个密钥可以存储在另一个位置。

        【讨论】:

          【解决方案6】:

          正如其他人指出的,一次性密码可能是您提出的方案的一个很好的解决方案。

          有一个OTP implemented in C#,你可以看看https://code.google.com/p/otpnet/

          【讨论】:

            【解决方案7】:

            理想情况下,我们想要一个依赖于时间的生成器,但我不知道今天有什么算法可以做到这一点。

            更一般地说,如果 Alice 想让 Bob 在某个特定时间点知道某事,您可以考虑以下设置:

            假设我们有一个公共算法,它有两个参数:一个非常大的随机种子数和该算法将花费的预期秒数来找到问题的唯一解决方案。

            • Alice 生成了一个大种子。
            • Alice 首先在她的计算机上运行它并计算问题的解决方案。这是关键。她使用此密钥对消息进行加密,并将其与种子一起发送给 Bob。
            • Bob 收到消息后,立即使用正确的种子运行算法并找到解决方案。然后他用这个密钥解密消息。

            这种方法存在三个缺陷:

            • 某些计算机可能比其他计算机更快,因此必须以最小化两台不同计算机之间的差异的方式制定算法。
            • 它需要工作证明,这在大多数情况下都可以(你好比特币!)。
            • 如果 Bob 有一些延迟,那么他将需要更多时间才能看到此消息。

            但是,如果算法独立于运行它的机器,并且种子足够大,则可以保证 Bob 在截止日期之前看不到消息的内容。

            【讨论】:

              猜你喜欢
              • 2012-01-24
              • 1970-01-01
              • 2023-03-23
              • 1970-01-01
              • 2019-04-14
              • 2015-09-19
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              相关资源
              最近更新 更多