SSL 的替代方案 - “手册"加密?

问题描述

我想对在我的 Web 应用程序中在服务器和客户端之间来回传输的数据进行加密.我会使用 SSL，但这需要证书和专用 IP 地址.我获得证书没有问题，但专用 IP 要求我升级到商业托管计划，在我的 Web 主机上每月收费 20 美元.我没有这样做的计划，因为我坚持每年 20 美元的共享托管计划.

I would like to encrypt data that travels back and forth between the server and client in my Web application. I would use SSL but that requires a certificate along with a dedicated IP address. I have no problem getting a certificate but the dedicated IP requires me to upgrade to a business hosting plan which is $20 a month on my Web host. I have no plans on doing that as I'm sticking with my $20/year shared hosting plan.

所以，我想实现 SSL 的替代方案.不过，它比 SSL 做得更多.除了加密来回发送的数据外，它还加密数据库中的行.我正在考虑做这样的事情:

So, I would like to implement an alternative to SSL. It does more than SSL does, though. Along with encrypting the data sent back and forth, it also encrypts the rows in the database. I was thinking of doing something like this:

JavaScript 代码:

var transfer_key = 'whatever';
function encrypt(data, key) {...}
function decrypt(data, key) {...}

function send_data_to_server(url, data)
{
    $.post(url, {'data' : encrypt(data, transfer_key) }, function(response) {
        var decrypted_response = JSON.parse(decrypt(response));
    });
}

PHP 代码:

$data = $_POST['data'];
$transfer_key = 'whatever';
$storage_key = 'whatever2';

function encrypt($data, $key) {...}
function decrypt($data, $key) {...}

databaseQuery('INSERT INTO table VALUES (?)', encrypt($data, $storage_key));

$decrypted_data = decrypt($data, $transfer_key);
$response = processData($decrypted_data);

echo encrypt($transfer_key, $response);

如您所见，客户端发送到服务器的数据是加密的，反之亦然.并且数据库中的数据也是加密的.当然，我永远不会像那样实现密钥.我可能会为每个用户随机生成第二个或第三个密钥.所以 transfer_key 可以等于一个 constant_key 与一个随机密钥连接在一起，storage_key 也是如此.

As you can see, the data the client sends to the server is encrypted, and vice versa. And the data in the database is encrypted as well. Now of course, I would never implement the keys like that. I would probably have a second or third key that's randomly generated for each user. So transfer_key could be equal to a constant_key concatenated with a random key, and same goes for storage_key.

这会是 SSL 的一个很好的替代品吗?
我如何才能以更难被击败的方式实施这种类型的加密?这种方法有什么特别的弱点吗?

Would this be a good alternative to SSL?
How can I implement this type of encryption in such a way that it is harder to defeat? Are there any particular weaknesses to this approach?

我可能会找到一个 JavaScript 库，它负责加密并在服务器端使用 PHP 的 mcrypt 扩展.我在考虑 Blowfish，也许是 AES256，但我不确定哪一个给了我最佳的加密强度与内存消耗比率.

I'm probably going to find a JavaScript library that takes care of the encryption and use PHP's mcrypt extension for the server-side. I was thinking of Blowfish, maybe AES256, but I'm not sure which one gives me the best ratio of encryption strength to memory consumption.

建议?

推荐答案

呃，哦.祝你好运.您是否查看过 TLS 规范?你认为你能想出足够的东西来接受数百万人的考验吗?

Uh, oh. Good luck with that. Have you had a look at the TLS specification? Do you think you can come up with something adequate that will be tested by millions of people?

不，实际上，多年来 TLS 已经经过了这么多人的测试和改进，密码学家除了破坏此类协议外什么都不做，想出足够的东西将是一项艰巨的任务.

No, really, TLS has been tested and improved over the years by so many people, cryptographers who do nothing else than breaking such protocols, it would be a hard task coming up with something adequate.

SSL 是由该领域的专家开发的，他们一开始肯定也认为他们的协议绝对牢不可破.但后来有版本 2，然后是 3，然后是 TLS v.1、v1.1，现在是 1.2.

SSL has been developed by experts in the field and they most certainly thought at first, too, that their protocol was absolutely unbreakable. But then there was version 2, then 3, then TLS v.1, v1.1 and now 1.2.

如果您之前没有任何设计安全协议的经验，您应该坚持主流并使用 TLS/SSL.

If you don't have any prior experience in designing secure protocols you should stick with the mainstream and use TLS/SSL.

安全性是少数有意义的领域之一，与主流合作实际上很酷，所以我认为增加的钱会花得很好.

Security is one of the rare fields where it makes sense and is actually cool to go with the mainstream, so I'd say the added money would be well spent.

也许我有点苛刻，我没有解释为什么你的方法不能与 TLS 等有点复杂的协议竞争，所以让我们分析一下:

Maybe I was a bit harsh, and I lacked some explanation as to why your approach cannot compete with a somewhat complex protocol such as TLS, so let's analyze it:

1) 您将如何进行密钥交换?要使 AES 在两端都工作，您需要执行 密钥交换，对于对称加密，两者各方需要拥有相同的密钥.正如您所说，您希望在客户端上随机生成它 - 到目前为止一切顺利.第一个问题 - 您需要生成一个 安全随机数 - 否则，例如通过使用内置的 Javascript 随机数生成器 - 攻击者可以在一段时间后预测您的随机数.

1) How would you do the key exchange? For AES to work on both ends, you need to do a Key Exchange, for symmetric encryption, both parties need to possess the same key. As you said, you would like to generate it randomly on the client - so far so good. First problem - you need to generate a secure random number - otherwise, e.g. by using the built-in Javascript random number generator - attackers would be able to predict your random numbers after some time.

2) 假设您已经掌握了这一点.那么下一个问题出现了，你将如何以安全的方式将这个密钥发送到服务器，即执行密钥交换?在那里您需要在服务器端进行某种形式的身份验证，否则几乎任何人都可以强加为您的服务器并执行此操作:

2) Let's say you got that mastered. Then the next problem arises, how would you send this key to the server in a secure manner, i.e. perform the key exchange? There you will need some form of authentication on the server side, otherwise just about anyone could impose as your server and do this:

• 先诱骗人们将他们的密钥发送到他们的恶意服务器
• 然后将密钥转发到您的服务器
• 您的服务器会尽职尽责地发送使用已建立的密钥加密的数据
• 攻击者会拦截该数据并通过使用他们刚刚窃取的密钥解密来愉快地读取您的秘密

3) 所以你至少需要服务器身份验证，如果不是客户端身份验证也是如此.这意味着您需要某种形式的非对称/公钥密码术来使用服务器的公钥加密/包装密钥，以便只有服务器才能对其进行解密.

3) So you need server authentication, at least, if not client authentication, too. This will imply that you need some form of asymmetric/public key cryptography to encrypt/wrap the key with the server's public key so that just the server is able to decrypt it.

4) 一旦掌握了这一点，您仍然容易受到更复杂的攻击形式，例如重放攻击, man-in-the-middle-attacks, 反射攻击, ...

4) Once you mastered that, you are still susceptible to more involved forms of attacks such as replay attacks, man-in-the-middle-attacks, reflection attacks, ...

5) 也许您还想要完美的前向保密，以便一旦密钥 受到威胁，攻击者将无法解密任何过去的数据.您将需要 Diffie-Hellman(最好在其 Elliptic Curve Cryptography 形式)来实现这一点.

5) Maybe you also want Perfect Forward Secrecy so that once a key does get compromised the attacker would not be capable of decrypting any past data. You will need Diffie-Hellman (preferably in its Elliptic Curve Cryptography form) to achieve this.

6) 最后但并非最不重要的一点是，会话机制可能也很不错，这样您就可以使用已经建立的对称密钥来获取以前的会话，这样您就可以通过不必重新建立服务器来减少它的负载再次使用有点资源密集型的公钥算法.

6) Last but not least, a session mechanism would probably also be nice so that you can pick up previous sessions with already established symmetric keys, so that you can reduce the load on the server by not having to re-establish it again using the somewhat resource-intensive public key algorithms.

-> 添加更多功能，例如安全协商客户端和服务器都承认支持的算法套件，您将重新实现 TLS 协议.

-> Add a couple more features, such as securely negotiating an algorithm suite that both client and server acknowledge to support and you will have reimplemented the TLS protocol.

对不起，如果这听起来有点讽刺，但我知道推出自己的加密方案似乎很诱人(这也很有趣)，但最终你应该坚持使用 TLS:它(相对)易于使用，它运行在传输层上(这样您就可以像根本没有加密一样对您的应用程序进行编码)，而且最重要的是，它是安全的.

Sorry if this sounds a bit sarcastic, but I know it seems tempting to roll your own crypto schemes (it's fun, too), but in the end you should stick with TLS: it's (relatively) easy to use, it runs on the transport layer (so you can code your applications as if there were no encryption at all) and best of all, it's secure.

好吧，最近发生了一些攻击，但几乎所有攻击都利用这些协议中的人为因素"，攻击支持协议的公钥证书(Comodo、DigiNotar 等).是突出的例子)或更神秘的协议特性，如算法协商等，但 BEAST 是 TLS 首次在密码学层面被成功攻击，既有趣又可怕，因为该攻击的基础知识已经为 几年了.

Well, there have been some attacks recently, but almost all attacks exploited the "human factor" in these protocols by attacking the public key certificates that back the protocol (Comodo, DigiNotar etc. are prominent examples) or more arcane features of the protocol like algorithm negotiation etc., but the BEAST has been the first time that TLS has been successfully attacked on the cryptography level, which is interesting and scary at the same time, because the basics of that attack have been known for some years now.

尽管如此，最近针对 BEAST 的修复已经到位，我敢打赌 TLS 仍然是您在网络上进行安全通信的最佳选择，尤其是与手工制作的解决方案相比时.

Still, with recent fixes for BEAST in place by now, I would bet that TLS is still the best option you have for secure communication on the web, especially when compared to hand-crafted solutions.

这篇关于SSL 的替代方案 - “手册"加密?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！