Re: [Cryptography Team] Re: [squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random
Andreas,
I will volunteer to take this on. I think it is a good idea. I need write access to the trunk repository, I believe. Can you help me with that? I am not sure how inbox gets used or whether I should use it.
From what I have gathered that you said, we should have the following
packages:
CryptoCore CryptoCoreTests CryptoExtras CryptoExtrasTests Certificates CertificatesTests
Can you confirm this and that all would become Truck packages?
A question below....
-------------------------------------------------- From: "Andreas Raab" andreas.raab@gmx.de
- It has too many variations (all those *WithPrimitive and
*NonPrimitive) variants. There's no need to have both; write the primitive variants so that they use non-primitive fallback code or simply require the primitives.
This really isn't so bad. There are 4 plugins, and so there are 4 *WithPrimitive and 4 *NonPrimitive variants. I suggest for phase 1 we leave these alone. The issue is that in some cases the algorithm used for the Primitive is different than the algorithm used in the image. It will take some thinking to write non-primitive fallback code and untangle the algorithm class to use it. A worthy goal but not something that prevents us from packaging Crypto into the Trunk.
Cheers, Rob
- ASN1, X509, PKCS. This is not cryptography, this is certificate
handling. It should be in a Certificates package, not Cryptography.
- A category per class. Puh-lease...
If you do all of the above you'll end up with one or two "Crypto-Core" categories containing all of the "essentials" like MD5, Triple DES, DSA, RSA, SHA1, SHA256. That's probably about what you'd want in the base image and I'd be surprised if it's more than 20 classes. I think you could make a *very* reasoned case that this Crypto-Core should be included in the trunk image by default in particular considering that it would remain loadable and simplify the System (and other) packages.
Then you have Crypt-Extras with the less common stuff, from MD2 to DiffieHelman. On top of which is the Certificate package with ASN1, X509, and PKCS. On top of which is the SSL stuff.
I think this would be quite a nice structure and I'd be supporting getting a small Crypto-Core package into trunk. Anyone up for it?
Cheers,
- Andreas
From: "Chris Muller" asqueaker@gmail.com Sent: Thursday, August 26, 2010 7:02 PM To: "Cryptography Team Development List" cryptography@lists.squeakfoundation.org Cc: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [Cryptography Team] Re: [squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random
DigitalSignatureAlgorithm, SecureHashAlgorithm and ThirtyTwoBitRegister have been part of Squeak for a long time, there are legacy users, although I think they should migrate to using the counterparts in Cryptography.
Folding Cryptography into Squeak would probably go against the political momentum toward smaller, more modular images. We don't need to do something that drastic just to solve this issue.
I suggest instead that we merely move two utility methods from Cryptography:
RandomGenerator class>>unpredictableStringsDo: aBlock RandomGenerator class>>generateKey
to Random class in Squeak, and then employ them in DigitalSignatureAlgorithm for its #initRandomNonInteractively. #generateKey should be patched up from its dependence on Cryptography methods.
This allows Squeak to purge the insecure approach of grabbing bits from a (silent or disconnected) SoundService, in favor of the robust one in Cryptography (except now moved to Squeak).
- Chris
On Mon, Aug 23, 2010 at 10:09 AM, Rob Withers reefedjib@gmail.com wrote:
Hi Chris,
It works really well. The only issue now is the DigitalSignatureAlgorithm is located in the core squeak image and the changes I made are in the Cryptography package. It would be nice to fold Cryptography into the core squeak image, or pull DigitalSignatureAlgorithm out into Cryptography.
Rob
From: "Chris Muller" asqueaker@gmail.com Sent: Sunday, August 22, 2010 5:35 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Crypto" cryptography@lists.squeakfoundation.org Subject: [Cryptography Team] Re: [squeak-dev] DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random
Good, SecureRandom employs its #generateKey method (on the class side) to initialize its 'picker' (class-instance var). This was intended to serve as a globally usable SecureRandom so that clients like DigitalSignatureAlgorithm would not have to define their own.
On Sat, Aug 21, 2010 at 5:30 AM, Rob Withers reefedjib@gmail.com wrote:
I found a problem with DigitalSignatureAlgorithm>>#initRandomNonInteractively. It is grabbing randomBits from the SoundSystem, but I may not have that installed. It gave me the same bits repeatedly. I modified DigitalSignatureAlgorithm>>#initRandomNonInteractively to not rely on the SoundSystem and instead use SecureRandom. This is published in the Cryptography repository.
Rob
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
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 -
-------------------------------------------------- From: "Bert Freudenberg" bert@freudenbergs.de Sent: Saturday, August 28, 2010 6:42 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Crypto" cryptography@lists.squeakfoundation.org Subject: Re: [Cryptography Team] Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyis not random
It's best to first publish to the inbox. You do not need special permissions for that. Once we're happy with the packages we move them over to trunk.
Done. The following packages are in the Inbox:
CryptoCore CryptoCoreTests CryptoExtras CryptoExtrasTests CryptoCerts CryptoCertsTests
All tests pass, although I have not tried to load just CryptoCore and CryptoCoreTests and run its tests.
Rob
On 28.08.2010, at 12:59, Rob Withers wrote:
From: "Bert Freudenberg" bert@freudenbergs.de Sent: Saturday, August 28, 2010 6:42 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Crypto" cryptography@lists.squeakfoundation.org 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 -
-------------------------------------------------- From: "Bert Freudenberg" bert@freudenbergs.de Sent: Saturday, August 28, 2010 7:13 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random
On 28.08.2010, at 12:59, Rob Withers wrote:
From: "Bert Freudenberg" bert@freudenbergs.de Sent: Saturday, August 28, 2010 6:42 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Crypto" cryptography@lists.squeakfoundation.org 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
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 -
-------------------------------------------------- From: "Bert Freudenberg" bert@freudenbergs.de Sent: Saturday, August 28, 2010 7:50 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org 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
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
On Sat, 28 Aug 2010, Rob Withers wrote:
From: "Bert Freudenberg" bert@freudenbergs.de Sent: Saturday, August 28, 2010 7:13 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random
On 28.08.2010, at 12:59, Rob Withers wrote:
From: "Bert Freudenberg" bert@freudenbergs.de Sent: Saturday, August 28, 2010 6:42 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Crypto" cryptography@lists.squeakfoundation.org 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
2010/8/28 Levente Uzonyi leves@elte.hu:
On Sat, 28 Aug 2010, Rob Withers wrote:
From: "Bert Freudenberg" bert@freudenbergs.de Sent: Saturday, August 28, 2010 7:13 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random
On 28.08.2010, at 12:59, Rob Withers wrote:
From: "Bert Freudenberg" bert@freudenbergs.de Sent: Saturday, August 28, 2010 6:42 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Crypto" cryptography@lists.squeakfoundation.org 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
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
2010/8/29 Levente Uzonyi leves@elte.hu:
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
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?
On Sat, Aug 28, 2010 at 6:30 AM, Rob Withers reefedjib@gmail.com wrote:
From: "Bert Freudenberg" bert@freudenbergs.de Sent: Saturday, August 28, 2010 7:13 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random
On 28.08.2010, at 12:59, Rob Withers wrote:
From: "Bert Freudenberg" bert@freudenbergs.de Sent: Saturday, August 28, 2010 6:42 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Crypto" cryptography@lists.squeakfoundation.org 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
On 9/2/2010 1:43 PM, Chris Muller wrote:
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.
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.
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
On Sat, Aug 28, 2010 at 6:30 AM, Rob Withersreefedjib@gmail.com wrote:
From: "Bert Freudenberg"bert@freudenbergs.de Sent: Saturday, August 28, 2010 7:13 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random
On 28.08.2010, at 12:59, Rob Withers wrote:
From: "Bert Freudenberg"bert@freudenbergs.de Sent: Saturday, August 28, 2010 6:42 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Crypto"cryptography@lists.squeakfoundation.org 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
-------------------------------------------------- From: "Andreas Raab" andreas.raab@gmx.de Sent: Thursday, September 02, 2010 4:59 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Re: [Cryptography Team]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random
On 9/2/2010 1:43 PM, Chris Muller wrote:
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.
Me too. Since we will continue to store Certificates package in the Cryptography repository, I think it makes sense to rename to Certificates.
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).
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
On Sat, Aug 28, 2010 at 6:30 AM, Rob Withersreefedjib@gmail.com wrote:
From: "Bert Freudenberg"bert@freudenbergs.de Sent: Saturday, August 28, 2010 7:13 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random
On 28.08.2010, at 12:59, Rob Withers wrote:
From: "Bert Freudenberg"bert@freudenbergs.de Sent: Saturday, August 28, 2010 6:42 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Crypto"cryptography@lists.squeakfoundation.org 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
On 9/2/2010 2:22 PM, Rob Withers wrote:
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
On Sat, Aug 28, 2010 at 6:30 AM, Rob Withersreefedjib@gmail.com wrote:
From: "Bert Freudenberg"bert@freudenbergs.de Sent: Saturday, August 28, 2010 7:13 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot
random
On 28.08.2010, at 12:59, Rob Withers wrote:
From: "Bert Freudenberg"bert@freudenbergs.de Sent: Saturday, August 28, 2010 6:42 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Cc: "Squeak Crypto"cryptography@lists.squeakfoundation.org 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
-------------------------------------------------- From: "Andreas Raab" andreas.raab@gmx.de Sent: Thursday, September 02, 2010 6:10 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Re: [Cryptography Team]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random
On 9/2/2010 2:22 PM, Rob Withers wrote:
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.
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
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
On Sat, Aug 28, 2010 at 6:30 AM, Rob Withersreefedjib@gmail.com wrote:
From: "Bert Freudenberg"bert@freudenbergs.de Sent: Saturday, August 28, 2010 7:13 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [Cryptography Team]Re:[squeak-dev]DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot
random
On 28.08.2010, at 12:59, Rob Withers wrote:
> > > -------------------------------------------------- > From: "Bert Freudenberg"bert@freudenbergs.de > Sent: Saturday, August 28, 2010 6:42 AM > To: "The general-purpose Squeak developers list" > squeak-dev@lists.squeakfoundation.org > Cc: "Squeak Crypto"cryptography@lists.squeakfoundation.org > 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
2010/9/3 Rob Withers reefedjib@gmail.com:
From: "Andreas Raab" andreas.raab@gmx.de Sent: Thursday, September 02, 2010 6:10 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: [squeak-dev] Re: [Cryptography Team]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random
On 9/2/2010 2:22 PM, Rob Withers wrote:
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.
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
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
-------------------------------------------------- From: "Nicolas Cellier" nicolas.cellier.aka.nice@gmail.com Sent: Friday, September 03, 2010 1:43 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Re: [CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom
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
2010/9/3 Rob Withers reefedjib@gmail.com:
From: "Nicolas Cellier" nicolas.cellier.aka.nice@gmail.com Sent: Friday, September 03, 2010 1:43 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Re: [CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom
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
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
-------------------------------------------------- From: "Nicolas Cellier" nicolas.cellier.aka.nice@gmail.com
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
Nicolas
On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Nicolas Cellier" nicolas.cellier.aka.nice@gmail.com
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.
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
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
Nicolas
-------------------------------------------------- From: "Levente Uzonyi" leves@elte.hu Sent: Friday, September 03, 2010 11:32 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
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
On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu Sent: Friday, September 03, 2010 11:32 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
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
Regards, Rob
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
2010/9/3 Levente Uzonyi leves@elte.hu:
On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu Sent: Friday, September 03, 2010 11:32 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
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
Regards, Rob
-------------------------------------------------- From: "Levente Uzonyi" leves@elte.hu
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
On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu
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
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
-------------------------------------------------- From: "Levente Uzonyi" leves@elte.hu Sent: Friday, September 03, 2010 6:14 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu
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.
I did this too, by hand:
ConfigurationOfMetacello project latestVersion load: #('UI').
ConfigurationOfMetacello project latestVersion load: #('Tutorial').
now what?
Thanks, Rob
Levente
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
On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu Sent: Friday, September 03, 2010 6:14 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu
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.
I did this too, 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
Thanks, Rob
Levente
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
-------------------------------------------------- From: "Levente Uzonyi" leves@elte.hu Sent: Friday, September 03, 2010 7:25 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu Sent: Friday, September 03, 2010 6:14 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu
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.
I did this too, 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.
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
Levente
Thanks, Rob
Levente
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
On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu Sent: Friday, September 03, 2010 7:25 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu Sent: Friday, September 03, 2010 6:14 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu
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.
I did this too, 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.
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.
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
Thanks, Rob
Levente
Thanks, Rob
Levente
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
-------------------------------------------------- From: "Levente Uzonyi" leves@elte.hu Sent: Saturday, September 04, 2010 3:21 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
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?
Rob
On 04.09.2010, at 10:44, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu Sent: Saturday, September 04, 2010 3:21 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
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 -
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" bert@freudenbergs.de Sent: Saturday, September 04, 2010 8:16 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Installing VMMaker
On 04.09.2010, at 10:44, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu Sent: Saturday, September 04, 2010 3:21 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
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 -
On 04.09.2010, at 14:24, Rob Withers wrote:
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 -
From: "Bert Freudenberg" bert@freudenbergs.de Sent: Saturday, September 04, 2010 8:16 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Installing VMMaker
On 04.09.2010, at 10:44, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu Sent: Saturday, September 04, 2010 3:21 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
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 -
-------------------------------------------------- From: "Bert Freudenberg" bert@freudenbergs.de Sent: Saturday, September 04, 2010 9:01 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Installing VMMaker
On 04.09.2010, at 14:24, Rob Withers wrote:
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.
On 9/3/2010 4:25 PM, Levente Uzonyi wrote:
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
On Fri, 3 Sep 2010, Andreas Raab wrote:
On 9/3/2010 4:25 PM, Levente Uzonyi wrote:
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
Cheers,
- Andreas
On Sat, 4 Sep 2010, Levente Uzonyi wrote:
On Fri, 3 Sep 2010, Andreas Raab wrote:
On 9/3/2010 4:25 PM, Levente Uzonyi wrote:
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
Levente
Cheers,
- Andreas
On 9/3/2010 11:57 PM, Levente Uzonyi wrote:
On Fri, 3 Sep 2010, Andreas Raab wrote:
On 9/3/2010 4:25 PM, Levente Uzonyi wrote:
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
-------------------------------------------------- From: "Levente Uzonyi" leves@elte.hu
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
On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu
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
Rob
-------------------------------------------------- From: "Levente Uzonyi" leves@elte.hu Sent: Friday, September 03, 2010 6:16 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu
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
I just tried with this version of VMMaker: VMMaker-John M McIntosh.184 with the same result.
-------------------------------------------------- From: "Rob Withers" reefedjib@gmail.com Sent: Friday, September 03, 2010 6:22 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom>
From: "Levente Uzonyi" leves@elte.hu Sent: Friday, September 03, 2010 6:16 PM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:
From: "Levente Uzonyi" leves@elte.hu
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
(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
-------------------------------------------------- From: "Andreas Raab" andreas.raab@gmx.de Sent: Saturday, August 28, 2010 11:42 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org 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
On 8/28/2010 9:17 AM, Rob Withers wrote:
- 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
- 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.
- I published SSL to Inbox. Same question as #2.
Same answer. Let's keep it in the Cryptography repository for now.
- 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
(my message seems to have gotten lost....resending)
-------------------------------------------------- From: "Andreas Raab" andreas.raab@gmx.de Sent: Saturday, August 28, 2010 11:42 AM To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org 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
Well, I can see you all waited for me to go on vacation for one week before going hog-wild on the Cryptography package! :)
I mostly like the simple split that's been done; so we won't run into the same problems we did 5 years ago when Cryptography was split. However, a couple of questions:
First, why rename the package to "Crypto?" The quality of the package is worth the original full name, "Cryptography".
Second, I wonder about the semantics of "Core" vs. "Extra". This ambiguity was part of the issue with the original breakup of the Cryptography package by the Cryptography team years ago that led to its re-integration into one big package.
For example, PasswordSaltAndStretch could be considered a "core" smart thing to do with all passwords. It's small and simple. So why shouldn't be part of the "core"? Keyholder could be considered for core for the same reasons.
That would leave just those obsolete ciphers left in Extras and, therefore, an opportunity to reduce the ambiguity of the package name; "Cryptography-Obsolete" ???
- Chris
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.
#destroy is implemented on several byte-based objects to wipe out a sensitive key bytes immediately after use, so that it won't hang around exposed in memory or, worse, get saved into the image.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Chris Muller -
Colin Putney -
Levente Uzonyi -
Nicolas Cellier -
Rob Withers