反覆加密（隨機填充+ const int32） - 妥協祕密？

任何加密方案能否安全地允許我重複加密相同的整數，並且每次都使用不同的隨機材料？這似乎是那種可能讓我處於熱水中的手術。反覆加密（隨機填充+ const int32） - 妥協祕密？

我想阻止我的web應用程序中的項目被盜取，但仍有持久的項目ID/URL，因此內容鏈接不會隨着時間的推移而過期。我的安全要求並不高，但我寧願不做一些完全無知的事情，這顯然會危及祕密。

// 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人口稀少（小於1 uint32.Max是唯一的，並且我可以添加另一個常數填充到縮減現有猜測的情形產生），並且客戶端可以每次運行相同的搜索並使用不同的代表ID獲得相同的結果。我認爲它符合我的要求，除非有明顯的密碼問題。

實施例：

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

在此，就沒有辦法，以確定tokenA和tokenB都指向相同的項目;這可以防止蜘蛛刪除重複搜索結果而不檢索它們（同時檢索增量使用量表）。另外，item2可能不存在。

知道重新運行搜索將返回相同的int32填充多個方式與相同的祕密，我可以安全地使用任何流行的加密算法？謝謝，加密專家！

注：這是一個後續問題如我所希望的是沒有解決：Encrypt integer with a secret and shared salt

來源

2012-07-29 shannon

如果ID沒有改變或失效，任何人都可以簡單地記住他們看到的那些，而且不能讓他們忘記。您可以從大量項目中隨機分配ID以使其難以列出，但這並不會讓您很難記住它們。當然，您可以限制在任何給定時間段內可以從一個IP請求多少個ID。這有幫助嗎？ – Qsario 2012-07-29 04:39:56

@qsario：謝謝。對於記住他們所見過的人來說，我確實可以。由於數百萬個網址代表相同的項目，並且數百萬個網址無效，因此該網址無法幫助我抓取內容。此外，我確實計劃實施檢查項目的每日配額。 – shannon 2012-07-29 05:01:14

如果你的加密是安全的，然後隨機填充，使裂紋既不容易也不困難。對於這個簡短的消息來說，一個單獨的塊，或者一切都妥協或者什麼都沒有。即使使用流密碼，您仍需要密鑰才能獲得更多信息;好的加密點在於你不需要額外的隨機性。如果可能的話，零填充或其他已知消息至少在一開始就會被避免，但這不是問題。這是純粹的噪音，一旦有人發現，他們只是跳過，並從那裏開始破解。

現在，在流密碼中，您可以在開始時添加所有的隨機性，並且後面的字節仍然與相同的密鑰相同，請不要忘記這一點。這對於分組密碼實際上只做任何事情，否則你必須將隨機比特變成真正的值才能使用它。

但是，使用MAC作爲填充可能會更好：使用適當的加密，加密的mac將不會提供任何信息，但它看起來是半隨機的，您可以使用它來驗證沒有錯誤或解密期間的惡意攻擊。任何你喜歡的哈希函數都可以創建MAC，即使是一個簡單的CRC-32，在加密後也不會給任何東西。如果事先知道它們是如何相關的，那麼一個密碼專家可能會找到一種方法，因爲它們之間的關聯性會削減一兩個小時，但是這仍然遠遠超出實用性。）

正如你以前問過的那樣，你可以安全地在每條消息前面放入一個未加密的鹽;只要鹽被恰當地混合到密鑰中，特別是在解密之前可以將其混合到擴展密鑰調度中，只有在實現被破壞或密鑰泄漏的情況下，鹽纔可以危害加密值。具有許多位的現代散列算法真的很好，但即使混入常規輸入密鑰中，也總是具有與單獨密鑰相同的安全性。

來源

2012-07-29 04:52:51 SilverbackNet

隨機性不是爲了幫助*加密*，而是爲了1）防止編程確定搜索結果中的項目是否已經被看到2）導致多個表面上隨機的URL表示相同的項目ID。這些因素意味着一個蜘蛛抓取工具無法確定一個URL上的內容是否已經在未請求內容的情況下被蜘蛛抓取（這將通過每日配額解決）。我擔心的是，塊中填充不同的相同內容的多個表示可能會嚴重削弱某些內容。 – shannon 2012-07-29 05:06:39

如果我使用任何常數值（例如MAC地址）作爲唯一的填充，則具有spidering應用程序的濫用者可以檢查搜索結果中返回的URL，以確定它們是否已被查看。 – shannon 2012-07-29 05:10:30

我相信如果他們能夠輕易地確定它們實際上是相同的，它只會削弱加密。在這種情況下，您可能每次只能返回一個新的GUID，並將其映射到表中的一個真實ID;根本不需要加密。那麼你是唯一一個可以將一個映射到另一個的人。如果每隔一段時間清除一次GUID，就會徹底擊敗蜘蛛。 – SilverbackNet 2012-07-29 05:17:21

反覆加密（隨機填充+ const int32） - 妥協祕密？

回答

相關問題