SHA512 squeak implementation?

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

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

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