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

Rob Withers reefedjib at gmail.com
Fri Aug 27 23:15:09 UTC 2010


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 at gmx.de>

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

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

>
> 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
>
>
> --------------------------------------------------
> From: "Chris Muller" <asqueaker at gmail.com>
> Sent: Thursday, August 26, 2010 7:02 PM
> To: "Cryptography Team Development List" 
> <cryptography at lists.squeakfoundation.org>
> Cc: "The general-purpose Squeak developers list" 
> <squeak-dev at 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 at 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 at gmail.com>
>>> Sent: Sunday, August 22, 2010 5:35 PM
>>> To: "The general-purpose Squeak developers list"
>>> <squeak-dev at lists.squeakfoundation.org>
>>> Cc: "Squeak Crypto" <cryptography at 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 at 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 at lists.squeakfoundation.org
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>>>>
>>> _______________________________________________
>>> Cryptography mailing list
>>> Cryptography at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>>>
>>
>>
> 



More information about the Squeak-dev mailing list