重复加密（随机填充+ 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.Max中小于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.

现在，在流密码，你可以添加所有的随机在开始和以后的字节将仍然是相同的相同的键，不要忘记。这实际上只做一个块密码的任何东西，否则你必须xor随机位到真正的价值，以得到任何使用它。

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屋！