<html><head></head><body>
<p>Hey Levente,<br/>
<br/>
I just released new versions of CryptographyASN1-rww.7 and
CryptographyHashing-rww.24, after moving all the #oidString
methods to Hashing. Now, once again, ASN1 is independent of any
other Cryptography classes, as it should be. <b>ProCrypto-1-1-1
is updated.</b><br/>
</p>
<p>Cryptography is relying on other classes being available. String
and ByteArray and such, fine that should all be common Smalltalk
library. <br/>
<br/>
Some other classes Cryptography expects should not be. So our
ThirtyTwoBitRegister use should change to RGThirtyTwoBitRegister,
as long as it has all the expected protocol. This keeps it within
the ProCrypto load boundaries. As well, use of SecureHashAlgorithm
should change to SHA1. I was glad to see that MD5 checks for
MD5Plugin, then if absent, checks for the CroquetPlugin. Are there
any other specialized class use that could be withdrawn?<br/>
<br/>
Then to test on Pharo. I ran the PharoLauncher and grabbed a Pharo
8 64-bit image and added the repositories. As Installer is absent
and Gofer fails to load a config map, I manually loaded Core and
Hashing. In #initializeInitialHashValues, there was an <b>Error:
improper store into indexable object</b> so Crypto fails in
Pharo.<br/>
<br/>
I really have no intention of spending any more time in the Pharo
environment, it is petty foreign to me. Others will need to ensure
compatibility, unless we could automate it...<br/>
</p>
<p>K, r<br/>
</p>
<div class="moz-cite-prefix">On 3/20/20 9:06 AM, Robert wrote:<br/>
</div>
<blockquote type="cite" cite="mid:05528ae5-1542-d9d7-bfbc-11c95d017af8@pm.me">
<pre class="moz-quote-pre" wrap="">Hi Levente,
I got tangled up in an image that had older Crypto code loaded, then I
loaded the most recent and I had failing tests. So I went back to a
virgin image and loaded into that. All tests pass Green. I am trying to
track all the changes you made, for instance relying on the stock
ThirtyTwoBitRegister>>#rotateLeftBy: and also using the native
SecureHashAlgorithm>>#hashInteger:seed:. It is confusing. Cryptography
was supposed to be complete and independent, but it relies on certain
classes being present, with certain implementations. Given this, would
ProCrypto be loadable in Pharo and pass green?
One thing I recall you saying, I think you said you are using postscript
initialization. Where could I find that?
k, r
On 3/18/20 7:50 AM, Levente Uzonyi wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi Robert,
I've finished the integration of Hasher into the Cryptography package.
I didn't publish Monticello Configurations, but here's a list I would
publish if I did:
Registers-Core-ul.1
CryptographyCore-ul.7
CryptographyHashing-ul.23
CryptographyASN1-ul.6
CryptographyRandom-ul.13
CryptographyCiphers-rww.16
CryptographySignatures-ul.17
CryptographyKeyExchange-rww.14
CryptographyArchive-ul.18
CryptographyX509-ul.15
The Registers repository should be added to the configuration first, then
you can select Registers-Core and move it to the top of the list.
Regarding load order, I swapped CryptographyHashing with CryptographyASN1
because I added extension methods to the latter which extend classes of
the former.
Since CryptographyHashing does not depend on CryptographyCore, those two
can be swapped as well if needed.
For the tests, the configuration should contain the following packages:
CryptographyASN1Tests-rww.1
CryptographyCoreTests-rww.1
CryptographyHashingTests-ul.2
CryptographyRandomTests-rww.1
CryptographyCiphersTests-rww.1
CryptographySignaturesTests-rww.1
CryptographyKeyExchangeTests-rww.1
CryptographyArchiveTests-rww.1
CryptographyX509Tests-rww.1
Registers-Tests-ul.1
Levente
On Tue, 17 Mar 2020, Robert wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi Levente,
On 3/16/20 2:53 PM, Levente Uzonyi wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi Robert,
On Fri, 13 Mar 2020, Robert wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 3/12/20 7:49 PM, Levente Uzonyi wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Thu, 12 Mar 2020, Robert wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">See this post: <a class="moz-txt-link-freetext" href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207872.html">http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207872.html</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I must have missed that post.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I apologize for tacking after some other stuff, in the middle of a
paragraph. That was limiting.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I couldn't find the SignalEncryption package anywhere.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">It is CryptoChallengeNumberFive. I had downloaded the java implementation of Signal and they have 2 special crypto algorithms, I think one a hashFunction and the other their Public/PrivateKeys. Thus I wrote for NumberFive SignalEncryption and SignalProtocol. The first would extend root classes in Core for the HashFunction and the Keys from KeyExchange. Oh! Yeah so we already use a subpackage to subclass Keys, I think. So why not Hashing? Okay, leave it in CryptographyHashing, I see now.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Is there a cryptographic hash function that is missing from Hasher?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">There could be as alternate packages extend it, such as our future
SignalEncryption package.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">If there is, can it be implemented as a subclass of HashFunction?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Sure, just load Hashing.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">If yes, why doesn't it belong to the same package as the other subclasses
of HashFunction?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">To promote broad development to extend as needed. Perhaps rolled over to
Hashing later...Does that work?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">That's fine then, please put these classes also in the Core package.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I don't see how the CryptographyCore package would be a good place for
Registers.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Okay, same deal as above then. But you are adding another package
dependency. Easy enough to record in the ProCrypto-1-1-1 configuration map.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">The PRNGs I implemented are unrelated to Cryptography.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">PRNGs? I had not heard. Do you want to roll those over to Random, please?
K, r
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Levente
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Does that work for you?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Working our way to the garden.
k, r
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Levente
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">k, r
On 3/12/20 7:26 PM, Levente Uzonyi wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi Robert,
On Wed, 11 Mar 2020, Robert wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">What merge do you mean?
Levente
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
<a class="moz-txt-link-freetext" href="https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins">https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins</a>
.
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:
<a class="moz-txt-link-freetext" href="https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins">https://www.dropbox.com/home/Callisto%20House/squeak-crypto-plugins</a>
.
rttyk, r
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">--
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">--
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">--
Kindly,
Robert
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
Kindly,
Robert</pre>
</body></html>