RE: Random Number Seed in File? (was: ElcomSoft Co.Ltd. fould a flaw in V3Beta1)

Hi Frank,

Indeed Linux does something like this, storing/restoring the seed at
shutdown/restore.

I'm not sure that this applies in our case, though. The main problem is when
a database is created - that's when a highly random key is needed, and
exacly when there's no prestored seed to read.

I like your idea of reading inter-keystroke timing when the user enters her
passphrase. I'll try to implement this in the next beta, as well as some
other, weaker, sources of entropy (current time, mouse coordinates, process
number, all mixed in a cryptographic hash. I'll also try to implement a
decent PRNG, perhaps something along the lines of the FIPS 186-2 Appendix 3
scheme.

	Cheers,

		R.

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On 
> Behalf Of Frank Pilhofer
> Sent: Saturday, April 08, 2006 1:49 AM
> To: Rony Shapiro; [email protected]
> Subject: [Passwordsafe-devel] Random Number Seed in File? 
> (was: ElcomSoft Co.Ltd. fould a flaw in V3Beta1)
> 
> On Fri, 24 Mar 2006 01:31:08 -0500, Rony Shapiro 
> <[email protected]> wrote:
> >
> > The good folks at ElcomSoft have found a weakness in the new release
that
> > makes the master encryption key vulnerable to a brute-force attack when
> > running pwsafe on pre-XP versions of Windows, basically since we
fallback to
> > the rand() prng for those platforms.
> >
> 
> I was thinking about this the other day. So all implementations of
Password
> Safe require a good random number generator (whether provided by the
operating
> system or not), and, just as important, need to seed any PRNG. It is not
easy
> to come up with a good source of entropy to initialize the PRNG's seed.  
> Password Gorilla currently uses the (microsecond) timing between 
> keystrokes when the user enters the master password.
> 
> I was wondering if it would be a good idea to set aside a 
> header field in  the
> V3 database format for the seed, so that it can be carried 
> over across runs.
> This new header field would be a random number that an implementation
could
> optionally use to (help) seed a PRNG.
> 
> When a database file is opened, the implementation would add 
> some "new"  entropy
> to the one in the header field, and, if the file is saved, 
> update the seed  with
> new random numbers. The entropy in the file would then "get 
> better" over  time,
> as more and more fresh randomness is added to the initial 
> value from file creation.
> 
> If an implementation used an external (e.g., OS-provided)  (P)RNG, it
could
> ignore the header field, but would still have to fill in the random number

> when saving the database.
> 
> IIRC, Linux does something quite similar for its /dev/random entropy
generator.
> 
> This field would have to be encrypted, a la the B1-B4 header fields.
> 
> Does this make sense?
> Frank
> 
> 
> -- 
> Frank Pilhofer, [email protected]




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642