DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random

Rob Withers-2
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


Reply | Threaded
Open this post in threaded view
|

Re: DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random

Chris Muller-3
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
>
>

Reply | Threaded
Open this post in threaded view
|

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

Rob Withers-2
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
>

Reply | Threaded
Open this post in threaded view
|

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

Chris Muller-3
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
>

Reply | Threaded
Open this post in threaded view
|

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

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

Reply | Threaded
Open this post in threaded view
|

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

Rob Withers-2
In reply to this post by Chris Muller-3
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" <[hidden email]>

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

Reply | Threaded
Open this post in threaded view
|

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

Bert Freudenberg
On 28.08.2010, at 01:15, Rob Withers wrote:

> Andreas,
>
> I will volunteer to take this on.

Yay! :)

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

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.

- Bert -


Reply | Threaded
Open this post in threaded view
|

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

Rob Withers-2


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


Reply | Threaded
Open this post in threaded view
|

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

Bert Freudenberg

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

The convention is to use hyphenation. As Andreas suggested, that would be "Crypto-Core", "Crypto-Core-Tests" etc.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random

Rob Withers-2


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


Reply | Threaded
Open this post in threaded view
|

Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random

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

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: [CryptographyTeam]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

Rob Withers-2


--------------------------------------------------
From: "Bert Freudenberg" <[hidden email]>
Sent: Saturday, August 28, 2010 7:50 AM
To: "The general-purpose Squeak developers list"
<[hidden email]>
Subject: Re:
[CryptographyTeam]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

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

But I can change it if you want me too.   In fact, I already have.  Should I
publish it as Crypto-Core, etc?

Rob


Reply | Threaded
Open this post in threaded view
|

Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random

Colin Putney
In reply to this post by Rob Withers-2

On 2010-08-28, at 4:30 AM, 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.

Just move the 'Tests' part to the middle:

Crypto-Core
Crypto-Tests-Core
Crypto-Extras
Crypto-Tests-Extras
Crypto-Certs
Crypto-Tests-Certs

Colin
Reply | Threaded
Open this post in threaded view
|

Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random

Levente Uzonyi-2
In reply to this post by Rob Withers-2
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
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Cryptography in trunk (Re: [Cryptography Team] Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis not random)

Andreas.Raab
In reply to this post by Rob Withers-2
(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.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Cryptography in trunk (Re: [Cryptography Team] Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis not random)

Rob Withers-2


--------------------------------------------------
From: "Andreas Raab" <[hidden email]>
Sent: Saturday, August 28, 2010 11:42 AM
To: "The general-purpose Squeak developers list"
<[hidden email]>
Subject: [squeak-dev] Cryptography in trunk (Re: [Cryptography Team]
Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis not random)

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

Andreas,

I am glad this is moving forward.  A few questions come to mind.

1) What should be the final package naming?  I chose CryptoCore, etc.  You
think CryptoCerts should be Certificates.   Bert and Colin had suggestions
for Crypto-Core and Tests (I especially like Colin's suggestion).  I have
renamed the packages here to Crypto-Core, etc, but not Certificates yet
(which has extension protocol cat name changes), but I have not pushed them
to Inbox.  Given final naming, I can push to Inbox and you can clean out old
stuff.   So what's the final naming decision?

2) Are there packages in trunk that are not built in the trunk image?  If
not, where do alternate packages live?  I wonder where Certificates will end
up.

3) I published SSL to Inbox.  Same question as #2.

4) Certificates.  Perhaps better suited to its own thread.  Currently used
by SSL's SSLCertificateStore, which is an in-memory certificate store of
certificates and their private keys and root CA certificates.  I do not
recall the level of support to passing certificate chains.  Several topics
here.  Should we establish a persistent Squeak certificate store, where we
have a key database file, encrypted, and a cert database file not encrypted?
Kinda like NSS.  We could apply for a Squeak CA certificate from Verisign or
someone and then have a way to allow Squeakers to apply for a signed cert
from the Squeak CA.  (generate CSR from local certStore, submit for Cert,
...)  Does this help your SqueakSSL stuff?  Thoughts on all I have written?

Cheers,
Rob


Reply | Threaded
Open this post in threaded view
|

Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random

Nicolas Cellier
In reply to this post by Levente Uzonyi-2
2010/8/28 Levente Uzonyi <[hidden email]>:

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

For example http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-July/130162.html
Maybe http://bugs.squeak.org/view.php?id=7109 would serve a bit too...

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

Reply | Threaded
Open this post in threaded view
|

Re: Cryptography in trunk (Re: [Cryptography Team] Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis not random)

Rob Withers-2
In reply to this post by Andreas.Raab
(my message seems to have gotten lost....resending)

--------------------------------------------------
From: "Andreas Raab" <[hidden email]>
Sent: Saturday, August 28, 2010 11:42 AM
To: "The general-purpose Squeak developers list"
<[hidden email]>
Subject: [squeak-dev] Cryptography in trunk (Re: [Cryptography Team]
Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis not random)

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

Andreas,

I am glad this is moving forward.  A few questions come to mind.

1) What should be the final package naming?  I chose CryptoCore, etc.  You
think CryptoCerts should be Certificates.   Bert and Colin had suggestions
for Crypto-Core and Tests (I especially like Colin's suggestion).  I have
renamed the packages here to Crypto-Core, etc, but not Certificates yet
(which has extension protocol cat name changes), but I have not pushed them
to Inbox.  Given final naming, I can push to Inbox and you can clean out old
stuff.   So what's the final naming decision?

2) Are there packages in trunk that are not built in the trunk image?  If
not, where do alternate packages live?  I wonder where Certificates will end
up.

3) I published SSL to Inbox.  Same question as #2.

4) Certificates.  Perhaps better suited to its own thread.  Currently used
by SSL's SSLCertificateStore, which is an in-memory certificate store of
certificates and their private keys and root CA certificates.  I do not
recall the level of support to passing certificate chains.  Several topics
here.  Should we establish a persistent Squeak certificate store, where we
have a key database file, encrypted, and a cert database file not encrypted?
Kinda like NSS.  We could apply for a Squeak CA certificate from Verisign or
someone and then have a way to allow Squeakers to apply for a signed cert
from the Squeak CA.  (generate CSR from local certStore, submit for Cert,
...)  Does this help your SqueakSSL stuff?  Thoughts on all I have written?

Cheers,
Rob
 


Reply | Threaded
Open this post in threaded view
|

Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random

Levente Uzonyi-2
In reply to this post by Nicolas Cellier
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
>>>
>>>
>>>
>>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random

Nicolas Cellier
2010/8/29 Levente Uzonyi <[hidden email]>:

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

I should have a look at source then...

Currently I'm playing with modular arithmetic bottlenecks.
It seems that NINV algorithm (
http://www.iacr.org/archive/ches2005/017.pdf ) is better than binary
one employed for modular inversion.
I get near a 2x factor on this specific method, leading to roughly 15%
improvment on this kind of sequence
                h := hasher hashMessage: 'Nicolas Cellier'.
                sig := dsa computeSignatureForMessageHash: h privateKey: privateKey.
                dsa signatureToString: sig
I'm quite sure there exist a Lehmer's variant to the extended Euclid
used to compute the inverse. I don't own Knuth bible and my brain is
just too tired to reinvent.

Anyway, the biggest contributor is #raisedTo:modulo: and it can be
improved to for sure (I previously failed trying to use Montgomery).

Nicolas


NINVinverseOf: x mod: n
        "NINV algorithm variant"

        | v u u1 v1 f fv t1 b result result2 |
        ((x <= 0) or: [n <= 0]) ifTrue: [self error: 'x and n must be greater
than zero'].
        x >= n ifTrue: [self error: 'x must be < n'].

        u := x.
        v := n.
        b := (v highBit + 1).
        f := 1 bitShift: b.
        u1 := (u bitShift: b) + 1.
        v1 := (v bitShift: b).
        fv := f + v.
        [v1 >= fv] whileTrue:
                [t1 := v1.
                v1 := u1 \\ v1.
                u1 := t1].
        result := v1 - f.
        (result2 := result + v) > 0
                ifFalse: [self error: 'no inverse'].
        ^result positive
                ifTrue: [result]
                ifFalse: [result2]


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

123