重复加密（随机填充+ const int32） - 妥协秘密？ [英] Repeatedly encrypt(random padding + const int32) - compromise secret?

问题描述

任何加密方案是否可以安全地允许我重复加密相同的整数，每次都会添加不同的随机材料？似乎是可能让我热水的操作。

Will any encryption scheme safely allow me to encrypt the same integer repeatedly, with different random material prepended each time? It seems like the kind of operation that might get me in hot water.

我想防止在我的网页应用程序上填充项目，但仍然有持久的项目ID / URL，所以内容链接不会随着时间过期。我的安全要求并不是很高，但是我宁愿不做任何明显妥协的秘密。

I want to prevent spidering of items at my web application, but still have persistent item IDs/URLs so content links don't expire over time. My security requirements aren't really high for this, but I'd rather not do something totally moronic that obviously compromises the secret.

// performed on each ID before transmitting item search results to the client
public int64 encryptWithRandomPadding(int32 id) {
    int32 randomPadding = getNextRandomInt32();
    return encrypt(((int64)randomPadding << 32) + id), SECRET);
}

// performed on an encrypted/padded ID for which the client requests details
public int32 decryptAndRemoveRandomPadding(int64 idToDecrypt) {
    int64 idWithPadding = decrypt(idToDecrypt, SECRET);
    return (int32)idWithPadding;
}

static readonly string SECRET = "thesecret";

生成的ID / URL是永久性的，加密的ID被稀疏地填充（在uint32中小于1）是唯一的，我可以添加另一个常量填充来减少猜测存在的可能性），并且客户端可以运行相同的搜索，并且每次都使用不同的代表ID获得相同的结果。我认为它符合我的要求，除非有明显的加密问题。

Generated IDs/URLs are permanent, the encrypted IDs are sparsely populated (less than 1 in uint32.Max are unique, and I could add another constant padding to reduce the likelyhood of a guess existing), and the client may run the same search and get the same results with different representative IDs each time. I think it meets my requirements, unless there's a blatant cryptographic issue.

示例：

 encrypt(rndA + item1)   -> tokenA
 encrypt(rndB + item1)   -> tokenB
 encrypt(rndC + item2)   -> tokenC
 encrypt(rndD + item175) -> tokenD

这里没有办法识别tokenA和tokenB都指向相同的项目;这样可以防止蜘蛛在不检索的情况下删除重复的搜索结果（同时检索增量使用率表）。另外，item2可能不存在。

Here, there is no way to identify that tokenA and tokenB both point to identical items; this prevents a spider from removing duplicate search results without retrieving them (while retrieving increments the usage meter). Additionally, item2 may not exist.

知道重新运行搜索将以相同的秘密返回相同的int32填充多种方式，我可以安全地执行与任何流行的加密算法？谢谢，加密专家！

Knowing that re-running a search will return the same int32 padded multiple ways with the same secret, can I do this safely with any popular crypto algorithms? Thanks, crypto experts!

注意：这是一个后期的问题，没有像我所希望的那样工作：加密带有秘密和共享盐的整数

note: this is a follow-up to a question that didn't work out as I'd hoped: Encrypt integer with a secret and shared salt

推荐答案

如果你的加密是安全的，那么随机填充使得破解既不容易也不难。对于一个短消息，一个单一的块长，任何事情都是妥协的，没有什么。即使使用流密码，您仍然需要进一步的密钥;加密的好处是你不需要额外的随机性。如果可能，零填充或其他已知的消息至少在一开始很长一段时间显然是要避免的，但这不是这里的问题。这是纯粹的噪音，一旦有人发现，他们就会跳过来，从那里开始破解。

If your encryption is secure, then random padding makes cracking neither easier nor harder. For a message this short, a single block long, either everything is compromised or nothing is. Even with a stream cipher, you'd still need the key to get any further; the point of good encryption is that you don't need extra randomness. Zero padding or other known messages at least a block long at the beginning are obviously to be avoided if possible, but that's not the issue here. It's pure noise, and once someone discovered that, they'd just skip ahead and start cracking from there.

现在，在流密码中，你可以添加所有的随机性在开头和后面的字节将仍然是相同的密钥，不要忘记。这只是实际上对块密码做了任何事情，否则你必须将随机位置入真实值以获得任何使用。

Now, in a stream cipher, you can add all the randomness in the beginning and the later bytes will still be the same with the same key, don't forget that. This only actually does anything at all for a block cipher, otherwise you'd have to xor the random bits into the real value to get any use out of it.

然而您可能会更喜欢使用MAC作为填充：通过适当的加密，加密的Mac将不会提供任何信息，但它看起来是半随机的，您可以使用它来验证在解密过程中没有错误或恶意攻击。任何您喜欢的哈希函数都可以创建MAC，即使是简单的CRC-32，也不会在加密后产生任何影响。

However, you might be better off using a MAC as padding: with proper encryption, the encrypted mac won't give any information away, but it looks semi-randomish and you can use it to verify that there were no errors or malicious attacks during decryption. Any hash function you like can create the MAC, even a simple CRC-32, without giving anything away after encryption.

（密码学家可能会找到一种方法来刮胡子或者由于相关性而产生的两个关系，如果他们事先知道他们是如何相关的，将会有大量的明文，但是这还远远超出实用性。）

(A cryptographer might find a way to shave a bit or two off due to the relatedness, will tons of plaintexts if they knew beforehand how they were related, but that's still far beyond practicality.)

如前所述，你可以安全地在每个信息前面放入一个不加密的盐;只要盐被正确地混合到密钥中，特别是如果您可以在解密之前将其混合到扩展的密钥计划中，则盐只能损害加密值，如果实现被破坏或密钥泄密。现代哈希算法有很多位，这是非常好的，但即使混合成常规的输入密钥也总是具有与密钥相同的安全性。

As you asked before, you can safely throw in an unecrypted salt in front of every message; a salt can only compromise an encrypted value if the implementation is broken or the key compromised, as long as the salt is properly mixed into the key, particularly if you can mix it into the expanded key schedule before decryption. Modern hash algorithms with lots of bits are really good at that, but even mixing into a regular input key will always have the same security as the key alone.

这篇关于重复加密（随机填充+ const int32） - 妥协秘密？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！