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

Post by Rob Withers
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

Rob Withers

2012-01-28 12:38:31 UTC

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" <***@gmail.com>
Sent: Sunday, August 22, 2010 5:35 PM
To: "The general-purpose Squeak developers list"
<squeak-***@lists.squeakfoundation.org>
Cc: "Squeak Crypto" <***@lists.squeakfoundation.org>
Subject: [Cryptography Team] Re: [squeak-dev]
DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random

Post by Chris Muller
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.

Post by Rob Withers
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
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Chris Muller

2012-01-28 12:38:39 UTC

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

Post by Rob Withers
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
--------------------------------------------------
Sent: Sunday, August 22, 2010 5:35 PM
To: "The general-purpose Squeak developers list"
Subject: [Cryptography Team] Re: [squeak-dev]
DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random

Post by Chris Muller
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.

_______________________________________________
Cryptography mailing list
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Andreas Raab

2012-01-28 12:38:40 UTC

Post by Chris Muller
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

Rob Withers

2012-01-28 12:38:41 UTC

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

--------------------------------------------------

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
--------------------------------------------------
Sent: Thursday, August 26, 2010 7:02 PM
To: "Cryptography Team Development List"
Cc: "The general-purpose Squeak developers list"
[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractively is not
random

Post by Chris Muller
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.
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

Post by Rob Withers
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
--------------------------------------------------
Sent: Sunday, August 22, 2010 5:35 PM
To: "The general-purpose Squeak developers list"
Subject: [Cryptography Team] Re: [squeak-dev]
DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random

Post by Rob Withers
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
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Bert Freudenberg

2012-01-28 12:38:41 UTC

Post by Rob Withers
Andreas,
I will volunteer to take this on.

Yay! :)

Post by Rob Withers
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 -

Rob Withers

2012-01-28 12:38:42 UTC

--------------------------------------------------
From: "Bert Freudenberg" <***@freudenbergs.de>
Sent: Saturday, August 28, 2010 6:42 AM
To: "The general-purpose Squeak developers list"
<squeak-***@lists.squeakfoundation.org>
Cc: "Squeak Crypto" <***@lists.squeakfoundation.org>
Subject: Re: [Cryptography Team]
Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis not
random

Post by Bert Freudenberg
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

Bert Freudenberg

2012-01-28 12:38:42 UTC

Post by Rob Withers
--------------------------------------------------
Sent: Saturday, August 28, 2010 6:42 AM
Subject: Re: [Cryptography Team] Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis not random

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

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 -

Rob Withers

2012-01-28 12:38:42 UTC

--------------------------------------------------
From: "Bert Freudenberg" <***@freudenbergs.de>
Sent: Saturday, August 28, 2010 7:13 AM
To: "The general-purpose Squeak developers list"
<squeak-***@lists.squeakfoundation.org>
Subject: Re: [Cryptography
Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot
random

Post by Rob Withers
--------------------------------------------------
Sent: Saturday, August 28, 2010 6:42 AM
To: "The general-purpose Squeak developers list"
Subject: Re: [Cryptography Team]
Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis
not random

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

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.

Post by Bert Freudenberg
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

Bert Freudenberg

2012-01-28 12:38:42 UTC

Post by Bert Freudenberg
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 -

Rob Withers

2012-01-28 12:38:42 UTC

--------------------------------------------------
From: "Bert Freudenberg" <***@freudenbergs.de>
Sent: Saturday, August 28, 2010 7:50 AM
To: "The general-purpose Squeak developers list"
<squeak-***@lists.squeakfoundation.org>
Subject: Re:
[CryptographyTeam]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

Post by Bert Freudenberg
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

Colin Putney

2012-01-28 12:38:42 UTC

Post by Bert Freudenberg
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

Levente Uzonyi

2012-01-28 12:38:42 UTC

Post by Rob Withers
--------------------------------------------------
Sent: Saturday, August 28, 2010 7:13 AM
To: "The general-purpose Squeak developers list"
Subject: Re: [Cryptography
Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot
random

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

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

Post by Bert Freudenberg
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

Nicolas Cellier

2012-01-28 12:38:43 UTC

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

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

Post by Bert Freudenberg
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

Levente Uzonyi

2012-01-28 12:38:43 UTC

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.

Post by Nicolas Cellier
For example http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-July/130162.html

Like this.

Post by Nicolas Cellier
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

Post by Nicolas Cellier
Nicolas

Post by Bert Freudenberg
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

Nicolas Cellier

2012-01-28 12:38:43 UTC

snip
I just took a look at the extension methods (there are quite a lot) and most
of them can be simplified or removed.

Post by Nicolas Cellier
For example
http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-July/130162.html

Like this.

Post by Nicolas Cellier
Maybe http://bugs.squeak.org/view.php?id=7109 would serve a bit too...

Hm. This looks interresting, I guess some optimizations are already
| 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]

Post by Nicolas Cellier
Nicolas

Post by Bert Freudenberg
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

Chris Muller

2012-01-28 12:38:51 UTC

Shouldn't we stay with the same naming convention, "Cryptography"?

What is the plan to deal with the redundant classes, such as
SecureHashAlgorithm and SHA1?

If RSA is in Cryptography-Core, shouldn't ElGamal and DiffieHellman
belong in core as well?

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

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.

Post by Bert Freudenberg
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

Andreas Raab

2012-01-28 12:38:51 UTC

Post by Chris Muller
Shouldn't we stay with the same naming convention, "Cryptography"?

Fine either way. Though the argument could be made that for
compatibility it might be useful to leave the current "Cryptography"
alone and have the new packages use slightly different naming
conventions, such that:

Crypto + Certificates = Cryptography.

But like I said I'm good either way.

Post by Chris Muller
What is the plan to deal with the redundant classes, such as
SecureHashAlgorithm and SHA1?

The goal is to get them out of the System package and into the
Crypto-Core package to further reduce the size of System.

Post by Chris Muller
If RSA is in Cryptography-Core, shouldn't ElGamal and DiffieHellman
belong in core as well?

Could do. I'm not the expert here, so I'll let others comment. My main
dividing line is that the core should contain what is widely used and
practical (i.e., performs well enough to be used in practice). As a
consequence, MD5, SHA1, SHA256 are all obvious choices since they're
both widely used and perform well (with prims at least and we may
require that), whereas for example MD2, MD4 (outdated) and DiffieHellman
(WAY too slow) are not. RSA, on the other hand, is somewhere in the
middle - it performs reasonably well (we use it for key exchange in our
products) but one could easily argue that it's not a common enough
feature to be required in Core. Not sure on ElGamal.

But in any case, I think I'll leave this to the experts, which I think
is you, Rob and Ron :-)

Cheers,
- Andreas

Post by Chris Muller

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

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.

Post by Bert Freudenberg
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

Rob Withers

2012-01-28 12:38:51 UTC

--------------------------------------------------
From: "Andreas Raab" <***@gmx.de>
Sent: Thursday, September 02, 2010 4:59 PM
To: "The general-purpose Squeak developers list"
<squeak-***@lists.squeakfoundation.org>
Subject: [squeak-dev] Re: [Cryptography
Team]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random

Post by Chris Muller
Shouldn't we stay with the same naming convention, "Cryptography"?

Fine either way. Though the argument could be made that for compatibility
it might be useful to leave the current "Cryptography" alone and have the
Crypto + Certificates = Cryptography.
But like I said I'm good either way.

Me too. Since we will continue to store Certificates package in the
Cryptography repository, I think it makes sense to rename to Certificates.

Post by Chris Muller
If RSA is in Cryptography-Core, shouldn't ElGamal and DiffieHellman
belong in core as well?

Currently in Core:

ARC4
MD5
DES/TripleDES
Rijndael(AES)
SHA1
SHA256
DSA/Generator/PublicKey/PrivateKey
RSA/Generator/Key/PrivateKey
ElGamal/Generator/PublicKey/PrivateKey
DiffieHellman
SecureRandom

(in Core-Utilities

Fortuna
PrimesFinder
primitive wrappers
other stuff)

Currently in Extras:

ARC2
MD2
MD4

As a consequence, MD5, SHA1, SHA256 are all obvious choices since they're
both widely used and perform well (with prims at least and we may require
that),

We have prims, located in the Cryptography repository, for:

DES
DSA
MD5
SHA256

whereas for example MD2, MD4 (outdated) and DiffieHellman (WAY too slow)
are not.

Andreas, I use DiffieHellman for key exchange in my system. It is
considered slow? It is a one time use in a connection...

RSA, on the other hand, is somewhere in the middle - it performs
reasonably well (we use it for key exchange in our products) but one could
easily argue that it's not a common enough feature to be required in Core.
Not sure on ElGamal.

How do you use RSA for key exchange?

But in any case, I think I'll leave this to the experts, which I think is
you, Rob and Ron :-)

That's what I got,
Rob

Cheers,
- Andreas

Post by Chris Muller

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

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.

Post by Bert Freudenberg
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

Andreas Raab

2012-01-28 12:38:51 UTC

whereas for example MD2, MD4 (outdated) and DiffieHellman (WAY too
slow) are not.

Andreas, I use DiffieHellman for key exchange in my system. It is
considered slow? It is a one time use in a connection...

If I remember correctly (it's been a few years since I did this) the
problem was the DH had a significant server load for each connection
(several seconds for each new connection) whereas RSA had a high inital
cost but after that was basically instant. Of course all of this was
pre-cog so very different performance tradeoffs but when I did the math,
the bottom line was that a DH reconnect of ten people could never be
completed in less than 30 seconds simply because each connection would
require 3+ seconds server time and (at that point) all of the
connections were serialized. It was just a no-go.

RSA, on the other hand, is somewhere in the middle - it performs
reasonably well (we use it for key exchange in our products) but one
could easily argue that it's not a common enough feature to be
required in Core. Not sure on ElGamal.

How do you use RSA for key exchange?

The server generates a new key pair on startup and when the client
connects the server sends its public key to the client. The client uses
the public key to encrypt the session key for the connection and sends
it back. The server decrypts the session key, both ends install a
streaming cipher based on the session key and we're done.

Cheers,
- Andreas

But in any case, I think I'll leave this to the experts, which I think
is you, Rob and Ron :-)

That's what I got,
Rob

Cheers,
- Andreas

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

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.

Post by Bert Freudenberg
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

Rob Withers

2012-01-28 12:38:51 UTC

--------------------------------------------------
From: "Andreas Raab" <***@gmx.de>
Sent: Thursday, September 02, 2010 6:10 PM
To: "The general-purpose Squeak developers list"
<squeak-***@lists.squeakfoundation.org>
Subject: [squeak-dev] Re: [Cryptography
Team]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random

whereas for example MD2, MD4 (outdated) and DiffieHellman (WAY too
slow) are not.

Andreas, I use DiffieHellman for key exchange in my system. It is
considered slow? It is a one time use in a connection...

Very interesting. I have never measured it. I take my prime and generator
from E. I just tried a 1024 bit DiffieHellman and it took 65 seconds! With
E's numbers I get 315 ms pretty consistently. This seems to match a 192
bit DH pretty well. This is both send and receive messages so is the total
time for one side. This is pre-cog.

RSA, on the other hand, is somewhere in the middle - it performs
reasonably well (we use it for key exchange in our products) but one
could easily argue that it's not a common enough feature to be
required in Core. Not sure on ElGamal.

How do you use RSA for key exchange?

The server generates a new key pair on startup and when the client
connects the server sends its public key to the client. The client uses
the public key to encrypt the session key for the connection and sends it
back. The server decrypts the session key, both ends install a streaming
cipher based on the session key and we're done.

Ok, that makes sense. There is a qualitative security difference between DH
and this approach. DH does not pass the key across the wire. It does
modulo arithmetic to pass derivative numbers.

To speed things up, we could primitize hot spots:

17.1% {7ms} SHA1>>finalHash
14.6% {6ms} ThirtyTwoBitRegister>>load:
9.8% {4ms} LargePositiveInteger>>+

from SecureRandom

and in raisedTo: modulo:

65.5% {1045ms} Array(SequenceableCollection)>>second
32.5% {519ms} LargePositiveInteger>>>=

Not sure if that would improve with a plugin.

Of course, the same is true of RSA.

Cheers,
Rob

Post by Andreas Raab
Cheers,
- Andreas

But in any case, I think I'll leave this to the experts, which I think
is you, Rob and Ron :-)

That's what I got,
Rob

Cheers,
- Andreas

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

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.

Post by Bert Freudenberg
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

Nicolas Cellier

2012-01-28 12:38:52 UTC

Post by Rob Withers
--------------------------------------------------
Sent: Thursday, September 02, 2010 6:10 PM
To: "The general-purpose Squeak developers list"
Subject: [squeak-dev] Re: [Cryptography
Team]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random

whereas for example MD2, MD4 (outdated) and DiffieHellman (WAY too
slow) are not.

Andreas, I use DiffieHellman for key exchange in my system. It is
considered slow? It is a one time use in a connection...

If I remember correctly (it's been a few years since I did this) the
problem was the DH had a significant server load for each connection
(several seconds for each new connection) whereas RSA had a high inital cost
but after that was basically instant. Of course all of this was pre-cog so
very different performance tradeoffs but when I did the math, the bottom
line was that a DH reconnect of ten people could never be completed in less
than 30 seconds simply because each connection would require 3+ seconds
server time and (at that point) all of the connections were serialized. It
was just a no-go.

Very interesting. ? I have never measured it. ?I take my prime and generator
from E. ?I just tried a 1024 bit DiffieHellman and it took 65 seconds! ?With
E's numbers I get 315 ms pretty consistently. ? This seems to match a 192
bit DH pretty well. ?This is both send and receive messages so is the total
time for one side. ?This is pre-cog.

RSA, on the other hand, is somewhere in the middle - it performs
reasonably well (we use it for key exchange in our products) but one
could easily argue that it's not a common enough feature to be
required in Core. Not sure on ElGamal.

How do you use RSA for key exchange?

The server generates a new key pair on startup and when the client
connects the server sends its public key to the client. The client uses the
public key to encrypt the session key for the connection and sends it back.
The server decrypts the session key, both ends install a streaming cipher
based on the session key and we're done.

Ok, that makes sense. ?There is a qualitative security difference between DH
and this approach. ?DH does not pass the key across the wire. ?It does
modulo arithmetic to pass derivative numbers.
17.1% {7ms} SHA1>>finalHash
9.8% {4ms} LargePositiveInteger>>+
from SecureRandom
65.5% {1045ms} Array(SequenceableCollection)>>second
32.5% {519ms} LargePositiveInteger>>>=
Not sure if that would improve with a plugin.
Of course, the same is true of RSA.
Cheers,
Rob

I recompiled http://bugs.squeak.org/view.php?id=7120, and also 7109 in
COG along with recent changes of recoprocalModulo:, I get a decent
speed up at least for in trunk DSA.

Nicolas

Rob Withers

2012-01-28 12:38:53 UTC

--------------------------------------------------
From: "Nicolas Cellier" <***@gmail.com>
Sent: Friday, September 03, 2010 1:43 AM
To: "The general-purpose Squeak developers list"
<squeak-***@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re:
[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

Post by Nicolas Cellier
I recompiled http://bugs.squeak.org/view.php?id=7120, and also 7109 in
COG along with recent changes of recoprocalModulo:, I get a decent
speed up at least for in trunk DSA.

Nicolas, I am sorry to report that performance is way, way, WAY too slow
with your montgomery algorithm.

I run this code:

| secrets dh msg |
secrets := VatTPEncryptionSecrets new.
dh := DiffieHellman prime: secrets dhPrime generator: secrets dhGenerator.
[msg := dh sendMessage.
dh receiveMessage: msg] timeToRun.

where the generator is 2 and the prime is:

119737914775462509838170437650443916377511571523280127227899447719294084320704253537978070284126826302859486033998465467188646855777933154987304015680716743916472238051242730320539605643481248526686248310127334173449056014874439925491652836615915938029029782321539388697349613396698017627677439533107752978203.

With the version of raisedTo:modulo: with Crypto-Core, I get 312 ms.

With your montgomery algorithm, I get 26616 ms.

Profiling, my leafs are:

79.5% {21696ms} SmallInteger(Integer)>>digitMontgomeryTimes:modulo:mInvModB:
20.3% {5540ms} SmallInteger(Integer)>>>>

HTH,
Rob

Nicolas Cellier

2012-01-28 12:38:53 UTC

Post by Rob Withers
--------------------------------------------------
Sent: Friday, September 03, 2010 1:43 AM
To: "The general-purpose Squeak developers list"
[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

Post by Nicolas Cellier
I recompiled http://bugs.squeak.org/view.php?id=7120, and also 7109 in
COG along with recent changes of recoprocalModulo:, I get a decent
speed up at least for in trunk DSA.

Nicolas, I am sorry to report that performance is way, way, WAY too slow
with your montgomery algorithm.
? ? ? ?| secrets dh msg |
? ? ? ?secrets := VatTPEncryptionSecrets new.
? ? ? ?dh := DiffieHellman prime: secrets dhPrime generator: secrets
dhGenerator.
? ? ? ?[msg := dh sendMessage.
? ? ? ? ? ? ? ?dh receiveMessage: msg] timeToRun.
119737914775462509838170437650443916377511571523280127227899447719294084320704253537978070284126826302859486033998465467188646855777933154987304015680716743916472238051242730320539605643481248526686248310127334173449056014874439925491652836615915938029029782321539388697349613396698017627677439533107752978203.
With the version of raisedTo:modulo: with Crypto-Core, I get 312 ms.
With your montgomery algorithm, I get 26616 ms.
20.3% {5540ms} SmallInteger(Integer)>>>>
HTH,
Rob

Sure, this require the primitive to be compiled with LargeInteger plugin.
Otherwise, it is as if you would replace primitive for multiplying 2
LargeInt by Smalltalk code...

Nicolas

Rob Withers

2012-01-28 12:38:53 UTC

--------------------------------------------------

Post by Nicolas Cellier
Sure, this require the primitive to be compiled with LargeInteger plugin.
Otherwise, it is as if you would replace primitive for multiplying 2
LargeInt by Smalltalk code...

Ok, that makes sense.

However....

I am giving up building a Win32 vm. It is a piece of crap. Ever since I
wrote the VMMakerTool back in 2000 at Exobox, it relied on having good
platform code and good Plugin code in the image. I am getting endless
errors on various plugins, which I have been removing from Internal, back to
Not Built. From a fresh 4.2 image with VMMaker, the plugins I have
removed:

UUIDPlugin
QuicktimePlugin
SocketPlugin (I really need this one!)
SoundCodecPrims
SoundGenerationPlugin
SoundPlugin
StarSqueakPlugin

that's it, it is broke dick. I am giving up.

Unless you can get me an external LargeIntegerPlugin.dll, I will have to for
go testing your algorithm. Darn, I was looking forward to it.

Rob

Post by Nicolas Cellier
Nicolas

Levente Uzonyi

2012-01-28 12:38:54 UTC

Post by Rob Withers
--------------------------------------------------

Post by Nicolas Cellier
Sure, this require the primitive to be compiled with LargeInteger plugin.
Otherwise, it is as if you would replace primitive for multiplying 2
LargeInt by Smalltalk code...

Well, it works for most people, so you're doing something wrong. If you
give a step-by-step description of your vm-building process, then someone
will be able to help.

Levente

Post by Rob Withers
Unless you can get me an external LargeIntegerPlugin.dll, I will have to for
go testing your algorithm. Darn, I was looking forward to it.
Rob

Post by Nicolas Cellier
Nicolas

Rob Withers

2012-01-28 12:38:54 UTC

--------------------------------------------------
From: "Levente Uzonyi" <***@elte.hu>
Sent: Friday, September 03, 2010 11:32 AM
To: "The general-purpose Squeak developers list"

Post by Rob Withers
I am giving up building a Win32 vm.

Well, it works for most people, so you're doing something wrong. If you
give a step-by-step description of your vm-building process, then someone
will be able to help.

Yeah, sorry folks for going on a rant there. I was up too early.

I've had some offline assistance and I will try with the latest source zip
tonight after work.

I am confused as to where to get the latest VMMaker: SqueakSource or
Metacello?

Regards,
Rob

Levente Uzonyi

2012-01-28 12:38:54 UTC

Post by Rob Withers
--------------------------------------------------
Sent: Friday, September 03, 2010 11:32 AM
To: "The general-purpose Squeak developers list"
[squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom>

Post by Rob Withers
I am giving up building a Win32 vm.

Well, it works for most people, so you're doing something wrong. If you
give a step-by-step description of your vm-building process, then someone
will be able to help.

Yeah, sorry folks for going on a rant there. I was up too early.
I've had some offline assistance and I will try with the latest source zip
tonight after work.
I am confused as to where to get the latest VMMaker: SqueakSource or
Metacello?

Metacello is just a tool, it gets the packages from SqueakSource.

Levente

Post by Rob Withers
Regards,
Rob

Nicolas Cellier

2012-01-28 12:38:54 UTC

For a COG VM, it's simpler to start with the image prepared by Eliot
which has exactly the necessary packages and Workspaces with
generation instructions - almost just one doIt click! (2 or 3
confirmations apart).

All the necessary stuff is available (via svn) at
http://squeakvm.org/svn/squeak/branches/Cog/

What I did is loading 7109 and 7120 in image/VMMaker-Squeak4.1.image,
changed the var:type: into pragmas <var:type:>, generated with
workspace doit, then used the xcodeproj in the Macbuild to compile...

Maybe I'll try the win32 cygwin build if I have time...

Nicolas

Post by Rob Withers
I am giving up building a Win32 vm.

Well, it works for most people, so you're doing something wrong. If you
give a step-by-step description of your vm-building process, then someone
will be able to help.

Yeah, sorry folks for going on a rant there. ? I was up too early.
I've had some offline assistance and I will try with the latest source zip
tonight after work.
I am confused as to where to get the latest VMMaker: ? ? SqueakSource or
Metacello?

Metacello is just a tool, it gets the packages from SqueakSource.
Levente

Post by Rob Withers
Regards,
Rob

Rob Withers

2012-01-28 12:38:54 UTC

--------------------------------------------------

Post by Levente Uzonyi
Metacello is just a tool, it gets the packages from SqueakSource.

So I finally found the page that discusses loading Metacello. Did that.
Loaded the UI. Where is it at? I see no menu option to open up a
MetacelloLoader or whatever. This is not a point and click system.

Rob

Levente Uzonyi

2012-01-28 12:38:54 UTC

Post by Rob Withers
--------------------------------------------------

Post by Levente Uzonyi
Metacello is just a tool, it gets the packages from SqueakSource.

So I finally found the page that discusses loading Metacello. Did that.

You shouldn't load Metacello by hand. Just load the ConfigurationOfVMMaker
from squeaksource.com/MetacelloRepository , then evaluate
[ConfigurationOfVMMaker load] (if it doesn't work try
[ConfigurationOfVMMaker project latestVersion load]).

Levente

Post by Rob Withers
Loaded the UI. Where is it at? I see no menu option to open up a
MetacelloLoader or whatever. This is not a point and click system.
Rob

Rob Withers

2012-01-28 12:38:54 UTC

--------------------------------------------------
From: "Levente Uzonyi" <***@elte.hu>
Sent: Friday, September 03, 2010 6:14 PM
To: "The general-purpose Squeak developers list"

Post by Rob Withers
--------------------------------------------------

Post by Levente Uzonyi
Metacello is just a tool, it gets the packages from SqueakSource.

So I finally found the page that discusses loading Metacello. Did that.

That's how I loaded by hand.

I did this too, by hand:

ConfigurationOfMetacello project latestVersion load: #('UI').

ConfigurationOfMetacello project latestVersion load: #('Tutorial').

now what?

Thanks,
Rob

Post by Levente Uzonyi
Levente

Post by Rob Withers
Loaded the UI. Where is it at? I see no menu option to open up a
MetacelloLoader or whatever. This is not a point and click system.
Rob

Levente Uzonyi

2012-01-28 12:38:54 UTC

Post by Rob Withers
--------------------------------------------------
Sent: Friday, September 03, 2010 6:14 PM
To: "The general-purpose Squeak developers list"
[squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom>

Post by Rob Withers
--------------------------------------------------

Post by Levente Uzonyi
Metacello is just a tool, it gets the packages from SqueakSource.

So I finally found the page that discusses loading Metacello. Did that.

That's how I loaded by hand.
ConfigurationOfMetacello project latestVersion load: #('UI').
ConfigurationOfMetacello project latestVersion load: #('Tutorial').
now what?

You loaded ConfigurationOfMetacello instead of ConfigurationOfVMMaker,
that's why it doesn't work. I know this because ConfigurationOfVMMaker
loads VMMaker-dtl.169, not VMMaker-dtl.185.

And ConfigurationOfVMMaker can't load VMMaker, because there's a bug in
HTTPSocket class >> #httpRequest:url:headers:content:response:. It double
encodes the value of rawUrl. This prevents the code to load
"Freetype-Plugin-John M McIntosh.55.mcz" because the filename contains
spaces (initials shouldn't contain spaces...). Which are encoded to %20,
then %20 is encoded to %2520 which results in a 404 error.

After getting over this issue, I could generate the source of all
plugins on windows (which can be built on windows).

Levente

Post by Rob Withers
Thanks,
Rob

Post by Levente Uzonyi
Levente

Post by Rob Withers
Loaded the UI. Where is it at? I see no menu option to open up a
MetacelloLoader or whatever. This is not a point and click system.
Rob

Rob Withers

2012-01-28 12:38:54 UTC

--------------------------------------------------
From: "Levente Uzonyi" <***@elte.hu>
Sent: Friday, September 03, 2010 7:25 PM
To: "The general-purpose Squeak developers list"

Post by Rob Withers
--------------------------------------------------

Post by Levente Uzonyi
Metacello is just a tool, it gets the packages from SqueakSource.

So I finally found the page that discusses loading Metacello. Did that.

You shouldn't load Metacello by hand. Just load the
ConfigurationOfVMMaker from squeaksource.com/MetacelloRepository , then
evaluate [ConfigurationOfVMMaker load] (if it doesn't work try
[ConfigurationOfVMMaker project latestVersion load]).

That's how I loaded by hand.
ConfigurationOfMetacello project latestVersion load: #('UI').
ConfigurationOfMetacello project latestVersion load: #('Tutorial').
now what?

You loaded ConfigurationOfMetacello instead of ConfigurationOfVMMaker,
that's why it doesn't work. I know this because ConfigurationOfVMMaker
loads VMMaker-dtl.169, not VMMaker-dtl.185.

Ah, I see now.

Post by Levente Uzonyi
And ConfigurationOfVMMaker can't load VMMaker, because there's a bug in
HTTPSocket class >> #httpRequest:url:headers:content:response:. It double
encodes the value of rawUrl. This prevents the code to load
"Freetype-Plugin-John M McIntosh.55.mcz" because the filename contains
spaces (initials shouldn't contain spaces...). Which are encoded to %20,
then %20 is encoded to %2520 which results in a 404 error.
After getting over this issue, I could generate the source of all plugins
on windows (which can be built on windows).

How do you get over that issue? I am stuck there now.

Thanks,
Rob

Post by Levente Uzonyi
Levente

Post by Rob Withers
Thanks,
Rob

Post by Levente Uzonyi
Levente

Post by Rob Withers
Loaded the UI. Where is it at? I see no menu option to open up a
MetacelloLoader or whatever. This is not a point and click system.
Rob

Levente Uzonyi

2012-01-28 12:38:55 UTC

Post by Rob Withers
--------------------------------------------------
Sent: Friday, September 03, 2010 7:25 PM
To: "The general-purpose Squeak developers list"
[squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom>

Post by Rob Withers
--------------------------------------------------

Post by Levente Uzonyi
Metacello is just a tool, it gets the packages from SqueakSource.

So I finally found the page that discusses loading Metacello. Did that.

You shouldn't load Metacello by hand. Just load the
ConfigurationOfVMMaker from squeaksource.com/MetacelloRepository , then
evaluate [ConfigurationOfVMMaker load] (if it doesn't work try
[ConfigurationOfVMMaker project latestVersion load]).

That's how I loaded by hand.
ConfigurationOfMetacello project latestVersion load: #('UI').
ConfigurationOfMetacello project latestVersion load: #('Tutorial').
now what?

You loaded ConfigurationOfMetacello instead of ConfigurationOfVMMaker,
that's why it doesn't work. I know this because ConfigurationOfVMMaker
loads VMMaker-dtl.169, not VMMaker-dtl.185.

Ah, I see now.

How do you get over that issue? I am stuck there now.

No easy answer yet. I did it with the debugger. When you get the DNU,
select "aResolvedReference version" and debug it. Use over/into/through
till you get to HTTPSocket class >>
#httpRequest:url:headers:content:response:, then step over the last
assignment of rawUrl, and replace the double encoded string with a single
encoded version with the inspector. Proceed. In the original debugger go
back to MetacelloFetchingMCSpecLoader>>resolveDependencies:into: and
restart it, then proceed.

Levente

Post by Rob Withers
Thanks,
Rob

Post by Levente Uzonyi
Levente

Post by Rob Withers
Thanks,
Rob

Post by Levente Uzonyi
Levente

Post by Rob Withers
Loaded the UI. Where is it at? I see no menu option to open up a
MetacelloLoader or whatever. This is not a point and click system.
Rob

Rob Withers

2012-01-28 12:38:55 UTC

--------------------------------------------------
From: "Levente Uzonyi" <***@elte.hu>
Sent: Saturday, September 04, 2010 3:21 AM
To: "The general-purpose Squeak developers list"

Post by Rob Withers
How do you get over that issue? I am stuck there now.

How do I replace the double encoded string with a single encoded version?

Rob

Bert Freudenberg

2012-01-28 12:38:55 UTC

Post by Rob Withers
--------------------------------------------------
Sent: Saturday, September 04, 2010 3:21 AM

Post by Rob Withers
How do you get over that issue? I am stuck there now.

No easy answer yet. I did it with the debugger. When you get the DNU, select "aResolvedReference version" and debug it. Use over/into/through till you get to HTTPSocket class >> #httpRequest:url:headers:content:response:, then step over the last assignment of rawUrl, and replace the double encoded string with a single encoded version with the inspector. Proceed. In the original debugger go back to MetacelloFetchingMCSpecLoader>>resolveDependencies:into: and restart it, then proceed.

How do I replace the double encoded string with a single encoded version?

Using the inspector in the lower part of the debugger. Just change it. It's all just objects.

That's the power of Smalltalk - for all its quirks, you can fix about anything on the fly if needed.

- Bert -

Rob Withers

2012-01-28 12:38:55 UTC

For some reason, I couldn't change the String. Are they immutable now? I
ended up doing a

self becomeForward: 'blah/blah%20blah.mcz'

all objects and message sending. :-)

--------------------------------------------------
From: "Bert Freudenberg" <***@freudenbergs.de>
Sent: Saturday, September 04, 2010 8:16 AM
To: "The general-purpose Squeak developers list"
<squeak-***@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Installing VMMaker

Post by Rob Withers
--------------------------------------------------
Sent: Saturday, September 04, 2010 3:21 AM
To: "The general-purpose Squeak developers list"
[squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom>

Post by Rob Withers
How do you get over that issue? I am stuck there now.

No easy answer yet. I did it with the debugger. When you get the DNU,
select "aResolvedReference version" and debug it. Use over/into/through
till you get to HTTPSocket class >>
#httpRequest:url:headers:content:response:, then step over the last
assignment of rawUrl, and replace the double encoded string with a
single encoded version with the inspector. Proceed. In the original
debugger go back to
MetacelloFetchingMCSpecLoader>>resolveDependencies:into: and restart it,
then proceed.

How do I replace the double encoded string with a single encoded version?

Using the inspector in the lower part of the debugger. Just change it.
It's all just objects.
That's the power of Smalltalk - for all its quirks, you can fix about
anything on the fly if needed.
- Bert -

Bert Freudenberg

2012-01-28 12:38:55 UTC

For some reason, I couldn't change the String. Are they immutable now?

No, but still fixed-length.

I meant not changing the string but replacing it with the right one. The debugger's inspector lists all temp vars. If you click on one, you see its value, which is the string . Just editing and accepting it there should change the variable.

I ended up doing a
self becomeForward: 'blah/blah%20blah.mcz'
all objects and message sending. :-)

Yeah, if that's what it takes ;_

- Bert -

--------------------------------------------------
Sent: Saturday, September 04, 2010 8:16 AM
Subject: Re: [squeak-dev] Installing VMMaker

Post by Rob Withers
--------------------------------------------------
Sent: Saturday, September 04, 2010 3:21 AM

Post by Rob Withers
How do you get over that issue? I am stuck there now.

No easy answer yet. I did it with the debugger. When you get the DNU, select "aResolvedReference version" and debug it. Use over/into/through till you get to HTTPSocket class >> #httpRequest:url:headers:content:response:, then step over the last assignment of rawUrl, and replace the double encoded string with a single encoded version with the inspector. Proceed. In the original debugger go back to MetacelloFetchingMCSpecLoader>>resolveDependencies:into: and restart it, then proceed.

How do I replace the double encoded string with a single encoded version?

Using the inspector in the lower part of the debugger. Just change it. It's all just objects.
That's the power of Smalltalk - for all its quirks, you can fix about anything on the fly if needed.
- Bert -

Rob Withers

2012-01-28 12:38:55 UTC

--------------------------------------------------
From: "Bert Freudenberg" <***@freudenbergs.de>
Sent: Saturday, September 04, 2010 9:01 AM
To: "The general-purpose Squeak developers list"
<squeak-***@lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Installing VMMaker

For some reason, I couldn't change the String. Are they immutable now?

No, but still fixed-length.
I meant not changing the string but replacing it with the right one. The
debugger's inspector lists all temp vars. If you click on one, you see its
value, which is the string . Just editing and accepting it there should
change the variable.

Oh right. I had opened an inspector on the string.

Andreas Raab

2012-01-28 12:38:55 UTC

Post by Levente Uzonyi
And ConfigurationOfVMMaker can't load VMMaker, because there's a bug in
HTTPSocket class >> #httpRequest:url:headers:content:response:. It
double encodes the value of rawUrl. This prevents the code to load
"Freetype-Plugin-John M McIntosh.55.mcz" because the filename contains
spaces (initials shouldn't contain spaces...). Which are encoded to %20,
then %20 is encoded to %2520 which results in a 404 error.

Ouch. What's the easiest way to reproduce this problem?

Cheers,
- Andreas

Levente Uzonyi

2012-01-28 12:38:55 UTC

Post by Levente Uzonyi
And ConfigurationOfVMMaker can't load VMMaker, because there's a bug in
HTTPSocket class >> #httpRequest:url:headers:content:response:. It
double encodes the value of rawUrl. This prevents the code to load
"Freetype-Plugin-John M McIntosh.55.mcz" because the filename contains
spaces (initials shouldn't contain spaces...). Which are encoded to %20,
then %20 is encoded to %2520 which results in a 404 error.

Ouch. What's the easiest way to reproduce this problem?

repository := MCHttpRepository
location: 'http://source.impara.de/freetype'
user: ''
password: ''.
repository readStreamForFileNamed: 'Freetype-Plugin-John M McIntosh.55.mcz' do: [ :contents | 'ok' ].

This should print 'ok' instead of nil. Debug it for details.

Levente

Post by Andreas Raab
Cheers,
- Andreas

Levente Uzonyi

2012-01-28 12:38:55 UTC

Post by Levente Uzonyi
And ConfigurationOfVMMaker can't load VMMaker, because there's a bug in
HTTPSocket class >> #httpRequest:url:headers:content:response:. It
double encodes the value of rawUrl. This prevents the code to load
"Freetype-Plugin-John M McIntosh.55.mcz" because the filename contains
spaces (initials shouldn't contain spaces...). Which are encoded to %20,
then %20 is encoded to %2520 which results in a 404 error.

Ouch. What's the easiest way to reproduce this problem?

repository := MCHttpRepository
location: 'http://source.impara.de/freetype'
user: ''
password: ''.
repository readStreamForFileNamed: 'Freetype-Plugin-John M McIntosh.55.mcz'
do: [ :contents | 'ok' ].
This should print 'ok' instead of nil. Debug it for details.

This example is even better:

HTTPSocket
httpGet: 'http://source.impara.de/freetype/Freetype-Plugin-John M McIntosh.55.mcz'
args: nil
user: ''
passwd: ''.

Levente

Post by Levente Uzonyi
Levente

Post by Andreas Raab
Cheers,
- Andreas

Andreas Raab

2012-01-28 12:38:57 UTC

Post by Levente Uzonyi
And ConfigurationOfVMMaker can't load VMMaker, because there's a bug in
HTTPSocket class >> #httpRequest:url:headers:content:response:. It
double encodes the value of rawUrl. This prevents the code to load
"Freetype-Plugin-John M McIntosh.55.mcz" because the filename contains
spaces (initials shouldn't contain spaces...). Which are encoded to %20,
then %20 is encoded to %2520 which results in a 404 error.

Ouch. What's the easiest way to reproduce this problem?

repository := MCHttpRepository
location: 'http://source.impara.de/freetype'
user: ''
password: ''.
repository readStreamForFileNamed: 'Freetype-Plugin-John M
McIntosh.55.mcz' do: [ :contents | 'ok' ].
This should print 'ok' instead of nil. Debug it for details.

Thanks, fixed now. Looking at 4.1 it's clear that the incoming URLs are
all assumed to be encoded already (which isn't a bad idea for
consistency) so I just took that encoding out and added a more
straightforward way to escape incoming URLs by means of
String>>urlEncoded, i.e.,

'http://squeak.org/name with space?key=value' urlEncoded.
=> 'http://squeak.org/name%20with%20space?key=value'

Not to be confused with #encodeForHTTP which would yield:

'http://squeak.org/name with space?key=value' encodeForHTTP.
=> 'http%3A%2F%2Fsqueak.org%2Fname%20with%20space%3Fkey%3Dvalue'

Cheers,
- Andreas

Rob Withers

2012-01-28 12:38:54 UTC

--------------------------------------------------

Post by Levente Uzonyi
Well, it works for most people, so you're doing something wrong. If you
give a step-by-step description of your vm-building process, then someone
will be able to help.

I downloaded SqueakVM-Win32-4.1.1-src.zip and installed. Took a clean 4.2
image and loaded the latest VMMaker and then tried to generate and build.
Same problem as before.

Rob

Levente Uzonyi

2012-01-28 12:38:54 UTC

Post by Rob Withers
--------------------------------------------------

Post by Levente Uzonyi
Well, it works for most people, so you're doing something wrong. If you
give a step-by-step description of your vm-building process, then someone
will be able to help.

I downloaded SqueakVM-Win32-4.1.1-src.zip and installed. Took a clean 4.2
image and loaded the latest VMMaker and then tried to generate and build.
Same problem as before.

Which version of VMMaker did you load?

Levente

Post by Rob Withers
Rob

Rob Withers

2012-01-28 12:38:54 UTC

--------------------------------------------------
From: "Levente Uzonyi" <***@elte.hu>
Sent: Friday, September 03, 2010 6:16 PM
To: "The general-purpose Squeak developers list"

Post by Rob Withers
--------------------------------------------------

Post by Levente Uzonyi
Well, it works for most people, so you're doing something wrong. If you
give a step-by-step description of your vm-building process, then
someone will be able to help.

I downloaded SqueakVM-Win32-4.1.1-src.zip and installed. Took a clean
4.2 image and loaded the latest VMMaker and then tried to generate and
build. Same problem as before.

Which version of VMMaker did you load?

VMMaker-dtl.185

Rob Withers

2012-01-28 12:38:54 UTC

I just tried with this version of VMMaker: VMMaker-John M McIntosh.184 with
the same result.

--------------------------------------------------
From: "Rob Withers" <***@gmail.com>
Sent: Friday, September 03, 2010 6:22 PM
To: "The general-purpose Squeak developers list"
<squeak-***@lists.squeakfoundation.org>
Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom>

Post by Rob Withers
--------------------------------------------------
Sent: Friday, September 03, 2010 6:16 PM
To: "The general-purpose Squeak developers list"
[squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom>

Post by Rob Withers
--------------------------------------------------

Post by Levente Uzonyi
Well, it works for most people, so you're doing something wrong. If you
give a step-by-step description of your vm-building process, then
someone will be able to help.

I downloaded SqueakVM-Win32-4.1.1-src.zip and installed. Took a clean
4.2 image and loaded the latest VMMaker and then tried to generate and
build. Same problem as before.

Which version of VMMaker did you load?

VMMaker-dtl.185

Andreas Raab

2012-01-28 12:38:42 UTC

(changed subject for better tracking)

Post by Rob Withers
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

Rob Withers

2012-01-28 12:38:43 UTC

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

Post by Andreas Raab
(changed subject for better tracking)

Post by Rob Withers
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

Andreas Raab

2012-01-28 12:38:44 UTC

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?

Here is my proposal (not final; feel free to discuss or modify):

CryptoCore -> Crypto-Core
CryptoExtras -> Crypto-Extras
CryptoCoreTests -> Crypto-Tests-Core
CryptoExtrasTests -> Crypto-Tests-Extras

CryptoCerts -> Certificates-Core
CryptoCertsTests -> Certificates-Tests

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.

I would keep Certificates and SSL in the Cryptography repository on
Squeaksource for the time being. We may choose a different repository at
some point, but for now the Cryptography repository seems like a fine place.

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

Same answer. Let's keep it in the Cryptography repository for now.

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?

I don't know. SqueakSSL uses the platform stores, specifically to
integrate with already installed certificates. I have never used the
Cryptography SSL package myself, only the cryptographic algorithms from it.

Cheers,
- Andreas

Rob Withers

2012-01-28 12:38:43 UTC

(my message seems to have gotten lost....resending)

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

Post by Andreas Raab
(changed subject for better tracking)

Post by Rob Withers
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.

Chris Muller

2012-01-28 12:38:51 UTC