Cryptography March 2020

cryptography@lists.squeakfoundation.org

4 participants
23 discussions

Re: [Cryptography Team] [squeak-dev] SHA512 squeak implementation?
by Robert 20 Mar '20

20 Mar '20

Hey Levente, On 3/20/20 6:14 PM, Levente Uzonyi wrote: > Hi Robert, > > On Fri, 20 Mar 2020, Robert wrote: > >> Hey Levente, 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. ProCrypto-1-1-1 is updated. > I still do not consider CryptographyHashing the right package for those > methods, because they have no users in there. Perhaps > CryptographyKeyExchange is a better place for them. Well, here consider those oidStrings to be a part of the specification of those HashFunctions. It is a part of their identity. Even though not used immediately the stage has been set for when KeyExchange brings in the #oid method. I think that this is exactly right and I wouldn't change a thing. > >> Cryptography is relying on other classes being available. String and ByteArray and such, fine that should all be common Smalltalk library. 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 > There are plenty of extension methods which make it not easy to use the > register implementation of the Registers package. The worst offenders > (e.g.: #asByteArray , #asReverseInteger, #byte1:byte2:byte3:byte4:, > #byteAt:) assume some sort of endianness, but do not specify which, so it > would take some time to figure that out. I sort of understand what you are saying. I have never really worried about endiannesss, so it is foreign to me. May I leave this in your capable hands? > >> checks for MD5Plugin, then if absent, checks for the CroquetPlugin. Are there any other specialized class use that could be withdrawn? 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 Error: improper store into indexable object so Crypto >> fails in Pharo. 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... > It made me curious why that failed, so I gave it a try. It turned out to > be a Pharo VM bug. HEH! That's a problem. meh... K, r > > Levente > >> K, r >> >> On 3/20/20 9:06 AM, 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 >> 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: >> >> 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.ht… >> >> 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

1 0

Re: [Cryptography Team] [Vm-dev] [squeak-dev] SHA512 squeak implementation?
by Robert 20 Mar '20

20 Mar '20

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: > 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 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.ht… >>> 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 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. >> >>> 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 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 >>>>>> -- >>>> -- >> -- >> Kindly, >> Robert >> >> >> -- Kindly, Robert

1 1

Re: [Cryptography Team] [Vm-dev] [squeak-dev] SHA512 squeak implementation?
by Robert 19 Mar '20

19 Mar '20

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

1 9

Re: [Cryptography Team] [Vm-dev] [squeak-dev] SHA512 squeak implementation?
by Robert 17 Mar '20

17 Mar '20

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 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.ht… > 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 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. > 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 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 >>>> -- >> -- -- Kindly, Robert

1 0

Re: [Cryptography Team] [SAA] ProCrypto 1.1.1 Five Challenges FOR all'y'all
by Robert 17 Mar '20

17 Mar '20

Hi Matthew, I apologize for misusing the ietf mailing list for my announcement and attempted marketing of the newly ported to Squeak 5.3, ProCrypto 1.1.1. I hoped to generate some interest and I thought the experience and knowledge of the folks on the ietf list were a welcome (susceptible?) audience for that. Still hoping for a wave of interest in Squeak to proceed. I will always hold onto my hope, in faith. I had posted some time ago with my proposal for v3.7 protocol of ParrotTalk. Here is the IETF document i generated: https://www.dropbox.com/s/r0q0bzm00h3sa00/draft-withers-parrot-talk-v36-v37…. It is based on the v3.7 ParrotTalk protocol as specified here: https://www.dropbox.com/s/jnmp2edkfdpn0wh/ParrotTalkFrameDesign-3.7.pdf?dl=0 ProCrypto 1.1.1 underlies ParrotTalk and used to build encrypted end to end communications. ParrotTalk in particular is designed in a LEGO like toolkit, for educational purposes in building your own protocols. I am porting my implementation of SSL onto the ThunkStack framework upon which rests ParrotTalk. Following that there is SSH to port. And getting Raven to work in the Galaxy Object Scenario: https://www.dropbox.com/s/5rxwno7heimimx2/The%20GalaxyObject%20scenario%20r… Sorry to bother, I will be sure to run by the chair in the future. Thank you for the understanding email. Kindly, Robert On 3/16/20 9:45 PM, Sergeant-at-Arms wrote: > Hi Robert, > > I am writing to you on behalf of the sergeant-at-arms (SAA) team for > ietf(a)ietf.org. This message has been vetted with others on the SAA team, > which is described in more detail at [1]. > > We are reaching out to you because of your recent message to > ietf(a)ietf.org [2]. The message includes unsolicited email as per [3]. > Please try to avoid sending these messages on ietf(a)ietf.org in the > future. You can reach the IETF chair at chair(a)ietf.org to seek approval > before sending. > > We consider this an initial suggestion. We do not believe your message > is part of a pattern of abuse that would warrant the restriction of your > posting rights. If a pattern emerges, we will consider temporarily > restricting your posting rights to ietf(a)ietf.org. > > Thanks, > Matthew Miller > > [1] https://www.ietf.org/how/lists/discussion/ > [2] https://mailarchive.ietf.org/arch/msg/ietf/V-ixHVo-uP67ine0TXZn5kawuxc/ > [3] https://tools.ietf.org/html/rfc3005 -- Kindly, Robert

1 0

your thoughts
by Robert 13 Mar '20

13 Mar '20

Hey all'y'all, I have a question. As I am marketing Crypto/Squeak as ProCrypto and pointing them to the Cryptography repository, would it make sense to rename all these Cryptography packages as ProCryptov1_1_1? --

3 13

Re: [Cryptography Team] [Vm-dev] [squeak-dev] SHA512 squeak implementation?
by Robert 13 Mar '20

13 Mar '20

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.ht… > 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 >> >> -- --

1 0

Re: [Cryptography Team] [Vm-dev] [squeak-dev] SHA512 squeak implementation?
by Robert 11 Mar '20

11 Mar '20

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](http://www.squeaksource.com/Cryptography/Cr… Author: [Robert Withers](http://www.squeaksource.com/@x4F_VDyHPTW39OmM/1dY6OOdf?24) Timestamp: 10 March 2020 9:57:39 pm UUID: b7df722e-ab05-4465-97ef-deeffb0212d0 Ancestors: [CryptographyHashing-rww.14](http://www.squeaksource.com/@x4F_VDyHPTW39OmM/1… Dependencies: [CryptographyCore-rww.5](http://www.squeaksource.com/@x4F_VDyHPTW39OmM/1dY6O… 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

1 3

the seventh plague
by Robert 11 Mar '20

11 Mar '20

It's coming. Here are some words about it, with a caution. Pardon but I must inform. 𝑫𝑶𝑵'𝑻 𝑻𝑨𝑳𝑲!!! STOP TALKING TO PEOPLE OR BEING AROUND PEOPLE WHO TALK. 𝑷𝑼𝑻 𝑫𝑶𝑾𝑵 𝒀𝑶𝑼𝑹 𝑺𝑾𝑶𝑹𝑫...people die by the sword. 𝐄𝐳𝐞𝐤𝐢𝐞𝐥 𝟑𝟓:7-9 7 Thus will I make mount Seir most desolate, and 𝒄𝒖𝒕 𝒐𝒇𝒇 𝒇𝒓𝒐𝒎 𝒊𝒕 𝒉𝒊𝒎 𝒕𝒉𝒂𝒕 𝒑𝒂𝒔𝒔𝒆𝒕𝒉 𝒐𝒖𝒕 𝒂𝒏𝒅 𝒉𝒊𝒎 𝒕𝒉𝒂𝒕 𝒓𝒆𝒕𝒖𝒓𝒏𝒆𝒕𝒉 [𝒒𝒖𝒂𝒓𝒂𝒏𝒕𝒊𝒏𝒆]. 8 And I will fill his mountains with his slain men: in thy hills, and in thy valleys, and in all thy rivers, shall they fall that are slain with the sword. 9 I will make thee perpetual desolations, and thy cities shall not return: and ye shall know that I am the Lord.

1 0

Re: [Cryptography Team] [squeak-dev] [Vm-dev] SHA512 squeak implementation?
by Chris Muller 10 Mar '20

10 Mar '20

> > On Mon, Mar 9, 2020 at 6:41 PM Robert via Squeak-dev < > squeak-dev(a)lists.squeakfoundation.org> 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

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography March 2020