SHA512 squeak implementation?

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

ProCrypto v1.1.1 Re: [Vm-dev] SHA512 squeak implementation?

Squeak - Dev mailing list

Two CryptoChallenges have now been solved, both by Levente Uzonyi! Numbers Two and Four, Awesome! Thank you so much!!!

PDF: https://www.dropbox.com/s/oo36r4xxatpd3mz/ProCrypto.pdf?dl=0


JPG:



On 3/12/20 7:31 PM, Robert wrote:

Oh? I thought we discussed your package becoming the core solution, for HashFunctions. I was thinking you were going to rename all your classes back to no prefixes (except RGThirtyTwoBitRegister renamed to CryptoThirtyTwoBitRegister). And your hashFunction becomes the one in CryptographyCore. Your Registers and HashFunctions, become CryptographyHashing. Then I'll reset the dependencies to load yours.

I got a little excited and released Pro Crypto v1.1.1, so with your code it would be ProCrypto v1.2.1.

Did I misunderstand?

k, r

On 3/12/20 7:26 PM, Levente Uzonyi wrote:
Hi Robert,

On Wed, 11 Mar 2020, Robert wrote:

Dear Levente,

I had to rework the Hashing package. It was recording change records that moved RGSixtyTwoBitRegisters before another to rename them CryptoSixtyTwoBitRegisters, CryptographyHashing was ripping them out of your Registers package and your code started failing. So I had to swap classes around packages and fix a few
issues I had with SHA512 initialization, class & instance sides. I verified that they load in either order now and fully CryptoGreen. I setup dependencies through the latest Hashing package, 21. Here are the versions & how I load:

Anything with your merge I can help with, Levente? I am excited for the day to announce ProCrypto v1.1.1, you know! ^,^ Milk it. I added a pointer to the plugins.
What merge do you mean?


Levente

Installer ss      project: 'Registers';      install: 'Registers';      project: 'Hasher';      install: 'HAHasher-Core';      install: 'HAHasher-Tests'. Installer ss      project: 'Cryptography';      install: 'CryptographyPlugins';      install: 'CryptographyX509'.

K, r

ProCrypto packages and dependencies
Package
Size (kb)
Dependencies
Algorithms
1
CryptographyCore-rww.5
18
HMAC, CBC, CFB, CTR, OFB
2
CryptographyASN1-rww.4
58
ASN1Module, ASN1InputStream, ASN1OutputStream
3
CryptographyHashing-rww.21
208
CryptographyCore-rww.5
ND2, MD4, MD5, SHA1, SHA256, SHA512
4
CryptographyRandom-rww.11
21
CryptographyHashing-rww.21
RandomPool, PrimesFinder, Miller-Rabin, Fortuna, SecureRandom
5
CryptographyCiphers-rww.15
81
CryptographyRandom-rww.11 CryptographyASN1-rww.4
ARC2, ARC4, DES, TripleDES, Blowfish, Rijndael
6
CryptographySignatures-rww.15
37
CryptographyCiphers-rww.15
DSAKeyPairGenerator, ElGamalKeyPairGenerator, RSAKeyPairGenerator
7
CryptographyKeyExchange-rww.13
5
CryptographySignatures-rww.15
Diffie-Hellman
8
CryptographyArchive-rww.15
17
CryptographyKeyExchange-rww.13
PBKDF2WithHmacSHA1, PBKDF2WithHmacSHA256, PKCS12
9
CryptographyX509-rww.13
34
CryptographyArchive-rww.15
X509Certificate, X509CertificateDerReader, DSAPrivateKeyFileReader, RSAPublicKeyFileGenerator, RSAPrivateKeyFileGenerator
479
Loadable
Unloadable

On 3/10/20 8:31 PM, Robert wrote:

      I should share with you that I can load Levente's work in parallel and there are no toes stepped on. And all of his tests are CryptoGreen, with & out. This is a good.

      *message too large* kindly, rabbit

      On 3/10/20 6:06 PM, Robert wrote:

      Hi Levente,

      Here is a new release of CryptographyHashing-rww.15. It is not linked up through dependencies, so load it after. It supports SHA512WithPrimitive and SHA512NonPrimitive and passes all tests. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
      https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins.

      Here is this working implementation of SHA512. The naming ought to be without prefix for th ecore classes. I have no problem whatsoever if we were to rebase your work as the defining implementation for all of thosew funcrtions, using one plugin. That's something wonderful. We should use you
      hashFunction and rename without prefix. Tests separate, that's fashionable. We can figure out the mc config later.

      publish your work on, then I will link your solution into dependencies.

                                                                                                                                                CryptographyHashing-ul.16

                                                                                                                                           CryptographyHashing-rww.15 (Release)

      File:
      CryptographyHashing-rww.15.mcz
      Author:
      Robert Withers
      Timestamp:
      10 March 2020 9:57:39 pm
      UUID:
      b7df722e-ab05-4465-97ef-deeffb0212d0
      Ancestors:
      CryptographyHashing-rww.14
      Dependencies:
      CryptographyCore-rww.5
      Release:
      This is a release that can be read by anybody.
      Message:
      adapt to new #primCopyoubleWords:intoBytes:. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64: https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins.
rttyk, r



--
--


Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] SHA512 squeak implementation?

Levente Uzonyi
In reply to this post by Squeak - Dev mailing list
On Thu, 12 Mar 2020, Robert wrote:

> Oh? I thought we discussed your package becoming the core solution, for HashFunctions. I was thinking you were going to rename all your classes back to no prefixes (except RGThirtyTwoBitRegister renamed to CryptoThirtyTwoBitRegister). And your hashFunction becomes the one in CryptographyCore. Your Registers and HashFunctions, become CryptographyHashing. Then I'll reset the dependencies to load yours.
>
> I got a little excited and released Pro Crypto v1.1.1, so with your code it would be ProCrypto v1.2.1.
>
> Did I misunderstand?

I proposed that about three times in these discussions but got no
response from you.
Since you started integrating SHA512 manually, my impression was that you
want to keep the exising classes.
If you want Hasher to be merged into Cryptography, then I can give it a
try on the weekend, but

1) HashFunction should stay in the same package as its subclasses. Why?
When another package doesn't use any of HashFunction's subclasses, it will
not use HashFunction. When another package needs a subclass, HashFunction
has to be present.

2) Registers should stay in a separate package. Why?
They can be used for other things. For example, I've got an unpublished
package containing various PRNG implementations using it.

Does that work for you?


Levente

>
> k, r
>
> On 3/12/20 7:26 PM, Levente Uzonyi wrote:
>
>> Hi Robert,
>>
>> On Wed, 11 Mar 2020, Robert wrote:
>>
>>> Dear Levente,
>>>
>>> I had to rework the Hashing package. It was recording change records that moved RGSixtyTwoBitRegisters before another to rename them CryptoSixtyTwoBitRegisters, CryptographyHashing was ripping them out of your Registers package and your code started failing. So I had to swap classes around packages and fix a few
>>> issues I had with SHA512 initialization, class & instance sides. I verified that they load in either order now and fully CryptoGreen. I setup dependencies through the latest Hashing package, 21. Here are the versions & how I load:
>>>
>>> Anything with your merge I can help with, Levente? I am excited for the day to announce ProCrypto v1.1.1, you know! ^,^ Milk it. I added a pointer to the plugins.
>>
>> What merge do you mean?
>>
>> Levente
>>
>>> Installer ss      project: 'Registers';      install: 'Registers';      project: 'Hasher';      install: 'HAHasher-Core';      install: 'HAHasher-Tests'. Installer ss      project: 'Cryptography';      install: 'CryptographyPlugins';      install: 'CryptographyX509'.
>>>
>>> K, r
>>>
>>> ProCrypto packages and dependencies
>>> Package
>>> Size (kb)
>>> Dependencies
>>> Algorithms
>>> 1
>>> CryptographyCore-rww.5
>>> 18
>>> HMAC, CBC, CFB, CTR, OFB
>>> 2
>>> CryptographyASN1-rww.4
>>> 58
>>> ASN1Module, ASN1InputStream, ASN1OutputStream
>>> 3
>>> CryptographyHashing-rww.21
>>> 208
>>> CryptographyCore-rww.5
>>> ND2, MD4, MD5, SHA1, SHA256, SHA512
>>> 4
>>> CryptographyRandom-rww.11
>>> 21
>>> CryptographyHashing-rww.21
>>> RandomPool, PrimesFinder, Miller-Rabin, Fortuna, SecureRandom
>>> 5
>>> CryptographyCiphers-rww.15
>>> 81
>>> CryptographyRandom-rww.11 CryptographyASN1-rww.4
>>> ARC2, ARC4, DES, TripleDES, Blowfish, Rijndael
>>> 6
>>> CryptographySignatures-rww.15
>>> 37
>>> CryptographyCiphers-rww.15
>>> DSAKeyPairGenerator, ElGamalKeyPairGenerator, RSAKeyPairGenerator
>>> 7
>>> CryptographyKeyExchange-rww.13
>>> 5
>>> CryptographySignatures-rww.15
>>> Diffie-Hellman
>>> 8
>>> CryptographyArchive-rww.15
>>> 17
>>> CryptographyKeyExchange-rww.13
>>> PBKDF2WithHmacSHA1, PBKDF2WithHmacSHA256, PKCS12
>>> 9
>>> CryptographyX509-rww.13
>>> 34
>>> CryptographyArchive-rww.15
>>> X509Certificate, X509CertificateDerReader, DSAPrivateKeyFileReader, RSAPublicKeyFileGenerator, RSAPrivateKeyFileGenerator
>>> 479
>>> Loadable
>>> Unloadable
>>>
>>> On 3/10/20 8:31 PM, Robert wrote:
>>>
>>>       I should share with you that I can load Levente's work in parallel and there are no toes stepped on. And all of his tests are CryptoGreen, with & out. This is a good.
>>>
>>>       *message too large* kindly, rabbit
>>>
>>>       On 3/10/20 6:06 PM, Robert wrote:
>>>
>>>       Hi Levente,
>>>
>>>       Here is a new release of CryptographyHashing-rww.15. It is not linked up through dependencies, so load it after. It supports SHA512WithPrimitive and SHA512NonPrimitive and passes all tests. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>>> .
>>>
>>>       Here is this working implementation of SHA512. The naming ought to be without prefix for th ecore classes. I have no problem whatsoever if we were to rebase your work as the defining implementation for all of thosew funcrtions, using one plugin. That's something wonderful. We should use you
>>>       hashFunction and rename without prefix. Tests separate, that's fashionable. We can figure out the mc config later.
>>>
>>>       publish your work on, then I will link your solution into dependencies.
>>>
>>>                                                                                                                                                 CryptographyHashing-ul.16
>>>
>>>                                                                                                                                            CryptographyHashing-rww.15 (Release)
>>>
>>>       File:
>>>       CryptographyHashing-rww.15.mcz
>>>       Author:
>>>       Robert Withers
>>>       Timestamp:
>>>       10 March 2020 9:57:39 pm
>>>       UUID:
>>>       b7df722e-ab05-4465-97ef-deeffb0212d0
>>>       Ancestors:
>>>       CryptographyHashing-rww.14
>>>       Dependencies:
>>>       CryptographyCore-rww.5
>>>       Release:
>>>       This is a release that can be read by anybody.
>>>       Message:
>>>       adapt to new #primCopyoubleWords:intoBytes:. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>>> .
>>> rttyk, r
>
> --

Reply | Threaded
Open this post in threaded view
|

Re: ProCrypto v1.1.1 Re: [Vm-dev] SHA512 squeak implementation?

Squeak - Dev mailing list
In reply to this post by Squeak - Dev mailing list

Hey all'y'all,

There is a new release of ProCrypto-1-1-1. I split out the Tests from all Crypto packages and created a Monticello config map to load all CryptoTests packages.

Here is code to load all Cryptography packages and all CryptoTests packages:

Installer ss
     project: 'Cryptography';
     install: 'ProCrypto-1-1-1';
     install: 'ProCryptoTests-1-1-1'.

If we can get a spot on the CI testing pklatform, we would need to load both configs to run the tests there. *hint, hint*

ProCrypto 1.1.1 flyer: https://www.dropbox.com/s/7y7ngnya9qeg5gf/ProCrypto-1-1-1.pdf?dl=0




On 3/12/20 7:40 PM, Robert wrote:

Two CryptoChallenges have now been solved, both by Levente Uzonyi! Numbers Two and Four, Awesome! Thank you so much!!!




Reply | Threaded
Open this post in threaded view
|

Re: ProCrypto v1.1.1 Re: [Vm-dev] SHA512 squeak implementation?

Squeak - Dev mailing list

Alright, another send, with a Smalltalk cheat sheet for newbies and a smaller resolution image so the email is not too large. Forward these links to folks, please! Cheers!

k, r

ProCrypto 1.1.1 flyer: https://www.dropbox.com/s/7y7ngnya9qeg5gf/ProCrypto-1-1-1.pdf?dl=0
Smalltalk Cheat Sheet: https://www.dropbox.com/s/p4iz51a0qouv8wu/st-cheatsheet.pdf?dl=0



On 3/13/20 11:29 AM, Robert wrote:

Hey all'y'all,

There is a new release of ProCrypto-1-1-1. I split out the Tests from all Crypto packages and created a Monticello config map to load all CryptoTests packages.

Here is code to load all Cryptography packages and all CryptoTests packages:

Installer ss
     project: 'Cryptography';
     install: 'ProCrypto-1-1-1';
     install: 'ProCryptoTests-1-1-1'.

If we can get a spot on the CI testing pklatform, we would need to load both configs to run the tests there. *hint, hint*




Reply | Threaded
Open this post in threaded view
|

Re: ProCrypto v1.1.1 Re: [Vm-dev] SHA512 squeak implementation?

Squeak - Dev mailing list
In reply to this post by Squeak - Dev mailing list

My image was still the large one. Here is the email with a smaller image to forward...Alright, another send, with a Smalltalk cheat sheet for newbies and a smaller resolution image so the email is not too large. Forward these links to folks, please! Cheers!

Load doIt: Installer ss
     project: 'Cryptography';
     install: 'ProCrypto-1-1-1';
     install: 'ProCryptoTests-1-1-1'.

k, r

ProCrypto 1.1.1 flyer: https://www.dropbox.com/s/7y7ngnya9qeg5gf/ProCrypto-1-1-1.pdf?dl=0
Smalltalk Cheat Sheet: https://www.dropbox.com/s/p4iz51a0qouv8wu/st-cheatsheet.pdf?dl=0

On 3/13/20 11:29 AM, Robert wrote:

Hey all'y'all,

There is a new release of ProCrypto-1-1-1. I split out the Tests from all Crypto packages and created a Monticello config map to load all CryptoTests packages.

Here is code to load all Cryptography packages and all CryptoTests packages:




Reply | Threaded
Open this post in threaded view
|

Squeak marketing of ProCrypto v1.1.1 Re: [Vm-dev] SHA512 squeak implementation?

Squeak - Dev mailing list

I was hoping to have a chance to pass out these flyers (and offer the electronic PDF, by thumb drive or email, with working links) to all of the College/University Departments of Crypto/Netwroking/CompSci in the area that I could. i do not have contact with any so I haven't found a way to email these departments. Unfortunately, or rather Fortunately, schools are out on Spring Break, to be extended. So unless you guys and gals have contact to some departments, my marketing strategy of enlisting college hackers has fallen short. I did get to NCCU, right next door to me, and handed out the flyers to the CompSci professors. I printed out a bunch to plaster Duke and UNC, going to buy a few thumb drives. And timing. I think I need to wait until the kids return.

What are your thoughts about Squeak marketing? It's like turning out the vote. We should expand with Squeak 5.3! Any sort of multiplayer Croquet game to hook them with? Or other games!

K, r

On 3/13/20 11:52 AM, Robert wrote:

My image was still the large one. Here is the email with a smaller image to forward...Alright, another send, with a Smalltalk cheat sheet for newbies and a smaller resolution image so the email is not too large. Forward these links to folks, please! Cheers!

Load doIt: Installer ss
     project: 'Cryptography';
     install: 'ProCrypto-1-1-1';
     install: 'ProCryptoTests-1-1-1'.

k, r

ProCrypto 1.1.1 flyer: https://www.dropbox.com/s/7y7ngnya9qeg5gf/ProCrypto-1-1-1.pdf?dl=0
Smalltalk Cheat Sheet: https://www.dropbox.com/s/p4iz51a0qouv8wu/st-cheatsheet.pdf?dl=0

On 3/13/20 11:29 AM, Robert wrote:

Hey all'y'all,

There is a new release of ProCrypto-1-1-1. I split out the Tests from all Crypto packages and created a Monticello config map to load all CryptoTests packages.

Here is code to load all Cryptography packages and all CryptoTests packages:


-- 
Kindly,
Robert


Reply | Threaded
Open this post in threaded view
|

Re: ProCrypto v1.1.1 Re: [Vm-dev] SHA512 squeak implementation?

Squeak - Dev mailing list
In reply to this post by Squeak - Dev mailing list

I was hoping to have a chance to pass out these flyers (and offer the electronic PDF, by thumb drive or email, with working links) to all of the College/University Departments of Crypto/Networking/CompSci in the area that I could. i do not have contact with any so I haven't found a way to email those departments, other than to a professor at my Alma Mater, Guilford College: https://www.guilford.edu/cyber-and-network-security, which is a Great Fit. That's what inspired me to move forward this promotional way.

Unfortunately, or rather Fortunately, schools are out on Spring Break, to be extended. So unless you guys and gals have contact into some departments, my marketing strategy of enlisting college hackers has fallen short. I did get to NCCU, right next door to me, and handed out the flyers to the CompSci professors. I printed out a bunch to plaster Duke and UNC, going to buy a few thumb drives. And timing. I think I need to wait until the kids return.

What are your thoughts about Squeak marketing? It's like turning out the vote. We should expand with Squeak 5.3! Any sort of multiplayer Croquet game to hook them with? Or other games!

Thank You Kindly,
Robert

---
To load core + tests, doIt:

[Installer ss
     project: 'Cryptography';
     install: 'ProCrypto-1-1-1';
     install: 'ProCryptoTests-1-1-1'.] timeToRun.

"I get 46.9 seconds loading into my vm. 174 tests run in 3 seconds."
---
ProCrypto 1.1.1 flyer: https://www.dropbox.com/s/7y7ngnya9qeg5gf/ProCrypto-1-1-1.pdf?dl=0
Smalltalk Cheat Sheet: https://www.dropbox.com/s/p4iz51a0qouv8wu/st-cheatsheet.pdf?dl=0






ProCrypto-1-1-1.pdf (158K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Squeak marketing of ProCrypto v1.1.1 Re: [Vm-dev] SHA512 squeak implementation?

Squeak - Dev mailing list

Here is a perfect representative Guilford College course, scratching at the underbelly of societal challenges...heh. ^,^

JPS 233.  Deviance and Society.  4.

This course focuses on a theoretical examination of deviance and responses to deviance including critical concepts, measurement and operationalization of these concepts, and the utility of theory and research on policy. The historical evolution (emergence, dominance, and decline) of major deviance theories is also examined as well as the main research and policy implications of the state of knowledge in many areas relating to deviance and social control.

K, r

On 3/15/20 4:32 PM, Robert wrote:

I was hoping to have a chance to pass out these flyers (and offer the electronic PDF, by thumb drive or email, with working links) to all of the College/University Departments of Crypto/Networking/CompSci in the area that I could. i do not have contact with any so I haven't found a way to email those departments, other than to a professor at my Alma Mater, Guilford College: https://www.guilford.edu/cyber-and-network-security, which is a Great Fit. That's what inspired me to move forward this promotional way.

Unfortunately, or rather Fortunately, schools are out on Spring Break, to be extended. So unless you guys and gals have contact into some departments, my marketing strategy of enlisting college hackers has fallen short. I did get to NCCU, right next door to me, and handed out the flyers to the CompSci professors. I printed out a bunch to plaster Duke and UNC, going to buy a few thumb drives. And timing. I think I need to wait until the kids return.

What are your thoughts about Squeak marketing? It's like turning out the vote. We should expand with Squeak 5.3! Any sort of multiplayer Croquet game to hook them with? Or other games!

Thank You Kindly,
Robert

---
To load core + tests, doIt:

[Installer ss
     project: 'Cryptography';
     install: 'ProCrypto-1-1-1';
     install: 'ProCryptoTests-1-1-1'.] timeToRun.

"I get 46.9 seconds loading into my vm. 174 tests run in 3 seconds."
---
ProCrypto 1.1.1 flyer: https://www.dropbox.com/s/7y7ngnya9qeg5gf/ProCrypto-1-1-1.pdf?dl=0
Smalltalk Cheat Sheet: https://www.dropbox.com/s/p4iz51a0qouv8wu/st-cheatsheet.pdf?dl=0



-- 
Kindly,
Robert


Reply | Threaded
Open this post in threaded view
|

Squeak marketing of ProCrypto v1.1.1 Re: [Vm-dev] SHA512 squeak implementation?

Squeak - Dev mailing list
In reply to this post by Squeak - Dev mailing list

Here is a perfect representative Guilford College course, scratching at the underbelly of societal challenges...heh. ^,^

JPS 233.  Deviance and Society.  4.

This course focuses on a theoretical examination of deviance and responses to deviance including critical concepts, measurement and operationalization of these concepts, and the utility of theory and research on policy. The historical evolution (emergence, dominance, and decline) of major deviance theories is also examined as well as the main research and policy implications of the state of knowledge in many areas relating to deviance and social control.

K, r

On 3/15/20 4:32 PM, Robert wrote:

I was hoping to have a chance to pass out these flyers (and offer the electronic PDF, by thumb drive or email, with working links) to all of the College/University Departments of Crypto/Networking/CompSci in the area that I could. i do not have contact with any so I haven't found a way to email those departments, other than to a professor at my Alma Mater, Guilford College: https://www.guilford.edu/cyber-and-network-security, which is a Great Fit. That's what inspired me to move forward this promotional way.

Unfortunately, or rather Fortunately, schools are out on Spring Break, to be extended. So unless you guys and gals have contact into some departments, my marketing strategy of enlisting college hackers has fallen short. I did get to NCCU, right next door to me, and handed out the flyers to the CompSci professors. I printed out a bunch to plaster Duke and UNC, going to buy a few thumb drives. And timing. I think I need to wait until the kids return.

What are your thoughts about Squeak marketing? It's like turning out the vote. We should expand with Squeak 5.3! Any sort of multiplayer Croquet game to hook them with? Or other games!

Thank You Kindly,
Robert

---
To load core + tests, doIt:

[Installer ss
     project: 'Cryptography';
     install: 'ProCrypto-1-1-1';
     install: 'ProCryptoTests-1-1-1'.] timeToRun.

"I get 46.9 seconds loading into my vm. 174 tests run in 3 seconds."
---
ProCrypto 1.1.1 flyer: https://www.dropbox.com/s/7y7ngnya9qeg5gf/ProCrypto-1-1-1.pdf?dl=0
Smalltalk Cheat Sheet: https://www.dropbox.com/s/p4iz51a0qouv8wu/st-cheatsheet.pdf?dl=0



-- 
Kindly,
Robert


Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] SHA512 squeak implementation?

Levente Uzonyi
In reply to this post by Levente Uzonyi
Hi Robert,

On Fri, 13 Mar 2020, Robert wrote:

> On 3/12/20 7:49 PM, Levente Uzonyi wrote:
>
>> On Thu, 12 Mar 2020, Robert wrote:
>>
>>> Oh? I thought we discussed your package becoming the core solution, for HashFunctions. I was thinking you were going to rename all your classes back to no prefixes (except RGThirtyTwoBitRegister renamed to CryptoThirtyTwoBitRegister). And your hashFunction becomes the one in CryptographyCore. Your Registers and HashFunctions, become CryptographyHashing. Then I'll reset the dependencies to load yours.
>>>
>>> I got a little excited and released Pro Crypto v1.1.1, so with your code it would be ProCrypto v1.2.1.
>>>
>>> Did I misunderstand?
>>
>> I proposed that about three times in these discussions but got no
>> response from you.
>> Since you started integrating SHA512 manually, my impression was that you
>> want to keep the exising classes.
>> If you want Hasher to be merged into Cryptography, then I can give it a
>> try on the weekend, but
>
> See this post: http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207872.html

I must have missed that post.

>
>> 1) HashFunction should stay in the same package as its subclasses. Why?
>> When another package doesn't use any of HashFunction's subclasses, it will
>> not use HashFunction. When another package needs a subclass, HashFunction
>> has to be present.
>
> No, I see this through the lens of reuse. there may be other packages that wish to extend hashFunction for their own use. AN example would be a SignalEncryption package. It has a HashFunction. So all the class roots belong in the Core package.

I couldn't find the SignalEncryption package anywhere.
Is there a cryptographic hash function that is missing from Hasher?
If there is, can it be implemented as a subclass of HashFunction?
If yes, why doesn't it belong to the same package as the other subclasses
of HashFunction?

>
>> 2) Registers should stay in a separate package. Why?
>> They can be used for other things. For example, I've got an unpublished
>> package containing various PRNG implementations using it.
>
> That's fine then, please put these classes also in the Core package.

I don't see how the CryptographyCore package would be a good place for
Registers.
The PRNGs I implemented are unrelated to Cryptography.

Levente

>
>> Does that work for you?
>
> Working our way to the garden.
>
> k, r
>
>> Levente
>>
>>> k, r
>>>
>>> On 3/12/20 7:26 PM, Levente Uzonyi wrote:
>>>
>>>> Hi Robert,
>>>>
>>>> On Wed, 11 Mar 2020, Robert wrote:
>>>>
>>>>> Dear Levente,
>>>>>
>>>>> I had to rework the Hashing package. It was recording change records that moved RGSixtyTwoBitRegisters before another to rename them CryptoSixtyTwoBitRegisters, CryptographyHashing was ripping them out of your Registers package and your code started failing. So I had to swap classes around packages and fix a few
>>>>> issues I had with SHA512 initialization, class & instance sides. I verified that they load in either order now and fully CryptoGreen. I setup dependencies through the latest Hashing package, 21. Here are the versions & how I load:
>>>>>
>>>>> Anything with your merge I can help with, Levente? I am excited for the day to announce ProCrypto v1.1.1, you know! ^,^ Milk it. I added a pointer to the plugins.
>>>>
>>>> What merge do you mean?
>>>>
>>>> Levente
>>>>
>>>>> Installer ss      project: 'Registers';      install: 'Registers';      project: 'Hasher';      install: 'HAHasher-Core';      install: 'HAHasher-Tests'. Installer ss      project: 'Cryptography';      install: 'CryptographyPlugins';      install: 'CryptographyX509'.
>>>>>
>>>>> K, r
>>>>>
>>>>> ProCrypto packages and dependencies
>>>>> Package
>>>>> Size (kb)
>>>>> Dependencies
>>>>> Algorithms
>>>>> 1
>>>>> CryptographyCore-rww.5
>>>>> 18
>>>>> HMAC, CBC, CFB, CTR, OFB
>>>>> 2
>>>>> CryptographyASN1-rww.4
>>>>> 58
>>>>> ASN1Module, ASN1InputStream, ASN1OutputStream
>>>>> 3
>>>>> CryptographyHashing-rww.21
>>>>> 208
>>>>> CryptographyCore-rww.5
>>>>> ND2, MD4, MD5, SHA1, SHA256, SHA512
>>>>> 4
>>>>> CryptographyRandom-rww.11
>>>>> 21
>>>>> CryptographyHashing-rww.21
>>>>> RandomPool, PrimesFinder, Miller-Rabin, Fortuna, SecureRandom
>>>>> 5
>>>>> CryptographyCiphers-rww.15
>>>>> 81
>>>>> CryptographyRandom-rww.11 CryptographyASN1-rww.4
>>>>> ARC2, ARC4, DES, TripleDES, Blowfish, Rijndael
>>>>> 6
>>>>> CryptographySignatures-rww.15
>>>>> 37
>>>>> CryptographyCiphers-rww.15
>>>>> DSAKeyPairGenerator, ElGamalKeyPairGenerator, RSAKeyPairGenerator
>>>>> 7
>>>>> CryptographyKeyExchange-rww.13
>>>>> 5
>>>>> CryptographySignatures-rww.15
>>>>> Diffie-Hellman
>>>>> 8
>>>>> CryptographyArchive-rww.15
>>>>> 17
>>>>> CryptographyKeyExchange-rww.13
>>>>> PBKDF2WithHmacSHA1, PBKDF2WithHmacSHA256, PKCS12
>>>>> 9
>>>>> CryptographyX509-rww.13
>>>>> 34
>>>>> CryptographyArchive-rww.15
>>>>> X509Certificate, X509CertificateDerReader, DSAPrivateKeyFileReader, RSAPublicKeyFileGenerator, RSAPrivateKeyFileGenerator
>>>>> 479
>>>>> Loadable
>>>>> Unloadable
>>>>>
>>>>> On 3/10/20 8:31 PM, Robert wrote:
>>>>>
>>>>>       I should share with you that I can load Levente's work in parallel and there are no toes stepped on. And all of his tests are CryptoGreen, with & out. This is a good.
>>>>>
>>>>>       *message too large* kindly, rabbit
>>>>>
>>>>>       On 3/10/20 6:06 PM, Robert wrote:
>>>>>
>>>>>       Hi Levente,
>>>>>
>>>>>       Here is a new release of CryptographyHashing-rww.15. It is not linked up through dependencies, so load it after. It supports SHA512WithPrimitive and SHA512NonPrimitive and passes all tests. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>>>>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>>>>> .
>>>>>
>>>>>       Here is this working implementation of SHA512. The naming ought to be without prefix for th ecore classes. I have no problem whatsoever if we were to rebase your work as the defining implementation for all of thosew funcrtions, using one plugin. That's something wonderful. We should use you
>>>>>       hashFunction and rename without prefix. Tests separate, that's fashionable. We can figure out the mc config later.
>>>>>
>>>>>       publish your work on, then I will link your solution into dependencies.
>>>>>
>>>>>                                                                                                                                                 CryptographyHashing-ul.16
>>>>>
>>>>>                                                                                                                                            CryptographyHashing-rww.15 (Release)
>>>>>
>>>>>       File:
>>>>>       CryptographyHashing-rww.15.mcz
>>>>>       Author:
>>>>>       Robert Withers
>>>>>       Timestamp:
>>>>>       10 March 2020 9:57:39 pm
>>>>>       UUID:
>>>>>       b7df722e-ab05-4465-97ef-deeffb0212d0
>>>>>       Ancestors:
>>>>>       CryptographyHashing-rww.14
>>>>>       Dependencies:
>>>>>       CryptographyCore-rww.5
>>>>>       Release:
>>>>>       This is a release that can be read by anybody.
>>>>>       Message:
>>>>>       adapt to new #primCopyoubleWords:intoBytes:. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>>>>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>>>>> .
>>>>> rttyk, r
>>>
>>> --
>
> --

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] SHA512 squeak implementation?

Squeak - Dev mailing list
Hi Levente,

On 3/16/20 2:53 PM, Levente Uzonyi wrote:

> Hi Robert,
>
> On Fri, 13 Mar 2020, Robert wrote:
>
>> On 3/12/20 7:49 PM, Levente Uzonyi wrote:
>>
>>> On Thu, 12 Mar 2020, Robert wrote:
>>>
>>>> Oh? I thought we discussed your package becoming the core solution, for HashFunctions. I was thinking you were going to rename all your classes back to no prefixes (except RGThirtyTwoBitRegister renamed to CryptoThirtyTwoBitRegister). And your hashFunction becomes the one in CryptographyCore. Your Registers and HashFunctions, become CryptographyHashing. Then I'll reset the dependencies to load yours.
>>>>
>>>> I got a little excited and released Pro Crypto v1.1.1, so with your code it would be ProCrypto v1.2.1.
>>>>
>>>> Did I misunderstand?
>>> I proposed that about three times in these discussions but got no
>>> response from you.
>>> Since you started integrating SHA512 manually, my impression was that you
>>> want to keep the exising classes.
>>> If you want Hasher to be merged into Cryptography, then I can give it a
>>> try on the weekend, but
>> See this post: http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207872.html
> I must have missed that post.

I apologize for tacking after some other stuff, in the middle of a
paragraph. That was limiting.

>
>>> 1) HashFunction should stay in the same package as its subclasses. Why?
>>> When another package doesn't use any of HashFunction's subclasses, it will
>>> not use HashFunction. When another package needs a subclass, HashFunction
>>> has to be present.
>> No, I see this through the lens of reuse. there may be other packages that wish to extend hashFunction for their own use. AN example would be a SignalEncryption package. It has a HashFunction. So all the class roots belong in the Core package.
> I couldn't find the SignalEncryption package anywhere.

It is CryptoChallengeNumberFive. I had downloaded the java implementation of Signal and they have 2 special crypto algorithms, I think one a hashFunction and the other their Public/PrivateKeys. Thus I wrote for NumberFive SignalEncryption and SignalProtocol. The first would extend root classes in Core for the HashFunction and the Keys from KeyExchange. Oh! Yeah so we already use a subpackage to subclass Keys, I think. So why not Hashing? Okay, leave it in CryptographyHashing, I see now.

> Is there a cryptographic hash function that is missing from Hasher?
There could be as alternate packages extend it, such as our future
SignalEncryption package.
> If there is, can it be implemented as a subclass of HashFunction?
Sure, just load Hashing.
> If yes, why doesn't it belong to the same package as the other subclasses
> of HashFunction?
To promote broad development to extend as needed. Perhaps rolled over to
Hashing later...Does that work?
>
>>> 2) Registers should stay in a separate package. Why?
>>> They can be used for other things. For example, I've got an unpublished
>>> package containing various PRNG implementations using it.
>> That's fine then, please put these classes also in the Core package.
> I don't see how the CryptographyCore package would be a good place for
> Registers.

Okay, same deal as above then. But you are adding another package
dependency. Easy enough to record in the ProCrypto-1-1-1 configuration map.


> The PRNGs I implemented are unrelated to Cryptography.

PRNGs? I had not heard. Do you want to roll those over to Random, please?

K, r

>
> Levente
>
>>> Does that work for you?
>> Working our way to the garden.
>>
>> k, r
>>
>>> Levente
>>>
>>>> k, r
>>>>
>>>> On 3/12/20 7:26 PM, Levente Uzonyi wrote:
>>>>
>>>>> Hi Robert,
>>>>>
>>>>> On Wed, 11 Mar 2020, Robert wrote:
>>>>>
>>>>>> Dear Levente,
>>>>>>
>>>>>> I had to rework the Hashing package. It was recording change records that moved RGSixtyTwoBitRegisters before another to rename them CryptoSixtyTwoBitRegisters, CryptographyHashing was ripping them out of your Registers package and your code started failing. So I had to swap classes around packages and fix a few
>>>>>> issues I had with SHA512 initialization, class & instance sides. I verified that they load in either order now and fully CryptoGreen. I setup dependencies through the latest Hashing package, 21. Here are the versions & how I load:
>>>>>>
>>>>>> Anything with your merge I can help with, Levente? I am excited for the day to announce ProCrypto v1.1.1, you know! ^,^ Milk it. I added a pointer to the plugins.
>>>>> What merge do you mean?
>>>>>
>>>>> Levente
>>>>>
>>>>>> Installer ss      project: 'Registers';      install: 'Registers';      project: 'Hasher';      install: 'HAHasher-Core';      install: 'HAHasher-Tests'. Installer ss      project: 'Cryptography';      install: 'CryptographyPlugins';      install: 'CryptographyX509'.
>>>>>>
>>>>>> K, r
>>>>>>
>>>>>> ProCrypto packages and dependencies
>>>>>> Package
>>>>>> Size (kb)
>>>>>> Dependencies
>>>>>> Algorithms
>>>>>> 1
>>>>>> CryptographyCore-rww.5
>>>>>> 18
>>>>>> HMAC, CBC, CFB, CTR, OFB
>>>>>> 2
>>>>>> CryptographyASN1-rww.4
>>>>>> 58
>>>>>> ASN1Module, ASN1InputStream, ASN1OutputStream
>>>>>> 3
>>>>>> CryptographyHashing-rww.21
>>>>>> 208
>>>>>> CryptographyCore-rww.5
>>>>>> ND2, MD4, MD5, SHA1, SHA256, SHA512
>>>>>> 4
>>>>>> CryptographyRandom-rww.11
>>>>>> 21
>>>>>> CryptographyHashing-rww.21
>>>>>> RandomPool, PrimesFinder, Miller-Rabin, Fortuna, SecureRandom
>>>>>> 5
>>>>>> CryptographyCiphers-rww.15
>>>>>> 81
>>>>>> CryptographyRandom-rww.11 CryptographyASN1-rww.4
>>>>>> ARC2, ARC4, DES, TripleDES, Blowfish, Rijndael
>>>>>> 6
>>>>>> CryptographySignatures-rww.15
>>>>>> 37
>>>>>> CryptographyCiphers-rww.15
>>>>>> DSAKeyPairGenerator, ElGamalKeyPairGenerator, RSAKeyPairGenerator
>>>>>> 7
>>>>>> CryptographyKeyExchange-rww.13
>>>>>> 5
>>>>>> CryptographySignatures-rww.15
>>>>>> Diffie-Hellman
>>>>>> 8
>>>>>> CryptographyArchive-rww.15
>>>>>> 17
>>>>>> CryptographyKeyExchange-rww.13
>>>>>> PBKDF2WithHmacSHA1, PBKDF2WithHmacSHA256, PKCS12
>>>>>> 9
>>>>>> CryptographyX509-rww.13
>>>>>> 34
>>>>>> CryptographyArchive-rww.15
>>>>>> X509Certificate, X509CertificateDerReader, DSAPrivateKeyFileReader, RSAPublicKeyFileGenerator, RSAPrivateKeyFileGenerator
>>>>>> 479
>>>>>> Loadable
>>>>>> Unloadable
>>>>>>
>>>>>> On 3/10/20 8:31 PM, Robert wrote:
>>>>>>
>>>>>>        I should share with you that I can load Levente's work in parallel and there are no toes stepped on. And all of his tests are CryptoGreen, with & out. This is a good.
>>>>>>
>>>>>>        *message too large* kindly, rabbit
>>>>>>
>>>>>>        On 3/10/20 6:06 PM, Robert wrote:
>>>>>>
>>>>>>        Hi Levente,
>>>>>>
>>>>>>        Here is a new release of CryptographyHashing-rww.15. It is not linked up through dependencies, so load it after. It supports SHA512WithPrimitive and SHA512NonPrimitive and passes all tests. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>>>>>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>>>>>> .
>>>>>>
>>>>>>        Here is this working implementation of SHA512. The naming ought to be without prefix for th ecore classes. I have no problem whatsoever if we were to rebase your work as the defining implementation for all of thosew funcrtions, using one plugin. That's something wonderful. We should use you
>>>>>>        hashFunction and rename without prefix. Tests separate, that's fashionable. We can figure out the mc config later.
>>>>>>
>>>>>>        publish your work on, then I will link your solution into dependencies.
>>>>>>
>>>>>>                                                                                                                                                  CryptographyHashing-ul.16
>>>>>>
>>>>>>                                                                                                                                             CryptographyHashing-rww.15 (Release)
>>>>>>
>>>>>>        File:
>>>>>>        CryptographyHashing-rww.15.mcz
>>>>>>        Author:
>>>>>>        Robert Withers
>>>>>>        Timestamp:
>>>>>>        10 March 2020 9:57:39 pm
>>>>>>        UUID:
>>>>>>        b7df722e-ab05-4465-97ef-deeffb0212d0
>>>>>>        Ancestors:
>>>>>>        CryptographyHashing-rww.14
>>>>>>        Dependencies:
>>>>>>        CryptographyCore-rww.5
>>>>>>        Release:
>>>>>>        This is a release that can be read by anybody.
>>>>>>        Message:
>>>>>>        adapt to new #primCopyoubleWords:intoBytes:. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>>>>>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>>>>>> .
>>>>>> rttyk, r
>>>> --
>> --

--
Kindly,
Robert



Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] SHA512 squeak implementation?

Levente Uzonyi
Hi Robert,

I've finished the integration of Hasher into the Cryptography package.
I didn't publish Monticello Configurations, but here's a list I would
publish if I did:

Registers-Core-ul.1
CryptographyCore-ul.7
CryptographyHashing-ul.23
CryptographyASN1-ul.6
CryptographyRandom-ul.13
CryptographyCiphers-rww.16
CryptographySignatures-ul.17
CryptographyKeyExchange-rww.14
CryptographyArchive-ul.18
CryptographyX509-ul.15

The Registers repository should be added to the configuration first, then
you can select Registers-Core and move it to the top of the list.
Regarding load order, I swapped CryptographyHashing with CryptographyASN1
because I added extension methods to the latter which extend classes of
the former.

Since CryptographyHashing does not depend on CryptographyCore, those two
can be swapped as well if needed.

For the tests, the configuration should contain the following packages:

CryptographyASN1Tests-rww.1
CryptographyCoreTests-rww.1
CryptographyHashingTests-ul.2
CryptographyRandomTests-rww.1
CryptographyCiphersTests-rww.1
CryptographySignaturesTests-rww.1
CryptographyKeyExchangeTests-rww.1
CryptographyArchiveTests-rww.1
CryptographyX509Tests-rww.1
Registers-Tests-ul.1


Levente

On Tue, 17 Mar 2020, Robert wrote:

> Hi Levente,
>
> On 3/16/20 2:53 PM, Levente Uzonyi wrote:
>> Hi Robert,
>>
>> On Fri, 13 Mar 2020, Robert wrote:
>>
>>> On 3/12/20 7:49 PM, Levente Uzonyi wrote:
>>>
>>>> On Thu, 12 Mar 2020, Robert wrote:
>>>>
>>>>> Oh? I thought we discussed your package becoming the core solution, for HashFunctions. I was thinking you were going to rename all your classes back to no prefixes (except RGThirtyTwoBitRegister renamed to CryptoThirtyTwoBitRegister). And your hashFunction becomes the one in CryptographyCore. Your Registers and HashFunctions, become CryptographyHashing. Then I'll reset the dependencies to load yours.
>>>>>
>>>>> I got a little excited and released Pro Crypto v1.1.1, so with your code it would be ProCrypto v1.2.1.
>>>>>
>>>>> Did I misunderstand?
>>>> I proposed that about three times in these discussions but got no
>>>> response from you.
>>>> Since you started integrating SHA512 manually, my impression was that you
>>>> want to keep the exising classes.
>>>> If you want Hasher to be merged into Cryptography, then I can give it a
>>>> try on the weekend, but
>>> See this post: http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207872.html
>> I must have missed that post.
>
> I apologize for tacking after some other stuff, in the middle of a
> paragraph. That was limiting.
>
>>
>>>> 1) HashFunction should stay in the same package as its subclasses. Why?
>>>> When another package doesn't use any of HashFunction's subclasses, it will
>>>> not use HashFunction. When another package needs a subclass, HashFunction
>>>> has to be present.
>>> No, I see this through the lens of reuse. there may be other packages that wish to extend hashFunction for their own use. AN example would be a SignalEncryption package. It has a HashFunction. So all the class roots belong in the Core package.
>> I couldn't find the SignalEncryption package anywhere.
>
> It is CryptoChallengeNumberFive. I had downloaded the java implementation of Signal and they have 2 special crypto algorithms, I think one a hashFunction and the other their Public/PrivateKeys. Thus I wrote for NumberFive SignalEncryption and SignalProtocol. The first would extend root classes in Core for the HashFunction and the Keys from KeyExchange. Oh! Yeah so we already use a subpackage to subclass Keys, I think. So why not Hashing? Okay, leave it in CryptographyHashing, I see now.
>
>> Is there a cryptographic hash function that is missing from Hasher?
> There could be as alternate packages extend it, such as our future
> SignalEncryption package.
>> If there is, can it be implemented as a subclass of HashFunction?
> Sure, just load Hashing.
>> If yes, why doesn't it belong to the same package as the other subclasses
>> of HashFunction?
> To promote broad development to extend as needed. Perhaps rolled over to
> Hashing later...Does that work?
>>
>>>> 2) Registers should stay in a separate package. Why?
>>>> They can be used for other things. For example, I've got an unpublished
>>>> package containing various PRNG implementations using it.
>>> That's fine then, please put these classes also in the Core package.
>> I don't see how the CryptographyCore package would be a good place for
>> Registers.
>
> Okay, same deal as above then. But you are adding another package
> dependency. Easy enough to record in the ProCrypto-1-1-1 configuration map.
>
>
>> The PRNGs I implemented are unrelated to Cryptography.
>
> PRNGs? I had not heard. Do you want to roll those over to Random, please?
>
> K, r
>
>>
>> Levente
>>
>>>> Does that work for you?
>>> Working our way to the garden.
>>>
>>> k, r
>>>
>>>> Levente
>>>>
>>>>> k, r
>>>>>
>>>>> On 3/12/20 7:26 PM, Levente Uzonyi wrote:
>>>>>
>>>>>> Hi Robert,
>>>>>>
>>>>>> On Wed, 11 Mar 2020, Robert wrote:
>>>>>>
>>>>>>> Dear Levente,
>>>>>>>
>>>>>>> I had to rework the Hashing package. It was recording change records that moved RGSixtyTwoBitRegisters before another to rename them CryptoSixtyTwoBitRegisters, CryptographyHashing was ripping them out of your Registers package and your code started failing. So I had to swap classes around packages and fix a few
>>>>>>> issues I had with SHA512 initialization, class & instance sides. I verified that they load in either order now and fully CryptoGreen. I setup dependencies through the latest Hashing package, 21. Here are the versions & how I load:
>>>>>>>
>>>>>>> Anything with your merge I can help with, Levente? I am excited for the day to announce ProCrypto v1.1.1, you know! ^,^ Milk it. I added a pointer to the plugins.
>>>>>> What merge do you mean?
>>>>>>
>>>>>> Levente
>>>>>>
>>>>>>> Installer ss      project: 'Registers';      install: 'Registers';      project: 'Hasher';      install: 'HAHasher-Core';      install: 'HAHasher-Tests'. Installer ss      project: 'Cryptography';      install: 'CryptographyPlugins';      install: 'CryptographyX509'.
>>>>>>>
>>>>>>> K, r
>>>>>>>
>>>>>>> ProCrypto packages and dependencies
>>>>>>> Package
>>>>>>> Size (kb)
>>>>>>> Dependencies
>>>>>>> Algorithms
>>>>>>> 1
>>>>>>> CryptographyCore-rww.5
>>>>>>> 18
>>>>>>> HMAC, CBC, CFB, CTR, OFB
>>>>>>> 2
>>>>>>> CryptographyASN1-rww.4
>>>>>>> 58
>>>>>>> ASN1Module, ASN1InputStream, ASN1OutputStream
>>>>>>> 3
>>>>>>> CryptographyHashing-rww.21
>>>>>>> 208
>>>>>>> CryptographyCore-rww.5
>>>>>>> ND2, MD4, MD5, SHA1, SHA256, SHA512
>>>>>>> 4
>>>>>>> CryptographyRandom-rww.11
>>>>>>> 21
>>>>>>> CryptographyHashing-rww.21
>>>>>>> RandomPool, PrimesFinder, Miller-Rabin, Fortuna, SecureRandom
>>>>>>> 5
>>>>>>> CryptographyCiphers-rww.15
>>>>>>> 81
>>>>>>> CryptographyRandom-rww.11 CryptographyASN1-rww.4
>>>>>>> ARC2, ARC4, DES, TripleDES, Blowfish, Rijndael
>>>>>>> 6
>>>>>>> CryptographySignatures-rww.15
>>>>>>> 37
>>>>>>> CryptographyCiphers-rww.15
>>>>>>> DSAKeyPairGenerator, ElGamalKeyPairGenerator, RSAKeyPairGenerator
>>>>>>> 7
>>>>>>> CryptographyKeyExchange-rww.13
>>>>>>> 5
>>>>>>> CryptographySignatures-rww.15
>>>>>>> Diffie-Hellman
>>>>>>> 8
>>>>>>> CryptographyArchive-rww.15
>>>>>>> 17
>>>>>>> CryptographyKeyExchange-rww.13
>>>>>>> PBKDF2WithHmacSHA1, PBKDF2WithHmacSHA256, PKCS12
>>>>>>> 9
>>>>>>> CryptographyX509-rww.13
>>>>>>> 34
>>>>>>> CryptographyArchive-rww.15
>>>>>>> X509Certificate, X509CertificateDerReader, DSAPrivateKeyFileReader, RSAPublicKeyFileGenerator, RSAPrivateKeyFileGenerator
>>>>>>> 479
>>>>>>> Loadable
>>>>>>> Unloadable
>>>>>>>
>>>>>>> On 3/10/20 8:31 PM, Robert wrote:
>>>>>>>
>>>>>>>        I should share with you that I can load Levente's work in parallel and there are no toes stepped on. And all of his tests are CryptoGreen, with & out. This is a good.
>>>>>>>
>>>>>>>        *message too large* kindly, rabbit
>>>>>>>
>>>>>>>        On 3/10/20 6:06 PM, Robert wrote:
>>>>>>>
>>>>>>>        Hi Levente,
>>>>>>>
>>>>>>>        Here is a new release of CryptographyHashing-rww.15. It is not linked up through dependencies, so load it after. It supports SHA512WithPrimitive and SHA512NonPrimitive and passes all tests. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>>>>>>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>>>>>>> .
>>>>>>>
>>>>>>>        Here is this working implementation of SHA512. The naming ought to be without prefix for th ecore classes. I have no problem whatsoever if we were to rebase your work as the defining implementation for all of thosew funcrtions, using one plugin. That's something wonderful. We should use you
>>>>>>>        hashFunction and rename without prefix. Tests separate, that's fashionable. We can figure out the mc config later.
>>>>>>>
>>>>>>>        publish your work on, then I will link your solution into dependencies.
>>>>>>>
>>>>>>>                                                                                                                                                  CryptographyHashing-ul.16
>>>>>>>
>>>>>>>                                                                                                                                             CryptographyHashing-rww.15 (Release)
>>>>>>>
>>>>>>>        File:
>>>>>>>        CryptographyHashing-rww.15.mcz
>>>>>>>        Author:
>>>>>>>        Robert Withers
>>>>>>>        Timestamp:
>>>>>>>        10 March 2020 9:57:39 pm
>>>>>>>        UUID:
>>>>>>>        b7df722e-ab05-4465-97ef-deeffb0212d0
>>>>>>>        Ancestors:
>>>>>>>        CryptographyHashing-rww.14
>>>>>>>        Dependencies:
>>>>>>>        CryptographyCore-rww.5
>>>>>>>        Release:
>>>>>>>        This is a release that can be read by anybody.
>>>>>>>        Message:
>>>>>>>        adapt to new #primCopyoubleWords:intoBytes:. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>>>>>>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>>>>>>> .
>>>>>>> rttyk, r
>>>>> --
>>> --
>
> --
> Kindly,
> Robert
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: ProCrypto v1.1.1 Re: [Vm-dev] SHA512 squeak implementation?

Squeak - Dev mailing list
In reply to this post by Squeak - Dev mailing list

Newer version of ProCrypto-1-1-1 and ProCryptoTests-1-1-1 published with Levente's hashFunctions. #CryptoGreen.  Thanks Levente! The Install doIt will pick up the latest version.

Installer ss
    project: 'Cryptography';
    install: 'ProCrypto-1-1-1';
    install: 'ProCryptoTests-1-1-1'.

K, r

On 3/15/20 4:32 PM, Robert wrote:

I was hoping to have a chance to pass out these flyers (and offer the electronic PDF, by thumb drive or email, with working links) to all of the College/University Departments of Crypto/Networking/CompSci in the area that I could. i do not have contact with any so I haven't found a way to email those departments, other than to a professor at my Alma Mater, Guilford College: https://www.guilford.edu/cyber-and-network-security, which is a Great Fit. That's what inspired me to move forward this promotional way.

Unfortunately, or rather Fortunately, schools are out on Spring Break, to be extended. So unless you guys and gals have contact into some departments, my marketing strategy of enlisting college hackers has fallen short. I did get to NCCU, right next door to me, and handed out the flyers to the CompSci professors. I printed out a bunch to plaster Duke and UNC, going to buy a few thumb drives. And timing. I think I need to wait until the kids return.

What are your thoughts about Squeak marketing? It's like turning out the vote. We should expand with Squeak 5.3! Any sort of multiplayer Croquet game to hook them with? Or other games!

Thank You Kindly,
Robert

---
To load core + tests, doIt:

[Installer ss
     project: 'Cryptography';
     install: 'ProCrypto-1-1-1';
     install: 'ProCryptoTests-1-1-1'.] timeToRun.

"I get 46.9 seconds loading into my vm. 174 tests run in 3 seconds."
---
ProCrypto 1.1.1 flyer: https://www.dropbox.com/s/7y7ngnya9qeg5gf/ProCrypto-1-1-1.pdf?dl=0
Smalltalk Cheat Sheet: https://www.dropbox.com/s/p4iz51a0qouv8wu/st-cheatsheet.pdf?dl=0



-- 
Kindly,
Robert


Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] SHA512 squeak implementation?

Squeak - Dev mailing list
In reply to this post by Levente Uzonyi
Hi Levente,

I got tangled up in an image that had older Crypto code loaded, then I
loaded the most recent and I had failing tests. So I went back to a
virgin image and loaded into that. All tests pass Green. I am trying to
track all the changes you made, for instance relying on the stock
ThirtyTwoBitRegister>>#rotateLeftBy: and also using the native
SecureHashAlgorithm>>#hashInteger:seed:. It is confusing. Cryptography
was supposed to be complete and independent, but it relies on certain
classes being present, with certain implementations. Given this, would
ProCrypto be loadable in Pharo and pass green?

One thing I recall you saying, I think you said you are using postscript
initialization. Where could I find that?

k, r

On 3/18/20 7:50 AM, Levente Uzonyi wrote:

> Hi Robert,
>
> I've finished the integration of Hasher into the Cryptography package.
> I didn't publish Monticello Configurations, but here's a list I would
> publish if I did:
>
> Registers-Core-ul.1
> CryptographyCore-ul.7
> CryptographyHashing-ul.23
> CryptographyASN1-ul.6
> CryptographyRandom-ul.13
> CryptographyCiphers-rww.16
> CryptographySignatures-ul.17
> CryptographyKeyExchange-rww.14
> CryptographyArchive-ul.18
> CryptographyX509-ul.15
>
> The Registers repository should be added to the configuration first, then
> you can select Registers-Core and move it to the top of the list.
> Regarding load order, I swapped CryptographyHashing with CryptographyASN1
> because I added extension methods to the latter which extend classes of
> the former.
>
> Since CryptographyHashing does not depend on CryptographyCore, those two
> can be swapped as well if needed.
>
> For the tests, the configuration should contain the following packages:
>
> CryptographyASN1Tests-rww.1
> CryptographyCoreTests-rww.1
> CryptographyHashingTests-ul.2
> CryptographyRandomTests-rww.1
> CryptographyCiphersTests-rww.1
> CryptographySignaturesTests-rww.1
> CryptographyKeyExchangeTests-rww.1
> CryptographyArchiveTests-rww.1
> CryptographyX509Tests-rww.1
> Registers-Tests-ul.1
>
>
> Levente
>
> On Tue, 17 Mar 2020, Robert wrote:
>
>> Hi Levente,
>>
>> On 3/16/20 2:53 PM, Levente Uzonyi wrote:
>>> Hi Robert,
>>>
>>> On Fri, 13 Mar 2020, Robert wrote:
>>>
>>>> On 3/12/20 7:49 PM, Levente Uzonyi wrote:
>>>>
>>>>> On Thu, 12 Mar 2020, Robert wrote:
>>>>>
>>>>>> Oh? I thought we discussed your package becoming the core solution, for HashFunctions. I was thinking you were going to rename all your classes back to no prefixes (except RGThirtyTwoBitRegister renamed to CryptoThirtyTwoBitRegister). And your hashFunction becomes the one in CryptographyCore. Your Registers and HashFunctions, become CryptographyHashing. Then I'll reset the dependencies to load yours.
>>>>>>
>>>>>> I got a little excited and released Pro Crypto v1.1.1, so with your code it would be ProCrypto v1.2.1.
>>>>>>
>>>>>> Did I misunderstand?
>>>>> I proposed that about three times in these discussions but got no
>>>>> response from you.
>>>>> Since you started integrating SHA512 manually, my impression was that you
>>>>> want to keep the exising classes.
>>>>> If you want Hasher to be merged into Cryptography, then I can give it a
>>>>> try on the weekend, but
>>>> See this post: http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207872.html
>>> I must have missed that post.
>> I apologize for tacking after some other stuff, in the middle of a
>> paragraph. That was limiting.
>>
>>>>> 1) HashFunction should stay in the same package as its subclasses. Why?
>>>>> When another package doesn't use any of HashFunction's subclasses, it will
>>>>> not use HashFunction. When another package needs a subclass, HashFunction
>>>>> has to be present.
>>>> No, I see this through the lens of reuse. there may be other packages that wish to extend hashFunction for their own use. AN example would be a SignalEncryption package. It has a HashFunction. So all the class roots belong in the Core package.
>>> I couldn't find the SignalEncryption package anywhere.
>> It is CryptoChallengeNumberFive. I had downloaded the java implementation of Signal and they have 2 special crypto algorithms, I think one a hashFunction and the other their Public/PrivateKeys. Thus I wrote for NumberFive SignalEncryption and SignalProtocol. The first would extend root classes in Core for the HashFunction and the Keys from KeyExchange. Oh! Yeah so we already use a subpackage to subclass Keys, I think. So why not Hashing? Okay, leave it in CryptographyHashing, I see now.
>>
>>> Is there a cryptographic hash function that is missing from Hasher?
>> There could be as alternate packages extend it, such as our future
>> SignalEncryption package.
>>> If there is, can it be implemented as a subclass of HashFunction?
>> Sure, just load Hashing.
>>> If yes, why doesn't it belong to the same package as the other subclasses
>>> of HashFunction?
>> To promote broad development to extend as needed. Perhaps rolled over to
>> Hashing later...Does that work?
>>>>> 2) Registers should stay in a separate package. Why?
>>>>> They can be used for other things. For example, I've got an unpublished
>>>>> package containing various PRNG implementations using it.
>>>> That's fine then, please put these classes also in the Core package.
>>> I don't see how the CryptographyCore package would be a good place for
>>> Registers.
>> Okay, same deal as above then. But you are adding another package
>> dependency. Easy enough to record in the ProCrypto-1-1-1 configuration map.
>>
>>
>>> The PRNGs I implemented are unrelated to Cryptography.
>> PRNGs? I had not heard. Do you want to roll those over to Random, please?
>>
>> K, r
>>
>>> Levente
>>>
>>>>> Does that work for you?
>>>> Working our way to the garden.
>>>>
>>>> k, r
>>>>
>>>>> Levente
>>>>>
>>>>>> k, r
>>>>>>
>>>>>> On 3/12/20 7:26 PM, Levente Uzonyi wrote:
>>>>>>
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>> On Wed, 11 Mar 2020, Robert wrote:
>>>>>>>
>>>>>>>> Dear Levente,
>>>>>>>>
>>>>>>>> I had to rework the Hashing package. It was recording change records that moved RGSixtyTwoBitRegisters before another to rename them CryptoSixtyTwoBitRegisters, CryptographyHashing was ripping them out of your Registers package and your code started failing. So I had to swap classes around packages and fix a few
>>>>>>>> issues I had with SHA512 initialization, class & instance sides. I verified that they load in either order now and fully CryptoGreen. I setup dependencies through the latest Hashing package, 21. Here are the versions & how I load:
>>>>>>>>
>>>>>>>> Anything with your merge I can help with, Levente? I am excited for the day to announce ProCrypto v1.1.1, you know! ^,^ Milk it. I added a pointer to the plugins.
>>>>>>> What merge do you mean?
>>>>>>>
>>>>>>> Levente
>>>>>>>
>>>>>>>> Installer ss      project: 'Registers';      install: 'Registers';      project: 'Hasher';      install: 'HAHasher-Core';      install: 'HAHasher-Tests'. Installer ss      project: 'Cryptography';      install: 'CryptographyPlugins';      install: 'CryptographyX509'.
>>>>>>>>
>>>>>>>> K, r
>>>>>>>>
>>>>>>>> ProCrypto packages and dependencies
>>>>>>>> Package
>>>>>>>> Size (kb)
>>>>>>>> Dependencies
>>>>>>>> Algorithms
>>>>>>>> 1
>>>>>>>> CryptographyCore-rww.5
>>>>>>>> 18
>>>>>>>> HMAC, CBC, CFB, CTR, OFB
>>>>>>>> 2
>>>>>>>> CryptographyASN1-rww.4
>>>>>>>> 58
>>>>>>>> ASN1Module, ASN1InputStream, ASN1OutputStream
>>>>>>>> 3
>>>>>>>> CryptographyHashing-rww.21
>>>>>>>> 208
>>>>>>>> CryptographyCore-rww.5
>>>>>>>> ND2, MD4, MD5, SHA1, SHA256, SHA512
>>>>>>>> 4
>>>>>>>> CryptographyRandom-rww.11
>>>>>>>> 21
>>>>>>>> CryptographyHashing-rww.21
>>>>>>>> RandomPool, PrimesFinder, Miller-Rabin, Fortuna, SecureRandom
>>>>>>>> 5
>>>>>>>> CryptographyCiphers-rww.15
>>>>>>>> 81
>>>>>>>> CryptographyRandom-rww.11 CryptographyASN1-rww.4
>>>>>>>> ARC2, ARC4, DES, TripleDES, Blowfish, Rijndael
>>>>>>>> 6
>>>>>>>> CryptographySignatures-rww.15
>>>>>>>> 37
>>>>>>>> CryptographyCiphers-rww.15
>>>>>>>> DSAKeyPairGenerator, ElGamalKeyPairGenerator, RSAKeyPairGenerator
>>>>>>>> 7
>>>>>>>> CryptographyKeyExchange-rww.13
>>>>>>>> 5
>>>>>>>> CryptographySignatures-rww.15
>>>>>>>> Diffie-Hellman
>>>>>>>> 8
>>>>>>>> CryptographyArchive-rww.15
>>>>>>>> 17
>>>>>>>> CryptographyKeyExchange-rww.13
>>>>>>>> PBKDF2WithHmacSHA1, PBKDF2WithHmacSHA256, PKCS12
>>>>>>>> 9
>>>>>>>> CryptographyX509-rww.13
>>>>>>>> 34
>>>>>>>> CryptographyArchive-rww.15
>>>>>>>> X509Certificate, X509CertificateDerReader, DSAPrivateKeyFileReader, RSAPublicKeyFileGenerator, RSAPrivateKeyFileGenerator
>>>>>>>> 479
>>>>>>>> Loadable
>>>>>>>> Unloadable
>>>>>>>>
>>>>>>>> On 3/10/20 8:31 PM, Robert wrote:
>>>>>>>>
>>>>>>>>         I should share with you that I can load Levente's work in parallel and there are no toes stepped on. And all of his tests are CryptoGreen, with & out. This is a good.
>>>>>>>>
>>>>>>>>         *message too large* kindly, rabbit
>>>>>>>>
>>>>>>>>         On 3/10/20 6:06 PM, Robert wrote:
>>>>>>>>
>>>>>>>>         Hi Levente,
>>>>>>>>
>>>>>>>>         Here is a new release of CryptographyHashing-rww.15. It is not linked up through dependencies, so load it after. It supports SHA512WithPrimitive and SHA512NonPrimitive and passes all tests. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>>>>>>>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>>>>>>>> .
>>>>>>>>
>>>>>>>>         Here is this working implementation of SHA512. The naming ought to be without prefix for th ecore classes. I have no problem whatsoever if we were to rebase your work as the defining implementation for all of thosew funcrtions, using one plugin. That's something wonderful. We should use you
>>>>>>>>         hashFunction and rename without prefix. Tests separate, that's fashionable. We can figure out the mc config later.
>>>>>>>>
>>>>>>>>         publish your work on, then I will link your solution into dependencies.
>>>>>>>>
>>>>>>>>                                                                                                                                                   CryptographyHashing-ul.16
>>>>>>>>
>>>>>>>>                                                                                                                                              CryptographyHashing-rww.15 (Release)
>>>>>>>>
>>>>>>>>         File:
>>>>>>>>         CryptographyHashing-rww.15.mcz
>>>>>>>>         Author:
>>>>>>>>         Robert Withers
>>>>>>>>         Timestamp:
>>>>>>>>         10 March 2020 9:57:39 pm
>>>>>>>>         UUID:
>>>>>>>>         b7df722e-ab05-4465-97ef-deeffb0212d0
>>>>>>>>         Ancestors:
>>>>>>>>         CryptographyHashing-rww.14
>>>>>>>>         Dependencies:
>>>>>>>>         CryptographyCore-rww.5
>>>>>>>>         Release:
>>>>>>>>         This is a release that can be read by anybody.
>>>>>>>>         Message:
>>>>>>>>         adapt to new #primCopyoubleWords:intoBytes:. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>>>>>>>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>>>>>>>> .
>>>>>>>> rttyk, r
>>>>>> --
>>>> --
>> --
>> Kindly,
>> Robert
>>
>>
>>
--
Kindly,
Robert



Reply | Threaded
Open this post in threaded view
|

Re: SHA512 squeak implementation?

Squeak - Dev mailing list

Hey Levente,

I just released new versions of CryptographyASN1-rww.7 and CryptographyHashing-rww.24, after moving all the #oidString methods to Hashing. Now, once again, ASN1 is independent of any other Cryptography classes, as it should be. ProCrypto-1-1-1 is updated.

Cryptography is relying on other classes being available. String and ByteArray and such, fine that should all be common Smalltalk library.

Some other classes Cryptography expects should not be. So our ThirtyTwoBitRegister use should change to RGThirtyTwoBitRegister, as long as it has all the expected protocol. This keeps it within the ProCrypto load boundaries. As well, use of SecureHashAlgorithm should change to SHA1. I was glad to see that MD5 checks for MD5Plugin, then if absent, checks for the CroquetPlugin. Are there any other specialized class use that could be withdrawn?

Then to test on Pharo. I ran the PharoLauncher and grabbed a Pharo 8 64-bit image and added the repositories. As Installer is absent and Gofer fails to load a config map, I manually loaded Core and Hashing. In #initializeInitialHashValues, there was an Error: improper store into indexable object so Crypto fails in Pharo.

I really have no intention of spending any more time in the Pharo environment, it is petty foreign to me. Others will need to ensure compatibility, unless we could automate it...

K, r

On 3/20/20 9:06 AM, Robert wrote:
Hi Levente,

I got tangled up in an image that had older Crypto code loaded, then I 
loaded the most recent and I had failing tests. So I went back to a 
virgin image and loaded into that. All tests pass Green. I am trying to 
track all the changes you made, for instance relying on the stock 
ThirtyTwoBitRegister>>#rotateLeftBy: and also using the native 
SecureHashAlgorithm>>#hashInteger:seed:. It is confusing. Cryptography 
was supposed to be complete and independent, but it relies on certain 
classes being present, with certain implementations. Given this, would 
ProCrypto be loadable in Pharo and pass green?

One thing I recall you saying, I think you said you are using postscript 
initialization. Where could I find that?

k, r

On 3/18/20 7:50 AM, Levente Uzonyi wrote:
Hi Robert,

I've finished the integration of Hasher into the Cryptography package.
I didn't publish Monticello Configurations, but here's a list I would
publish if I did:

Registers-Core-ul.1
CryptographyCore-ul.7
CryptographyHashing-ul.23
CryptographyASN1-ul.6
CryptographyRandom-ul.13
CryptographyCiphers-rww.16
CryptographySignatures-ul.17
CryptographyKeyExchange-rww.14
CryptographyArchive-ul.18
CryptographyX509-ul.15

The Registers repository should be added to the configuration first, then
you can select Registers-Core and move it to the top of the list.
Regarding load order, I swapped CryptographyHashing with CryptographyASN1
because I added extension methods to the latter which extend classes of
the former.

Since CryptographyHashing does not depend on CryptographyCore, those two
can be swapped as well if needed.

For the tests, the configuration should contain the following packages:

CryptographyASN1Tests-rww.1
CryptographyCoreTests-rww.1
CryptographyHashingTests-ul.2
CryptographyRandomTests-rww.1
CryptographyCiphersTests-rww.1
CryptographySignaturesTests-rww.1
CryptographyKeyExchangeTests-rww.1
CryptographyArchiveTests-rww.1
CryptographyX509Tests-rww.1
Registers-Tests-ul.1


Levente

On Tue, 17 Mar 2020, Robert wrote:

Hi Levente,

On 3/16/20 2:53 PM, Levente Uzonyi wrote:
Hi Robert,

On Fri, 13 Mar 2020, Robert wrote:

On 3/12/20 7:49 PM, Levente Uzonyi wrote:

On Thu, 12 Mar 2020, Robert wrote:

Oh? I thought we discussed your package becoming the core solution, for HashFunctions. I was thinking you were going to rename all your classes back to no prefixes (except RGThirtyTwoBitRegister renamed to CryptoThirtyTwoBitRegister). And your hashFunction becomes the one in CryptographyCore. Your Registers and HashFunctions, become CryptographyHashing. Then I'll reset the dependencies to load yours.

I got a little excited and released Pro Crypto v1.1.1, so with your code it would be ProCrypto v1.2.1.

Did I misunderstand?
I proposed that about three times in these discussions but got no
response from you.
Since you started integrating SHA512 manually, my impression was that you
want to keep the exising classes.
If you want Hasher to be merged into Cryptography, then I can give it a
try on the weekend, but
See this post: http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207872.html
I must have missed that post.
I apologize for tacking after some other stuff, in the middle of a
paragraph. That was limiting.

1) HashFunction should stay in the same package as its subclasses. Why?
When another package doesn't use any of HashFunction's subclasses, it will
not use HashFunction. When another package needs a subclass, HashFunction
has to be present.
No, I see this through the lens of reuse. there may be other packages that wish to extend hashFunction for their own use. AN example would be a SignalEncryption package. It has a HashFunction. So all the class roots belong in the Core package.
I couldn't find the SignalEncryption package anywhere.
It is CryptoChallengeNumberFive. I had downloaded the java implementation of Signal and they have 2 special crypto algorithms, I think one a hashFunction and the other their Public/PrivateKeys. Thus I wrote for NumberFive SignalEncryption and SignalProtocol. The first would extend root classes in Core for the HashFunction and the Keys from KeyExchange. Oh! Yeah so we already use a subpackage to subclass Keys, I think. So why not Hashing? Okay, leave it in CryptographyHashing, I see now.

Is there a cryptographic hash function that is missing from Hasher?
There could be as alternate packages extend it, such as our future
SignalEncryption package.
If there is, can it be implemented as a subclass of HashFunction?
Sure, just load Hashing.
If yes, why doesn't it belong to the same package as the other subclasses
of HashFunction?
To promote broad development to extend as needed. Perhaps rolled over to
Hashing later...Does that work?
2) Registers should stay in a separate package. Why?
They can be used for other things. For example, I've got an unpublished
package containing various PRNG implementations using it.
That's fine then, please put these classes also in the Core package.
I don't see how the CryptographyCore package would be a good place for
Registers.
Okay, same deal as above then. But you are adding another package
dependency. Easy enough to record in the ProCrypto-1-1-1 configuration map.


The PRNGs I implemented are unrelated to Cryptography.
PRNGs? I had not heard. Do you want to roll those over to Random, please?

K, r

Levente

Does that work for you?
Working our way to the garden.

k, r

Levente

k, r

On 3/12/20 7:26 PM, Levente Uzonyi wrote:

Hi Robert,

On Wed, 11 Mar 2020, Robert wrote:

Dear Levente,

I had to rework the Hashing package. It was recording change records that moved RGSixtyTwoBitRegisters before another to rename them CryptoSixtyTwoBitRegisters, CryptographyHashing was ripping them out of your Registers package and your code started failing. So I had to swap classes around packages and fix a few
issues I had with SHA512 initialization, class & instance sides. I verified that they load in either order now and fully CryptoGreen. I setup dependencies through the latest Hashing package, 21. Here are the versions & how I load:

Anything with your merge I can help with, Levente? I am excited for the day to announce ProCrypto v1.1.1, you know! ^,^ Milk it. I added a pointer to the plugins.
What merge do you mean?

Levente

Installer ss      project: 'Registers';      install: 'Registers';      project: 'Hasher';      install: 'HAHasher-Core';      install: 'HAHasher-Tests'. Installer ss      project: 'Cryptography';      install: 'CryptographyPlugins';      install: 'CryptographyX509'.

K, r

ProCrypto packages and dependencies
Package
Size (kb)
Dependencies
Algorithms
1
CryptographyCore-rww.5
18
HMAC, CBC, CFB, CTR, OFB
2
CryptographyASN1-rww.4
58
ASN1Module, ASN1InputStream, ASN1OutputStream
3
CryptographyHashing-rww.21
208
CryptographyCore-rww.5
ND2, MD4, MD5, SHA1, SHA256, SHA512
4
CryptographyRandom-rww.11
21
CryptographyHashing-rww.21
RandomPool, PrimesFinder, Miller-Rabin, Fortuna, SecureRandom
5
CryptographyCiphers-rww.15
81
CryptographyRandom-rww.11 CryptographyASN1-rww.4
ARC2, ARC4, DES, TripleDES, Blowfish, Rijndael
6
CryptographySignatures-rww.15
37
CryptographyCiphers-rww.15
DSAKeyPairGenerator, ElGamalKeyPairGenerator, RSAKeyPairGenerator
7
CryptographyKeyExchange-rww.13
5
CryptographySignatures-rww.15
Diffie-Hellman
8
CryptographyArchive-rww.15
17
CryptographyKeyExchange-rww.13
PBKDF2WithHmacSHA1, PBKDF2WithHmacSHA256, PKCS12
9
CryptographyX509-rww.13
34
CryptographyArchive-rww.15
X509Certificate, X509CertificateDerReader, DSAPrivateKeyFileReader, RSAPublicKeyFileGenerator, RSAPrivateKeyFileGenerator
479
Loadable
Unloadable

On 3/10/20 8:31 PM, Robert wrote:

        I should share with you that I can load Levente's work in parallel and there are no toes stepped on. And all of his tests are CryptoGreen, with & out. This is a good.

        *message too large* kindly, rabbit

        On 3/10/20 6:06 PM, Robert wrote:

        Hi Levente,

        Here is a new release of CryptographyHashing-rww.15. It is not linked up through dependencies, so load it after. It supports SHA512WithPrimitive and SHA512NonPrimitive and passes all tests. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
.

        Here is this working implementation of SHA512. The naming ought to be without prefix for th ecore classes. I have no problem whatsoever if we were to rebase your work as the defining implementation for all of thosew funcrtions, using one plugin. That's something wonderful. We should use you
        hashFunction and rename without prefix. Tests separate, that's fashionable. We can figure out the mc config later.

        publish your work on, then I will link your solution into dependencies.

                                                                                                                                                  CryptographyHashing-ul.16

                                                                                                                                             CryptographyHashing-rww.15 (Release)

        File:
        CryptographyHashing-rww.15.mcz
        Author:
        Robert Withers
        Timestamp:
        10 March 2020 9:57:39 pm
        UUID:
        b7df722e-ab05-4465-97ef-deeffb0212d0
        Ancestors:
        CryptographyHashing-rww.14
        Dependencies:
        CryptographyCore-rww.5
        Release:
        This is a release that can be read by anybody.
        Message:
        adapt to new #primCopyoubleWords:intoBytes:. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
.
rttyk, r
--
--
--
Kindly,
Robert



-- 
Kindly,
Robert


Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] SHA512 squeak implementation?

Levente Uzonyi
In reply to this post by Squeak - Dev mailing list
Hi Robert,

On Fri, 20 Mar 2020, Robert wrote:

> Hi Levente,
>
> I got tangled up in an image that had older Crypto code loaded, then I
> loaded the most recent and I had failing tests. So I went back to a

Interesting. I did my best to minimize such changes, but it's possible
that some objects held references to instances of obsolete classes, which
is not easy to fix.

> virgin image and loaded into that. All tests pass Green. I am trying to
> track all the changes you made, for instance relying on the stock
> ThirtyTwoBitRegister>>#rotateLeftBy: and also using the native

ThirtyTwoBitRegister was moved to Squeak 10+ years ago. Overriding a
method of it from an external package is not a good idea, as the internals
of the class may change over time.
If you compare the two versions of #rotateLeftBy:, you'll find that
Squeak's version is faster. Now that we have a dependency on the Registers
package, it is possible to migrate all users of ThirtyTwoBitRegister to
those registers in the Registers package for an additional performance
boost.

> SecureHashAlgorithm>>#hashInteger:seed:. It is confusing. Cryptography

It is confusing. The idea of using integers with any HashFunction is
simply wrong. HashFunctions are defined on ByteArray inputs, so using
integers means some kind of mapping between the two - aka hardcoded
endianness. Besides being confusing, this is a great source of performance
loss.

I did not want to rewrite the senders of #hashInteger:seed:, and I did not
intend to introduce the method because of the above, so I decided to do
the simplest thing and use SecureHashAlgorithm which is present in
Squeak core, provided by the same package ThirtyTwoBitRegister lives in.

> was supposed to be complete and independent, but it relies on certain
> classes being present, with certain implementations. Given this, would

Well, define independend. The package relies on many classes not in the
Cryptography repository but the Squeak core (e.g. Integer, ByteArray,
ByteString, Stream, ThirtyTwoBitRegister, etc).

> ProCrypto be loadable in Pharo and pass green?

I do not use Pharo, but based on the way Pharo is developed, I doubt it
would load and work in any existing Pharo versions except for the most
ancient ones.
I think that even if you made it work in the latest Pharo version, it
would very likely stop working in the next release. So, if I were you, I
wouldn't bother. I wouldn't be surprised if they dropped Monticello
support in the next release, forcing you to use whatever packaging system
they come up with.

>
> One thing I recall you saying, I think you said you are using postscript
> initialization. Where could I find that?

Open the Monticello Browser, select a package, click on Scripts. A menu
will appear where you can choose which package script you would like to
edit. I added a postscript to CryptographyCiphers to reinitialize the
class variables of Rijndael.


Levente

>
> k, r
>
> On 3/18/20 7:50 AM, Levente Uzonyi wrote:
>> Hi Robert,
>>
>> I've finished the integration of Hasher into the Cryptography package.
>> I didn't publish Monticello Configurations, but here's a list I would
>> publish if I did:
>>
>> Registers-Core-ul.1
>> CryptographyCore-ul.7
>> CryptographyHashing-ul.23
>> CryptographyASN1-ul.6
>> CryptographyRandom-ul.13
>> CryptographyCiphers-rww.16
>> CryptographySignatures-ul.17
>> CryptographyKeyExchange-rww.14
>> CryptographyArchive-ul.18
>> CryptographyX509-ul.15
>>
>> The Registers repository should be added to the configuration first, then
>> you can select Registers-Core and move it to the top of the list.
>> Regarding load order, I swapped CryptographyHashing with CryptographyASN1
>> because I added extension methods to the latter which extend classes of
>> the former.
>>
>> Since CryptographyHashing does not depend on CryptographyCore, those two
>> can be swapped as well if needed.
>>
>> For the tests, the configuration should contain the following packages:
>>
>> CryptographyASN1Tests-rww.1
>> CryptographyCoreTests-rww.1
>> CryptographyHashingTests-ul.2
>> CryptographyRandomTests-rww.1
>> CryptographyCiphersTests-rww.1
>> CryptographySignaturesTests-rww.1
>> CryptographyKeyExchangeTests-rww.1
>> CryptographyArchiveTests-rww.1
>> CryptographyX509Tests-rww.1
>> Registers-Tests-ul.1
>>
>>
>> Levente
>>
>> On Tue, 17 Mar 2020, Robert wrote:
>>
>>> Hi Levente,
>>>
>>> On 3/16/20 2:53 PM, Levente Uzonyi wrote:
>>>> Hi Robert,
>>>>
>>>> On Fri, 13 Mar 2020, Robert wrote:
>>>>
>>>>> On 3/12/20 7:49 PM, Levente Uzonyi wrote:
>>>>>
>>>>>> On Thu, 12 Mar 2020, Robert wrote:
>>>>>>
>>>>>>> Oh? I thought we discussed your package becoming the core solution, for HashFunctions. I was thinking you were going to rename all your classes back to no prefixes (except RGThirtyTwoBitRegister renamed to CryptoThirtyTwoBitRegister). And your hashFunction becomes the one in CryptographyCore. Your Registers and HashFunctions, become CryptographyHashing. Then I'll reset the dependencies to load yours.
>>>>>>>
>>>>>>> I got a little excited and released Pro Crypto v1.1.1, so with your code it would be ProCrypto v1.2.1.
>>>>>>>
>>>>>>> Did I misunderstand?
>>>>>> I proposed that about three times in these discussions but got no
>>>>>> response from you.
>>>>>> Since you started integrating SHA512 manually, my impression was that you
>>>>>> want to keep the exising classes.
>>>>>> If you want Hasher to be merged into Cryptography, then I can give it a
>>>>>> try on the weekend, but
>>>>> See this post: http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207872.html
>>>> I must have missed that post.
>>> I apologize for tacking after some other stuff, in the middle of a
>>> paragraph. That was limiting.
>>>
>>>>>> 1) HashFunction should stay in the same package as its subclasses. Why?
>>>>>> When another package doesn't use any of HashFunction's subclasses, it will
>>>>>> not use HashFunction. When another package needs a subclass, HashFunction
>>>>>> has to be present.
>>>>> No, I see this through the lens of reuse. there may be other packages that wish to extend hashFunction for their own use. AN example would be a SignalEncryption package. It has a HashFunction. So all the class roots belong in the Core package.
>>>> I couldn't find the SignalEncryption package anywhere.
>>> It is CryptoChallengeNumberFive. I had downloaded the java implementation of Signal and they have 2 special crypto algorithms, I think one a hashFunction and the other their Public/PrivateKeys. Thus I wrote for NumberFive SignalEncryption and SignalProtocol. The first would extend root classes in Core for the HashFunction and the Keys from KeyExchange. Oh! Yeah so we already use a subpackage to subclass Keys, I think. So why not Hashing? Okay, leave it in CryptographyHashing, I see now.
>>>
>>>> Is there a cryptographic hash function that is missing from Hasher?
>>> There could be as alternate packages extend it, such as our future
>>> SignalEncryption package.
>>>> If there is, can it be implemented as a subclass of HashFunction?
>>> Sure, just load Hashing.
>>>> If yes, why doesn't it belong to the same package as the other subclasses
>>>> of HashFunction?
>>> To promote broad development to extend as needed. Perhaps rolled over to
>>> Hashing later...Does that work?
>>>>>> 2) Registers should stay in a separate package. Why?
>>>>>> They can be used for other things. For example, I've got an unpublished
>>>>>> package containing various PRNG implementations using it.
>>>>> That's fine then, please put these classes also in the Core package.
>>>> I don't see how the CryptographyCore package would be a good place for
>>>> Registers.
>>> Okay, same deal as above then. But you are adding another package
>>> dependency. Easy enough to record in the ProCrypto-1-1-1 configuration map.
>>>
>>>
>>>> The PRNGs I implemented are unrelated to Cryptography.
>>> PRNGs? I had not heard. Do you want to roll those over to Random, please?
>>>
>>> K, r
>>>
>>>> Levente
>>>>
>>>>>> Does that work for you?
>>>>> Working our way to the garden.
>>>>>
>>>>> k, r
>>>>>
>>>>>> Levente
>>>>>>
>>>>>>> k, r
>>>>>>>
>>>>>>> On 3/12/20 7:26 PM, Levente Uzonyi wrote:
>>>>>>>
>>>>>>>> Hi Robert,
>>>>>>>>
>>>>>>>> On Wed, 11 Mar 2020, Robert wrote:
>>>>>>>>
>>>>>>>>> Dear Levente,
>>>>>>>>>
>>>>>>>>> I had to rework the Hashing package. It was recording change records that moved RGSixtyTwoBitRegisters before another to rename them CryptoSixtyTwoBitRegisters, CryptographyHashing was ripping them out of your Registers package and your code started failing. So I had to swap classes around packages and fix a few
>>>>>>>>> issues I had with SHA512 initialization, class & instance sides. I verified that they load in either order now and fully CryptoGreen. I setup dependencies through the latest Hashing package, 21. Here are the versions & how I load:
>>>>>>>>>
>>>>>>>>> Anything with your merge I can help with, Levente? I am excited for the day to announce ProCrypto v1.1.1, you know! ^,^ Milk it. I added a pointer to the plugins.
>>>>>>>> What merge do you mean?
>>>>>>>>
>>>>>>>> Levente
>>>>>>>>
>>>>>>>>> Installer ss      project: 'Registers';      install: 'Registers';      project: 'Hasher';      install: 'HAHasher-Core';      install: 'HAHasher-Tests'. Installer ss      project: 'Cryptography';      install: 'CryptographyPlugins';      install: 'CryptographyX509'.
>>>>>>>>>
>>>>>>>>> K, r
>>>>>>>>>
>>>>>>>>> ProCrypto packages and dependencies
>>>>>>>>> Package
>>>>>>>>> Size (kb)
>>>>>>>>> Dependencies
>>>>>>>>> Algorithms
>>>>>>>>> 1
>>>>>>>>> CryptographyCore-rww.5
>>>>>>>>> 18
>>>>>>>>> HMAC, CBC, CFB, CTR, OFB
>>>>>>>>> 2
>>>>>>>>> CryptographyASN1-rww.4
>>>>>>>>> 58
>>>>>>>>> ASN1Module, ASN1InputStream, ASN1OutputStream
>>>>>>>>> 3
>>>>>>>>> CryptographyHashing-rww.21
>>>>>>>>> 208
>>>>>>>>> CryptographyCore-rww.5
>>>>>>>>> ND2, MD4, MD5, SHA1, SHA256, SHA512
>>>>>>>>> 4
>>>>>>>>> CryptographyRandom-rww.11
>>>>>>>>> 21
>>>>>>>>> CryptographyHashing-rww.21
>>>>>>>>> RandomPool, PrimesFinder, Miller-Rabin, Fortuna, SecureRandom
>>>>>>>>> 5
>>>>>>>>> CryptographyCiphers-rww.15
>>>>>>>>> 81
>>>>>>>>> CryptographyRandom-rww.11 CryptographyASN1-rww.4
>>>>>>>>> ARC2, ARC4, DES, TripleDES, Blowfish, Rijndael
>>>>>>>>> 6
>>>>>>>>> CryptographySignatures-rww.15
>>>>>>>>> 37
>>>>>>>>> CryptographyCiphers-rww.15
>>>>>>>>> DSAKeyPairGenerator, ElGamalKeyPairGenerator, RSAKeyPairGenerator
>>>>>>>>> 7
>>>>>>>>> CryptographyKeyExchange-rww.13
>>>>>>>>> 5
>>>>>>>>> CryptographySignatures-rww.15
>>>>>>>>> Diffie-Hellman
>>>>>>>>> 8
>>>>>>>>> CryptographyArchive-rww.15
>>>>>>>>> 17
>>>>>>>>> CryptographyKeyExchange-rww.13
>>>>>>>>> PBKDF2WithHmacSHA1, PBKDF2WithHmacSHA256, PKCS12
>>>>>>>>> 9
>>>>>>>>> CryptographyX509-rww.13
>>>>>>>>> 34
>>>>>>>>> CryptographyArchive-rww.15
>>>>>>>>> X509Certificate, X509CertificateDerReader, DSAPrivateKeyFileReader, RSAPublicKeyFileGenerator, RSAPrivateKeyFileGenerator
>>>>>>>>> 479
>>>>>>>>> Loadable
>>>>>>>>> Unloadable
>>>>>>>>>
>>>>>>>>> On 3/10/20 8:31 PM, Robert wrote:
>>>>>>>>>
>>>>>>>>>         I should share with you that I can load Levente's work in parallel and there are no toes stepped on. And all of his tests are CryptoGreen, with & out. This is a good.
>>>>>>>>>
>>>>>>>>>         *message too large* kindly, rabbit
>>>>>>>>>
>>>>>>>>>         On 3/10/20 6:06 PM, Robert wrote:
>>>>>>>>>
>>>>>>>>>         Hi Levente,
>>>>>>>>>
>>>>>>>>>         Here is a new release of CryptographyHashing-rww.15. It is not linked up through dependencies, so load it after. It supports SHA512WithPrimitive and SHA512NonPrimitive and passes all tests. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>>>>>>>>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>>         Here is this working implementation of SHA512. The naming ought to be without prefix for th ecore classes. I have no problem whatsoever if we were to rebase your work as the defining implementation for all of thosew funcrtions, using one plugin. That's something wonderful. We should use you
>>>>>>>>>         hashFunction and rename without prefix. Tests separate, that's fashionable. We can figure out the mc config later.
>>>>>>>>>
>>>>>>>>>         publish your work on, then I will link your solution into dependencies.
>>>>>>>>>
>>>>>>>>>                                                                                                                                                   CryptographyHashing-ul.16
>>>>>>>>>
>>>>>>>>>                                                                                                                                              CryptographyHashing-rww.15 (Release)
>>>>>>>>>
>>>>>>>>>         File:
>>>>>>>>>         CryptographyHashing-rww.15.mcz
>>>>>>>>>         Author:
>>>>>>>>>         Robert Withers
>>>>>>>>>         Timestamp:
>>>>>>>>>         10 March 2020 9:57:39 pm
>>>>>>>>>         UUID:
>>>>>>>>>         b7df722e-ab05-4465-97ef-deeffb0212d0
>>>>>>>>>         Ancestors:
>>>>>>>>>         CryptographyHashing-rww.14
>>>>>>>>>         Dependencies:
>>>>>>>>>         CryptographyCore-rww.5
>>>>>>>>>         Release:
>>>>>>>>>         This is a release that can be read by anybody.
>>>>>>>>>         Message:
>>>>>>>>>         adapt to new #primCopyoubleWords:intoBytes:. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>>>>>>>>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>>>>>>>>> .
>>>>>>>>> rttyk, r
>>>>>>> --
>>>>> --
>>> --
>>> Kindly,
>>> Robert
>>>
>>>
>>>
> --
> Kindly,
> Robert
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: SHA512 squeak implementation?

Levente Uzonyi
In reply to this post by Squeak - Dev mailing list
Hi Robert,

On Fri, 20 Mar 2020, Robert wrote:

>
> Hey Levente, I just released new versions of CryptographyASN1-rww.7 and CryptographyHashing-rww.24, after moving all the #oidString methods to Hashing. Now, once again, ASN1 is independent of any other Cryptography classes,
> as it should be. ProCrypto-1-1-1 is updated.

I still do not consider CryptographyHashing the right package for those
methods, because they have no users in there. Perhaps
CryptographyKeyExchange is a better place for them.

>
> Cryptography is relying on other classes being available. String and ByteArray and such, fine that should all be common Smalltalk library. Some other classes Cryptography expects should not be. So our ThirtyTwoBitRegister use
> should change to RGThirtyTwoBitRegister, as long as it has all the expected protocol. This keeps it within the ProCrypto load boundaries. As well, use of SecureHashAlgorithm should change to SHA1. I was glad to see that MD5

There are plenty of extension methods which make it not easy to use the
register implementation of the Registers package. The worst offenders
(e.g.: #asByteArray , #asReverseInteger, #byte1:byte2:byte3:byte4:,
#byteAt:) assume some sort of endianness, but do not specify which, so it
would take some time to figure that out.

> checks for MD5Plugin, then if absent, checks for the CroquetPlugin. Are there any other specialized class use that could be withdrawn? Then to test on Pharo. I ran the PharoLauncher and grabbed a Pharo 8 64-bit image and
> added the repositories. As Installer is absent and Gofer fails to load a config map, I manually loaded Core and Hashing. In #initializeInitialHashValues, there was an Error: improper store into indexable object so Crypto
> fails in Pharo. I really have no intention of spending any more time in the Pharo environment, it is petty foreign to me. Others will need to ensure compatibility, unless we could automate it...

It made me curious why that failed, so I gave it a try. It turned out to
be a Pharo VM bug.

Levente

>
> K, r
>
> On 3/20/20 9:06 AM, Robert wrote:
>
> Hi Levente,
>
> I got tangled up in an image that had older Crypto code loaded, then I
> loaded the most recent and I had failing tests. So I went back to a
> virgin image and loaded into that. All tests pass Green. I am trying to
> track all the changes you made, for instance relying on the stock
> ThirtyTwoBitRegister>>#rotateLeftBy: and also using the native
> SecureHashAlgorithm>>#hashInteger:seed:. It is confusing. Cryptography
> was supposed to be complete and independent, but it relies on certain
> classes being present, with certain implementations. Given this, would
> ProCrypto be loadable in Pharo and pass green?
>
> One thing I recall you saying, I think you said you are using postscript
> initialization. Where could I find that?
>
> k, r
>
> On 3/18/20 7:50 AM, Levente Uzonyi wrote:
>
> Hi Robert,
>
> I've finished the integration of Hasher into the Cryptography package.
> I didn't publish Monticello Configurations, but here's a list I would
> publish if I did:
>
> Registers-Core-ul.1
> CryptographyCore-ul.7
> CryptographyHashing-ul.23
> CryptographyASN1-ul.6
> CryptographyRandom-ul.13
> CryptographyCiphers-rww.16
> CryptographySignatures-ul.17
> CryptographyKeyExchange-rww.14
> CryptographyArchive-ul.18
> CryptographyX509-ul.15
>
> The Registers repository should be added to the configuration first, then
> you can select Registers-Core and move it to the top of the list.
> Regarding load order, I swapped CryptographyHashing with CryptographyASN1
> because I added extension methods to the latter which extend classes of
> the former.
>
> Since CryptographyHashing does not depend on CryptographyCore, those two
> can be swapped as well if needed.
>
> For the tests, the configuration should contain the following packages:
>
> CryptographyASN1Tests-rww.1
> CryptographyCoreTests-rww.1
> CryptographyHashingTests-ul.2
> CryptographyRandomTests-rww.1
> CryptographyCiphersTests-rww.1
> CryptographySignaturesTests-rww.1
> CryptographyKeyExchangeTests-rww.1
> CryptographyArchiveTests-rww.1
> CryptographyX509Tests-rww.1
> Registers-Tests-ul.1
>
>
> Levente
>
> On Tue, 17 Mar 2020, Robert wrote:
>
> Hi Levente,
>
> On 3/16/20 2:53 PM, Levente Uzonyi wrote:
>
> Hi Robert,
>
> On Fri, 13 Mar 2020, Robert wrote:
>
> On 3/12/20 7:49 PM, Levente Uzonyi wrote:
>
> On Thu, 12 Mar 2020, Robert wrote:
>
> Oh? I thought we discussed your package becoming the core solution, for HashFunctions. I was thinking you were going to rename all your classes back to no prefixes (except RGThirtyTwoBitRegister renamed to CryptoThirtyTwoBitR
> egister). And your hashFunction becomes the one in CryptographyCore. Your Registers and HashFunctions, become CryptographyHashing. Then I'll reset the dependencies to load yours.
>
> I got a little excited and released Pro Crypto v1.1.1, so with your code it would be ProCrypto v1.2.1.
>
> Did I misunderstand?
>
> I proposed that about three times in these discussions but got no
> response from you.
> Since you started integrating SHA512 manually, my impression was that you
> want to keep the exising classes.
> If you want Hasher to be merged into Cryptography, then I can give it a
> try on the weekend, but
>
> See this post: http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207872.html
>
> I must have missed that post.
>
> I apologize for tacking after some other stuff, in the middle of a
> paragraph. That was limiting.
>
> 1) HashFunction should stay in the same package as its subclasses. Why?
> When another package doesn't use any of HashFunction's subclasses, it will
> not use HashFunction. When another package needs a subclass, HashFunction
> has to be present.
>
> No, I see this through the lens of reuse. there may be other packages that wish to extend hashFunction for their own use. AN example would be a SignalEncryption package. It has a HashFunction. So all the class roots belong in
>  the Core package.
>
> I couldn't find the SignalEncryption package anywhere.
>
> It is CryptoChallengeNumberFive. I had downloaded the java implementation of Signal and they have 2 special crypto algorithms, I think one a hashFunction and the other their Public/PrivateKeys. Thus I wrote for NumberFive Sig
> nalEncryption and SignalProtocol. The first would extend root classes in Core for the HashFunction and the Keys from KeyExchange. Oh! Yeah so we already use a subpackage to subclass Keys, I think. So why not Hashing? Okay, le
> ave it in CryptographyHashing, I see now.
>
> Is there a cryptographic hash function that is missing from Hasher?
>
> There could be as alternate packages extend it, such as our future
> SignalEncryption package.
>
> If there is, can it be implemented as a subclass of HashFunction?
>
> Sure, just load Hashing.
>
> If yes, why doesn't it belong to the same package as the other subclasses
> of HashFunction?
>
> To promote broad development to extend as needed. Perhaps rolled over to
> Hashing later...Does that work?
>
> 2) Registers should stay in a separate package. Why?
> They can be used for other things. For example, I've got an unpublished
> package containing various PRNG implementations using it.
>
> That's fine then, please put these classes also in the Core package.
>
> I don't see how the CryptographyCore package would be a good place for
> Registers.
>
> Okay, same deal as above then. But you are adding another package
> dependency. Easy enough to record in the ProCrypto-1-1-1 configuration map.
>
>
> The PRNGs I implemented are unrelated to Cryptography.
>
> PRNGs? I had not heard. Do you want to roll those over to Random, please?
>
> K, r
>
> Levente
>
> Does that work for you?
>
> Working our way to the garden.
>
> k, r
>
> Levente
>
> k, r
>
> On 3/12/20 7:26 PM, Levente Uzonyi wrote:
>
> Hi Robert,
>
> On Wed, 11 Mar 2020, Robert wrote:
>
> Dear Levente,
>
> I had to rework the Hashing package. It was recording change records that moved RGSixtyTwoBitRegisters before another to rename them CryptoSixtyTwoBitRegisters, CryptographyHashing was ripping them out of your Registers packa
> ge and your code started failing. So I had to swap classes around packages and fix a few
> issues I had with SHA512 initialization, class & instance sides. I verified that they load in either order now and fully CryptoGreen. I setup dependencies through the latest Hashing package, 21. Here are the versions & how I
> load:
>
> Anything with your merge I can help with, Levente? I am excited for the day to announce ProCrypto v1.1.1, you know! ^,^ Milk it. I added a pointer to the plugins.
>
> What merge do you mean?
>
> Levente
>
> Installer ss      project: 'Registers';      install: 'Registers';      project: 'Hasher';      install: 'HAHasher-Core';      install: 'HAHasher-Tests'. Installer ss      project: 'Cryptography';      install: 'CryptographyP
> lugins';      install: 'CryptographyX509'.
>
> K, r
>
> ProCrypto packages and dependencies
> Package
> Size (kb)
> Dependencies
> Algorithms
> 1
> CryptographyCore-rww.5
> 18
> HMAC, CBC, CFB, CTR, OFB
> 2
> CryptographyASN1-rww.4
> 58
> ASN1Module, ASN1InputStream, ASN1OutputStream
> 3
> CryptographyHashing-rww.21
> 208
> CryptographyCore-rww.5
> ND2, MD4, MD5, SHA1, SHA256, SHA512
> 4
> CryptographyRandom-rww.11
> 21
> CryptographyHashing-rww.21
> RandomPool, PrimesFinder, Miller-Rabin, Fortuna, SecureRandom
> 5
> CryptographyCiphers-rww.15
> 81
> CryptographyRandom-rww.11 CryptographyASN1-rww.4
> ARC2, ARC4, DES, TripleDES, Blowfish, Rijndael
> 6
> CryptographySignatures-rww.15
> 37
> CryptographyCiphers-rww.15
> DSAKeyPairGenerator, ElGamalKeyPairGenerator, RSAKeyPairGenerator
> 7
> CryptographyKeyExchange-rww.13
> 5
> CryptographySignatures-rww.15
> Diffie-Hellman
> 8
> CryptographyArchive-rww.15
> 17
> CryptographyKeyExchange-rww.13
> PBKDF2WithHmacSHA1, PBKDF2WithHmacSHA256, PKCS12
> 9
> CryptographyX509-rww.13
> 34
> CryptographyArchive-rww.15
> X509Certificate, X509CertificateDerReader, DSAPrivateKeyFileReader, RSAPublicKeyFileGenerator, RSAPrivateKeyFileGenerator
> 479
> Loadable
> Unloadable
>
> On 3/10/20 8:31 PM, Robert wrote:
>
>         I should share with you that I can load Levente's work in parallel and there are no toes stepped on. And all of his tests are CryptoGreen, with & out. This is a good.
>
>         *message too large* kindly, rabbit
>
>         On 3/10/20 6:06 PM, Robert wrote:
>
>         Hi Levente,
>
>         Here is a new release of CryptographyHashing-rww.15. It is not linked up through dependencies, so load it after. It supports SHA512WithPrimitive and SHA512NonPrimitive and passes all tests. CryptoGreen for SHA512, wit
> h the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
> .
>
>         Here is this working implementation of SHA512. The naming ought to be without prefix for th ecore classes. I have no problem whatsoever if we were to rebase your work as the defining implementation for all of thosew f
> uncrtions, using one plugin. That's something wonderful. We should use you
>         hashFunction and rename without prefix. Tests separate, that's fashionable. We can figure out the mc config later.
>
>         publish your work on, then I will link your solution into dependencies.
>
>                                                                                                                                                   CryptographyHashing-ul.16
>
>                                                                                                                                              CryptographyHashing-rww.15 (Release)
>
>         File:
>         CryptographyHashing-rww.15.mcz
>         Author:
>         Robert Withers
>         Timestamp:
>         10 March 2020 9:57:39 pm
>         UUID:
>         b7df722e-ab05-4465-97ef-deeffb0212d0
>         Ancestors:
>         CryptographyHashing-rww.14
>         Dependencies:
>         CryptographyCore-rww.5
>         Release:
>         This is a release that can be read by anybody.
>         Message:
>         adapt to new #primCopyoubleWords:intoBytes:. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
> .
> rttyk, r
>
> --
>
> --
>
> --
> Kindly,
> Robert
>
>
>
> --
> Kindly,
> Robert
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] SHA512 squeak implementation?

Squeak - Dev mailing list
In reply to this post by Levente Uzonyi

Hey Levente,

On 3/20/20 5:10 PM, Levente Uzonyi wrote:
Hi Robert,

On Fri, 20 Mar 2020, Robert wrote:

Hi Levente,

I got tangled up in an image that had older Crypto code loaded, then I
loaded the most recent and I had failing tests. So I went back to a
Interesting. I did my best to minimize such changes, but it's possible
that some objects held references to instances of obsolete classes, which
is not easy to fix.
Perhaps, I 86ed it and started over.

virgin image and loaded into that. All tests pass Green. I am trying to
track all the changes you made, for instance relying on the stock
ThirtyTwoBitRegister>>#rotateLeftBy: and also using the native
ThirtyTwoBitRegister was moved to Squeak 10+ years ago. Overriding a
method of it from an external package is not a good idea, as the internals
of the class may change over time.
I totally agree. I made that mistake with DateAndTime.
If you compare the two versions of #rotateLeftBy:, you'll find that
Squeak's version is faster.
Indeed.
 Now that we have a dependency on the Registers
package, it is possible to migrate all users of ThirtyTwoBitRegister to
those registers in the Registers package for an additional performance
boost.
Exactly what I was thinking!

SecureHashAlgorithm>>#hashInteger:seed:. It is confusing. Cryptography
It is confusing. The idea of using integers with any HashFunction is
simply wrong. HashFunctions are defined on ByteArray inputs, so using
integers means some kind of mapping between the two - aka hardcoded
endianness. Besides being confusing, this is a great source of performance
loss.
Then we should rewrite all senders of such to use the byteArray interface.
I did not want to rewrite the senders of #hashInteger:seed:, 
Oh, I think we should!
and I did not
intend to introduce the method because of the above, so I decided to do
the simplest thing and use SecureHashAlgorithm which is present in
Squeak core, provided by the same package ThirtyTwoBitRegister lives in.
I would rather not depend on that, even though in a system category; I'd like self-contained.

was supposed to be complete and independent, but it relies on certain
classes being present, with certain implementations. Given this, would
Well, define independend. The package relies on many classes not in the
Cryptography repository but the Squeak core (e.g. Integer, ByteArray,
ByteString, Stream, ThirtyTwoBitRegister, etc). The ThirtyTwoBitRegister
 and SecureHashAlgorithm I would rather not be dependent on.

ProCrypto be loadable in Pharo and pass green?
I do not use Pharo, but based on the way Pharo is developed, I doubt it
would load and work in any existing Pharo versions except for the most
ancient ones.
It used to load.
I think that even if you made it work in the latest Pharo version, it
would very likely stop working in the next release. So, if I were you, I
wouldn't bother.
I won't bother. There is poison there. Good to check your code, though.
 I wouldn't be surprised if they dropped Monticello
support in the next release, forcing you to use whatever packaging system
they come up with.
One Pharo enthusiast called Monticello config maps "and mcm config files is a thing of the stone age :wink:". I think not, I really like configuration maps. It gets the job done and from multiple repositories as well!

One thing I recall you saying, I think you said you are using postscript
initialization. Where could I find that?
Open the Monticello Browser, select a package, click on Scripts. A menu
will appear where you can choose which package script you would like to
edit. I added a postscript to CryptographyCiphers to reinitialize the
class variables of Rijndael.

Alright, this is the sort of code I like to see in a #startUp: method so I moved it and added Rijndael to the startUpList in #initialize. There is a CryptographyCiphers-rww.19 and the ProCrypto config is up to date with it.

K, r



Levente

k, r

On 3/18/20 7:50 AM, Levente Uzonyi wrote:
Hi Robert,

I've finished the integration of Hasher into the Cryptography package.
I didn't publish Monticello Configurations, but here's a list I would
publish if I did:

Registers-Core-ul.1
CryptographyCore-ul.7
CryptographyHashing-ul.23
CryptographyASN1-ul.6
CryptographyRandom-ul.13
CryptographyCiphers-rww.16
CryptographySignatures-ul.17
CryptographyKeyExchange-rww.14
CryptographyArchive-ul.18
CryptographyX509-ul.15

The Registers repository should be added to the configuration first, then
you can select Registers-Core and move it to the top of the list.
Regarding load order, I swapped CryptographyHashing with CryptographyASN1
because I added extension methods to the latter which extend classes of
the former.

Since CryptographyHashing does not depend on CryptographyCore, those two
can be swapped as well if needed.

For the tests, the configuration should contain the following packages:

CryptographyASN1Tests-rww.1
CryptographyCoreTests-rww.1
CryptographyHashingTests-ul.2
CryptographyRandomTests-rww.1
CryptographyCiphersTests-rww.1
CryptographySignaturesTests-rww.1
CryptographyKeyExchangeTests-rww.1
CryptographyArchiveTests-rww.1
CryptographyX509Tests-rww.1
Registers-Tests-ul.1


Levente

On Tue, 17 Mar 2020, Robert wrote:

Hi Levente,

On 3/16/20 2:53 PM, Levente Uzonyi wrote:
Hi Robert,

On Fri, 13 Mar 2020, Robert wrote:

On 3/12/20 7:49 PM, Levente Uzonyi wrote:

On Thu, 12 Mar 2020, Robert wrote:

Oh? I thought we discussed your package becoming the core solution, for HashFunctions. I was thinking you were going to rename all your classes back to no prefixes (except RGThirtyTwoBitRegister renamed to CryptoThirtyTwoBitRegister). And your hashFunction becomes the one in CryptographyCore. Your Registers and HashFunctions, become CryptographyHashing. Then I'll reset the dependencies to load yours.

I got a little excited and released Pro Crypto v1.1.1, so with your code it would be ProCrypto v1.2.1.

Did I misunderstand?
I proposed that about three times in these discussions but got no
response from you.
Since you started integrating SHA512 manually, my impression was that you
want to keep the exising classes.
If you want Hasher to be merged into Cryptography, then I can give it a
try on the weekend, but
See this post: http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207872.html
I must have missed that post.
I apologize for tacking after some other stuff, in the middle of a
paragraph. That was limiting.

1) HashFunction should stay in the same package as its subclasses. Why?
When another package doesn't use any of HashFunction's subclasses, it will
not use HashFunction. When another package needs a subclass, HashFunction
has to be present.
No, I see this through the lens of reuse. there may be other packages that wish to extend hashFunction for their own use. AN example would be a SignalEncryption package. It has a HashFunction. So all the class roots belong in the Core package.
I couldn't find the SignalEncryption package anywhere.
It is CryptoChallengeNumberFive. I had downloaded the java implementation of Signal and they have 2 special crypto algorithms, I think one a hashFunction and the other their Public/PrivateKeys. Thus I wrote for NumberFive SignalEncryption and SignalProtocol. The first would extend root classes in Core for the HashFunction and the Keys from KeyExchange. Oh! Yeah so we already use a subpackage to subclass Keys, I think. So why not Hashing? Okay, leave it in CryptographyHashing, I see now.

Is there a cryptographic hash function that is missing from Hasher?
There could be as alternate packages extend it, such as our future
SignalEncryption package.
If there is, can it be implemented as a subclass of HashFunction?
Sure, just load Hashing.
If yes, why doesn't it belong to the same package as the other subclasses
of HashFunction?
To promote broad development to extend as needed. Perhaps rolled over to
Hashing later...Does that work?
2) Registers should stay in a separate package. Why?
They can be used for other things. For example, I've got an unpublished
package containing various PRNG implementations using it.
That's fine then, please put these classes also in the Core package.
I don't see how the CryptographyCore package would be a good place for
Registers.
Okay, same deal as above then. But you are adding another package
dependency. Easy enough to record in the ProCrypto-1-1-1 configuration map.


The PRNGs I implemented are unrelated to Cryptography.
PRNGs? I had not heard. Do you want to roll those over to Random, please?

K, r

Levente

Does that work for you?
Working our way to the garden.

k, r

Levente

k, r

On 3/12/20 7:26 PM, Levente Uzonyi wrote:

Hi Robert,

On Wed, 11 Mar 2020, Robert wrote:

Dear Levente,

I had to rework the Hashing package. It was recording change records that moved RGSixtyTwoBitRegisters before another to rename them CryptoSixtyTwoBitRegisters, CryptographyHashing was ripping them out of your Registers package and your code started failing. So I had to swap classes around packages and fix a few
issues I had with SHA512 initialization, class & instance sides. I verified that they load in either order now and fully CryptoGreen. I setup dependencies through the latest Hashing package, 21. Here are the versions & how I load:

Anything with your merge I can help with, Levente? I am excited for the day to announce ProCrypto v1.1.1, you know! ^,^ Milk it. I added a pointer to the plugins.
What merge do you mean?

Levente

Installer ss      project: 'Registers';      install: 'Registers';      project: 'Hasher';      install: 'HAHasher-Core';      install: 'HAHasher-Tests'. Installer ss      project: 'Cryptography';      install: 'CryptographyPlugins';      install: 'CryptographyX509'.

K, r

ProCrypto packages and dependencies
Package
Size (kb)
Dependencies
Algorithms
1
CryptographyCore-rww.5
18
HMAC, CBC, CFB, CTR, OFB
2
CryptographyASN1-rww.4
58
ASN1Module, ASN1InputStream, ASN1OutputStream
3
CryptographyHashing-rww.21
208
CryptographyCore-rww.5
ND2, MD4, MD5, SHA1, SHA256, SHA512
4
CryptographyRandom-rww.11
21
CryptographyHashing-rww.21
RandomPool, PrimesFinder, Miller-Rabin, Fortuna, SecureRandom
5
CryptographyCiphers-rww.15
81
CryptographyRandom-rww.11 CryptographyASN1-rww.4
ARC2, ARC4, DES, TripleDES, Blowfish, Rijndael
6
CryptographySignatures-rww.15
37
CryptographyCiphers-rww.15
DSAKeyPairGenerator, ElGamalKeyPairGenerator, RSAKeyPairGenerator
7
CryptographyKeyExchange-rww.13
5
CryptographySignatures-rww.15
Diffie-Hellman
8
CryptographyArchive-rww.15
17
CryptographyKeyExchange-rww.13
PBKDF2WithHmacSHA1, PBKDF2WithHmacSHA256, PKCS12
9
CryptographyX509-rww.13
34
CryptographyArchive-rww.15
X509Certificate, X509CertificateDerReader, DSAPrivateKeyFileReader, RSAPublicKeyFileGenerator, RSAPrivateKeyFileGenerator
479
Loadable
Unloadable

On 3/10/20 8:31 PM, Robert wrote:

        I should share with you that I can load Levente's work in parallel and there are no toes stepped on. And all of his tests are CryptoGreen, with & out. This is a good.

        *message too large* kindly, rabbit

        On 3/10/20 6:06 PM, Robert wrote:

        Hi Levente,

        Here is a new release of CryptographyHashing-rww.15. It is not linked up through dependencies, so load it after. It supports SHA512WithPrimitive and SHA512NonPrimitive and passes all tests. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
.

        Here is this working implementation of SHA512. The naming ought to be without prefix for th ecore classes. I have no problem whatsoever if we were to rebase your work as the defining implementation for all of thosew funcrtions, using one plugin. That's something wonderful. We should use you
        hashFunction and rename without prefix. Tests separate, that's fashionable. We can figure out the mc config later.

        publish your work on, then I will link your solution into dependencies.

                                                                                                                                                  CryptographyHashing-ul.16

                                                                                                                                             CryptographyHashing-rww.15 (Release)

        File:
        CryptographyHashing-rww.15.mcz
        Author:
        Robert Withers
        Timestamp:
        10 March 2020 9:57:39 pm
        UUID:
        b7df722e-ab05-4465-97ef-deeffb0212d0
        Ancestors:
        CryptographyHashing-rww.14
        Dependencies:
        CryptographyCore-rww.5
        Release:
        This is a release that can be read by anybody.
        Message:
        adapt to new #primCopyoubleWords:intoBytes:. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
.
rttyk, r
--
--
--
Kindly,
Robert



--
Kindly,
Robert



-- 
Kindly,
Robert


Reply | Threaded
Open this post in threaded view
|

Re: SHA512 squeak implementation?

Squeak - Dev mailing list
In reply to this post by Levente Uzonyi
Hey Levente,

On 3/20/20 6:14 PM, Levente Uzonyi wrote:
> Hi Robert,
>
> On Fri, 20 Mar 2020, Robert wrote:
>
>> Hey Levente, I just released new versions of CryptographyASN1-rww.7 and CryptographyHashing-rww.24, after moving all the #oidString methods to Hashing. Now, once again, ASN1 is independent of any other Cryptography classes,
>> as it should be. ProCrypto-1-1-1 is updated.
> I still do not consider CryptographyHashing the right package for those
> methods, because they have no users in there. Perhaps
> CryptographyKeyExchange is a better place for them.

Well, here consider those oidStrings to be a part of the specification
of those HashFunctions. It is a part of their identity. Even though not
used immediately the stage has been set for when KeyExchange brings in
the #oid method. I think that this is exactly right and I wouldn't
change a thing.

>
>> Cryptography is relying on other classes being available. String and ByteArray and such, fine that should all be common Smalltalk library. Some other classes Cryptography expects should not be. So our ThirtyTwoBitRegister use
>> should change to RGThirtyTwoBitRegister, as long as it has all the expected protocol. This keeps it within the ProCrypto load boundaries. As well, use of SecureHashAlgorithm should change to SHA1. I was glad to see that MD5
> There are plenty of extension methods which make it not easy to use the
> register implementation of the Registers package. The worst offenders
> (e.g.: #asByteArray , #asReverseInteger, #byte1:byte2:byte3:byte4:,
> #byteAt:) assume some sort of endianness, but do not specify which, so it
> would take some time to figure that out.

I sort of understand what you are saying. I have never really worried
about endiannesss, so it is foreign to me. May I leave this in your
capable hands?

>
>> checks for MD5Plugin, then if absent, checks for the CroquetPlugin. Are there any other specialized class use that could be withdrawn? Then to test on Pharo. I ran the PharoLauncher and grabbed a Pharo 8 64-bit image and
>> added the repositories. As Installer is absent and Gofer fails to load a config map, I manually loaded Core and Hashing. In #initializeInitialHashValues, there was an Error: improper store into indexable object so Crypto
>> fails in Pharo. I really have no intention of spending any more time in the Pharo environment, it is petty foreign to me. Others will need to ensure compatibility, unless we could automate it...
> It made me curious why that failed, so I gave it a try. It turned out to
> be a Pharo VM bug.

HEH! That's a problem. meh...


K, r

>
> Levente
>
>> K, r
>>
>> On 3/20/20 9:06 AM, Robert wrote:
>>
>> Hi Levente,
>>
>> I got tangled up in an image that had older Crypto code loaded, then I
>> loaded the most recent and I had failing tests. So I went back to a
>> virgin image and loaded into that. All tests pass Green. I am trying to
>> track all the changes you made, for instance relying on the stock
>> ThirtyTwoBitRegister>>#rotateLeftBy: and also using the native
>> SecureHashAlgorithm>>#hashInteger:seed:. It is confusing. Cryptography
>> was supposed to be complete and independent, but it relies on certain
>> classes being present, with certain implementations. Given this, would
>> ProCrypto be loadable in Pharo and pass green?
>>
>> One thing I recall you saying, I think you said you are using postscript
>> initialization. Where could I find that?
>>
>> k, r
>>
>> On 3/18/20 7:50 AM, Levente Uzonyi wrote:
>>
>> Hi Robert,
>>
>> I've finished the integration of Hasher into the Cryptography package.
>> I didn't publish Monticello Configurations, but here's a list I would
>> publish if I did:
>>
>> Registers-Core-ul.1
>> CryptographyCore-ul.7
>> CryptographyHashing-ul.23
>> CryptographyASN1-ul.6
>> CryptographyRandom-ul.13
>> CryptographyCiphers-rww.16
>> CryptographySignatures-ul.17
>> CryptographyKeyExchange-rww.14
>> CryptographyArchive-ul.18
>> CryptographyX509-ul.15
>>
>> The Registers repository should be added to the configuration first, then
>> you can select Registers-Core and move it to the top of the list.
>> Regarding load order, I swapped CryptographyHashing with CryptographyASN1
>> because I added extension methods to the latter which extend classes of
>> the former.
>>
>> Since CryptographyHashing does not depend on CryptographyCore, those two
>> can be swapped as well if needed.
>>
>> For the tests, the configuration should contain the following packages:
>>
>> CryptographyASN1Tests-rww.1
>> CryptographyCoreTests-rww.1
>> CryptographyHashingTests-ul.2
>> CryptographyRandomTests-rww.1
>> CryptographyCiphersTests-rww.1
>> CryptographySignaturesTests-rww.1
>> CryptographyKeyExchangeTests-rww.1
>> CryptographyArchiveTests-rww.1
>> CryptographyX509Tests-rww.1
>> Registers-Tests-ul.1
>>
>>
>> Levente
>>
>> On Tue, 17 Mar 2020, Robert wrote:
>>
>> Hi Levente,
>>
>> On 3/16/20 2:53 PM, Levente Uzonyi wrote:
>>
>> Hi Robert,
>>
>> On Fri, 13 Mar 2020, Robert wrote:
>>
>> On 3/12/20 7:49 PM, Levente Uzonyi wrote:
>>
>> On Thu, 12 Mar 2020, Robert wrote:
>>
>> Oh? I thought we discussed your package becoming the core solution, for HashFunctions. I was thinking you were going to rename all your classes back to no prefixes (except RGThirtyTwoBitRegister renamed to CryptoThirtyTwoBitR
>> egister). And your hashFunction becomes the one in CryptographyCore. Your Registers and HashFunctions, become CryptographyHashing. Then I'll reset the dependencies to load yours.
>>
>> I got a little excited and released Pro Crypto v1.1.1, so with your code it would be ProCrypto v1.2.1.
>>
>> Did I misunderstand?
>>
>> I proposed that about three times in these discussions but got no
>> response from you.
>> Since you started integrating SHA512 manually, my impression was that you
>> want to keep the exising classes.
>> If you want Hasher to be merged into Cryptography, then I can give it a
>> try on the weekend, but
>>
>> See this post: http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207872.html
>>
>> I must have missed that post.
>>
>> I apologize for tacking after some other stuff, in the middle of a
>> paragraph. That was limiting.
>>
>> 1) HashFunction should stay in the same package as its subclasses. Why?
>> When another package doesn't use any of HashFunction's subclasses, it will
>> not use HashFunction. When another package needs a subclass, HashFunction
>> has to be present.
>>
>> No, I see this through the lens of reuse. there may be other packages that wish to extend hashFunction for their own use. AN example would be a SignalEncryption package. It has a HashFunction. So all the class roots belong in
>>   the Core package.
>>
>> I couldn't find the SignalEncryption package anywhere.
>>
>> It is CryptoChallengeNumberFive. I had downloaded the java implementation of Signal and they have 2 special crypto algorithms, I think one a hashFunction and the other their Public/PrivateKeys. Thus I wrote for NumberFive Sig
>> nalEncryption and SignalProtocol. The first would extend root classes in Core for the HashFunction and the Keys from KeyExchange. Oh! Yeah so we already use a subpackage to subclass Keys, I think. So why not Hashing? Okay, le
>> ave it in CryptographyHashing, I see now.
>>
>> Is there a cryptographic hash function that is missing from Hasher?
>>
>> There could be as alternate packages extend it, such as our future
>> SignalEncryption package.
>>
>> If there is, can it be implemented as a subclass of HashFunction?
>>
>> Sure, just load Hashing.
>>
>> If yes, why doesn't it belong to the same package as the other subclasses
>> of HashFunction?
>>
>> To promote broad development to extend as needed. Perhaps rolled over to
>> Hashing later...Does that work?
>>
>> 2) Registers should stay in a separate package. Why?
>> They can be used for other things. For example, I've got an unpublished
>> package containing various PRNG implementations using it.
>>
>> That's fine then, please put these classes also in the Core package.
>>
>> I don't see how the CryptographyCore package would be a good place for
>> Registers.
>>
>> Okay, same deal as above then. But you are adding another package
>> dependency. Easy enough to record in the ProCrypto-1-1-1 configuration map.
>>
>>
>> The PRNGs I implemented are unrelated to Cryptography.
>>
>> PRNGs? I had not heard. Do you want to roll those over to Random, please?
>>
>> K, r
>>
>> Levente
>>
>> Does that work for you?
>>
>> Working our way to the garden.
>>
>> k, r
>>
>> Levente
>>
>> k, r
>>
>> On 3/12/20 7:26 PM, Levente Uzonyi wrote:
>>
>> Hi Robert,
>>
>> On Wed, 11 Mar 2020, Robert wrote:
>>
>> Dear Levente,
>>
>> I had to rework the Hashing package. It was recording change records that moved RGSixtyTwoBitRegisters before another to rename them CryptoSixtyTwoBitRegisters, CryptographyHashing was ripping them out of your Registers packa
>> ge and your code started failing. So I had to swap classes around packages and fix a few
>> issues I had with SHA512 initialization, class & instance sides. I verified that they load in either order now and fully CryptoGreen. I setup dependencies through the latest Hashing package, 21. Here are the versions & how I
>> load:
>>
>> Anything with your merge I can help with, Levente? I am excited for the day to announce ProCrypto v1.1.1, you know! ^,^ Milk it. I added a pointer to the plugins.
>>
>> What merge do you mean?
>>
>> Levente
>>
>> Installer ss      project: 'Registers';      install: 'Registers';      project: 'Hasher';      install: 'HAHasher-Core';      install: 'HAHasher-Tests'. Installer ss      project: 'Cryptography';      install: 'CryptographyP
>> lugins';      install: 'CryptographyX509'.
>>
>> K, r
>>
>> ProCrypto packages and dependencies
>> Package
>> Size (kb)
>> Dependencies
>> Algorithms
>> 1
>> CryptographyCore-rww.5
>> 18
>> HMAC, CBC, CFB, CTR, OFB
>> 2
>> CryptographyASN1-rww.4
>> 58
>> ASN1Module, ASN1InputStream, ASN1OutputStream
>> 3
>> CryptographyHashing-rww.21
>> 208
>> CryptographyCore-rww.5
>> ND2, MD4, MD5, SHA1, SHA256, SHA512
>> 4
>> CryptographyRandom-rww.11
>> 21
>> CryptographyHashing-rww.21
>> RandomPool, PrimesFinder, Miller-Rabin, Fortuna, SecureRandom
>> 5
>> CryptographyCiphers-rww.15
>> 81
>> CryptographyRandom-rww.11 CryptographyASN1-rww.4
>> ARC2, ARC4, DES, TripleDES, Blowfish, Rijndael
>> 6
>> CryptographySignatures-rww.15
>> 37
>> CryptographyCiphers-rww.15
>> DSAKeyPairGenerator, ElGamalKeyPairGenerator, RSAKeyPairGenerator
>> 7
>> CryptographyKeyExchange-rww.13
>> 5
>> CryptographySignatures-rww.15
>> Diffie-Hellman
>> 8
>> CryptographyArchive-rww.15
>> 17
>> CryptographyKeyExchange-rww.13
>> PBKDF2WithHmacSHA1, PBKDF2WithHmacSHA256, PKCS12
>> 9
>> CryptographyX509-rww.13
>> 34
>> CryptographyArchive-rww.15
>> X509Certificate, X509CertificateDerReader, DSAPrivateKeyFileReader, RSAPublicKeyFileGenerator, RSAPrivateKeyFileGenerator
>> 479
>> Loadable
>> Unloadable
>>
>> On 3/10/20 8:31 PM, Robert wrote:
>>
>>          I should share with you that I can load Levente's work in parallel and there are no toes stepped on. And all of his tests are CryptoGreen, with & out. This is a good.
>>
>>          *message too large* kindly, rabbit
>>
>>          On 3/10/20 6:06 PM, Robert wrote:
>>
>>          Hi Levente,
>>
>>          Here is a new release of CryptographyHashing-rww.15. It is not linked up through dependencies, so load it after. It supports SHA512WithPrimitive and SHA512NonPrimitive and passes all tests. CryptoGreen for SHA512, wit
>> h the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>> .
>>
>>          Here is this working implementation of SHA512. The naming ought to be without prefix for th ecore classes. I have no problem whatsoever if we were to rebase your work as the defining implementation for all of thosew f
>> uncrtions, using one plugin. That's something wonderful. We should use you
>>          hashFunction and rename without prefix. Tests separate, that's fashionable. We can figure out the mc config later.
>>
>>          publish your work on, then I will link your solution into dependencies.
>>
>>                                                                                                                                                    CryptographyHashing-ul.16
>>
>>                                                                                                                                               CryptographyHashing-rww.15 (Release)
>>
>>          File:
>>          CryptographyHashing-rww.15.mcz
>>          Author:
>>          Robert Withers
>>          Timestamp:
>>          10 March 2020 9:57:39 pm
>>          UUID:
>>          b7df722e-ab05-4465-97ef-deeffb0212d0
>>          Ancestors:
>>          CryptographyHashing-rww.14
>>          Dependencies:
>>          CryptographyCore-rww.5
>>          Release:
>>          This is a release that can be read by anybody.
>>          Message:
>>          adapt to new #primCopyoubleWords:intoBytes:. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
>> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
>> .
>> rttyk, r
>>
>> --
>>
>> --
>>
>> --
>> Kindly,
>> Robert
>>
>>
>>
>> --
>> Kindly,
>> Robert
>>
>>
--
Kindly,
Robert



Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] SHA512 squeak implementation?

Levente Uzonyi
In reply to this post by Squeak - Dev mailing list
Hi Robert,

On Fri, 20 Mar 2020, Robert wrote:

>
> Hey Levente,
>
> On 3/20/20 5:10 PM, Levente Uzonyi wrote:
>
> Hi Robert,
>
> On Fri, 20 Mar 2020, Robert wrote:
>
> Hi Levente,
>
> I got tangled up in an image that had older Crypto code loaded, then I
> loaded the most recent and I had failing tests. So I went back to a
>
> Interesting. I did my best to minimize such changes, but it's possible
> that some objects held references to instances of obsolete classes, which
> is not easy to fix.
>
> Perhaps, I 86ed it and started over.
>
> virgin image and loaded into that. All tests pass Green. I am trying to
> track all the changes you made, for instance relying on the stock
> ThirtyTwoBitRegister>>#rotateLeftBy: and also using the native
>
> ThirtyTwoBitRegister was moved to Squeak 10+ years ago. Overriding a
> method of it from an external package is not a good idea, as the internals
> of the class may change over time.
>
> I totally agree. I made that mistake with DateAndTime.
>
> If you compare the two versions of #rotateLeftBy:, you'll find that
> Squeak's version is faster.
>
> Indeed.
>
>  Now that we have a dependency on the Registers
> package, it is possible to migrate all users of ThirtyTwoBitRegister to
> those registers in the Registers package for an additional performance
> boost.
>
> Exactly what I was thinking!
>
> SecureHashAlgorithm>>#hashInteger:seed:. It is confusing. Cryptography
>
> It is confusing. The idea of using integers with any HashFunction is
> simply wrong. HashFunctions are defined on ByteArray inputs, so using
> integers means some kind of mapping between the two - aka hardcoded
> endianness. Besides being confusing, this is a great source of performance
> loss.
>
> Then we should rewrite all senders of such to use the byteArray interface.
>
> I did not want to rewrite the senders of #hashInteger:seed:,
>
> Oh, I think we should!
>
> and I did not
> intend to introduce the method because of the above, so I decided to do
> the simplest thing and use SecureHashAlgorithm which is present in
> Squeak core, provided by the same package ThirtyTwoBitRegister lives in.
>
> I would rather not depend on that, even though in a system category; I'd like self-contained.

I wanted to finish the integration with minimal changes. Even the
ThirtyTwoBitRegister stuff was too much as it caused unexpected problems.
So, I agree that it's better to not depend on SecureHashAlgorithm, but it
takes time and effort to make such changes, so I took the easy path.

>
> was supposed to be complete and independent, but it relies on certain
> classes being present, with certain implementations. Given this, would
>
> Well, define independend. The package relies on many classes not in the
> Cryptography repository but the Squeak core (e.g. Integer, ByteArray,
> ByteString, Stream, ThirtyTwoBitRegister, etc). The ThirtyTwoBitRegister
>  and SecureHashAlgorithm I would rather not be dependent on.
>
> ProCrypto be loadable in Pharo and pass green?
>
> I do not use Pharo, but based on the way Pharo is developed, I doubt it
> would load and work in any existing Pharo versions except for the most
> ancient ones.
>
> It used to load.
>
> I think that even if you made it work in the latest Pharo version, it
> would very likely stop working in the next release. So, if I were you, I
> wouldn't bother.
>
> I won't bother. There is poison there. Good to check your code, though.
>
>  I wouldn't be surprised if they dropped Monticello
> support in the next release, forcing you to use whatever packaging system
> they come up with.
>
> One Pharo enthusiast called Monticello config maps "and mcm config files is a thing of the stone age :wink: ". I think not, I really like configuration maps. It gets the job done and from multiple repositories as well!
>
> One thing I recall you saying, I think you said you are using postscript
> initialization. Where could I find that?
>
> Open the Monticello Browser, select a package, click on Scripts. A menu
> will appear where you can choose which package script you would like to
> edit. I added a postscript to CryptographyCiphers to reinitialize the
> class variables of Rijndael.
>
> Alright, this is the sort of code I like to see in a #startUp: method so I moved it and added Rijndael to the startUpList in #initialize. There is a CryptographyCiphers-rww.19 and the ProCrypto config is up to date with it.

That's not the right place for such code. The package postscript is
executed when you load a version of the package that has a different
postscript than the previous version you had loaded into your image.
Things on the startup list are evaluated every single time you start your
image. There's no need to run this code that often.
That script simply fixes your image in the extremely rare case when you
loaded CryptographyCore-ul.7, then CryptographyCiphers-rww.16, and then
CryptographyCiphers-ul.17 in that order.


Levente

>
> K, r
>
>
>
> Levente
>
> k, r
>
> On 3/18/20 7:50 AM, Levente Uzonyi wrote:
>
> Hi Robert,
>
> I've finished the integration of Hasher into the Cryptography package.
> I didn't publish Monticello Configurations, but here's a list I would
> publish if I did:
>
> Registers-Core-ul.1
> CryptographyCore-ul.7
> CryptographyHashing-ul.23
> CryptographyASN1-ul.6
> CryptographyRandom-ul.13
> CryptographyCiphers-rww.16
> CryptographySignatures-ul.17
> CryptographyKeyExchange-rww.14
> CryptographyArchive-ul.18
> CryptographyX509-ul.15
>
> The Registers repository should be added to the configuration first, then
> you can select Registers-Core and move it to the top of the list.
> Regarding load order, I swapped CryptographyHashing with CryptographyASN1
> because I added extension methods to the latter which extend classes of
> the former.
>
> Since CryptographyHashing does not depend on CryptographyCore, those two
> can be swapped as well if needed.
>
> For the tests, the configuration should contain the following packages:
>
> CryptographyASN1Tests-rww.1
> CryptographyCoreTests-rww.1
> CryptographyHashingTests-ul.2
> CryptographyRandomTests-rww.1
> CryptographyCiphersTests-rww.1
> CryptographySignaturesTests-rww.1
> CryptographyKeyExchangeTests-rww.1
> CryptographyArchiveTests-rww.1
> CryptographyX509Tests-rww.1
> Registers-Tests-ul.1
>
>
> Levente
>
> On Tue, 17 Mar 2020, Robert wrote:
>
> Hi Levente,
>
> On 3/16/20 2:53 PM, Levente Uzonyi wrote:
>
> Hi Robert,
>
> On Fri, 13 Mar 2020, Robert wrote:
>
> On 3/12/20 7:49 PM, Levente Uzonyi wrote:
>
> On Thu, 12 Mar 2020, Robert wrote:
>
> Oh? I thought we discussed your package becoming the core solution, for HashFunctions. I was thinking you were going to rename all your classes back to no prefixes (except RGThirtyTwoBitRegister renamed to CryptoThirtyTwoBitR
> egister). And your hashFunction becomes the one in CryptographyCore. Your Registers and HashFunctions, become CryptographyHashing. Then I'll reset the dependencies to load yours.
>
> I got a little excited and released Pro Crypto v1.1.1, so with your code it would be ProCrypto v1.2.1.
>
> Did I misunderstand?
>
> I proposed that about three times in these discussions but got no
> response from you.
> Since you started integrating SHA512 manually, my impression was that you
> want to keep the exising classes.
> If you want Hasher to be merged into Cryptography, then I can give it a
> try on the weekend, but
>
> See this post: http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207872.html
>
> I must have missed that post.
>
> I apologize for tacking after some other stuff, in the middle of a
> paragraph. That was limiting.
>
> 1) HashFunction should stay in the same package as its subclasses. Why?
> When another package doesn't use any of HashFunction's subclasses, it will
> not use HashFunction. When another package needs a subclass, HashFunction
> has to be present.
>
> No, I see this through the lens of reuse. there may be other packages that wish to extend hashFunction for their own use. AN example would be a SignalEncryption package. It has a HashFunction. So all the class roots belong in
>  the Core package.
>
> I couldn't find the SignalEncryption package anywhere.
>
> It is CryptoChallengeNumberFive. I had downloaded the java implementation of Signal and they have 2 special crypto algorithms, I think one a hashFunction and the other their Public/PrivateKeys. Thus I wrote for NumberFive Sig
> nalEncryption and SignalProtocol. The first would extend root classes in Core for the HashFunction and the Keys from KeyExchange. Oh! Yeah so we already use a subpackage to subclass Keys, I think. So why not Hashing? Okay, le
> ave it in CryptographyHashing, I see now.
>
> Is there a cryptographic hash function that is missing from Hasher?
>
> There could be as alternate packages extend it, such as our future
> SignalEncryption package.
>
> If there is, can it be implemented as a subclass of HashFunction?
>
> Sure, just load Hashing.
>
> If yes, why doesn't it belong to the same package as the other subclasses
> of HashFunction?
>
> To promote broad development to extend as needed. Perhaps rolled over to
> Hashing later...Does that work?
>
> 2) Registers should stay in a separate package. Why?
> They can be used for other things. For example, I've got an unpublished
> package containing various PRNG implementations using it.
>
> That's fine then, please put these classes also in the Core package.
>
> I don't see how the CryptographyCore package would be a good place for
> Registers.
>
> Okay, same deal as above then. But you are adding another package
> dependency. Easy enough to record in the ProCrypto-1-1-1 configuration map.
>
>
> The PRNGs I implemented are unrelated to Cryptography.
>
> PRNGs? I had not heard. Do you want to roll those over to Random, please?
>
> K, r
>
> Levente
>
> Does that work for you?
>
> Working our way to the garden.
>
> k, r
>
> Levente
>
> k, r
>
> On 3/12/20 7:26 PM, Levente Uzonyi wrote:
>
> Hi Robert,
>
> On Wed, 11 Mar 2020, Robert wrote:
>
> Dear Levente,
>
> I had to rework the Hashing package. It was recording change records that moved RGSixtyTwoBitRegisters before another to rename them CryptoSixtyTwoBitRegisters, CryptographyHashing was ripping them out of your Registers packa
> ge and your code started failing. So I had to swap classes around packages and fix a few
> issues I had with SHA512 initialization, class & instance sides. I verified that they load in either order now and fully CryptoGreen. I setup dependencies through the latest Hashing package, 21. Here are the versions & how I
> load:
>
> Anything with your merge I can help with, Levente? I am excited for the day to announce ProCrypto v1.1.1, you know! ^,^ Milk it. I added a pointer to the plugins.
>
> What merge do you mean?
>
> Levente
>
> Installer ss      project: 'Registers';      install: 'Registers';      project: 'Hasher';      install: 'HAHasher-Core';      install: 'HAHasher-Tests'. Installer ss      project: 'Cryptography';      install: 'CryptographyP
> lugins';      install: 'CryptographyX509'.
>
> K, r
>
> ProCrypto packages and dependencies
> Package
> Size (kb)
> Dependencies
> Algorithms
> 1
> CryptographyCore-rww.5
> 18
> HMAC, CBC, CFB, CTR, OFB
> 2
> CryptographyASN1-rww.4
> 58
> ASN1Module, ASN1InputStream, ASN1OutputStream
> 3
> CryptographyHashing-rww.21
> 208
> CryptographyCore-rww.5
> ND2, MD4, MD5, SHA1, SHA256, SHA512
> 4
> CryptographyRandom-rww.11
> 21
> CryptographyHashing-rww.21
> RandomPool, PrimesFinder, Miller-Rabin, Fortuna, SecureRandom
> 5
> CryptographyCiphers-rww.15
> 81
> CryptographyRandom-rww.11 CryptographyASN1-rww.4
> ARC2, ARC4, DES, TripleDES, Blowfish, Rijndael
> 6
> CryptographySignatures-rww.15
> 37
> CryptographyCiphers-rww.15
> DSAKeyPairGenerator, ElGamalKeyPairGenerator, RSAKeyPairGenerator
> 7
> CryptographyKeyExchange-rww.13
> 5
> CryptographySignatures-rww.15
> Diffie-Hellman
> 8
> CryptographyArchive-rww.15
> 17
> CryptographyKeyExchange-rww.13
> PBKDF2WithHmacSHA1, PBKDF2WithHmacSHA256, PKCS12
> 9
> CryptographyX509-rww.13
> 34
> CryptographyArchive-rww.15
> X509Certificate, X509CertificateDerReader, DSAPrivateKeyFileReader, RSAPublicKeyFileGenerator, RSAPrivateKeyFileGenerator
> 479
> Loadable
> Unloadable
>
> On 3/10/20 8:31 PM, Robert wrote:
>
>         I should share with you that I can load Levente's work in parallel and there are no toes stepped on. And all of his tests are CryptoGreen, with & out. This is a good.
>
>         *message too large* kindly, rabbit
>
>         On 3/10/20 6:06 PM, Robert wrote:
>
>         Hi Levente,
>
>         Here is a new release of CryptographyHashing-rww.15. It is not linked up through dependencies, so load it after. It supports SHA512WithPrimitive and SHA512NonPrimitive and passes all tests. CryptoGreen for SHA512, wit
> h the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
> .
>
>         Here is this working implementation of SHA512. The naming ought to be without prefix for th ecore classes. I have no problem whatsoever if we were to rebase your work as the defining implementation for all of thosew f
> uncrtions, using one plugin. That's something wonderful. We should use you
>         hashFunction and rename without prefix. Tests separate, that's fashionable. We can figure out the mc config later.
>
>         publish your work on, then I will link your solution into dependencies.
>
>                                                                                                                                                   CryptographyHashing-ul.16
>
>                                                                                                                                              CryptographyHashing-rww.15 (Release)
>
>         File:
>         CryptographyHashing-rww.15.mcz
>         Author:
>         Robert Withers
>         Timestamp:
>         10 March 2020 9:57:39 pm
>         UUID:
>         b7df722e-ab05-4465-97ef-deeffb0212d0
>         Ancestors:
>         CryptographyHashing-rww.14
>         Dependencies:
>         CryptographyCore-rww.5
>         Release:
>         This is a release that can be read by anybody.
>         Message:
>         adapt to new #primCopyoubleWords:intoBytes:. CryptoGreen for SHA512, with the shiny, new SHA2Plugin and without. Find plugins here, for linux64x64:
> https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins
> .
> rttyk, r
>
> --
>
> --
>
> --
> Kindly,
> Robert
>
>
>
> --
> Kindly,
> Robert
>
>
>
> --
> Kindly,
> Robert
>
>

123