php - 替代SSL- "Manual"加密吗？

Question

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

因此，我想实现SSL的替代方案。但是，它的功能比SSL还要强。除了加密来回发送的数据外，它还加密数据库中的行。我正在考虑做这样的事情:

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); 

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

这将是SSL的替代方案吗？如何以更难破解的方式实现这种类型的加密？这种方法有什么特别的弱点吗？

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

建议？

Answer 1

哦，哦。祝你好运。您看过TLS specification吗？您认为您可以提出足以被数百万人测试的东西吗？

不，实际上，多年来，TLS已经由许多人进行了测试和改进，密码学家除了破坏此类协议(protocol)外别无所求，要想提供足够的东西将是一项艰巨的任务。

SSL是由该领域的专家开发的，一开始他们当然也认为，他们的协议(protocol)是绝对坚不可摧的。但是接着是版本2，然后是3，然后是TLS v.1，v1.1，现在是1.2。

如果您以前没有设计安全协议(protocol)的经验，则应该坚持使用主流协议(protocol)，并使用TLS/SSL。

安全是有意义的稀有领域之一，与主流技术相比实际上是很酷的，所以我想说，花在增加的钱上的钱会用得其所。

编辑:

也许我有点苛刻，但对于您的方法为何无法与TLS等较复杂的协议(protocol)竞争的原因，我缺乏一些解释，因此让我们对其进行分析:

1)您将如何进行 key 交换？为了使AES在两端都能正常工作，您需要执行Key Exchange，为了进行对称加密，双方都需要拥有相同的 key 。如您所说，到目前为止，您希望在客户端上随机生成它。第一个问题-您需要生成secure random number-否则，例如通过使用内置的Javascript随机数生成器-攻击者可以在一段时间后预测您的随机数。

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

欺骗人们首先将 key 发送到他们的恶意服务器

然后将 key 转发到您的服务器

您的服务器会尽职地发送使用已建立的 key

加密的数据

攻击者会截获该数据并通过使用刚偷走的 key 解密的 key 来愉快地读取您的 secret

3)因此，您至少也需要服务器身份验证(如果不是客户端身份验证)。这意味着您需要某种形式的非对称/公共(public) key 加密技术，以用服务器的公共(public) key 对 key 进行加密/包装，以便仅服务器能够对其进行解密。

4)掌握了这一点之后，您仍然容易受到更复杂形式的攻击，例如 replay attacks， man-in-the-middle-attacks， reflection attacks，...

5)也许您还想要 Perfect Forward Secrecy，这样一旦 key 确实使受到攻击，攻击者将无法解密任何过去的数据。您将需要 Diffie-Hellman(最好采用 Elliptic Curve Cryptography形式)来实现此目的。

6)最后但并非最不重要的一点是， session 机制也可能不错，这样您就可以使用已经建立的对称 key 来接取先前的 session ，从而不必重新使用服务器重新建立 session 就可以减轻服务器的负载。一些资源密集型的公钥算法。

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

抱歉，这听起来有点讽刺，但是我知道似乎很想推出您自己的加密方案(这也很有趣)，但是最后您应​​该坚持使用TLS :(相对)易于使用，它可以在传输器上运行层(因此您可以对应用程序进行编码，就好像根本没有加密一样)，最重要的是，它是安全的。

编辑:嗯，最近发生了一些攻击，但是几乎所有攻击都通过攻击支持该协议(protocol)的公钥证书(Comodo，DigiNotar等是突出的例子)或这些工具的更多奥秘功能来利用这些协议(protocol)中的“人为因素”协议(protocol)(例如算法协商等)，但 BEAST首次成功在加密级别上对TLS进行了攻击，这同时很有趣，而且很恐怖，因为该攻击的基础知识现在已经针对 some years了。

尽管如此，由于目前已经有了BEAST的最新修复程序，我敢打赌TLS仍然是您在网络上进行安全通信的最佳选择，尤其是与手工制作的解决方案相比。