[squeak-dev] Re: [Cryptography Team] Re: DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random

Andreas Raab andreas.raab at gmx.de
Fri Aug 27 04:48:46 UTC 2010


On 8/26/2010 4:02 PM, Chris Muller wrote:
> Folding Cryptography into Squeak would probably go against the
> political momentum toward smaller, more modular images.

I'm not entirely sure about this. The problems with the Crypto package 
as I see it are:

1) It carries a lot of dead weight. It might be educational to carry an 
implementation of MD2 but it's also completely *useless*. So my take 
here would be to have two packages "Crypto-Core" and "Crypto-Extras" and 
move all of the non-essential stuff to Crypto-Extras.

2) It has too many variations (all those *WithPrimitive and 
*NonPrimitive) variants. There's no need to have both; write the 
primitive variants so that they use non-primitive fallback code or 
simply require the primitives.

3) ASN1, X509, PKCS. This is not cryptography, this is certificate 
handling. It should be in a Certificates package, not Cryptography.

4) A category per class. Puh-lease...

If you do all of the above you'll end up with one or two "Crypto-Core" 
categories containing all of the "essentials" like MD5, Triple DES, DSA, 
RSA, SHA1, SHA256. That's probably about what you'd want in the base 
image and I'd be surprised if it's more than 20 classes. I think you 
could make a *very* reasoned case that this Crypto-Core should be 
included in the trunk image by default in particular considering that it 
would remain loadable and simplify the System (and other) packages.

Then you have Crypt-Extras with the less common stuff, from MD2 to 
DiffieHelman. On top of which is the Certificate package with ASN1, 
X509, and PKCS. On top of which is the SSL stuff.

I think this would be quite a nice structure and I'd be supporting 
getting a small Crypto-Core package into trunk. Anyone up for it?

Cheers,
   - Andreas



More information about the Squeak-dev mailing list