4 ms·
The paper is worth reading: http://crypto.stanford.edu/sjcl/#paper http://crypto.stanford.edu/sjcl/#paper It reads fairly well. Interesting how they built thei
by paulbaumgart 17y ago
The paper is worth reading: http://crypto.stanford.edu/sjcl/#paper http://crypto.stanford.edu/sjcl/#paper It reads fairly well.
Interesting how they built their CSPRNG, using mouse movements gathered as the user interacts with a page (and optionally cookie data):
Since we extract 2 bits of entropy per mouse move sample,
we need 128 samples to generate a 256-bit AES key. Our data
shows the that median time for the generator to be seeded
to the default level of 128 samples is 9, 28 and 41 seconds
on the survey, forum and blog, respectively.
I wonder if there's a good way to buffer the entropy securely so it doesn't have to wait so long for every encryption.
- cortesi 17y agoIn a nutshell, that's almost what the Fortuna family of PRNGs do. In the JSCrypto implementation, entropy is collected from the mouse movements continuously, and like all Fortuna implementations it uses a clever dance using a block cypher and multiple entropy pools is to "buffer" the entropy. Google "fortuna" for more information.
- aaronblohowiak 17y agoEdit: Sorry. I deleted my comment. I thought you were being redundant and hadn't read the article. I didn't notice that you were the author. can someone vote this comment's parent up?
- cortesi 17y agoThat's a bit over-zealous - even if I hadn't been the author of the article, noting that Fortuna PRNGs can be thought of as "buffering" entropy would have been worthwhile in this context.
- paulbaumgart 17y agoGot it, thanks. It wasn't clear to me from the paper or the reference implementation that it did that, but it makes sense it would.