[Cryptography Team] CTR mode, SecureRandom, ElGamal updates

[Chris Muller]

Hi, this is just note to keep everyone informed about
what I've done.  Sorry its long, I will try to keep it
newsworthy and dense.   I have begun committing my
initial Cryptography improvements as promised.  I just
committed the following to our repository:

For CryptographyBase:

- Updated all usages of standard Random to use
SecureRandom.  This now allows calculation of 512,
1024, 2048 and, computational power permitting, larger
keys.  According to Schneier, Ferguson - "Practical
Cryptography" p. 217:
	"A prime of 2048 bits can be expected to secure data
until around 2022; 3072 bits is secure until 2038; and
4096 bits until 2050." ...  "Be careful with these
kinds of predictions."

- Extended SecureRandom with #nextInt: and
#nextFrom:to:.  The implementation just keeps calling
nextBits: until an in-range is returned, and it passed
a simple dispersion test.

- As a substitute for Collection
class>>#randomForPicking, we now have SecureRandom
class>>#picker.  This keys of this are wiped out and
regenerated on every image save, since saving the key
to disk is not recommended.

- Added SecureRandom class>>#withGeneratedKey.  This
enumerates a series of relatively unpredictable
Strings such as the bitmap of the current Squeak
desktop, mouse position, Timer values, etc.

- Fixed printOn:


For Cryptography-Core:

- Addition of CTR (counter) cipher mode.  In
"Practical Cryptography" Schneier reasons this is
preferred mode due to its simple implementation and no
need for padding.

- Added LargePositiveInteger>>#destroy to permit
wiping of keys from the image at proper times.


For Cryptography-ElGamal

- Now using SecureRandom instead of (insecure) Random.


For Cryptography-Tests

- The ElGamal cryptography tests let us down in terms
of testing for practical usage.  They were using
15-bit keys which totally obscured the problem with
the Random, which could not even generate numbers
large enough for the primes associated with 2048-bit
asymmetric keys (not to mention 1024 and 512!). 
Therefore, I upgraded the tests to use 384
(generated), 512, 1024, 2048 bit ElGamal keys.  The
2048-bit took 10 hours (!!) to generate, so I
instantiate with its #storeString so that the tests
run quickly.

- Also beefed up the associated DiffieHellman test to
use 384 bit keys (probably should test these with the
same key sizes as ElGamel).

- Because of the enhanced tests, there are more
methods, so I recategorized according to what they are
testing; "ElGamal", "DSA", "RSA", etc.  However, I'm
beginning to think we should move these tests to their
individual packages of what they're testing.  What
does everyone else think?

That's all for now, I hope you like it..!

 - Chris