SSL的替代方案 - "手动"加密？

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

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

这会是SSL的一个很好的替代品吗？如何以一种难以击败的方式实现这种类型的加密？这种方法有什么特别的缺点吗？

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

建议吗？

Answer 1

哦,哦.祝你好运.你看过TLS规范了吗？你认为你能提出足以让数百万人测试的东西吗？

不,真的,TLS已经经过多年的测试和改进,这么多人,密码学家除了打破这些协议之外什么也不做,这将是一项艰巨的任务.

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

如果您在设计安全协议方面没有任何经验,则应坚持使用主流并使用TLS/SSL.

安全性是一个罕见的领域,它是有道理的,与主流相比实际上很酷,所以我会说增加的钱会花得很好.

编辑:

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

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

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

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

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

4)一旦你掌握了这一点,你仍然容易受到更多参与形式的攻击,如重放攻击,中间人攻击,反射攻击 ......

5)也许你也想完全正向保密,因此一旦一个关键确实得到折扣,攻击者不能够解密任何过去的数据.您将需要Diffie-Hellman(最好采用椭圆曲线密码学形式)来实现这一目标.

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

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

很抱歉,如果这听起来有点讽刺,但我知道这似乎很诱人推出自己的加密方案(这很有趣,太),但最终,你应该使用TLS坚持:它的(相对)易于使用,它运行在运输层(因此您可以将应用程序编码为完全没有加密),最重要的是,它是安全的.

编辑:嗯,也出现了一些新的攻击,但几乎所有的攻击,攻击是背协议公钥证书(魔岛,DigiNotar等都是突出的例子)或更神秘的功能利用了这些协议的"人的因素"协议类似的算法协商等,但BEAST已经第一次TLS已经成功攻击了加密的水平,这是有趣的,可怕的,同时,因为攻击的基础已经知道了有些年头了.

尽管如此,最近对BEAST进行了修复,我敢打赌,TLS仍然是您在网络上进行安全通信的最佳选择,特别是与手工制作的解决方案相比时.

Answer 2

瑞恩:我说的是我希望这是最好的方式:记忆消耗是你问题中最不重要的.

这没什么安全的.没有. 没什么.

从第一次发送javascript开始就已经死了......我不在乎你的密钥有多长或者盐是多么随机.

你所拥有的东西不会阻止有人坐在咖啡店里,他们的笔记本电脑打开时会抓住数据包拦截钥匙,并能够轻松解密你来回传递的其他东西.哎呀,只要在流中看到"加密","解密"和"关键"这两个词,就足以激起某些人的兴趣,以便进一步获得乐趣(或获利......).没关系看着打开的连接突然开始转移部分中明确加密的数据包等部位.

如果您拥有的是值得加密的话,那么每年额外的240美元是值得的.请退出窗台,然后做好吧.

Answer 3

每个人都是如此消极,虽然我分享你本人可能不会这样做的情绪,但让我做一些一般性的评论:

对于安全通道,您需要三件事:

• 线加密
• 密钥交换
• 认证

对于加密,您需要实现密码.这是可行的.

密钥交换是关键点:两个对等方都需要知道他们知道公共密钥而其他任何人都无法知道公共密钥.存在协议,应该可以实现它.例如,SSL正在这样做.您可以嗅探SSL连接而不学习任何东西这一事实表明它可以完成.

身份验证对于阻止中间人攻击是必要的,这需要某种带外信息交换(如电话呼叫或PKI基础设施).这些是否真的有效,即使对于SSL也是如此具有争议性.

所以基本上如果你可以通过HTTP实现所有这些组件,那么原则上应该可以通过HTTP运行安全通信.毕竟,SSL正在做同样的事情,它在不安全的媒体上运行安全通道.基本上你想要的是在JavaScript中实现SSL.看看aSSL,他们尝试过类似的东西.