如何在非对称加密(libsodium)中使用随机数? [英] How to use nonces in asymmetric encryption (libsodium)?

查看:373
本文介绍了如何在非对称加密(libsodium)中使用随机数?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在编写一个应用程序,用户可以使用端到端加密在设备之间进行通信.为此,我使用libsodium加密库.非对称加密函数crypto_box(...)要求将随机数作为参数之一.

我对如何处理随机数感到困惑.发送给一个人的每条消息是否都需要使用不同的随机数进行加密?这似乎是不对的,因为我将不得不将用过的现时存储在具有公共访问权限的服务器上,在该服务器上,攻击者可能仅会再次使用其中一个用过的现时.

从A到B的所有消息具有不同的随机数是否足够,还是可以将从A到B的消息所使用的随机数不用于从C到B的发送?

有人可以向我解释一下吗?

解决方案

使用给定的共享密钥发送的每条消息都需要一个唯一的随机数.随机数不必是秘密的;一个简单的计数器就可以了;即使将同一封邮件发送两次,更改随机数中的单个位也将使密文看起来完全不同.

什么是共享机密?它是根据(A的私钥,B的公钥)或(A的公钥,B的私钥)计算出的密钥. A和B根据所拥有的内容执行不同的计算,但最终得到相同的共享机密.

crypto_box中使用的共享机密为256位长.这是巨大的.您可以放心地认为,每个对话"的共享机密都是唯一的.

因此,(A,B),(A,C)和(C,B)可以使用相同的随机数安全地交换消息. 但是,如果A使用给定的随机数向B发送消息,则B无法使用相同的随机数向A发送消息.随机数必须在A和B之间进行对话时交换的所有内容都是唯一的.

因此,一个简单的计数器就可以了.拥有A个偶数,将奇数留给B,在每条消息发送后将随机数增加2,就可以了.

但是crypto_box构造中使用的密码实际上具有非常大的随机数. 192位.

这意味着,如果您忽略我写的所有内容,而每次发送消息时都只是随机选择一个随机数,则发生碰撞的可能性非常小,因此您可以放心,它在实践中永远不会发生.

钠中包含的某些流密码(AES128-CTR,ChaCha20,Salsa20)具有更短的随机数,并且需要计数器来避免冲突.这就是为什么它们位于文档的高级"部分.

但是使用crypto_boxcrypto_secretbox时,只需每次随机选择一次随机数(randombytes_buf(nonce, sizeof nonce)),便会很安全.

I am writing an app where users can communicate between devices with end to end encryption. For this I use the libsodium encryption library. The asymmetric encryption function, crypto_box(...) requires a nonce as one of the arguments.

I am a bit confused about how to handle nonces. Does every message to one person need to be encrypted using different nonces? This does not seem right since I would have to store the used nonces on a server with public access where an attacker could just use one of the used nonces again.

Is it enough that all messages sent from A to B have different nonces or can the nonce use to send a message from A to B not be used to send from C to B?

Can someone please explain this to me.

解决方案

A unique nonce is required for every message sent using a given shared secret key. The nonce doesn't have to be secret; a simple counter is totally fine; changing a single bit in the nonce is going to make the ciphertext look totally different even if the same message is sent twice.

What's a shared secret? It a key calculated from (A's secret key, B's public key) or (A's public key, B's secret key). A and B perform a different calculation, based on what they have, but end up with the same shared secret.

The shared secrets used in crypto_box are 256-bit long. Which is huge. You can safely consider that shared secrets are going to be unique for each "conversation".

So, (A, B), (A, C) and (C, B) can safely exchange messages using the same nonces. But if A sends a message to B using a given nonce, B cannot send a message to A using the same nonce. Nonces have to be unique for everything exchanged during a conversation between A and B.

So, a simple counter can be fine. Have A pick even numbers, leave odd numbers to B, increment the nonce by 2 after every message sent and you're good to go.

But the cipher used in the crypto_box construction actually has a really huge nonce. 192 bits.

Which means that if you ignore everything I wrote and just pick a random nonce every time you send a message, the probability to get a collision is so small that you can rest assured that it will never ever happen in practice.

Some stream ciphers included in Sodium (AES128-CTR, ChaCha20, Salsa20) have a shorter nonce, and require a counter to avoid collisions. This is why they are in the "advanced" section of the documentation.

But with crypto_box and crypto_secretbox, just pick a random nonce every time (randombytes_buf(nonce, sizeof nonce)) and you will be safe.

这篇关于如何在非对称加密(libsodium)中使用随机数?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆