dckc
commented
5 years ago Why are we using a nonce here in the first place? Is it just an initialization vector for whatever underlying blockcipher mode secretbox is using?
I think so. We're just supposed to use a different nonce for each message we encrypt with the secret key. And we only ever encrypt one message per generated key pair.
Arguably the user should never recycle passwords, and we don't need to save them from themselves if they do, so perhaps we could just fix the nonce once and for all
Right... I picked a fixed random nonce, assuming the attacker shouldn't be able to predict it.
But I do see serial nonces all over the place, so maybe that's not something I should have worried about.
When symmetrically encrypting private keys for safe keeping in browser storage, we choose a random nonce (https://github.com/dckc/RSign/blob/sig-ext/sigTool.js#L146)
If our nonce is n bits long, then choosing randomly will on average produce sqrt(2^n) = 2^(n/2) unique nonces before repeating according to the birthday paradox. On the other hand, using sequential nonces will allow us a full 2^n unique nonces before repeating.
Thinking out loud for a moment: Why are we using a nonce here in the first place? Is it just an initialization vector for whatever underlying blockcipher mode secretbox is using? Arguably the user should never recycle passwords, and we don't need to save them from themselves if they do, so perhaps we could just fix the nonce once and for all. I learned my crypto from https://www.coursera.org/learn/crypto and some of the details are fading. But one thing that remains clear is that seemingly innocent implementation details can undermine the security of an entire system.
In any case, the nonce choice at least deserves a comment.
This issue is complete when a clear argument for how to choose the nonce has been made, implemented, and documented in this issue as well as briefly in the code.