hmac密鑰和鹽的長度

我正在使用hmac sha1簽署傳遞給第三方服務的用戶標識。所有用戶都使用同一個祕密，而salt對每個用戶都是唯一的。hmac密鑰和鹽的長度

token = userid : timestamp+2hours : hmac(userid : timestamp+2hours, salt+secret) 
token_hex = hex(hash)

將HMAC短串的工作？ userid：timestamp可以是例如12：1304985212 鹽和祕密事務的順序嗎？（鹽+祕密vs祕密+鹽）共享祕密長度應該是多少？鹽的長度應該是多少？我可以使用相同的密碼在服務器和遠程服務之間簽名消息，還是生成單獨的密碼更好？

感謝

來源

2011-05-10 pablo

您應該計算HMAC（鹽：用戶名：時間戳+2小時，祕密）和發送鹽：用戶名：時間戳+2小時：哈希。這裏鹽的目的是使明文更長，而不是重複，因此最好將其附加到明文上，而不是祕密。

如果你真的想改變祕密，做hmac（userid：timestamp + 2hours，hash（salt：secret）），它會讓一次祕密看起來更像隨機數。

來源

2011-05-10 13:26:16 blaze

將鹽添加到明文部分是有意義的。如果我在服務器和遠程服務之間傳輸salt或將它傳遞給離線服務器（如祕密），這有什麼關係？這個祕密有可能被破解嗎？你的第二個例子保護，但也許你的意思是：hmac（salt：userid：timestamp，hash（salt：secret））。在這種情況下，我是否真的需要hmac，還是有足夠的sha1（userid：timestamp：salt：secret）？ – pablo 2011-05-10 14:06:01

你不能以有用的方式離線傳遞鹽：salt必須是隨機的並且只能使用一次，並隨着每條消息而變化。所以你只能在使用之前從隨機數生成器中獲取並使用數據進行傳輸。鹽在每次變化之前都沒有什麼祕密。實際上，如果你每秒只發送一條消息，你根本不需要單獨使用salt：hash（timestamp）就足夠了。祕密不能從HMAC結果中提取出來，你唯一的風險就是從服務器上被盜取。第二個例子通過每次給予新的祕密使得HMAC不重複，而不是新的明文。 – blaze 2011-05-11 10:24:33

使用時間戳而不是哈希（時間戳）作爲salt和usersecret + globalsecret來防止彩虹攻擊有什麼問題？ – pablo 2011-05-11 19:43:31

hmac密鑰和鹽的長度

回答

相關問題