Andreas,
I will volunteer to take this on. I think it is a good idea. I need write access to the trunk repository, I believe. Can you help me with that? I am not sure how inbox gets used or whether I should use it.
From what I have gathered that you said, we should have the following
packages:
CryptoCore CryptoCoreTests CryptoExtras CryptoExtrasTests Certificates CertificatesTests
Can you confirm this and that all would become Truck packages?
A question below....
-------------------------------------------------- From: "Andreas Raab" andreas.raab@gmx.de
- 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.
This really isn't so bad. There are 4 plugins, and so there are 4 *WithPrimitive and 4 *NonPrimitive variants. I suggest for phase 1 we leave these alone. The issue is that in some cases the algorithm used for the Primitive is different than the algorithm used in the image. It will take some thinking to write non-primitive fallback code and untangle the algorithm class to use it. A worthy goal but not something that prevents us from packaging Crypto into the Trunk.
Cheers, Rob
- ASN1, X509, PKCS. This is not cryptography, this is certificate
handling. It should be in a Certificates package, not Cryptography.
- 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
From: "Chris Muller" asqueaker@gmail.com Sent: Thursday, August 26, 2010 7:02 PM To: "Cryptography Team Development List" cryptography@lists.squeakfoundation.org Cc: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [Cryptography Team] Re: [squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random
DigitalSignatureAlgorithm, SecureHashAlgorithm and ThirtyTwoBitRegister have been part of Squeak for a long time, there are legacy users, although I think they should migrate to using the counterparts in Cryptography.
Folding Cryptography into Squeak would probably go against the political momentum toward smaller, more modular images. We don't need to do something that drastic just to solve this issue.
I suggest instead that we merely move two utility methods from Cryptography:
RandomGenerator class>>unpredictableStringsDo: aBlock RandomGenerator class>>generateKey
to Random class in Squeak, and then employ them in DigitalSignatureAlgorithm for its #initRandomNonInteractively. #generateKey should be patched up from its dependence on Cryptography methods.
This allows Squeak to purge the insecure approach of grabbing bits from a (silent or disconnected) SoundService, in favor of the robust one in Cryptography (except now moved to Squeak).
- Chris
On Mon, Aug 23, 2010 at 10:09 AM, Rob Withers reefedjib@gmail.com wrote:
Hi Chris,
It works really well. The only issue now is the DigitalSignatureAlgorithm is located in the core squeak image and the changes I made are in the Cryptography package. It would be nice to fold Cryptography into the core squeak image, or pull DigitalSignatureAlgorithm out into Cryptography.
Rob
From: "Chris Muller" asqueaker@gmail.com Sent: Sunday, August 22, 2010 5:35 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Crypto" cryptography@lists.squeakfoundation.org Subject: [Cryptography Team] Re: [squeak-dev] DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random
Good, SecureRandom employs its #generateKey method (on the class side) to initialize its 'picker' (class-instance var). This was intended to serve as a globally usable SecureRandom so that clients like DigitalSignatureAlgorithm would not have to define their own.
On Sat, Aug 21, 2010 at 5:30 AM, Rob Withers reefedjib@gmail.com wrote:
I found a problem with DigitalSignatureAlgorithm>>#initRandomNonInteractively. It is grabbing randomBits from the SoundSystem, but I may not have that installed. It gave me the same bits repeatedly. I modified DigitalSignatureAlgorithm>>#initRandomNonInteractively to not rely on the SoundSystem and instead use SecureRandom. This is published in the Cryptography repository.
Rob
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography