Hey Nicolas,

To a very large extent, having these older dated functions available adds to the nature of Squeak Cryptography aas an encryption sandbox for educational experiences in studying cryptography. My ParrotTalk allows DES & TripleDES. Typically, I use AESCBC when running it. I think I am using SHA256.

I have just now folded in the Blowfish impplementation and subclassed uit from BlockCipher and adopted the BlockCipher protocol (#key:, #encryptBlock:, #decryptBlock:). All Blowfish tests call the old interface but that test class is present and green. New Blowfish tests of the BlockCipher protocol needs writing.

There is a newer version of Cryptography-v5.3-rww.119 with Blowfish included.

Having all these excellent variants of HashFunction, up to SHA512 would be a major addition to Cryptography, and I would need to change the settingsMap for ParrotTalk to include cipher and hash specifications. The forthcoming ParrotTalk v3.8 would adopt that, as well as naming and bridging for double encryption.

Kindly,
rabbit

Hi all,

For the agnostics like me, it's good to read some introduction like

https://www.garykessler.net/library/crypto.html#desmath

Relying only on obsolete technos like DESPlugin is a no go, it's not safe for years.

Even Triple-DES is also on its way to retirement, see for example

https://crypto.stackexchange.com/questions/51629/is-triple-des-still-considered-safe-to-use

MD5 also is not anymore a secure hash, it's just OK for checksum.

So having an uptodate Cryptography package is super important.

Robert, thank you for the initiative!

Le jeu. 5 mars 2020 à 19:11, Robert via Squeak-dev <[hidden email]> a écrit :

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?

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

Hi Jakob, Super! I was able to test adding a required package to ParrotTalk-rww.35, which auto-loads Cryptography-v5.3-rww.120.

I used this script, which I got working by specifying the full name with version. It auto-loads Cryptography.

Installer ss
    project: 'Cryptography';
    install: 'ParrotTalk-rww.35';
    yourself.

So now, in thinking about how to fragment Cryptography, using required packages and Installer scripts, here is a sample install script after fragmenting Cryptography.

Installer ss
    project: 'Cryptography';
    install: 'Cryptography-ciphers-rww.1';
    install: 'Cryptography-hash-rww.1';
    yourself.

These have Monticello required packages of ('Cryptography-base-rww.1' 'Cryptography-random-rww.1'). So all of it would load.

Now imagine loading SSL, in the future
Installer ss
    project: 'Cryptography';
    install: 'SSL-rww.50';
    yourself.

With dependencies, this will auto-load the following packages, after fragmentation.:
('Cryptography-base-rww.1'
 'Cryptography-random-rww.1'
 'Cryptography-ciphers-rww.1'
 'Cryptography-hash-rww.1'
 'Cryptography-ASN1-rww.1'
 'Cryptography-X509-rww.1'
 'ParrotTalk-rww.35')

Very well a solution! without using Metacello, which I do not like so much. A different package representation with lots of methods, like 'baseline' & ...., which gets stored separately. I actually spent a lot of time trying to get Tonal loaded in squeak to access the newer representations of github Smalltalk projects. I was unsuccessful.

Now the question becomes, which algorithms should be kept in the pro version?

Base: HashFunction, Registers, BlockCipher, RandomGenerator.

Random & Primes: KeyHolder, MillerRabin, PasswordSaltAndStretch, PBE, PrimesFinder, PrimesWheel, Fortuna, SecureRandom, RandomPool,

Hashes: MD5, SHA1, SHA256, SHA512.

Ciphers & Cipher Modes: DES, TripleDES, AES, Blowfish, CBC, CFB, CTR, OFB, PKCS5Or7PaddingMode...

ASN1: ASN1, ASN1-DefinitionModel, ASN1-Objects, ASN1-Types

X509: X509, X509-Extensions, X509-Readers

There may be lots of Extension methods in ASN1, for instance. These are all the class-side methods on various components of Cryptography that build ASN1Model, #initializeASN1Types. Like for RSA keys.

Comments?

Kindly,
rabbit

Robert via Squeak-dev <[hidden email]> schrieb am Sa., 7. März 2020, 15:39:

If only Monticello allowed for
dependencies,  

In fact it does. But it is never used so I suppose some piece is missing. 

What about Metacello? Most people use it for package dependency management nowadays.

Hi Nicolas,

I am very interested in learning more about the .mcm files, for MonticelloConfigurationMaps. I looked at the Monticeelo Configurations Browser but I got lost. Is there are good writeup on how to use it? I am intrigued about establishing dependencies this way to avoid cutting more versions to update the version of the required projects list. A config map for each package, with the dependencies set to the latest version of a dependent app, would be an excellent solution.

Thanks for your assistance!

K, r

Hi Robert,

there are several possible ways we can split the package and still load the whole thing.

One is Metacello as indicated by Jakob.

It shines if wanting to support multiple dialects (Gemstone, Pharo, Squeak), multiple versions of these dialects, and multiple release of our own packages, with slightly different recipes concerning the package assembly.

It also shines for gathering pacakges from several repositories or handling complex pre-requisites (like FFI, Registers etc...).

Be warned that Pharo users did already tend to fork everything which lies on a squeak* repo when they did use MC.

With the transition to git, I doubt you maintain anything for Pharo if not for yourself.

http://smalltalkhub.com/#!/~Cryptography/Cryptography/

https://github.com/zweidenker/Cryptography

By the way, I mistakenly uploaded two copies of Blowfish from Mariano Martinez Peck from smalltalkhub to http://www.squeaksource.com/Cryptography This was not necessary because they did not add anything to Blowfish-PaulDeBruicker.10.mcz.

Cuis never used MC, so naturally also tend to republish packages with their own format and own repository on github (mostly traditional .st chunk !).

https://github.com/garduino/Cuis-Smalltalk-Cryptography

Maybe https://github.com/KenDickey/Cuis-Smalltalk-Crypto-NaCl can be of interest too.

This is not a critic for Cuis and Pharo, but just to underline that cross-dialect is de facto not the criterion for selecting the packaging techno.

If all packages lie in the same repository and no pre-requisites is required, then there is also a much less powerful, but so much simpler option of using a MonticelloConfigurationMap.

It is a simple .mcm file listing the sequence of MC packages and version to load.

Packages are loaded in the order prescribed by the .mcm, and it's possible to load latest versions (highest version numbers).

There are tools in image for constructing and saving those .mcm

Le sam. 7 mars 2020 à 15:52, Jakob Reschke <[hidden email]> a écrit :

Robert via Squeak-dev <[hidden email]> schrieb am Sa., 7. März 2020, 15:39:

If only Monticello allowed for
dependencies,  

In fact it does. But it is never used so I suppose some piece is missing. 

What about Metacello? Most people use it for package dependency management nowadays.

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

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)

Hi Robert,

On Mon, 9 Mar 2020, Robert wrote:

Hi Levente,

On 3/9/20 5:14 PM, Levente Uzonyi wrote:

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.

Too many...I ride like a storm. Always have done so. I do hope that you
are not upset about my ripping SHA512 into a Crypto package. I feel very
strongly that a commitment by provider implementers doing Crypto to
subclass the Root classes: BlockCipher, HashFunction, BlockCipherMode,
and importantly adopt the common protocol inherited from those classes.
Then all Crypto implemeters will be able to easily interoperate.
Producing a lookup interface, much like Java's provider lookup, will be
a step we could take forwards with the shared and interoperable Crypto
library packages.

Are there any other "Crypo implementers" having hash functions? I doubt
it. So, I don't think we need anything like this. We need simple code
that works.

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.

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

As others wrote, this is not a good idea. You don't need those tests in
your production images.

a principle I try to follow. I suspect that maybe we could reduce the
tests, for SHA512, to a minimum. I will look into this. I also feel like
having a separate package with more robust testing is fair dinkum. I
think that would make a good solution here, where you could have a
couple of tests with the package and a separate Tests package for the
rest of them.

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.

Alright, how does this proposed approach grab you? I have a Hashing
package as a part of the ProCrypto offering. Dependencies are setup in
Monticello for Random to pull in that Hashing package, which has all our
traditional functions and now has SHA512, thanks to your offering. Here
is my further thought, If you interface with the common Crypto
superclasses (reclass HAHashFunction under HashFunction) and adopt the
Crypto protocol, your package as a provider package that could be loaded
side by side with Crypto's Hashing package. You would naturally extend
our offerings. This is my approach with SSL and SSH, as the port
progresses so slooowly, running as a specialization of the ParrotTalk
code, so it just fits in and works as an option.  I really see a
potential explosion of such solutions, if colleges and universities get
onboard. *dreaming about a better future*

Would this solution work well for you, Levente?

I did't clean up and restructure HashFunction in Hasher just to
reintroduce the stuff I removed/replaced.
Hasher is a replacement for the whole HashFunction hierarchy.

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.

As an alternate Crypto package, folks could choose your solution. This
way we can align our efforts together and mix and match solution
packages. That seems like the exact approach to managing Cryptography
library and how we conducts our affairs.

Our community is not large enough for that.

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.

I must tell you, that I am totally unfamiliar with the SHA256Plugin,
someone else wrote it over a decade ago! As such, I cannot evaluate the
quality of one over the other, so I will trust your views.

I wrote SHA256Plugin and MD5Plugin. I wrote the image side code for
SHA256, and I added plugin support to MD5 on the image side too.
Other than these hashes, the Cryptography package has SHA1, which is
buggy (try SHA1 hashMessage: ''), MD2 and MD4, which are obsolete, and
nothing else.
So, again, I suggest replacing the HashFunction hierarchy in Cryptography
with Hasher.


Levente

K, r

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

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.

kindly, rabbit

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

On 3/10/20 4:48 PM, Levente Uzonyi wrote:

Hi Robert,

On Mon, 9 Mar 2020, Robert wrote:

Hi Levente,

On 3/9/20 5:14 PM, Levente Uzonyi wrote:

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.

Too many...I ride like a storm. Always have done so. I do hope that you
are not upset about my ripping SHA512 into a Crypto package. I feel very
strongly that a commitment by provider implementers doing Crypto to
subclass the Root classes: BlockCipher, HashFunction, BlockCipherMode,
and importantly adopt the common protocol inherited from those classes.
Then all Crypto implemeters will be able to easily interoperate.
Producing a lookup interface, much like Java's provider lookup, will be
a step we could take forwards with the shared and interoperable Crypto
library packages.

Are there any other "Crypo implementers" having hash functions? I doubt
it. So, I don't think we need anything like this. We need simple code
that works.

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.

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

As others wrote, this is not a good idea. You don't need those tests in
your production images.

a principle I try to follow. I suspect that maybe we could reduce the
tests, for SHA512, to a minimum. I will look into this. I also feel like
having a separate package with more robust testing is fair dinkum. I
think that would make a good solution here, where you could have a
couple of tests with the package and a separate Tests package for the
rest of them.

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.

Alright, how does this proposed approach grab you? I have a Hashing
package as a part of the ProCrypto offering. Dependencies are setup in
Monticello for Random to pull in that Hashing package, which has all our
traditional functions and now has SHA512, thanks to your offering. Here
is my further thought, If you interface with the common Crypto
superclasses (reclass HAHashFunction under HashFunction) and adopt the
Crypto protocol, your package as a provider package that could be loaded
side by side with Crypto's Hashing package. You would naturally extend
our offerings. This is my approach with SSL and SSH, as the port
progresses so slooowly, running as a specialization of the ParrotTalk
code, so it just fits in and works as an option.  I really see a
potential explosion of such solutions, if colleges and universities get
onboard. *dreaming about a better future*

Would this solution work well for you, Levente?

I did't clean up and restructure HashFunction in Hasher just to
reintroduce the stuff I removed/replaced.
Hasher is a replacement for the whole HashFunction hierarchy.

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.

As an alternate Crypto package, folks could choose your solution. This
way we can align our efforts together and mix and match solution
packages. That seems like the exact approach to managing Cryptography
library and how we conducts our affairs.

Our community is not large enough for that.

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.

I must tell you, that I am totally unfamiliar with the SHA256Plugin,
someone else wrote it over a decade ago! As such, I cannot evaluate the
quality of one over the other, so I will trust your views.

I wrote SHA256Plugin and MD5Plugin. I wrote the image side code for
SHA256, and I added plugin support to MD5 on the image side too.
Other than these hashes, the Cryptography package has SHA1, which is
buggy (try SHA1 hashMessage: ''), MD2 and MD4, which are obsolete, and
nothing else.
So, again, I suggest replacing the HashFunction hierarchy in Cryptography
with Hasher.


Levente

K, r

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

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

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

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

--

--