Security advisory for SJCL
277 views
Skip to first unread message
Mike Hamburg
Jul 25, 2012, 1:32:00 AM7/25/12
to sjcl-d...@googlegroups.com, sjcl-a...@googlegroups.com
Hello all,
It seems we have a Debian-style PRNG bug on our hands. When I added crypto.getRandom support to SJCL, I didn't verify that my code actually worked. It doesn't. Instead it fails silently. So instead of having 256 bits of random data stirred into the pool on application startup, instead only the time and a bunch of Math.random() values get stirred in. On some browsers (in particular, on at least some versions of Chrome), Math.random has only 32 bits of state. If an attacker knows the time to the minute that you encrypted something, that leaves 48 bits of entropy. Not enough, and through side channels (i.e. other browser windows) even Math.random might be recovered.
I think Safari is safe because of its strong Math.random, but I don't know of other browsers which have this. And anyway I haven't checked this recently, they may have removed that feature, or it might be in other browsers. But let's play it safe.
Fortunately, messages which have been encrypted with a strong password (the default mode of SJCL) are still secure.
All secret keys which may have been generated using the browsers that support crypto.getRandom should be considered compromised. This includes EC secret keys and AES secret keys. This doesn't include the temporary keys generated from a password and salt in the normal SJCL encryption process; the salt being weak doesn't matter that much.
All ECDSA signature keys which were used to sign messages on such browsers should be considered compromised.
Messages encrypted with EC-ElGamal (but not the keys) should be considered compromised.
If you were somehow using many browsers / Node.js instances in parallel to encrypt many messages, and happened to start several of them at exactly the same time to the millisecond, then messages encrypted in those sessions may be compromised (by an IV collision).
5bfbed2a8828e7ae197b938362dfb4e738af528b (master)
bf02fde51d9e4702baa30852ec364f4f568a95ed (ecc)
df983c0079a6550df08fd3e78460ddcd779a289a (version-0.8)
Sorry for my laziness in maintaining SJCL... maybe when I get some more time I'll fix some of the $n$ outstanding feature requests and other issues.
Cheers,
Mike Hamburg
It seems we have a Debian-style PRNG bug on our hands. When I added crypto.getRandom support to SJCL, I didn't verify that my code actually worked. It doesn't. Instead it fails silently. So instead of having 256 bits of random data stirred into the pool on application startup, instead only the time and a bunch of Math.random() values get stirred in. On some browsers (in particular, on at least some versions of Chrome), Math.random has only 32 bits of state. If an attacker knows the time to the minute that you encrypted something, that leaves 48 bits of entropy. Not enough, and through side channels (i.e. other browser windows) even Math.random might be recovered.
I think Safari is safe because of its strong Math.random, but I don't know of other browsers which have this. And anyway I haven't checked this recently, they may have removed that feature, or it might be in other browsers. But let's play it safe.
Fortunately, messages which have been encrypted with a strong password (the default mode of SJCL) are still secure.
All secret keys which may have been generated using the browsers that support crypto.getRandom should be considered compromised. This includes EC secret keys and AES secret keys. This doesn't include the temporary keys generated from a password and salt in the normal SJCL encryption process; the salt being weak doesn't matter that much.
All ECDSA signature keys which were used to sign messages on such browsers should be considered compromised.
Messages encrypted with EC-ElGamal (but not the keys) should be considered compromised.
If you were somehow using many browsers / Node.js instances in parallel to encrypt many messages, and happened to start several of them at exactly the same time to the millisecond, then messages encrypted in those sessions may be compromised (by an IV collision).
5bfbed2a8828e7ae197b938362dfb4e738af528b (master)
bf02fde51d9e4702baa30852ec364f4f568a95ed (ecc)
df983c0079a6550df08fd3e78460ddcd779a289a (version-0.8)
Sorry for my laziness in maintaining SJCL... maybe when I get some more time I'll fix some of the $n$ outstanding feature requests and other issues.
Cheers,
Mike Hamburg
Mike Hamburg
Jul 25, 2012, 1:33:51 AM7/25/12
to sjcl-a...@googlegroups.com, sjcl-d...@googlegroups.com
P.S. Credit to Sc00bz for finding and fixing this bug.
Mike Hamburg
Jul 25, 2012, 1:36:19 AM7/25/12
to sjcl-d...@googlegroups.com, sjcl-a...@googlegroups.com
And... sorry for the spam ... Das Archive. Last one. I think.
Reply all
Reply to author
Forward
0 new messages