[squeak-dev] [Vm-dev] SHA512 squeak implementation?

Robert robert.withers at pm.me
Sat Mar 7 14:39:29 UTC 2020

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


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

More information about the Squeak-dev mailing list