Smalltalk › Squeak › Squeak - Dev

DigitalSignatureAlgorithm>>#initRandomNonInteractively is not random

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

54 messages Options

123

Andreas.Raab

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

On 8/28/2010 9:17 AM, Rob Withers wrote:
> 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

Chris Muller-3

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

In reply to this post by Rob Withers-2

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 <[hidden email]> wrote:

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

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.

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

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

In reply to this post by Andreas.Raab

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.

Rob Withers-2

Re: [Cryptography Team]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random

In reply to this post by Andreas.Raab

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

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.

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

Re: [Cryptography Team]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random

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

Re: [Cryptography Team]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnot random

2010/9/3 Rob Withers <[hidden email]>:

>
>
> --------------------------------------------------
> From: "Andreas Raab" <[hidden email]>
> Sent: Thursday, September 02, 2010 6:10 PM
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> 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

Rob Withers-2

Re: [CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

--------------------------------------------------
From: "Nicolas Cellier" <[hidden email]>
Sent: Friday, September 03, 2010 1:43 AM
To: "The general-purpose Squeak developers list"
<[hidden email]>
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

Nicolas Cellier

Re: [CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

2010/9/3 Rob Withers <[hidden email]>:

>
>
> --------------------------------------------------
> From: "Nicolas Cellier" <[hidden email]>
> Sent: Friday, September 03, 2010 1:43 AM
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> 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

Rob Withers-2

Re: Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

--------------------------------------------------
From: "Nicolas Cellier" <[hidden email]>

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

Levente Uzonyi-2

Re: Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

On Fri, 3 Sep 2010, Rob Withers wrote:

>
>
> --------------------------------------------------
> From: "Nicolas Cellier" <[hidden email]>
>
>> 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
>>
>>
>
>

Rob Withers-2

Re: Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

--------------------------------------------------
From: "Levente Uzonyi" <[hidden email]>
Sent: Friday, September 03, 2010 11:32 AM
To: "The general-purpose Squeak developers list"
<[hidden email]>
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

Levente Uzonyi-2

Re: Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

On Fri, 3 Sep 2010, Rob Withers wrote:

>
>
> --------------------------------------------------
> From: "Levente Uzonyi" <[hidden email]>
> Sent: Friday, September 03, 2010 11:32 AM
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> 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
>
>

Nicolas Cellier

Re: Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

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 <[hidden email]>:

> On Fri, 3 Sep 2010, Rob Withers wrote:
>
>>
>>
>> --------------------------------------------------
>> From: "Levente Uzonyi" <[hidden email]>
>> Sent: Friday, September 03, 2010 11:32 AM
>> To: "The general-purpose Squeak developers list"
>> <[hidden email]>
>> 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
>>
>
>

Rob Withers-2

Re: Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

In reply to this post by Levente Uzonyi-2

--------------------------------------------------
From: "Levente Uzonyi" <[hidden email]>

> 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

Rob Withers-2

Re: Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

In reply to this post by Levente Uzonyi-2

--------------------------------------------------
From: "Levente Uzonyi" <[hidden email]>

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

Re: Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

In reply to this post by Rob Withers-2

On Fri, 3 Sep 2010, Rob Withers wrote:

> --------------------------------------------------
> From: "Levente Uzonyi" <[hidden email]>
>
>> 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
>
>

Levente Uzonyi-2

Re: Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

In reply to this post by Rob Withers-2

On Fri, 3 Sep 2010, Rob Withers wrote:

> --------------------------------------------------
> From: "Levente Uzonyi" <[hidden email]>
>
>> 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
>
>

Rob Withers-2

Re: Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom

In reply to this post by Levente Uzonyi-2

--------------------------------------------------
From: "Levente Uzonyi" <[hidden email]>
Sent: Friday, September 03, 2010 6:14 PM
To: "The general-purpose Squeak developers list"
<[hidden email]>
Subject: Re: [squeak-dev]Re:[CryptographyTeam]Re:DigitalSignatureAlgorithm>>#initRandomNonInteractivelyisnotrandom> On Fri, 3 Sep 2010, Rob Withers wrote:

>
>> --------------------------------------------------
>> From: "Levente Uzonyi" <[hidden email]>
>>
>>> 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
>>
>
>

123