DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random

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

> 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 <[hidden email]> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>

> 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" <[hidden email]>
> Sent: Sunday, August 22, 2010 5:35 PM
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> Cc: "Squeak Crypto" <[hidden email]>
> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>

>
> 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" <[hidden email]>
> Sent: Thursday, August 26, 2010 7:02 PM
> To: "Cryptography Team Development List"
> <[hidden email]>
> Cc: "The general-purpose Squeak developers list"
> <[hidden email]>
> 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 <[hidden email]>
>> 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" <[hidden email]>
>>> Sent: Sunday, August 22, 2010 5:35 PM
>>> To: "The general-purpose Squeak developers list"
>>> <[hidden email]>
>>> Cc: "Squeak Crypto" <[hidden email]>
>>> 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 <[hidden email]>
>>>> 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
>>>> [hidden email]
>>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>>>>
>>> _______________________________________________
>>> Cryptography mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>>>
>>
>>
>

>
>
> --------------------------------------------------
> From: "Bert Freudenberg" <[hidden email]>
> Sent: Saturday, August 28, 2010 6:42 AM
> To: "The general-purpose Squeak developers list" <[hidden email]>
> Cc: "Squeak Crypto" <[hidden email]>
> Subject: Re: [Cryptography Team] Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis not random
>
>> It's best to first publish to the inbox. You do not need special permissions for that. Once we're happy with the packages we move them over to trunk.
>
> Done.   The following packages are in the Inbox:
>
> CryptoCore
> CryptoCoreTests
> CryptoExtras
> CryptoExtrasTests
> CryptoCerts
> CryptoCertsTests
>
> All tests pass, although I have not tried to load just CryptoCore and CryptoCoreTests and run its tests.
>
> Rob

>
> On 28.08.2010, at 12:59, Rob Withers wrote:
>
>>
>>
>> --------------------------------------------------
>> From: "Bert Freudenberg" <[hidden email]>
>> Sent: Saturday, August 28, 2010 6:42 AM
>> To: "The general-purpose Squeak developers list"
>> <[hidden email]>
>> Cc: "Squeak Crypto" <[hidden email]>
>> Subject: Re: [Cryptography Team]
>> Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis
>> not random
>>
>>> It's best to first publish to the inbox. You do not need special
>>> permissions for that. Once we're happy with the packages we move them
>>> over to trunk.
>>
>> Done.   The following packages are in the Inbox:
>>
>> CryptoCore
>> CryptoCoreTests
>> CryptoExtras
>> CryptoExtrasTests
>> CryptoCerts
>> CryptoCertsTests
>>
>> All tests pass, although I have not tried to load just CryptoCore and
>> CryptoCoreTests and run its tests.
>>
>> Rob
>
> Ah, should have commented on the package names - didn't think you're
> *that* fast ;)

> On 28.08.2010, at 13:30, Rob Withers wrote:
>
>>> The convention is to use hyphenation. As Andreas suggested, that would
>>> be "Crypto-Core", "Crypto-Core-Tests" etc.
>>
>> The problem with that approach is the the Test package gets included with
>> the core package.  In the example of "Kernel" and "KernelTests"
>> hyphenation is not used.
>
> Err, right.

>
>
> --------------------------------------------------
> From: "Bert Freudenberg" <[hidden email]>
> Sent: Saturday, August 28, 2010 7:13 AM
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> Subject: Re: [Cryptography
> Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot
> random
>
>>
>> On 28.08.2010, at 12:59, Rob Withers wrote:
>>
>>>
>>>
>>> --------------------------------------------------
>>> From: "Bert Freudenberg" <[hidden email]>
>>> Sent: Saturday, August 28, 2010 6:42 AM
>>> To: "The general-purpose Squeak developers list"
>>> <[hidden email]>
>>> Cc: "Squeak Crypto" <[hidden email]>
>>> Subject: Re: [Cryptography Team]
>>> Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis
>>> not random
>>>
>>>> It's best to first publish to the inbox. You do not need special
>>>> permissions for that. Once we're happy with the packages we move them
>>>> over to trunk.
>>>
>>> Done.   The following packages are in the Inbox:
>>>
>>> CryptoCore
>>> CryptoCoreTests
>>> CryptoExtras
>>> CryptoExtrasTests
>>> CryptoCerts
>>> CryptoCertsTests
>>>
>>> All tests pass, although I have not tried to load just CryptoCore and
>>> CryptoCoreTests and run its tests.
>>>
>>> Rob
>>
>> Ah, should have commented on the package names - didn't think you're *that*
>> fast ;)
>
> I did the work last night.

>
>>
>> The convention is to use hyphenation. As Andreas suggested, that would be
>> "Crypto-Core", "Crypto-Core-Tests" etc.
>
> The problem with that approach is the the Test package gets included with the
> core package.  In the example of "Kernel" and "KernelTests" hyphenation is
> not used.
>
> Rob
>
>
>
>

> (changed subject for better tracking)
>
> On 8/28/2010 3:59 AM, Rob Withers wrote:
>> Done. The following packages are in the Inbox:
>>
>> CryptoCore
>> CryptoCoreTests
>> CryptoExtras
>> CryptoExtrasTests
>> CryptoCerts
>> CryptoCertsTests
>>
>
> Thanks, Rob. I did a quick check and it's pretty close to what I was
> thinking in terms of structure (although I would rename CryptoCerts to
> just Certificates but that's a minor issue). As for inclusion, I *think*
> we should probably include CryptoCore and CryptoExtras in trunk but not
> the certificates package. My reasoning here is that people usually need
> the key crypto algorithm and cert handling usually goes together with
> other things (like SSL etc) and should probably be loaded when that is
> loaded. This is also partly why I would prefer a package Certificates
> because it would mean that the "Cryptography" stuff (Crypto-Core,
> Crypto-Extras, Crypto-Tests) is in trunk, whereas the Certificate and SSL
> package remain in the Cryptography repository on SqueakSource. But I'd
> like to hear other opinions on this.
>
> Also, I've checked the CryptoCore package and we'll need to do something
> about the extensions at some point. Several of them are reasonable (in
> fact, I like some of them very much like ByteArray bit manipulation which
> is extremely useful and should be part of the regular BA protocol) but
> some of them are duplicates (ByteArray unsignedLongAt:) and others are
> just obscure (String destroy etc). However, except from the conflicts we
> probably don't have to address these in the first round.

> On Sat, 28 Aug 2010, Rob Withers wrote:
>
>>
>>
>> --------------------------------------------------
>> From: "Bert Freudenberg" <[hidden email]>
>> Sent: Saturday, August 28, 2010 7:13 AM
>> To: "The general-purpose Squeak developers list"
>> <[hidden email]>
>> Subject: Re: [Cryptography
>> Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot
>> random
>>
>>>
>>> On 28.08.2010, at 12:59, Rob Withers wrote:
>>>
>>>>
>>>>
>>>> --------------------------------------------------
>>>> From: "Bert Freudenberg" <[hidden email]>
>>>> Sent: Saturday, August 28, 2010 6:42 AM
>>>> To: "The general-purpose Squeak developers list"
>>>> <[hidden email]>
>>>> Cc: "Squeak Crypto" <[hidden email]>
>>>> Subject: Re: [Cryptography Team]
>>>> Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis not
>>>> random
>>>>
>>>>> It's best to first publish to the inbox. You do not need special
>>>>> permissions for that. Once we're happy with the packages we move them over
>>>>> to trunk.
>>>>
>>>> Done.   The following packages are in the Inbox:
>>>>
>>>> CryptoCore
>>>> CryptoCoreTests
>>>> CryptoExtras
>>>> CryptoExtrasTests
>>>> CryptoCerts
>>>> CryptoCertsTests
>>>>
>>>> All tests pass, although I have not tried to load just CryptoCore and
>>>> CryptoCoreTests and run its tests.
>>>>
>>>> Rob
>>>
>>> Ah, should have commented on the package names - didn't think you're
>>> *that* fast ;)
>>
>> I did the work last night.
>
> Cool. I see we can improve quite a lot of things in CryptoCore.
>
>
> Levente
>

>>
>>>
>>> The convention is to use hyphenation. As Andreas suggested, that would be
>>> "Crypto-Core", "Crypto-Core-Tests" etc.
>>
>> The problem with that approach is the the Test package gets included with
>> the core package.  In the example of "Kernel" and "KernelTests" hyphenation
>> is not used.
>>
>> Rob
>>
>>
>>
>>
>
>

> (changed subject for better tracking)
>
> On 8/28/2010 3:59 AM, Rob Withers wrote:
>> Done. The following packages are in the Inbox:
>>
>> CryptoCore
>> CryptoCoreTests
>> CryptoExtras
>> CryptoExtrasTests
>> CryptoCerts
>> CryptoCertsTests
>>
>
> Thanks, Rob. I did a quick check and it's pretty close to what I was
> thinking in terms of structure (although I would rename CryptoCerts to
> just Certificates but that's a minor issue). As for inclusion, I *think*
> we should probably include CryptoCore and CryptoExtras in trunk but not
> the certificates package. My reasoning here is that people usually need
> the key crypto algorithm and cert handling usually goes together with
> other things (like SSL etc) and should probably be loaded when that is
> loaded. This is also partly why I would prefer a package Certificates
> because it would mean that the "Cryptography" stuff (Crypto-Core,
> Crypto-Extras, Crypto-Tests) is in trunk, whereas the Certificate and SSL
> package remain in the Cryptography repository on SqueakSource. But I'd
> like to hear other opinions on this.
>
> Also, I've checked the CryptoCore package and we'll need to do something
> about the extensions at some point. Several of them are reasonable (in
> fact, I like some of them very much like ByteArray bit manipulation which
> is extremely useful and should be part of the regular BA protocol) but
> some of them are duplicates (ByteArray unsignedLongAt:) and others are
> just obscure (String destroy etc). However, except from the conflicts we
> probably don't have to address these in the first round.

> On Sat, 28 Aug 2010, Nicolas Cellier wrote:
>
>>
>
> snip
>
> I just took a look at the extension methods (there are quite a lot) and most
> of them can be simplified or removed.
>
>> For example
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-July/130162.html
>
> Like this.
>
>> Maybe http://bugs.squeak.org/view.php?id=7109 would serve a bit too...
>
> Hm. This looks interresting, I guess some optimizations are already
> implemented:
>
> | x |
> x := SmallInteger maxVal raisedTo: 100.
> #(-1600 -1597 1597 1600) collect: [ :shift |
>        [ 1 to: 100000 do: [ :i | x bitShift: shift ] ] timeToRun ].
> "CogVM  ===> #(150 147 271 64)"
> "SquakVM ===> #(97 118 343 71)"
>
>
> Levente
>

>>
>> Nicolas
>>
>>>>
>>>>>
>>>>> The convention is to use hyphenation. As Andreas suggested, that would
>>>>> be
>>>>> "Crypto-Core", "Crypto-Core-Tests" etc.
>>>>
>>>> The problem with that approach is the the Test package gets included
>>>> with
>>>> the core package.  In the example of "Kernel" and "KernelTests"
>>>> hyphenation
>>>> is not used.
>>>>
>>>> Rob
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>
>