[guardian-dev] Android SecureRandom bug mitigation

[Nathan of Guardian]

On 08/12/2013 03:21 PM, Abel Luck wrote:
> Does anyone have any bona fide information as to what the flaw/weakness
> actually is?

I think you misread the key passage perhaps:

"FIRST - When creating a self seeding SecureRandom instance (by calling
the constructor without arguments and subsequent setSeed() call), the
code fails to adjust the byte offset (a pointer into the state buffer)
after inserting a start value. This causes a counter and the beginning
of a padding (a 32 bit word) to overwrite parts of the seed instead of
appending."

This means, when you call SecureRandom() as instructed by Google to do,
then the result is a seed that is not appended to, and thus of not a
sufficiently strong enough length.

> I haven't found anything yet, and the BTC devs don't seem to be
> releasing much information.

This commit seems to say it all - tap right into /dev/urandom instead of
letting Android/Harmony/kernel handle it for you:
https://code.google.com/p/bitcoin-wallet/source/detail?r=04d2044880d88107ee4a939a516fb4be4cedeaf9

> None of the bitcoin apps affected were seeding SecureRandom, so that
> wasn't the issue.

Right, they were doing what they were "supposed" to do, as are we, in
the case of say OTR4J, or whenever we init SSLContexts.

> > The armoredbarista link also didn't find any issues that would apply to
> SecureRandom used in BC, so that's not it.

I think it does. It is in fact, any app that decided to manually seed
and pass an argument to the SecureRandom constructor that is safe.

+n