Smalltalk › Squeak › Squeak VM

Re: [squeak-dev] SHA512 squeak implementation?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Robert Withers-2

Re: [squeak-dev] SHA512 squeak implementation?

Resending with correct recipient addresses. My van-dev was wrong.

Kindly,
Robert

On Thu, Mar 5, 2020 at 09:21, Robert via Squeak-dev <[hidden email]> wrote:

Hello everyone, I could have sworn that someone mentioned a squeak implementation of SHA512 that’s out there somewhere, but in looking back over all the emails I failed to find any mention of it.

If there is a SHA512 implementation anyone knows about, would you send me a link, please?

Kindly,
Robert

Levente Uzonyi

Re: [squeak-dev] SHA512 squeak implementation?

Hi Robert,

The mail you are looking for is here:
http://lists.squeakfoundation.org/pipermail/vm-dev/2020-March/032986.html

Since that email, to make life easier to those who have the Cryptography
package loaded in their images, I've uploaded another variant of
Hasher: HAHasher. It's the same as the Hasher package but all class
names are prefixed with HA.
To load that, evaluate:

Installer ss
project: 'Registers';
install: 'Registers';
project: 'Hasher';
install: 'HAHasher'.

And then you can write

HAHashFunction newSHA512 hashMessage: 'test'.

Levente

Levente Uzonyi

Re: [squeak-dev] SHA512 squeak implementation?

Hi Robert,

On Thu, 5 Mar 2020, Robert wrote:

> Oh yes, Levente, I recall speaking with you about it. I would like to
> make a proposal. Do you think you could fold all those hash functions,
> without the HA, into the Cryptography library? We have a HashFunction
> class in there, I do not know how different they may be in their public
> interface. I think it would be valuable to combine them. To support TLS
> 1.3, we would also need elliptical Diffie-Hellmans, I think.
>
> Levente, would you be willing to fold your work into Cryptography?

The reason why I created a separate package was that I found the
Cryptography package too bloated. Cryptographic hash functions seem to be
more commonly needed than ciphers, CSPRNGS, ASN1, etc.

It is possible to replace HashFunction and subclasses from Cryptography
with those in Hasher, but there would be some consequences:
1) Hasher doesn't have MD2 or MD4, but those are obsolete and broken. I
see little to no value rewriting them to satisfy Hasher's HashFunction
requirements, but it shouldn't be too hard to do that.
2) the way instances are created differ. I didn't want to do it the way
it's done in Cryptography's MD5, SHA1, SHA256, where class side #new may
return an object that is not of that class but a subclass. So, I added
instance creation methods to Hasher's HashFunction which return an
instance optimized for the current platform. So, a few methods need to
be changed in Cryptography to use the optimized hash functions.
3) Cryptography would depend on the Registers package.

Levente

>
> Kindly,
> Robert
>
> On 3/5/20 12:43 PM, Levente Uzonyi wrote:
>> Hi Robert,
>>
>> The mail you are looking for is here:
>> http://lists.squeakfoundation.org/pipermail/vm-dev/2020-March/032986.html
>>
>> Since that email, to make life easier to those who have the Cryptography
>> package loaded in their images, I've uploaded another variant of
>> Hasher: HAHasher. It's the same as the Hasher package but all class
>> names are prefixed with HA.
>> To load that, evaluate:
>>
>> Installer ss
>> project: 'Registers';
>> install: 'Registers';
>> project: 'Hasher';
>> install: 'HAHasher'.
>>
>> And then you can write
>>
>> HAHashFunction newSHA512 hashMessage: 'test'.
>>
>>
>> Levente
>
>

Robert Withers-2

Re: [squeak-dev] SHA512 squeak implementation?

Hi Levente,

Between this and your HashFunctions and my email in response to Jakob, I
have merged your work into Cryptography, published as:

Name: Cryptography-v5.3-rww.121
Author: rww
Time: 7 March 2020, 12:13:00.184627 pm
UUID: 2b69a713-eac3-4680-9d00-8104eea5a7da
Ancestors: Cryptography-v5.3-rww.120

Ported in the Registers & HAHasher packages and merged into
Cryptography. CryptoGreen!

I am now looking to recategorize to fragment Cryptography. Future work
should be released to the whole enchilada Cryptography package and
copied to the correct fragment. For example reorging, rebasing and
renaming HASHA512 to SHA512. As I fragment I will be adding required
packages. It seems like we are unable to specify a version to the
required package. Is this the case?

QUESTION TO CRYPTOGRAPHY TEAM: How do y'all feel about fragmenting
Cryptography? Pros? Cons?

---

Here is a profile of Cryptography and I see many leaves for the various
Registers, so there may be some optimization that could occur.

- 6250 tallies, 6325 msec.

**Leaves**
7.5% {476ms} RGSixtyFourBitRegister64>>loadFrom:
7.5% {472ms} Random>>nextBytes:into:startingAt:
6.8% {427ms} LargePositiveInteger(Integer)>>bitShift:
5.2% {328ms} [] SystemProgressMorph(Morph)>>updateDropShadowCache
4.4% {280ms} RGSixtyFourBitRegister64>>bitXor:
3.5% {220ms} Random>>generateStates
3.0% {192ms} RGThirtyTwoBitRegisterTest64(TestCase)>>timeout:after:
2.9% {181ms} RGSixtyFourBitRegister64>>+=
2.8% {178ms} HASHA256Inlined64>>processBuffer
2.7% {170ms} RGThirtyTwoBitRegister64>>loadFrom:
2.2% {140ms} RGThirtyTwoBitRegister64>>+=
2.1% {134ms} RGSixtyFourBitRegisterTest64(TestCase)>>assert:description:
2.1% {133ms} Point>>=
1.7% {109ms} RGThirtyTwoBitRegister64>>bitXor:
1.7% {107ms} SHA1>>hashStream:
1.5% {96ms} RGSixtyFourBitRegister64>>leftRotateBy:
1.4% {89ms} RGSixtyFourBitRegister64>>load:
1.4% {89ms} RGSixtyFourBitRegister32>>load:
1.4% {89ms} SmallInteger(Number)>>negative
1.4% {88ms} []
RGThirtyTwoBitRegisterTest64(RGRegisterTest)>>testLeftRotateBy
1.2% {77ms} LargePositiveInteger>>*
1.2% {76ms} GrafPort>>fillRoundRect:radius:
1.1% {70ms} GrafPort>>copyBits
1.1% {67ms} DisplayScreen(Form)>>depth

**Memory**
     old            +0 bytes
     young        +2,071,872 bytes
     used        +2,071,872 bytes
     free        -2,071,872 bytes

**GCs**
     full            1 totalling 74 ms (1.17% uptime), avg 74 ms
     incr            223 totalling 43 ms (0.7% uptime), avg 0.2 ms
     tenures        5,503 (avg 0 GCs/tenure)
     root table    0 overflows

K, r

On 3/7/20 9:39 AM, Robert wrote:

> Hi Levente,
>
> Thanks for your comments, I totally understand your views. I have some
> response, but the bottom line is that I or others in Cryptography
> (looking for new college age recruits...) will harvest some from your
> packages. It may only be SHA512 that we port over to round out the hash
> function offerings. I appreciate your willingness to allow us to do that.
>
> Your main argument is that Cryptography is too bloated, both with
> obsolete algorithms as well as combining the various facets into one
> package. The prime function of the Cryptography package is to have one
> package with all the Crypto we have, for single click loading. This also
> supports the Crypto toolbox/sandbox approach providing an educational
> environment to learning Crypto. Crypto is a learning package, as well as
> being fully functional.
>
> Cryptography, while larger than most packages, comes in at 300 kb, with
> the recent addition of Blowfish. That is loaded into an image file that
> is 47 MB! This means that Cryptography is just 0.6% the size of the
> image. This does not register to me as too bloated. But I see your
> perspective with outdated Crypto being present as well as the
> unnecessary add-ons, like X09 and ASN1; ciphers and hashes.
>
> When looking to do end to end encryption, we would load all of
> Cryptography (304 kb), ParrotTalk (93 kb), SSL (350 kb), Telnet (101 kb)
> & SSH (49 kb), for a total of 900 kb. That is only 1.9 % of the total
> image. Note that as I migrate SSL & SSH over onto the ParrotTalk
> framework, I expect to see the sizes of those two packages drastically
> reduce, through adoption of reuse.
>
> 1) having other hashes completes the scope of Crypto even if not utilized.
>
> 2) I look forward to diving deeper and understand your point here as
> well as see how your instances are created.
>
> 3) I would port Registers, as well.
>
> The absence of an ability to easily link dependencies provides a
> challenge to breaking Cryptography up. If only Monticello allowed for
> dependencies, It is doable to break up Cryptography.
>
> So let us imagine a future where Cryptography stabilizes again. Before
> declaring Crypto stable, I would include adding the Signal encryption
> needs into the Crypto package. This would include the double ratchet
> block cipher mode. As that point of stability is reached, we could
> preserve the total package for one click loading and also reduce and
> break it up into pieces. How would it sound to you if old obsolete
> functions & ciphers are removed, then the ASN1 and X509 is split off. At
> this point to your point let us consider splitting off the ciphers and
> the hash functions and the randomizers, leaving a Crypto base. Then a
> pro user would load Crypto-base, Randomizers, Hash Functions (No MD2...)
> and Ciphers (No DES...).
>
> I tried to use your example of use of the Installer to load Cryptography
> and it did not work. It could not find the versions.
>
> Installer ss
> project: 'Cryptography';
> install: 'Cryptography-v5.3'.
>
> If this could be made to work, then small scripts could load this split up Crypto pro solution. Optionally loading the different pieces.
>
> Installer ss
> project: 'Cryptography';
> install: 'Cryptography-base-v5.3';
> install: 'Cryptography-core-v5.3';
> install: 'Cryptography-hash-v5.3';
> install: 'Cryptography-cipher-v5.3';
> install: 'Cryptography-ASN1-v5.3';
> install: 'Cryptography-X509-v5.3';
> install: 'ParrotTalk';
> install: 'SSL';
> install: 'Telnet';
> install: 'SSH';
> install: 'Signal'.
>
> Kindly,
> Robert
>
>
>
> On 3/7/20 5:20 AM, Levente Uzonyi wrote:
>> Hi Robert,
>>
>> On Thu, 5 Mar 2020, Robert wrote:
>>
>>> Oh yes, Levente, I recall speaking with you about it. I would like to
>>> make a proposal. Do you think you could fold all those hash functions,
>>> without the HA, into the Cryptography library? We have a HashFunction
>>> class in there, I do not know how different they may be in their public
>>> interface. I think it would be valuable to combine them. To support TLS
>>> 1.3, we would also need elliptical Diffie-Hellmans, I think.
>>>
>>> Levente, would you be willing to fold your work into Cryptography?
>> The reason why I created a separate package was that I found the
>> Cryptography package too bloated. Cryptographic hash functions seem to be
>> more commonly needed than ciphers, CSPRNGS, ASN1, etc.
>>
>> It is possible to replace HashFunction and subclasses from Cryptography
>> with those in Hasher, but there would be some consequences:
>> 1) Hasher doesn't have MD2 or MD4, but those are obsolete and broken. I
>> see little to no value rewriting them to satisfy Hasher's HashFunction
>> requirements, but it shouldn't be too hard to do that.
>> 2) the way instances are created differ. I didn't want to do it the way
>> it's done in Cryptography's MD5, SHA1, SHA256, where class side #new may
>> return an object that is not of that class but a subclass. So, I added
>> instance creation methods to Hasher's HashFunction which return an
>> instance optimized for the current platform. So, a few methods need to
>> be changed in Cryptography to use the optimized hash functions.
>> 3) Cryptography would depend on the Registers package.
>>
>>
>> Levente
>>
>>> Kindly,
>>> Robert
>>>
>>> On 3/5/20 12:43 PM, Levente Uzonyi wrote:
>>>> Hi Robert,
>>>>
>>>> The mail you are looking for is here:
>>>> http://lists.squeakfoundation.org/pipermail/vm-dev/2020-March/032986.html
>>>>
>>>> Since that email, to make life easier to those who have the Cryptography
>>>> package loaded in their images, I've uploaded another variant of
>>>> Hasher: HAHasher. It's the same as the Hasher package but all class
>>>> names are prefixed with HA.
>>>> To load that, evaluate:
>>>>
>>>> Installer ss
>>>> project: 'Registers';
>>>> install: 'Registers';
>>>> project: 'Hasher';
>>>> install: 'HAHasher'.
>>>>
>>>> And then you can write
>>>>
>>>> HAHashFunction newSHA512 hashMessage: 'test'.
>>>>
>>>>
>>>> Levente

Levente Uzonyi

Re: [squeak-dev] SHA512 squeak implementation?

Hi Robert,

During the weekend I wrote a new plugin, SHA2Plugin, which covers all
cases of SHA2, therefore obsoletes SHA256Plugin. The code is available on
SqueakSource:
http://www.squeaksource.com/Cryptography/CryptographyPlugins-ul.18.mcz

I've updated the HAHasher package with hash variants using the new plugin
(and the old MD5 and SHA256 plugins), and split it up to Core and Tests,
so that the tests with the huge strings can be loaded optionally.
After building a VM with the new plugin, load:

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

However, SHA2Plugin is not complete yet. There's an issue with the VM's
code generator affecting 32-bit platforms, and I want to change the
methods swapping endianness before the plugin is added to the VMs.

On Sat, 7 Mar 2020, Robert wrote:

> Hi Levente,
>
> Between this and your HashFunctions and my email in response to Jakob, I
> have merged your work into Cryptography, published as:
>
> Name: Cryptography-v5.3-rww.121
> Author: rww
> Time: 7 March 2020, 12:13:00.184627 pm
> UUID: 2b69a713-eac3-4680-9d00-8104eea5a7da
> Ancestors: Cryptography-v5.3-rww.120
>
> Ported in the Registers & HAHasher packages and merged into
> Cryptography. CryptoGreen!

I suppose my point didn't get through. In my opinion, the code in
Hasher/HAHasher package should replace Cryptography's HashFunction and
subclasses. Why?
- it's a single package already (except for its dependency on Registers,
but I see no problem with Cryptography having dependencies)
- slimmer: fewer, simpler methods per class
- faster: uses the highly optimized Registers package when plugins are not
available; has plugin support for all implemented hashes (SHA2Plugin);
highly optimized in general
- way more hashes: supports all SHA-2 variants except for SHA-512/t for
arbitrary t other than 224, 256, 384, but that can be implemented as well
if there's need for it.
- has more comments and tests (e.g. check out SHA1 hashMessage: '' in
Cryptography)
- no bad tricks (e.g. check out SHA256 new class, or MD5 new class)

>
> I am now looking to recategorize to fragment Cryptography. Future work
> should be released to the whole enchilada Cryptography package and
> copied to the correct fragment. For example reorging, rebasing and
> renaming HASHA512 to SHA512. As I fragment I will be adding required
> packages. It seems like we are unable to specify a version to the
> required package. Is this the case?
>
> QUESTION TO CRYPTOGRAPHY TEAM: How do y'all feel about fragmenting
> Cryptography? Pros? Cons?
>
> ---
>
> Here is a profile of Cryptography and I see many leaves for the various
> Registers, so there may be some optimization that could occur.

Registers is a highly optimized package, which should perform better
than ThirtyTwoBitRegister, especially on 64-bit platforms. If you think
you can do even better in pure Smalltalk, I'm all ears.

Levente

>
> - 6250 tallies, 6325 msec.
>
> **Leaves**
> 7.5% {476ms} RGSixtyFourBitRegister64>>loadFrom:
> 7.5% {472ms} Random>>nextBytes:into:startingAt:
> 6.8% {427ms} LargePositiveInteger(Integer)>>bitShift:
> 5.2% {328ms} [] SystemProgressMorph(Morph)>>updateDropShadowCache
> 4.4% {280ms} RGSixtyFourBitRegister64>>bitXor:
> 3.5% {220ms} Random>>generateStates
> 3.0% {192ms} RGThirtyTwoBitRegisterTest64(TestCase)>>timeout:after:
> 2.9% {181ms} RGSixtyFourBitRegister64>>+=
> 2.8% {178ms} HASHA256Inlined64>>processBuffer
> 2.7% {170ms} RGThirtyTwoBitRegister64>>loadFrom:
> 2.2% {140ms} RGThirtyTwoBitRegister64>>+=
> 2.1% {134ms} RGSixtyFourBitRegisterTest64(TestCase)>>assert:description:
> 2.1% {133ms} Point>>=
> 1.7% {109ms} RGThirtyTwoBitRegister64>>bitXor:
> 1.7% {107ms} SHA1>>hashStream:
> 1.5% {96ms} RGSixtyFourBitRegister64>>leftRotateBy:
> 1.4% {89ms} RGSixtyFourBitRegister64>>load:
> 1.4% {89ms} RGSixtyFourBitRegister32>>load:
> 1.4% {89ms} SmallInteger(Number)>>negative
> 1.4% {88ms} []
> RGThirtyTwoBitRegisterTest64(RGRegisterTest)>>testLeftRotateBy
> 1.2% {77ms} LargePositiveInteger>>*
> 1.2% {76ms} GrafPort>>fillRoundRect:radius:
> 1.1% {70ms} GrafPort>>copyBits
> 1.1% {67ms} DisplayScreen(Form)>>depth
>
> **Memory**
>     old            +0 bytes
>     young        +2,071,872 bytes
>     used        +2,071,872 bytes
>     free        -2,071,872 bytes
>
> **GCs**
>     full            1 totalling 74 ms (1.17% uptime), avg 74 ms
>     incr            223 totalling 43 ms (0.7% uptime), avg 0.2 ms
>     tenures        5,503 (avg 0 GCs/tenure)
>     root table    0 overflows
>
> K, r
>
> On 3/7/20 9:39 AM, Robert wrote:
>> Hi Levente,
>>
>> Thanks for your comments, I totally understand your views. I have some
>> response, but the bottom line is that I or others in Cryptography
>> (looking for new college age recruits...) will harvest some from your
>> packages. It may only be SHA512 that we port over to round out the hash
>> function offerings. I appreciate your willingness to allow us to do that.
>>
>> Your main argument is that Cryptography is too bloated, both with
>> obsolete algorithms as well as combining the various facets into one
>> package. The prime function of the Cryptography package is to have one
>> package with all the Crypto we have, for single click loading. This also
>> supports the Crypto toolbox/sandbox approach providing an educational
>> environment to learning Crypto. Crypto is a learning package, as well as
>> being fully functional.
>>
>> Cryptography, while larger than most packages, comes in at 300 kb, with
>> the recent addition of Blowfish. That is loaded into an image file that
>> is 47 MB! This means that Cryptography is just 0.6% the size of the
>> image. This does not register to me as too bloated. But I see your
>> perspective with outdated Crypto being present as well as the
>> unnecessary add-ons, like X09 and ASN1; ciphers and hashes.
>>
>> When looking to do end to end encryption, we would load all of
>> Cryptography (304 kb), ParrotTalk (93 kb), SSL (350 kb), Telnet (101 kb)
>> & SSH (49 kb), for a total of 900 kb. That is only 1.9 % of the total
>> image. Note that as I migrate SSL & SSH over onto the ParrotTalk
>> framework, I expect to see the sizes of those two packages drastically
>> reduce, through adoption of reuse.
>>
>> 1) having other hashes completes the scope of Crypto even if not utilized.
>>
>> 2) I look forward to diving deeper and understand your point here as
>> well as see how your instances are created.
>>
>> 3) I would port Registers, as well.
>>
>> The absence of an ability to easily link dependencies provides a
>> challenge to breaking Cryptography up. If only Monticello allowed for
>> dependencies, It is doable to break up Cryptography.
>>
>> So let us imagine a future where Cryptography stabilizes again. Before
>> declaring Crypto stable, I would include adding the Signal encryption
>> needs into the Crypto package. This would include the double ratchet
>> block cipher mode. As that point of stability is reached, we could
>> preserve the total package for one click loading and also reduce and
>> break it up into pieces. How would it sound to you if old obsolete
>> functions & ciphers are removed, then the ASN1 and X509 is split off. At
>> this point to your point let us consider splitting off the ciphers and
>> the hash functions and the randomizers, leaving a Crypto base. Then a
>> pro user would load Crypto-base, Randomizers, Hash Functions (No MD2...)
>> and Ciphers (No DES...).
>>
>> I tried to use your example of use of the Installer to load Cryptography
>> and it did not work. It could not find the versions.
>>
>> Installer ss
>> project: 'Cryptography';
>> install: 'Cryptography-v5.3'.
>>
>> If this could be made to work, then small scripts could load this split up Crypto pro solution. Optionally loading the different pieces.
>>
>> Installer ss
>> project: 'Cryptography';
>> install: 'Cryptography-base-v5.3';
>> install: 'Cryptography-core-v5.3';
>> install: 'Cryptography-hash-v5.3';
>> install: 'Cryptography-cipher-v5.3';
>> install: 'Cryptography-ASN1-v5.3';
>> install: 'Cryptography-X509-v5.3';
>> install: 'ParrotTalk';
>> install: 'SSL';
>> install: 'Telnet';
>> install: 'SSH';
>> install: 'Signal'.
>>
>> Kindly,
>> Robert
>>
>>
>>
>> On 3/7/20 5:20 AM, Levente Uzonyi wrote:
>>> Hi Robert,
>>>
>>> On Thu, 5 Mar 2020, Robert wrote:
>>>
>>>> Oh yes, Levente, I recall speaking with you about it. I would like to
>>>> make a proposal. Do you think you could fold all those hash functions,
>>>> without the HA, into the Cryptography library? We have a HashFunction
>>>> class in there, I do not know how different they may be in their public
>>>> interface. I think it would be valuable to combine them. To support TLS
>>>> 1.3, we would also need elliptical Diffie-Hellmans, I think.
>>>>
>>>> Levente, would you be willing to fold your work into Cryptography?
>>> The reason why I created a separate package was that I found the
>>> Cryptography package too bloated. Cryptographic hash functions seem to be
>>> more commonly needed than ciphers, CSPRNGS, ASN1, etc.
>>>
>>> It is possible to replace HashFunction and subclasses from Cryptography
>>> with those in Hasher, but there would be some consequences:
>>> 1) Hasher doesn't have MD2 or MD4, but those are obsolete and broken. I
>>> see little to no value rewriting them to satisfy Hasher's HashFunction
>>> requirements, but it shouldn't be too hard to do that.
>>> 2) the way instances are created differ. I didn't want to do it the way
>>> it's done in Cryptography's MD5, SHA1, SHA256, where class side #new may
>>> return an object that is not of that class but a subclass. So, I added
>>> instance creation methods to Hasher's HashFunction which return an
>>> instance optimized for the current platform. So, a few methods need to
>>> be changed in Cryptography to use the optimized hash functions.
>>> 3) Cryptography would depend on the Registers package.
>>>
>>>
>>> Levente
>>>
>>>> Kindly,
>>>> Robert
>>>>
>>>> On 3/5/20 12:43 PM, Levente Uzonyi wrote:
>>>>> Hi Robert,
>>>>>
>>>>> The mail you are looking for is here:
>>>>> http://lists.squeakfoundation.org/pipermail/vm-dev/2020-March/032986.html
>>>>>
>>>>> Since that email, to make life easier to those who have the Cryptography
>>>>> package loaded in their images, I've uploaded another variant of
>>>>> Hasher: HAHasher. It's the same as the Hasher package but all class
>>>>> names are prefixed with HA.
>>>>> To load that, evaluate:
>>>>>
>>>>> Installer ss
>>>>> project: 'Registers';
>>>>> install: 'Registers';
>>>>> project: 'Hasher';
>>>>> install: 'HAHasher'.
>>>>>
>>>>> And then you can write
>>>>>
>>>>> HAHashFunction newSHA512 hashMessage: 'test'.
>>>>>
>>>>>
>>>>> Levente
>
>

Levente Uzonyi

Re: [squeak-dev] SHA512 squeak implementation?

Hi Robert,

On Mon, 9 Mar 2020, Robert wrote:

> Hi Levente,
>
> Have you seen my other posts on ProCrypto and the work I did to the
> Hashing package? After I ported your code, the size went up to 730 kb,
> while the rest of Cryptography was about 270 kb. So there was a lot of

Yes, I've seen your messages.

As I mentioned in my previous email, the size of the package is large
because of the test strings. I split the package up into Core and Tests.
If you have a look at the Hasher repository, you'll find that
HAHasher-Core.1 is 24.6 kB, while HAHasher-Tests.1 is 650kB.

By bloat I didn't mean that the size of the package is too large. I meant
that there are too many methods and classes are added to the environment
in a non-isolated way (no class prefixes, extension methods). And when you
only need a small chunk of those, you've got no way to load just that.

> bloat. As we already have solutions for SHA1 and SHA256, I really only
> needed SHA512. So I removed all the other classes and tests and ported

I think community needs come first, so having all SHA2 hash functions is
better than just having SHA512.

> SHA512 onto the HashFunction defined in CryptoCore. I removed all the
> RGThirtyTwoBitRegisters and I plan to move this ported SHA512 off of
> using a RGSixtyFourBitRegister, to eliminate that code. The size is

I see no value in doing that. The code is there, complete, ready for
integration.

> currently 204 kb for Hashing. I do not know how this plays with your
> plugin, but there should just be a SHA512Plugin.
>
> Thanks for digging in and writing your plugin! Can it be changed to just
> doing SHA512, easily?

It is designed to support all SHA2 functions. You may be able to remove
the SHA224/SHA256 stuff, but I see no value in that. This plugin is better
than SHA256Plugin.

Levente

>
> Kindly,
> Robert
>
> On 3/9/20 3:11 PM, Levente Uzonyi wrote:
>> Hi Robert,
>>
>> During the weekend I wrote a new plugin, SHA2Plugin, which covers all
>> cases of SHA2, therefore obsoletes SHA256Plugin. The code is available on
>> SqueakSource:
>> http://www.squeaksource.com/Cryptography/CryptographyPlugins-ul.18.mcz
>>
>> I've updated the HAHasher package with hash variants using the new plugin
>> (and the old MD5 and SHA256 plugins), and split it up to Core and Tests,
>> so that the tests with the huge strings can be loaded optionally.
>> After building a VM with the new plugin, load:
>>
>> Installer ss
>> project: 'Registers';
>> install: 'Registers';
>> project: 'Hasher';
>> install: 'HAHasher-Core';
>> install: 'HAHasher-Tests'.
>>
>>
>> However, SHA2Plugin is not complete yet. There's an issue with the VM's
>> code generator affecting 32-bit platforms, and I want to change the
>> methods swapping endianness before the plugin is added to the VMs.
>>
>> On Sat, 7 Mar 2020, Robert wrote:
>>
>>> Hi Levente,
>>>
>>> Between this and your HashFunctions and my email in response to Jakob, I
>>> have merged your work into Cryptography, published as:
>>>
>>> Name: Cryptography-v5.3-rww.121
>>> Author: rww
>>> Time: 7 March 2020, 12:13:00.184627 pm
>>> UUID: 2b69a713-eac3-4680-9d00-8104eea5a7da
>>> Ancestors: Cryptography-v5.3-rww.120
>>>
>>> Ported in the Registers & HAHasher packages and merged into
>>> Cryptography. CryptoGreen!
>> I suppose my point didn't get through. In my opinion, the code in
>> Hasher/HAHasher package should replace Cryptography's HashFunction and
>> subclasses. Why?
>> - it's a single package already (except for its dependency on Registers,
>> but I see no problem with Cryptography having dependencies)
>> - slimmer: fewer, simpler methods per class
>> - faster: uses the highly optimized Registers package when plugins are not
>> available; has plugin support for all implemented hashes (SHA2Plugin);
>> highly optimized in general
>> - way more hashes: supports all SHA-2 variants except for SHA-512/t for
>> arbitrary t other than 224, 256, 384, but that can be implemented as well
>> if there's need for it.
>> - has more comments and tests (e.g. check out SHA1 hashMessage: '' in
>> Cryptography)
>> - no bad tricks (e.g. check out SHA256 new class, or MD5 new class)
>>
>>> I am now looking to recategorize to fragment Cryptography. Future work
>>> should be released to the whole enchilada Cryptography package and
>>> copied to the correct fragment. For example reorging, rebasing and
>>> renaming HASHA512 to SHA512. As I fragment I will be adding required
>>> packages. It seems like we are unable to specify a version to the
>>> required package. Is this the case?
>>>
>>> QUESTION TO CRYPTOGRAPHY TEAM: How do y'all feel about fragmenting
>>> Cryptography? Pros? Cons?
>>>
>>> ---
>>>
>>> Here is a profile of Cryptography and I see many leaves for the various
>>> Registers, so there may be some optimization that could occur.
>> Registers is a highly optimized package, which should perform better
>> than ThirtyTwoBitRegister, especially on 64-bit platforms. If you think
>> you can do even better in pure Smalltalk, I'm all ears.
>>
>>
>> Levente
>>
>>> - 6250 tallies, 6325 msec.
>>>
>>> **Leaves**
>>> 7.5% {476ms} RGSixtyFourBitRegister64>>loadFrom:
>>> 7.5% {472ms} Random>>nextBytes:into:startingAt:
>>> 6.8% {427ms} LargePositiveInteger(Integer)>>bitShift:
>>> 5.2% {328ms} [] SystemProgressMorph(Morph)>>updateDropShadowCache
>>> 4.4% {280ms} RGSixtyFourBitRegister64>>bitXor:
>>> 3.5% {220ms} Random>>generateStates
>>> 3.0% {192ms} RGThirtyTwoBitRegisterTest64(TestCase)>>timeout:after:
>>> 2.9% {181ms} RGSixtyFourBitRegister64>>+=
>>> 2.8% {178ms} HASHA256Inlined64>>processBuffer
>>> 2.7% {170ms} RGThirtyTwoBitRegister64>>loadFrom:
>>> 2.2% {140ms} RGThirtyTwoBitRegister64>>+=
>>> 2.1% {134ms} RGSixtyFourBitRegisterTest64(TestCase)>>assert:description:
>>> 2.1% {133ms} Point>>=
>>> 1.7% {109ms} RGThirtyTwoBitRegister64>>bitXor:
>>> 1.7% {107ms} SHA1>>hashStream:
>>> 1.5% {96ms} RGSixtyFourBitRegister64>>leftRotateBy:
>>> 1.4% {89ms} RGSixtyFourBitRegister64>>load:
>>> 1.4% {89ms} RGSixtyFourBitRegister32>>load:
>>> 1.4% {89ms} SmallInteger(Number)>>negative
>>> 1.4% {88ms} []
>>> RGThirtyTwoBitRegisterTest64(RGRegisterTest)>>testLeftRotateBy
>>> 1.2% {77ms} LargePositiveInteger>>*
>>> 1.2% {76ms} GrafPort>>fillRoundRect:radius:
>>> 1.1% {70ms} GrafPort>>copyBits
>>> 1.1% {67ms} DisplayScreen(Form)>>depth
>>>
>>> **Memory**
>>>      old            +0 bytes
>>>      young        +2,071,872 bytes
>>>      used        +2,071,872 bytes
>>>      free        -2,071,872 bytes
>>>
>>> **GCs**
>>>      full            1 totalling 74 ms (1.17% uptime), avg 74 ms
>>>      incr            223 totalling 43 ms (0.7% uptime), avg 0.2 ms
>>>      tenures        5,503 (avg 0 GCs/tenure)
>>>      root table    0 overflows
>>>
>>> K, r
>>>
>>> On 3/7/20 9:39 AM, Robert wrote:
>>>> Hi Levente,
>>>>
>>>> Thanks for your comments, I totally understand your views. I have some
>>>> response, but the bottom line is that I or others in Cryptography
>>>> (looking for new college age recruits...) will harvest some from your
>>>> packages. It may only be SHA512 that we port over to round out the hash
>>>> function offerings. I appreciate your willingness to allow us to do that.
>>>>
>>>> Your main argument is that Cryptography is too bloated, both with
>>>> obsolete algorithms as well as combining the various facets into one
>>>> package. The prime function of the Cryptography package is to have one
>>>> package with all the Crypto we have, for single click loading. This also
>>>> supports the Crypto toolbox/sandbox approach providing an educational
>>>> environment to learning Crypto. Crypto is a learning package, as well as
>>>> being fully functional.
>>>>
>>>> Cryptography, while larger than most packages, comes in at 300 kb, with
>>>> the recent addition of Blowfish. That is loaded into an image file that
>>>> is 47 MB! This means that Cryptography is just 0.6% the size of the
>>>> image. This does not register to me as too bloated. But I see your
>>>> perspective with outdated Crypto being present as well as the
>>>> unnecessary add-ons, like X09 and ASN1; ciphers and hashes.
>>>>
>>>> When looking to do end to end encryption, we would load all of
>>>> Cryptography (304 kb), ParrotTalk (93 kb), SSL (350 kb), Telnet (101 kb)
>>>> & SSH (49 kb), for a total of 900 kb. That is only 1.9 % of the total
>>>> image. Note that as I migrate SSL & SSH over onto the ParrotTalk
>>>> framework, I expect to see the sizes of those two packages drastically
>>>> reduce, through adoption of reuse.
>>>>
>>>> 1) having other hashes completes the scope of Crypto even if not utilized.
>>>>
>>>> 2) I look forward to diving deeper and understand your point here as
>>>> well as see how your instances are created.
>>>>
>>>> 3) I would port Registers, as well.
>>>>
>>>> The absence of an ability to easily link dependencies provides a
>>>> challenge to breaking Cryptography up. If only Monticello allowed for
>>>> dependencies, It is doable to break up Cryptography.
>>>>
>>>> So let us imagine a future where Cryptography stabilizes again. Before
>>>> declaring Crypto stable, I would include adding the Signal encryption
>>>> needs into the Crypto package. This would include the double ratchet
>>>> block cipher mode. As that point of stability is reached, we could
>>>> preserve the total package for one click loading and also reduce and
>>>> break it up into pieces. How would it sound to you if old obsolete
>>>> functions & ciphers are removed, then the ASN1 and X509 is split off. At
>>>> this point to your point let us consider splitting off the ciphers and
>>>> the hash functions and the randomizers, leaving a Crypto base. Then a
>>>> pro user would load Crypto-base, Randomizers, Hash Functions (No MD2...)
>>>> and Ciphers (No DES...).
>>>>
>>>> I tried to use your example of use of the Installer to load Cryptography
>>>> and it did not work. It could not find the versions.
>>>>
>>>> Installer ss
>>>> project: 'Cryptography';
>>>> install: 'Cryptography-v5.3'.
>>>>
>>>> If this could be made to work, then small scripts could load this split up Crypto pro solution. Optionally loading the different pieces.
>>>>
>>>> Installer ss
>>>> project: 'Cryptography';
>>>> install: 'Cryptography-base-v5.3';
>>>> install: 'Cryptography-core-v5.3';
>>>> install: 'Cryptography-hash-v5.3';
>>>> install: 'Cryptography-cipher-v5.3';
>>>> install: 'Cryptography-ASN1-v5.3';
>>>> install: 'Cryptography-X509-v5.3';
>>>> install: 'ParrotTalk';
>>>> install: 'SSL';
>>>> install: 'Telnet';
>>>> install: 'SSH';
>>>> install: 'Signal'.
>>>>
>>>> Kindly,
>>>> Robert
>>>>
>>>>
>>>>
>>>> On 3/7/20 5:20 AM, Levente Uzonyi wrote:
>>>>> Hi Robert,
>>>>>
>>>>> On Thu, 5 Mar 2020, Robert wrote:
>>>>>
>>>>>> Oh yes, Levente, I recall speaking with you about it. I would like to
>>>>>> make a proposal. Do you think you could fold all those hash functions,
>>>>>> without the HA, into the Cryptography library? We have a HashFunction
>>>>>> class in there, I do not know how different they may be in their public
>>>>>> interface. I think it would be valuable to combine them. To support TLS
>>>>>> 1.3, we would also need elliptical Diffie-Hellmans, I think.
>>>>>>
>>>>>> Levente, would you be willing to fold your work into Cryptography?
>>>>> The reason why I created a separate package was that I found the
>>>>> Cryptography package too bloated. Cryptographic hash functions seem to be
>>>>> more commonly needed than ciphers, CSPRNGS, ASN1, etc.
>>>>>
>>>>> It is possible to replace HashFunction and subclasses from Cryptography
>>>>> with those in Hasher, but there would be some consequences:
>>>>> 1) Hasher doesn't have MD2 or MD4, but those are obsolete and broken. I
>>>>> see little to no value rewriting them to satisfy Hasher's HashFunction
>>>>> requirements, but it shouldn't be too hard to do that.
>>>>> 2) the way instances are created differ. I didn't want to do it the way
>>>>> it's done in Cryptography's MD5, SHA1, SHA256, where class side #new may
>>>>> return an object that is not of that class but a subclass. So, I added
>>>>> instance creation methods to Hasher's HashFunction which return an
>>>>> instance optimized for the current platform. So, a few methods need to
>>>>> be changed in Cryptography to use the optimized hash functions.
>>>>> 3) Cryptography would depend on the Registers package.
>>>>>
>>>>>
>>>>> Levente
>>>>>
>>>>>> Kindly,
>>>>>> Robert
>>>>>>
>>>>>> On 3/5/20 12:43 PM, Levente Uzonyi wrote:
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>> The mail you are looking for is here:
>>>>>>> http://lists.squeakfoundation.org/pipermail/vm-dev/2020-March/032986.html
>>>>>>>
>>>>>>> Since that email, to make life easier to those who have the Cryptography
>>>>>>> package loaded in their images, I've uploaded another variant of
>>>>>>> Hasher: HAHasher. It's the same as the Hasher package but all class
>>>>>>> names are prefixed with HA.
>>>>>>> To load that, evaluate:
>>>>>>>
>>>>>>> Installer ss
>>>>>>> project: 'Registers';
>>>>>>> install: 'Registers';
>>>>>>> project: 'Hasher';
>>>>>>> install: 'HAHasher'.
>>>>>>>
>>>>>>> And then you can write
>>>>>>>
>>>>>>> HAHashFunction newSHA512 hashMessage: 'test'.
>>>>>>>
>>>>>>>
>>>>>>> Levente
>>>
>
>

Chris Muller-3

Re: [squeak-dev] SHA512 squeak implementation?

On Mon, Mar 9, 2020 at 6:41 PM Robert via Squeak-dev <[hidden email]> wrote:
I see, alright, that's fair dinkum. I also feel strongly that a minimum
of tests be carried within the primary package for some code. If you
look at the Crypto packages, you'll see Hashing tests in hashing, Random
tests in Random, Cipher tests in Cipher. This way it is easy to run
them, off a CI server or what have you. The tests come with the code, is
a principle I try to follow.

Just my .02: I don't like the approach of putting tests with the code. I'm absolutely in favor of having as many tests as make sense, just please put them in a separate package. While your approach seems reasonable for people who are working interactively on code and want to make sure things stay working as they are making changes, it doesn't make sense when what you are going for is a minimal or server image where the existing code is just being used, not actively developed.

+1 Everyone has different configuration needs. As you know from your recent investigations on dependencies, it doesn't mean the ability to load (Core+Tests) has to require two clicks, it can still be just one. Including tests is not useful for the use-case of "verifying you're running the correct software" either, only an externally applied signature scheme can do that, since you have to verify the tests packages, too.

- Chris

Phil B

Re: [squeak-dev] SHA512 squeak implementation?

In reply to this post by Levente Uzonyi

Robert,

I'm not the Phil you're looking for. I only wrote my previous comment, not the plugin you're asking about...

Thanks,

Phil (a different one ;-)

On Tue, Mar 10, 2020 at 9:59 AM Robert <[hidden email]> wrote:

Hi Phil,

I would first note that I released a new CryptographyHashing package with some cleanups, especially using the common protocol for #processFinalBuffer:bitLength:. Added a couple of SHA512 tests. #CryptoGreen! I decided to not remove the Registers, nor alter any tests, there are only a few. I am however, interested in the plugin you wrote.

[plugin] I looked at it and please understand I think the classes you wrote and the framework is really quite nice. I am thrilled we found SHA512! It's impressive that your one plugin can handle a number of hash functions! Now all I need is to find the code that calls the SHA2Plugin. Levente, would you share that code, please?

On 3/9/20 6:56 PM, Phil B wrote:

Robert,

On Mon, Mar 9, 2020 at 6:41 PM Robert via Squeak-dev <[hidden email]> wrote:

I see, alright, that's fair dinkum. I also feel strongly that a minimum
of tests be carried within the primary package for some code. If you
look at the Crypto packages, you'll see Hashing tests in hashing, Random
tests in Random, Cipher tests in Cipher. This way it is easy to run
them, off a CI server or what have you. The tests come with the code, is
a principle I try to follow.

Just my .02: I don't like the approach of putting tests with the code. I'm absolutely in favor of having as many tests as make sense, just please put them in a separate package. While your approach seems reasonable for people who are working interactively on code and want to make sure things stay working as they are making changes, it doesn't make sense when what you are going for is a minimal or server image where the existing code is just being used, not actively developed.

My feeling, at this time, is that the tests size is a minimal increase to the size of unused code in an extremely large image, even if stripped. The issue is package management. I just split Crypto into 9 packages, a large number of dependent packages. I linked up dependencies. 8 of those packages have tests, so 8 more packages increases complexity, on the top of current complexity. Until package management can support test dependency, I would really rather leave it alone for now. I do see your perspective, I hope you see mine. So let's figure out how to do it best.

Thanks,

Phil

Kindly,
Robert

Robert Withers-2

Re: [squeak-dev] SHA512 squeak implementation?

In reply to this post by Levente Uzonyi

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.

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

ProCrypto.pdf (69K) Download Attachment

Levente Uzonyi

Re: [squeak-dev] SHA512 squeak implementation?

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

Robert Withers-2

Re: [squeak-dev] SHA512 squeak implementation?

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

Robert Withers-2

Re: [squeak-dev] SHA512 squeak implementation?

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

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.

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.

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

--

Phil B

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

In reply to this post by Robert Withers-2

Robert,

When posting to multiple lists, please just send one message to: all lists at once rather than separate messages per list. That way those of us subscribed to said lists won't get multiple copies of the message.

Thanks,

Phil

On Sun, Mar 15, 2020 at 4:44 PM Robert <[hidden email]> wrote:

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

Robert Withers-2

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

I don't really understand what you mean. I use thunderbird and it only allows me one recipient per To: line. It adds new lines for additional recipients. I will stop broadcasting to all lists. Keep it to the squeak-dev list as a marketing effort. Sorry for the multi messages. I also get them, but some say from me and others say from the list, so I delete the msgs inbound from a list and keep my author credentials. Sorry to flood y'all.

K, r

On 3/15/20 4:48 PM, Phil B wrote:

Robert,

When posting to multiple lists, please just send one message to: all lists at once rather than separate messages per list. That way those of us subscribed to said lists won't get multiple copies of the message.

Thanks,

Phil
On Sun, Mar 15, 2020 at 4:44 PM Robert <[hidden email]> wrote:
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

-- 
Kindly,
Robert