[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
|