Hi Chris and all, I think I agree with Ron, perhaps we should take SecureRandom (and RandomPool) out of the base. About collecting randomness, do you think we need SecureRandom class>>#entropicSourcesDo:? Shouldn't we use a RandomPool?
Luciano
On 2/13/06, Chris Muller chris@funkyobjects.org wrote:
I know we've talked about our package structure before but..
As I work through this book, I have some fixes and additions to our Crytography packages. Here is a list of things I plan to post in the coming days:
- addition of entropic sources for seed material
- addition of the CTR (counter) cipher mode
- addition of the "Fortuna" random generator
- fix for seriously broken MillerRabin algorithm
preventing generation of proper-sized asymmetric keys (i.e., for Diffie-Hellman / ElGamal and maybe RSA too).
For the first one "entropic sources for seed material". It individually hashes unpredictable strings from the users environment such as:
- current directory
- Time millisecondClockValue
- World imageForm bits compressToByteArray
- SmalltalkImage current vmStatisticsReportString
- Sensor mousePoint
- etc., etc.
and then finally SHA256 hashes the concatentation of all of those hashes. Slow, but totally unpredictable.
I've started by implementing SecureRandom class>>#entropicSourcesDo: which is used by SecureRandom class>>#randomSeed. But SecureRandom is in the "CryptographyBase" package, so I can't use SHA1 and SHA256.
It seems to me that many crypto primitives are built from other ones. Wouldn't it be easier to have everything back in one package? What are we trying to accomplish here by having them all in separate packages?
How should I proceed?
Thanks, Chris