可以使用私钥加密/使用公钥解密吗?

时间:2010-02-19 11:06:21

标签: cryptography cookies openssl rsa

[免责声明:我知道,如果你对加密有任何了解,你可能会告诉我为什么我做错了 - 我已经做了足够的谷歌搜索,知道这似乎是典型的回应。]

假设以下内容:您拥有一个想要为给定域发布登录cookie的中央权限。在此域上,您不一定信任所有人,但您有一些能够读取cookie的关键端点。我说了一些,但在实践中,这些“可信”的合作伙伴可能很大。 cookie不包含太多信息 - 用户名,时间戳,到期日,随机数。当然,出于性能原因,即使在加密后(在合理范围内),它仍应保持很小。现在,有两个安全问题:

1)我们不信任此域中的每个网络服务器都有用户数据。因此,读取cookie的能力应仅限于这些可信赖的合作伙伴。 2)虽然我们相信这些合作伙伴能够保护我们用户的数据,但我们仍然希望权威的中心点是不可伪造的(同样在合理范围内)。

现在,如果我们为权限生成私有RSA密钥并保密,并将公钥仅分发给“可信赖的合作伙伴”,我们应该能够使用私钥加密并让任何人都可以读取公钥。我不清楚的是,是否仍然需要签署该消息,或者解密行为是否是使用私钥生成的证据?这种方案的优点还是比向所有相关方传播对称密钥并使用它加密更好或更差,而使用私钥只是为了签名?当然可以随意告诉我这是一个愚蠢的想法,但请记住,实际的论点可能比重塑爱丽丝和鲍勃更有说服力。

哦,实施指针会受到欢迎,不过可以在Google上找到基础知识,如果有任何“陷阱”可能会有用!

7 个答案:

答案 0 :(得分:19)

Nate Lawson解释herehere为什么你不能安全地使用公钥作为一个密切关注的秘密解密密钥(这是一个微妙的点,并且是很多其他人之前犯过的错误你,所以不要心疼!)。

只需使用您的公钥签署真实性,并使用单独的对称密钥进行保密。

我已经阅读了有关针对公钥系统的有趣攻击,特别是RSA,我完全赞同这个结论:

  

公钥密码系统和RSA   特别是非常脆弱。做   不要以不同的方式使用它们   被设计了。

(这意味着:使用公钥进行加密,使用私钥进行签名,其他任何东西都在玩火。)

<强>附录:

如果您对缩小生成的cookie的大小感兴趣,则应考虑使用ECDSA而不是RSA来生成签名 - ECDSA签名远小于等效安全系数的RSA签名。

答案 1 :(得分:6)

在密码学中,你就是你所知道的。在您的方案中,您有一个能够发布cookie的中央权限,并且您不希望其他实体能够执行相同的操作。所以中央机关必须“知道”一些私人数据。此外,您希望“受信任的Web服务器”能够访问cookie的内容,并且您不希望任何人阅读cookie。因此,“受信任的Web服务器”也必须拥有自己的私有数据。

通常的做法是授权机构在cookie上应用数字签名,并使用可信Web服务器已知的密钥对cookie进行加密。你的想法是这样的:

  • 有一个RSA模数 n 和两个常用的RSA指数 d e (这样 ed = 1 modulo p-1 q-1 其中 n = pq )。中央权威机构知道 d ,受信任的Web服务器知道 e ,模数 n 是公开的。
  • 由中央机构处理cookie,将其填充为整数 c 模数 n ,并计算 s = c ^ d mod 名词
  • 受信任的Web服务器通过计算 c = s ^ e mod n 来访问cookie数据。

虽然这样的方案可行,但我发现其中存在以下问题:

  • 为了基本安全, e 必须很大。在通常的RSA描述中, e 是公共指数并且很小(如 e = 3 )。一个小的指数在公开时没有问题,但由于你不希望第三方可以访问cookie内容,你必须使 e 足够大以抵抗穷举搜索。同时,受信任的Web服务器不能只知道 p q ,只能知道 n 。这意味着受信任的Web服务器将需要计算具有大模数和大指数的事物,并且不知道模数因子。这似乎是一个小问题,但它取消了许多RSA实现库的资格。你将“独立”,具有大整数(以及所谓的“通道泄漏”的所有实现问题)。
  • RSA签名的抗性和RSA加密的阻力已得到很好的研究,但不是一起研究。碰巧是填充是必不可少的,并且您不使用相同的填充方案进行加密和签名。在这里,您需要一个填充方案,它对签名和加密都有好处。密码学家通常认为,当数百名训练有素的密码学家对该方案进行了几年的研究,并没有发现任何明显的弱点(或修复了发现的任何弱点)时,就能获得良好的安全性。家庭烹饪计划几乎总是无法实现安全。
  • 如果很多人知道一个秘密,那就不再是秘密了。在这里,如果所有Web服务器都知道 e ,那么在不选择新的 e 并将新值传递给所有剩余的可信Web服务器的情况下,您无法撤销受信任的Web服务器权限。您也会遇到共享对称密钥的问题。

目前正在研究确保同一类型的机密性和可验证完整性的问题。您可以查找signcryption。目前尚无既定标准。

基本上我认为你会更喜欢更经典的设计,数字签名仅用于签名,而(对称或非对称)加密用于保密部分。这将允许您使用现有的库,使用尽可能少的自制代码。

对于签名部分,您可能希望使用DSA或ECDSA:它们产生更短的签名(对于相当于1024位RSA签名的安全性DSA签名,通常为320位)。从中央权威的角度来看,ECDSA还可以提供更好的性能:在我的PC上,使用单核,OpenSSL每秒可以处理超过6500个ECDSA签名(在P-192 NIST曲线中)和每个“仅”1145个RSA签名秒(使用1024位密钥)。 ECDSA签名包含两个192位整数,即384位进行编码,而RSA签名长度为1024位。 P-192中的ECDSA被认为至少与RSA-1024一样强,可能更强。

答案 2 :(得分:5)

您应该使用某种数字信号方案,或其他一些旨在解决您的方案中完整性问题的机制。

加密本身是不够的。 你怎么知道解密的messege应该是什么? 解密用正确密钥加密的cookie肯定会提供“有效”的cookie,但是当您解密用错误密钥加密的cookie时会发生什么?或者只是一些毫无意义的数据?好吧,你可能只是得到一个看起来有效的cookie! (时间戳在您认为有效的范围内,用户名是合法的,随机数是......呃......数字等)。

在我所知的大多数非对称加密算法中,没有内置验证。这意味着用错误的密钥解密邮件不会“失败” - 它只会给你一个错误的明文,必须与有效的明文区别开来。这就是诚信发挥作用的地方,最常见的是 - 使用数字签名。

BTW,RSA经过长期研究并有几个“陷阱”,所以如果你打算从头开始实现它,你最好先读一下如何避免创建“相对容易破解”的密钥。

答案 3 :(得分:1)

根据定义,公钥是公共的。如果您使用私钥进行加密并使用公钥进行解密,那么窥探是不安全的。它只是说:“这些数据来自持有私人密钥X的X人”,而任何人都可以验证,因为密钥的另一半是公开的。

什么阻止某人不信任将公钥X放在您不信任的服务器上?

如果您想在两台服务器之间建立安全的通信线路,您需要让所有这些可信任的服务器都拥有自己的公钥/私钥对,我们将为一台此类服务器说明密钥对。

然后,服务器X可以使用私钥X和公钥Y加密消息。这表示“服务器X发送的消息只有Y可以读取,而Y可以验证它是否来自X.”

(并且该消息应该包含一个短命的对称密钥,因为公钥加密非常耗时。)

这就是SSL的作用。它使用公钥加密来设置会话密钥。

话虽如此,使用图书馆。这个东西很容易搞砸。

答案 4 :(得分:1)

您的问题的答案“解密行为会证明它是使用私钥生成的”,如果收件人可以对数据进行简单验证,则答案是肯定的。假设您有“用户名:John,时间戳:&lt; number&gt ;,到期时间:dd / mm / yyyy”。现在,如果使用错误的公钥进行解密,您将获得“用户名:&lt; some letters&gt;,timestamp:&lt; only numbers&gt;,expiry:?? / ?? / ????”的概率是零。您可以使用正则表达式(正则表达式)进行验证,例如“用户名:[a-zA-Z] +,时间戳:[0-9] +,到期:....”并删除验证失败。你甚至可以检查一天是在1到31之间,月份在1到12之间,但你不会使用它,因为如果使用了错误的公钥,正则表达式通常会在“用户名:”失败。如果验证成功,您仍然需要检查时间戳并确保没有重放攻击。

但是,请考虑以下事项:

  1. RSA公钥加密不是为结构化数据的批量加密而设计的,因为它可以被攻击者利用。公钥加密通常以两种方式使用:1)用于安全地传输将用于批量加密的对称密钥(根据定义没有结构);这是通过使用公钥加密对称密钥和2)通过使用私钥加密文档而不是文档的散列(再次没有结构的东西)来对文档进行数字签名来完成的。在您的情况下,您正在加密具有明确结构的cookie。
  2. 您依赖的公钥不会落入错误的人或实体的手中。
  3. 公钥加密比对称密钥加密慢大约1000倍。这可能不是你的一个因素。
  4. 如果您仍想使用此方法,并且能够将公钥分发给“可信赖的合作伙伴”,则应生成随机会话密钥(即对称密钥),对其进行加密使用私钥并发送给拥有公钥的所有收件人。然后使用会话密钥加密cookie。您可以定期更改会话密钥。更少见的是,您也可以更改公钥:您可以生成新的公钥/私钥对,并使用会话密钥加密公钥并将其发送给所有收件人。

答案 5 :(得分:0)

我认为您信任'可信赖的合作伙伴'来解密和验证cookie,但不希望他们能够生成自己的cookie?如果这不是问题,您可以使用更简单的系统:将密钥分发给所有各方,并使用它来加密cookie并为其生成HMAC。无需公钥加密,无需多个密钥。

答案 6 :(得分:0)

作为您的密钥分发方法的替代方案,可能适合或可能不适合您的应用程序,请考虑使用Kerberos,它使用对称密钥加密,一个高度保护的堡垒服务器,控制所有密钥材料,和一套聪明的协议(参见Needham-Schroder protocol