You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to use noise in a protocol that supports multiple parallel reliable streams (QUIC or enet). I'd like to avoid needing to do a handshake for each channel and just reuse the known keys from the initiating channel instead. I believe I have a solution, but I'm no cryptography expert and I'd like a second opinion.
Section 11.4 about out-of-order messsages says that it's possible to decrypt messages out-of-order simply by providing the nonce that the message was encrypted with. That seems to me that the only changing state in the connection, barring re-keys, is the nonce.
Therefore, I think I can support multiple streams by generating and keeping track of separate nonces for each channel, and setting the appropriate nonce in the reader before en/decrypting the channel's message.
The library I am using (snow, for rust) seems to just use a 64-bit counter for the nonce. I believe I should be able to partition that as 32 bits for the channel ID and 32 bits for the counter. They shouldn't overlap as long as I make sure the counter does not overflow.
Is this sound? Are there any security flaws that I have overlooked?
The text was updated successfully, but these errors were encountered:
I'd like to use noise in a protocol that supports multiple parallel reliable streams (QUIC or enet). I'd like to avoid needing to do a handshake for each channel and just reuse the known keys from the initiating channel instead. I believe I have a solution, but I'm no cryptography expert and I'd like a second opinion.
Section 11.4 about out-of-order messsages says that it's possible to decrypt messages out-of-order simply by providing the nonce that the message was encrypted with. That seems to me that the only changing state in the connection, barring re-keys, is the nonce.
Therefore, I think I can support multiple streams by generating and keeping track of separate nonces for each channel, and setting the appropriate nonce in the reader before en/decrypting the channel's message.
The library I am using (snow, for rust) seems to just use a 64-bit counter for the nonce. I believe I should be able to partition that as 32 bits for the channel ID and 32 bits for the counter. They shouldn't overlap as long as I make sure the counter does not overflow.
Is this sound? Are there any security flaws that I have overlooked?
The text was updated successfully, but these errors were encountered: