[Box Backup] New openssl packages fix predictable random number generator

[Bjarne Carlsen]

No gun is in my hand - see! ;)

You are absolutely correct. The author has chosen to seed the prng by
running through the (insecure on Debian/-derivatives) function
ssleay_rand_add a number of times, meaning that in the previous versions
of OpenSSL, which had the mixing function commented out on those
systems, the input was not mixed properly into the the state of the
prng.

That said, Box Backup uses the raw output from the prng, not the
generated .pem files, so the FileEncKeys.raw should be considerably more
secure - the raw data has a SHA-1 hash mixed in after all, and
collisions in SHA-1 in this context only means that two keys have a
finite and very small possibility of ending up the same, and they could
conceivably do that even on a non-Debian system.

A regeneration of FileEncKeys.raw after upgrading OpenSSL to the latest
verson should be considered by all Debian and -derivative users though. 

As I read the Box Backup docs, this would mean that all earlier backups
will be valueless, unless the old (possibly insecure) keys are kept, and
you would presumably have to back up and clear the store, and then start
a new backup cycle on the fresh store while keeping the old backups in
another place. 

Oh my! Now it's me who am going to get shot...

Bjarne

ons, 14 05 2008 kl. 22:29 +0100, skrev Kenny Millington:
> Hi,
> 
> > By letting OpenSSL generate 1024 random characters. It's the 'openssl
> > rand -out <idnumber>-FileEncKeys.raw 1024' command that is used.
> 
> Ah! That could be a problem then... (having checked by asking on
> #debian) "openssl rand ..." was also affected by problem reported in the
> Debian Security Advisory.
> 
> This means that if any data encryption keys were generated on vulnerable
> hosts they need to be regenerated or the data cannot be considered
> secure (given the amount of entropy that would have been used).
> 
> So, um, don't shoot the messenger! :o)
>