2012-03-26 118 views
2

我想加密小序列化的数据结构(〜256字节),所以我可以安全地将它们传递(特别是在URL中)。我目前的方法是使用对称分组密码,然后进行基础64编码,然后对密文进行URL编码。这产生了一个编码密码文本,(不出所料)比原始数据结构长得多。这些编码密码的长度有点可用性问题;理想情况下,我希望密文的长度与输入文本的长度相同。密码生成无安全编码的URL安全密文

是否有可以配置为将输出字节的值限制在URL安全范围内的分组密码?如果有的话,我认为会涉及安全权衡。

回答

2

对于给定的密钥K,密码必须为每个明文产生不同的密文。如果您的消息空间是256字节,则密码必须能够产生至少256^256个不同的消息。这将需要至少256个字节,并且任何输出字母表大小的减小都需要较长的消息。如你所见,你可以在后面做一些编码,以避免某些输出符号,代价是增加长度。此外,如果编码是适当的加密算法的一部分,您将支付相同的费用。这就是为什么这不是任何加密算法的功能。

正如其他人所提到的,唯一真正的答案是减少您正在加密的数据的大小,以便您需要编码更少的数据。 (或者不要将数据放在网址中,例如将数据存储在数据库中,并在URL中放入一个唯一的ID)。所以压缩>加密>编码。

+0

这正是我正在建议的。存储你的数据服务器端并传递一个散列标记,如sha1散列标识该数据库中的记录。然后,您只需处理40个不需要base64编码或urlencoded的字母数字字符,并且您可以轻松,安全且安全地将其从自己的服务器中拉出来引用数据,而不会将编码数据暴露给每个站点访问者要求黑客尝试打破你的加密并破坏你的网站。 – Brian 2012-03-26 19:06:42

1

URL编码不会显着扩展base64编码的字符串,因为64个字符中的62个不需要修改。但是,您可以使用modified base64 encoding做更好一点。此编码使用' - '和'_'字符代替'+'和'/'字符,以提高效率。

密码本身不会导致任何重要的数据扩展。它会将数据填充为块长度的倍数,但在您的情况下,这是无关紧要的。您可以尝试在加密之前压缩输入。 256字节并不多,但你可能会看到一些改进。

1

如果您的数据结构长度为256个字节,用8个字节的分组密码对其进行加密,最多可以将其增加到8个字节(取决于具体的输入长度)。

因此,在应用base64之前,最多有264个字节,它们由base64编码增加到352个字节。

因此,你可以看到最多的开销是由base64编码创建的。有一些稍微更有效的编码可以像base91那样 - 但它们非常罕见。

如果大小很重要,我建议在加密之前先压缩数据。