我正在使用 Node.js 原生加密方法（如createCipherIv.
const algorithm = "aes256";
const inputEncoding = "utf8";
const outputEncoding = "hex";
const iv = randomBytes(16);
export async function encryptObject(dataToEncrypt: object, key: Buffer) {
const clear = JSON.stringify(dataToEncrypt);
const cipher = createCipheriv(algorithm, key, iv);
let ciphered = cipher.update(clear, inputEncoding, outputEncoding);
ciphered = cipher.final(outputEncoding);
return iv.toString(outputEncoding) ":" ciphered;
}
有時我會多次加密同一個物件并通過 http(s) 發送它。這讓我覺得中間的人可以觀察到這種交流，并可能通過使用彩虹表之類的東西將加密的資料隨著時間的推移映射到真實資料來獲取有關我的用戶的資訊。
現在我不確定我的擔心是否有意義，但我在想，如果在其中添加鹽，我的加密可能會更安全。到目前為止，我只是在散列時遇到了鹽，而不是加密。散列不是我的選擇，因為我不能依賴散列是等價的。我實際上必須對資料做一些事情，所以我必須能夠再次解密它。
所以我的問題是：
- 我的想法加起來了，加鹽會更好嗎？
- 是否可以使用 Node.js 本機加密函式進行對稱加密，同時向機制添加鹽以便在每次運行時獲得不同的加密結果？
uj5u.com熱心網友回復：
基本上IV是你的鹽。這就是目的（除了初始化鏈接演算法）。所以你可以接受你在這里發布的代碼。初始化向量是隨機的，因此加密的位元組每次都會不同。
只需簡單檢查一下，console.log您就會發現每次生成的位元組都完全不同。
另一方面，我不認為這個（相同的加密位元組）在這里是一個很大的問題。我寧愿確保鏈接方法至少是 CBC。在這里您可以閱讀更多相關資訊： https ://en.m.wikipedia.org/wiki/Block_cipher_mode_of_operation
另外，如果您想在中間攻擊的人中保持超級安全。您可以在訊息中添加一些HMAC。這將確保沒有人可以在您的資訊中稍作改動以使其與眾不同。換句話說，它提供
訊息的資料完整性和真實性。
但是，如果您通過 httpS 發送資料，那么所有這些安全措施都已經到位。因此示例 https 密碼的名稱：
tls_dhe_rsa_with_aes_256_gcm_sha384. 提取我在這里提到的東西。它使用aes256鏈式gcm模式并sha348作為hmac.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/507716.html
標籤：javascript 节点.js 加密 密码学 盐
上一篇：如何在一個函式中有多個addeventlistener
下一篇：優先將元素推送到陣列