加密安全的產品密鑰
我正在尋找一種方案來生成和驗證加密安全的產品密鑰。我的要求是：
- 不可偽造。使用者必須不可能（或至少很難）偽造產品密鑰。
- 短的。使用者可以通過鍵入來輸入產品密鑰，因此必須方便輸入。可以使用 26 個 base-32 字元對 128 位進行編碼，這可能接近使用者可以輕鬆鍵入的最大值。
- 有效載荷。密鑰必須能夠攜帶有限數量的任意資訊。例如，這可能是有關已啟用產品功能的標誌。32 位的有效載荷應該足夠了。
- 很多的。同一有效負載必須有大量有效（但難以猜測）的產品密鑰。
- 獨特。當多次呼叫時，產品密鑰生成過程必須為相同的有效負載生成不同的產品密鑰。
下面我只考慮對稱密鑰方案。在我的情況下，不需要公鑰方案，因為密鑰生成和驗證是在伺服器上完成的，因此不需要公鑰/私鑰。
我考慮了許多不同的方案，但我發現他們都想要。主要問題是產品密鑰短。
顯而易見的第一選擇是創建形式的產品密鑰
nonce || timestamp || payload || HMAC(K, nonce || timestamp || payload)這
nonce || timestamp確保有許多唯一的產品密鑰。HMAC 是一種安全的 MAC，因此保證了不可偽造性。包括有效載荷。這裡唯一的問題是產品密鑰的長度。回想一下，所有這些都需要適合 128 位。即使我們將 HMAC 截斷為 80 位（建議的最小值），這也只為
nonce || timestamp || payload組件留下 48 位，這顯然是不夠的（payload單獨需要 32 位）。另一種選擇是創建形式的產品密鑰
AES-ECB(K, nonce || timestamp || magic || payload)在這裡，我們使用
magic強制不可偽造性。顯然，這是次優的，除非我們做magic的時間很長。如果魔法很短，攻擊者很容易繼續猜測產品密鑰並將它們提供給驗證伺服器以查看哪些通過（我們現在假設驗證伺服器沒有諸如節流之類的對策）。問題是該
nonce || timestamp部分還需要很長以避免使用 ECB 模式出現問題。理想情況下，它至少應該是 80 位，但也許我們可以使用 64 位。這將只留下 32 位magic，我懷疑這會使這個方案變弱。我也考慮過其他替代方案，但還沒有找到令人滿意的解決方案。我很想听聽您的任何回饋。
您的第二個解決方案似乎非常接近最優。除非時間戳是有效負載的一部分，否則您可能不需要nonce*和時間戳。*反正結構
$$ N||P, $$ 在哪裡 $ N $ 是 48 位隨機數和 $ P $ 是 32 位有效負載似乎足以滿足您的需求，因為您不太可能生成超過 $ 2^{48} $ 產品密鑰。為確保身份驗證（不可偽造），您只需添加一個 48 位零字元串（類似於您的“魔術”）並使用 AES 對其進行加密： $$ KEY = AES_K(N||P||0^{48}). $$ 除非攻擊者賺取超過 $ 2^{47} $ 嘗試（我也認為這是一個公平的假設）。 在此方案中，如果您有較大的有效負載但期望較少的密鑰或偽造嘗試，您可以更改所有這些參數。