代码之家 › 专栏 › 技术社区 › Xeoncross

RIJNDAEL加密是否可以安全地用于给用户的少量文本?

rijndael cryptography encryption cookies

Xeoncross · 技术社区 · 14 年前

无论如何,我计划使用 RIJNDAEL 256年。

function encrypt($text, $key) 
{
    return mcrypt_encrypt(MCRYPT_RIJNDAEL_256,$key,$text,MCRYPT_MODE_ECB,mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256,MCRYPT_MODE_ECB),MCRYPT_RAND)); 
}

print base64_encode(encrypt('text', 'key'));

7s6RyMaYd4yAibXZJ3C8EuBtB4F0qfJ31xu1tXm8Xvw=

我不担心单个用户的cookie被破坏,正如我担心攻击者会发现 key 能够建造 任何用户的任何会话

是否有方法可以验证与所用参数相关的预计开裂时间?或者,是否有一个标准的时间尺度与所使用的文本或键的大小有关?

我听到有人说,钥匙本身需要超过256位才能安全地与瑞恩戴尔一起使用。我还想知道加密文本的长度是否需要一定的长度,以免泄露密钥。

数据一般为200个字符

a:3{s:7:"user_id";i:345;s:5:"token";s:32:"0c4a14547ad221a5d877c2509b887ee6";s:4:"lang";s:2:"en";}

这安全吗?

5 回复 | 直到 14 年前

Lunatic Experimentalist 14 年前

避免使用ECB。它可以显示加密内容的信息。任何两个具有相同明文的块将具有相同的密文。CBC可以避免这种情况,但需要生成或保存IV。

根据数据的使用方式,您可能需要包括一个MAC。ECB和CBC的设计目的不是检测密文的任何更改,这些更改将导致明文中的垃圾。您可能希望在加密数据中包含一个HMAC,以便在将其作为canon之前对其进行身份验证。会话HMAC密钥必须从会话加密密钥派生。或者,您可以使用PCBC模式。PCBC是用来检测密文中的变化的,但它的能力受到填充大小的限制,它依赖于加密的数据,并不是所有的加密api都将其作为一个选项。

一旦你已经包括了一个MAC,那么你应该考虑采取措施防止重播攻击。任何时候,只要有人能够在会话范围内重新发送旧数据,就有可能发生重播攻击。使会话密钥的使用范围尽可能窄而不给用户造成问题是阻止重播攻击的一种方法。您还可以在加密数据中包含日期和时间,以便在数据被视为有效时创建一个窗口。

在夏天,保护钥匙只是冰山一角。

Community Tales Farias 7 年前

An IV must always be a Cryptographic Nonce . 您的代码明显违反了CWE-329。

不应使用ECB模式,必须使用CBC模式,这是为什么:

alt text

使用ECB模式加密:

alt text

使用CBC模式加密:

alt text

Jonathan Leffler 14 年前

也就是说,你应该仔细考虑你放在饼干里的东西。这取决于您在系统上的存储方式,但您可以简单地选择一个随机数(比如64位数字),并将其存储在cookie中。在您的服务器端系统中,您将记录该号码与谁关联以及其他详细信息。这完全避免了加密。您可以使用其他详细信息来验证(在任何可以验证的范围内)cookie是否是从最初发送到的浏览器发回的。

或者,可以为每个会话使用不同的加密密钥,跟踪哪个会话使用了哪个密钥。

Slartibartfast 14 年前

如果你用长钥匙,我会说钥匙很安全。有些事情你要关心:

如何验证数据的一些示例如下:

包括一个salt(这样具有相同会话数据的人就不会得到相同的cookie)和

Giacomo Verticale 14 年前

AES-128应该是足够的,不需要使用更长的密钥-如果密钥是随机选择的。

第二个问题是,您还应该附加一个消息身份验证代码。否则你将无法区分伪造的曲奇和好曲奇。