Replies: 1 comment 4 replies
-
Nonce handling is a bit tricky, but here are a few rules you can follow to avoid problems:
I could provide a basic sequential nonce (i.e., a number that just automatically increments starting from a random value), but I wouldn't want to require that you use the one I provide, because you can also take advantage of a nonce to improve security in certain cases. For example in a network API protocol: the nonce can be selected once during the initial handshake, and then sequentially incremented by the client and server separately each time a message is exchanged, but after the initial handshake you would never transmit the nonce over the wire again. This way, if someone intercepts some of the messages, it would be nearly impossible to figure out the value of the nonce unless the spy has a way to guarantee they've intercepted 100% of all the messages exchanged since the beginning of time, including the nonce. It wouldn't be possible to know the value of the nonce if you miss even just one message. This is a pretty common pattern for handling nonces within well-designed protocols. Sequences are commonly used because of the aforementioned use case: once the two parties involved know the initial nonce, you can simply increment it forever and you don't need to transmit the nonce over the wire. Alice and Bob only need to know the nonce at the beginning of a protocol. Of course, if one of the parties misses a message or loses track of the nonce, you would have to do a new handshake. Sequences are good because they make it hard to accidentally reuse the same value, which helps protect you from replay attacks. In the case of a 64 bit nonce, you have For the reasons mentioned above, I would consider it bad practice to enforce a certain behaviour or pattern for handling nonces, but I could still include a basic sequential nonce in the library for convenience, and leave it up to individuals to decide whether to use it or not, without requiring it. |
Beta Was this translation helpful? Give feedback.
-
I want to use symmetric encryption for some database columns.
DryocSecretBox
is clearly the right way to go, but it's not immediately obvious how to handle the nonce. Either I need separate columns for the nonces (one for each column I want to encrypt), or I need to store the nonce and ciphertext in the same column in some appropriate format. It would be great if dryoc did that for me.I notice that orion has a mode where it both automatically generates the nonce (so you can't accidentally mismanage it, e.g., by reusing) and prepends it (so you don't have to figure out how to store and retrieve it): orion::aead.
Would this be a useful addition to dryoc, and what would be the best way to add it? I can imagine a
DryocEasySecretBox
which has a nonce field, but there are quite a few new names to be thought of. An alternative would be to make a breaking change and always store the nonce (dryoc could still retain a method to supply a nonce on creation, but add a new one which picks it automatically).Beta Was this translation helpful? Give feedback.
All reactions