预测加密字符串的长度

发布于 2024-08-05 15:39:39 字数 350 浏览 4 评论 0原文

我使用它进行加密: http://msdn .microsoft.com/en-us/library/system.security.cryptography.rijndaelmanagement.aspx

有没有办法可以预测加密文本的外观?我正在将加密的输出转换为文本,以便可以将其存储在数据库中。

我只是想确保数据库列的大小足够大。

我将文本输入限制为 20 个字符。

I am using this for encryption: http://msdn.microsoft.com/en-us/library/system.security.cryptography.rijndaelmanaged.aspx

Is there a way I can predict what the encrypted text will look like? I am converting the encrypted output to text so I can store it in the db.

I just want to make sure the size of the database column is large enough.

I am limiting the text input to be 20 characters.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

鸩远一方 2024-08-12 15:39:39

您使用的是 SQL Server 2005 或更高版本吗?如果是这样,您可以仅使用 VARCHAR(MAX)NVARCHAR(MAX) 作为列类型。

如果您想更精确一点...

RijndaelManaged 的最大块大小为 256 位(32 字节)。

您的最大输入大小为 20 个字符,因此即使我们假设每个字符 4 个字节的最坏情况,也只会达到 80 个字节,然后将在加密过程中填充最多 96 个字节。

如果对加密输出使用 Base64 编码,则会从 96 个加密字节中创建 128 个字符。如果您使用十六进制编码,那么将从 96 个加密字节中创建 192 个字符(如果您在十六进制字符串前添加“0x”前缀,则可能还会添加几个额外字符)。无论哪种情况,200 个字符的列宽都应该为您提供足够的空间。

(注意:这些只是我的即兴计算。我尚未验证它们是否确实正确!)

Are you using SQL Server 2005 or above? If so you could just use VARCHAR(MAX) or NVARCHAR(MAX) for the column type.

If you want to be a bit more precise...

The maximum block size for RijndaelManaged is 256 bits (32 bytes).

Your maximum input size is 20 characters, so even if we assume a worst-case scenario of 4 bytes per character, that'll only amount to 80 bytes, which will then be padded up to a maximum of 96 bytes for the encryption process.

If you use Base64 encoding on the encrypted output that will create 128 characters from the 96 encrypted bytes. If you use hex encoding then that will create 192 characters from the 96 encrypted bytes (plus maybe a couple of extra characters if you're prefixing the hex string with "0x"). In either case a column width of 200 characters should give you more than enough headroom.

(NB: These are just off-the-top-of-my-head calculations. I haven't verified that they're actually correct!)

强者自强 2024-08-12 15:39:39

对于在网上找不到信息的未知加密算法,我会编写一个小测试程序,对一组最大长度的随机字符串进行加密,找到输出中的最长长度,然后根据该可能性的可能性乘以一个安全系数。输入的长度是否改变,以及测试程序的结果有多准确。

一般来说,您可能会处于 1.5 倍 - 2 倍输入长度范围内。

For an unknown encryption algorithm with no information to be found online, I would write a little test program that encrypted a random set of strings of maximum length, find the longest length in the output, then multiply by a safety factor based on how likely the length of input is to change, and how accurate the result of the test program was.

Really generally speaking though, you're probably going to be in the 1.5x - 2x input length range.

病女 2024-08-12 15:39:39

对于该特定算法,密文的长度为,

   ((length+16)/16)*16 

这是为了满足块大小和填充要求。

我建议您还向密文中添加一个随机 IV,这样就需要另外 16 个字节。

但是,如果您想将其作为字符放入数据库中,则必须对其进行编码。这会进一步增加。

对于 Base64,将其乘以 4/3。对于十六进制,将其加倍。

For this specific algorithm, the length of ciphertext will be,

   ((length+16)/16)*16 

This is to meet the block size and padding requirement.

I suggest you also add an random IV to the ciphertext so that will take another 16 bytes.

However, if you want put this as char in database, you have to encode it. That will increase it even more.

For base64, multiply it by 4/3. For hex, double it.

深陷 2024-08-12 15:39:39

加密永远不会增加数据大小超过所需的最小填充量。

如果它确实“扩展”了数据,那么它可能不是一个很好的加密算法。

Encryption will never increase the size of data beyond the minimum padding required.

If it does 'expand' the data, it is probably not a very good encryption algorithm.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文