Cryptography March 2020

cryptography@lists.squeakfoundation.org

4 participants
23 discussions

Re: [Cryptography Team] DoubleWordArray broken in Pharo
by Robert 28 Mar '20

28 Mar '20

I just rolled it all back. hashing-rww.24 and HashingTests-rww.2 are once again the latest versions. k, r On 3/28/20 12:14 PM, Levente Uzonyi wrote: > Hi Robert, > > Well, I just asked you not to do it. It's not worth it. > > > Levente > > On Sat, 28 Mar 2020, Robert wrote: > >> Hi Levente, >> >> Squeak... >> >> I went ahead and split off the plugin hashing code and loaded with and without in Squeak. #CryptoGreen. This loads it all. The specific versions for Squeak are below the Pharo section. Note: if you loaded the hashing plugins support then remove it the HashFunction class>>#newHash methods are ripped away by the >> plugin code. So if you load hashing plugins then remove it you will need to reload the CryptographyHashing package for green. >> >> Installer ss project: 'Cryptography'; install: 'ProCrypto-1-1-1'; install: 'ProCryptoTests-1-1-1'; install: 'SSLLoader'. >> >> Pharo... >> >> Here is a script to load all packages in Pharo, without Hashing plugins support. Unfortunately there are many errors: red and yellow. :( Crypto used to run on Pharo. Sad. >> >> Gofer new squeaksource: 'Registers'; package: 'Registers-Core'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyCore'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyHashing'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyASN1'; load. Gofer new >> squeaksource: 'Cryptography'; package: 'CryptographyRandom'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyCiphers'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographySignatures'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyKeyExchange'; load. Gofer >> new squeaksource: 'Cryptography'; package: 'CryptographyArchive'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyX509'; load. Gofer new squeaksource: 'Registers'; package: 'Registers-Tests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyCoreTests'; load. Gofer new >> squeaksource: 'Cryptography'; package: 'CryptographyHashingTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyASN1Tests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyRandomTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyCiphersTests'; >> load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographySignaturesTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyKeyExchangeTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyArchiveTests'; load. Gofer new squeaksource: 'Cryptography'; package: >> 'CryptographyX509Tests'; load. Gofer new squeaksource: 'Cryptography'; package: 'ThunkStack'; load. Gofer new squeaksource: 'Cryptography'; package: 'ParrotTalk'; load. >> >> Squeak versions... >> >> Here are the versions, in Squeak, without SSL: Installer ss project: 'Registers'; install: 'Registers-Core-ul.1'. Installer ss project: 'Cryptography'; install: 'CryptographyCore-ul.7'; install: 'CryptographyHashing-rww.26'; install: 'CryptographyHashingPluginSupport-rww.1'; install: >> 'CryptographyASN1-rww.7'; install: 'CryptographyRandom-ul.13'; install: 'CryptographyCiphers-rww.20'; install: 'CryptographySignatures-ul.17'; install: 'CryptographyKeyExchange-rww.14'; install: 'CryptographyArchive-ul.18'; install: 'CryptographyX509-ul.15'. Installer ss project: >> 'Registers'; install: 'Registers-Tests-ul.1'. Installer ss project: 'Cryptography'; install: 'CryptographyCoreTests-rww.1'; install: 'CryptographyHashingTests-rww.3'; install: 'CryptographyHashingPluginSupportTests-rww.1'; install: 'CryptographyASN1Tests-rww.1'; install: >> 'CryptographyRandomTests-rww.1'; install: 'CryptographyCiphersTests-rww.1'; install: 'CryptographySignaturesTests-rww.1'; install: 'CryptographyKeyExchangeTests-rww.1'; install: 'CryptographyArchiveTests-rww.1'; install: 'CryptographyX509Tests-rww.1'. Installer ss project: 'Cryptography'; >> install: 'ThunkStack-rww.12'; install: 'ParrotTalk-rww.48'. >> >> On 3/28/20 11:54 AM, Levente Uzonyi wrote: >> >> Hi Robert, >> >> Please don't mess up the code just because of Pharo. They'll eventually >> fix DoubleWordArray, but that doesn't mean the code will work at all on >> Pharo. >> >> Levente >> >> On Sat, 28 Mar 2020, Robert wrote: >> >> Hey Levente, >> >> In order to get Crypto running in Pharo, I will split the >> HashingPluginSupport code into a separate package, which Pharo will not >> load, but Squeak will. >> >> k, r >> >> On 3/28/20 10:26 AM, Robert wrote: >> >> On 3/28/20 10:16 AM, Levente Uzonyi wrote: >> >> Hi Robert, >> >> No, it's not a VM bug. My analysis I sent to you earlier is correct. It's >> that in Pharo DoubleWordArray is a variableWordSubclass instead of a >> variableDoubleWordSubclass. The latter is not available in Pharo. >> Here's the link to the issue they created based on my analysis you sent >> to them: https://github.com/pharo-project/pharo/issues/5956 >> >> Alright, I shared this analysis with Pharo's Discord channel. I must >> have missed the discussion of the #variableDoubleWordSubclass:. >> >> In theory, yes, it would be possible to rewrite SHA-512 and its related >> hash functions to avoid using DoubleWordArray, but I see no value in doing >> that. >> >> The value would be Crypto operational in Pharo. And all that follows >> from that (ParrotTalk, SSL, SSH, Signal, Raven). Is it possible for you >> to make these changes, please? I see this as more likely than Pharo >> accommodating #variableDoubleWordSubclass:. And other Smalltalks... >> >> k, r >> >> Pharo simply failed to properly integrate DoubleWordArray. It's there but >> it's disfunctional. Just wait until they fix it. >> >> >> Levente >> >> P.S.: This is pretty much off topic on squeak-dev. >> >> On Sat, 28 Mar 2020, Robert wrote: >> >> Hey Levente, >> >> I dug a little deeper into the Pharo issue with Cryptography and it IS a VM issue, I think. Primitive 61 is failing in DoubleWordArray>>#at:put:. Pharo seems totally uninterested in fixing this so I wanted to ask you, is there any way Cryptography can avoid reliance on DoubleWordArray? >> >> Kindly, >> Robert >> >> >> -- >> Kindly, >> Robert >> >> >> >> -- >> Kindly, >> Robert >> >> -- Kindly, Robert

1 0

Re: [Cryptography Team] DoubleWordArray broken in Pharo
by Robert 28 Mar '20

28 Mar '20

I had already done the work when I saw your post here. I may rewind. On 3/28/20 12:14 PM, Levente Uzonyi wrote: > Hi Robert, > > Well, I just asked you not to do it. It's not worth it. > > > Levente > > On Sat, 28 Mar 2020, Robert wrote: > >> Hi Levente, >> >> Squeak... >> >> I went ahead and split off the plugin hashing code and loaded with and without in Squeak. #CryptoGreen. This loads it all. The specific versions for Squeak are below the Pharo section. Note: if you loaded the hashing plugins support then remove it the HashFunction class>>#newHash methods are ripped away by the >> plugin code. So if you load hashing plugins then remove it you will need to reload the CryptographyHashing package for green. >> >> Installer ss project: 'Cryptography'; install: 'ProCrypto-1-1-1'; install: 'ProCryptoTests-1-1-1'; install: 'SSLLoader'. >> >> Pharo... >> >> Here is a script to load all packages in Pharo, without Hashing plugins support. Unfortunately there are many errors: red and yellow. :( Crypto used to run on Pharo. Sad. >> >> Gofer new squeaksource: 'Registers'; package: 'Registers-Core'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyCore'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyHashing'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyASN1'; load. Gofer new >> squeaksource: 'Cryptography'; package: 'CryptographyRandom'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyCiphers'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographySignatures'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyKeyExchange'; load. Gofer >> new squeaksource: 'Cryptography'; package: 'CryptographyArchive'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyX509'; load. Gofer new squeaksource: 'Registers'; package: 'Registers-Tests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyCoreTests'; load. Gofer new >> squeaksource: 'Cryptography'; package: 'CryptographyHashingTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyASN1Tests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyRandomTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyCiphersTests'; >> load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographySignaturesTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyKeyExchangeTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyArchiveTests'; load. Gofer new squeaksource: 'Cryptography'; package: >> 'CryptographyX509Tests'; load. Gofer new squeaksource: 'Cryptography'; package: 'ThunkStack'; load. Gofer new squeaksource: 'Cryptography'; package: 'ParrotTalk'; load. >> >> Squeak versions... >> >> Here are the versions, in Squeak, without SSL: Installer ss project: 'Registers'; install: 'Registers-Core-ul.1'. Installer ss project: 'Cryptography'; install: 'CryptographyCore-ul.7'; install: 'CryptographyHashing-rww.26'; install: 'CryptographyHashingPluginSupport-rww.1'; install: >> 'CryptographyASN1-rww.7'; install: 'CryptographyRandom-ul.13'; install: 'CryptographyCiphers-rww.20'; install: 'CryptographySignatures-ul.17'; install: 'CryptographyKeyExchange-rww.14'; install: 'CryptographyArchive-ul.18'; install: 'CryptographyX509-ul.15'. Installer ss project: >> 'Registers'; install: 'Registers-Tests-ul.1'. Installer ss project: 'Cryptography'; install: 'CryptographyCoreTests-rww.1'; install: 'CryptographyHashingTests-rww.3'; install: 'CryptographyHashingPluginSupportTests-rww.1'; install: 'CryptographyASN1Tests-rww.1'; install: >> 'CryptographyRandomTests-rww.1'; install: 'CryptographyCiphersTests-rww.1'; install: 'CryptographySignaturesTests-rww.1'; install: 'CryptographyKeyExchangeTests-rww.1'; install: 'CryptographyArchiveTests-rww.1'; install: 'CryptographyX509Tests-rww.1'. Installer ss project: 'Cryptography'; >> install: 'ThunkStack-rww.12'; install: 'ParrotTalk-rww.48'. >> >> On 3/28/20 11:54 AM, Levente Uzonyi wrote: >> >> Hi Robert, >> >> Please don't mess up the code just because of Pharo. They'll eventually >> fix DoubleWordArray, but that doesn't mean the code will work at all on >> Pharo. >> >> Levente >> >> On Sat, 28 Mar 2020, Robert wrote: >> >> Hey Levente, >> >> In order to get Crypto running in Pharo, I will split the >> HashingPluginSupport code into a separate package, which Pharo will not >> load, but Squeak will. >> >> k, r >> >> On 3/28/20 10:26 AM, Robert wrote: >> >> On 3/28/20 10:16 AM, Levente Uzonyi wrote: >> >> Hi Robert, >> >> No, it's not a VM bug. My analysis I sent to you earlier is correct. It's >> that in Pharo DoubleWordArray is a variableWordSubclass instead of a >> variableDoubleWordSubclass. The latter is not available in Pharo. >> Here's the link to the issue they created based on my analysis you sent >> to them: https://github.com/pharo-project/pharo/issues/5956 >> >> Alright, I shared this analysis with Pharo's Discord channel. I must >> have missed the discussion of the #variableDoubleWordSubclass:. >> >> In theory, yes, it would be possible to rewrite SHA-512 and its related >> hash functions to avoid using DoubleWordArray, but I see no value in doing >> that. >> >> The value would be Crypto operational in Pharo. And all that follows >> from that (ParrotTalk, SSL, SSH, Signal, Raven). Is it possible for you >> to make these changes, please? I see this as more likely than Pharo >> accommodating #variableDoubleWordSubclass:. And other Smalltalks... >> >> k, r >> >> Pharo simply failed to properly integrate DoubleWordArray. It's there but >> it's disfunctional. Just wait until they fix it. >> >> >> Levente >> >> P.S.: This is pretty much off topic on squeak-dev. >> >> On Sat, 28 Mar 2020, Robert wrote: >> >> Hey Levente, >> >> I dug a little deeper into the Pharo issue with Cryptography and it IS a VM issue, I think. Primitive 61 is failing in DoubleWordArray>>#at:put:. Pharo seems totally uninterested in fixing this so I wanted to ask you, is there any way Cryptography can avoid reliance on DoubleWordArray? >> >> Kindly, >> Robert >> >> >> -- >> Kindly, >> Robert >> >> >> >> -- >> Kindly, >> Robert >> >> -- Kindly, Robert

1 0

Re: [Cryptography Team] DoubleWordArray broken in Pharo
by Robert 28 Mar '20

28 Mar '20

Thanks, I'll try it out. On 3/28/20 12:12 PM, Levente Uzonyi wrote: > Hi Robert > > On Sat, 28 Mar 2020, Robert wrote: > >> On 3/28/20 10:16 AM, Levente Uzonyi wrote: >>> Hi Robert, >>> >>> No, it's not a VM bug. My analysis I sent to you earlier is correct. It's >>> that in Pharo DoubleWordArray is a variableWordSubclass instead of a >>> variableDoubleWordSubclass. The latter is not available in Pharo. >>> Here's the link to the issue they created based on my analysis you sent >>> to them: https://github.com/pharo-project/pharo/issues/5956 >> Alright, I shared this analysis with Pharo's Discord channel. I must >> have missed the discussion of the #variableDoubleWordSubclass:. >> >>> In theory, yes, it would be possible to rewrite SHA-512 and its related >>> hash functions to avoid using DoubleWordArray, but I see no value in doing >>> that. >> The value would be Crypto operational in Pharo. And all that follows > Fixing DoubleWordArray in Pharo alone won't make the packages operational. > Pharo is a moving target and it keeps breaking stuff all the time. > >> from that (ParrotTalk, SSL, SSH, Signal, Raven). Is it possible for you >> to make these changes, please? I see this as more likely than Pharo >> accommodating #variableDoubleWordSubclass:. And other Smalltalks... > I've attached a changeset. If you load it before the Cryptography > packages, CryptographyHashing will work in Pharo 8 and in the current > Pharo 9 alpha. Some tests will fail, because random strings are generated > with the Random class, which is different in Squeak and Pharo but still, > everything will work. > > > Levente > >> k, r >> >>> Pharo simply failed to properly integrate DoubleWordArray. It's there but >>> it's disfunctional. Just wait until they fix it. >>> >>> >>> Levente >>> >>> P.S.: This is pretty much off topic on squeak-dev. >>> >>> On Sat, 28 Mar 2020, Robert wrote: >>> >>>> Hey Levente, >>>> >>>> I dug a little deeper into the Pharo issue with Cryptography and it IS a VM issue, I think. Primitive 61 is failing in DoubleWordArray>>#at:put:. Pharo seems totally uninterested in fixing this so I wanted to ask you, is there any way Cryptography can avoid reliance on DoubleWordArray? >>>> >>>> Kindly, >>>> Robert >>>> >>>> >> -- >> Kindly, >> Robert >> >> > > -- Kindly, Robert

1 0

Re: [Cryptography Team] DoubleWordArray broken in Pharo
by Robert 28 Mar '20

28 Mar '20

Hi Levente, Squeak... I went ahead and split off the plugin hashing code and loaded with and without in Squeak. #CryptoGreen. This loads it all. The specific versions for Squeak are below the Pharo section. Note: if you loaded the hashing plugins support then remove it the HashFunction class>>#newHash methods are ripped away by the plugin code. So if you load hashing plugins then remove it you will need to reload the CryptographyHashing package for green. Installer ss project: 'Cryptography'; install: 'ProCrypto-1-1-1'; install: 'ProCryptoTests-1-1-1'; install: 'SSLLoader'. Pharo... Here is a script to load all packages in Pharo, without Hashing plugins support. Unfortunately there are many errors: red and yellow. :( Crypto used to run on Pharo. Sad. Gofer new squeaksource: 'Registers'; package: 'Registers-Core'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyCore'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyHashing'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyASN1'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyRandom'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyCiphers'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographySignatures'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyKeyExchange'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyArchive'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyX509'; load. Gofer new squeaksource: 'Registers'; package: 'Registers-Tests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyCoreTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyHashingTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyASN1Tests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyRandomTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyCiphersTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographySignaturesTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyKeyExchangeTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyArchiveTests'; load. Gofer new squeaksource: 'Cryptography'; package: 'CryptographyX509Tests'; load. Gofer new squeaksource: 'Cryptography'; package: 'ThunkStack'; load. Gofer new squeaksource: 'Cryptography'; package: 'ParrotTalk'; load. Squeak versions... Here are the versions, in Squeak, without SSL: Installer ss project: 'Registers'; install: 'Registers-Core-ul.1'. Installer ss project: 'Cryptography'; install: 'CryptographyCore-ul.7'; install: 'CryptographyHashing-rww.26'; install: 'CryptographyHashingPluginSupport-rww.1'; install: 'CryptographyASN1-rww.7'; install: 'CryptographyRandom-ul.13'; install: 'CryptographyCiphers-rww.20'; install: 'CryptographySignatures-ul.17'; install: 'CryptographyKeyExchange-rww.14'; install: 'CryptographyArchive-ul.18'; install: 'CryptographyX509-ul.15'. Installer ss project: 'Registers'; install: 'Registers-Tests-ul.1'. Installer ss project: 'Cryptography'; install: 'CryptographyCoreTests-rww.1'; install: 'CryptographyHashingTests-rww.3'; install: 'CryptographyHashingPluginSupportTests-rww.1'; install: 'CryptographyASN1Tests-rww.1'; install: 'CryptographyRandomTests-rww.1'; install: 'CryptographyCiphersTests-rww.1'; install: 'CryptographySignaturesTests-rww.1'; install: 'CryptographyKeyExchangeTests-rww.1'; install: 'CryptographyArchiveTests-rww.1'; install: 'CryptographyX509Tests-rww.1'. Installer ss project: 'Cryptography'; install: 'ThunkStack-rww.12'; install: 'ParrotTalk-rww.48'. On 3/28/20 11:54 AM, Levente Uzonyi wrote: > Hi Robert, > > Please don't mess up the code just because of Pharo. They'll eventually > fix DoubleWordArray, but that doesn't mean the code will work at all on > Pharo. > > Levente > > On Sat, 28 Mar 2020, Robert wrote: > >> Hey Levente, >> >> In order to get Crypto running in Pharo, I will split the >> HashingPluginSupport code into a separate package, which Pharo will not >> load, but Squeak will. >> >> k, r >> >> On 3/28/20 10:26 AM, Robert wrote: >> >>> On 3/28/20 10:16 AM, Levente Uzonyi wrote: >>> >>>> Hi Robert, >>>> >>>> No, it's not a VM bug. My analysis I sent to you earlier is correct. It's >>>> that in Pharo DoubleWordArray is a variableWordSubclass instead of a >>>> variableDoubleWordSubclass. The latter is not available in Pharo. >>>> Here's the link to the issue they created based on my analysis you sent >>>> to them: >>>> https://github.com/pharo-project/pharo/issues/5956 >>> >>> Alright, I shared this analysis with Pharo's Discord channel. I must >>> have missed the discussion of the #variableDoubleWordSubclass:. >>> >>>> In theory, yes, it would be possible to rewrite SHA-512 and its related >>>> hash functions to avoid using DoubleWordArray, but I see no value in doing >>>> that. >>> >>> The value would be Crypto operational in Pharo. And all that follows >>> from that (ParrotTalk, SSL, SSH, Signal, Raven). Is it possible for you >>> to make these changes, please? I see this as more likely than Pharo >>> accommodating #variableDoubleWordSubclass:. And other Smalltalks... >>> >>> k, r >>> >>>> Pharo simply failed to properly integrate DoubleWordArray. It's there but >>>> it's disfunctional. Just wait until they fix it. >>>> >>>> Levente >>>> >>>> P.S.: This is pretty much off topic on squeak-dev. >>>> >>>> On Sat, 28 Mar 2020, Robert wrote: >>>> >>>>> Hey Levente, >>>>> >>>>> I dug a little deeper into the Pharo issue with Cryptography and it IS a VM issue, I think. Primitive 61 is failing in DoubleWordArray>>#at:put:. Pharo seems totally uninterested in fixing this so I wanted to ask you, is there any way Cryptography can avoid reliance on DoubleWordArray? >>>>> >>>>> Kindly, >>>>> Robert >> >> -- >> Kindly, >> Robert -- Kindly, Robert

1 0

Re: [Cryptography Team] DoubleWordArray broken in Pharo
by Robert 28 Mar '20

28 Mar '20

On 3/28/20 10:16 AM, Levente Uzonyi wrote: > Hi Robert, > > No, it's not a VM bug. My analysis I sent to you earlier is correct. It's > that in Pharo DoubleWordArray is a variableWordSubclass instead of a > variableDoubleWordSubclass. The latter is not available in Pharo. > Here's the link to the issue they created based on my analysis you sent > to them: https://github.com/pharo-project/pharo/issues/5956 Alright, I shared this analysis with Pharo's Discord channel. I must have missed the discussion of the #variableDoubleWordSubclass:. > In theory, yes, it would be possible to rewrite SHA-512 and its related > hash functions to avoid using DoubleWordArray, but I see no value in doing > that. The value would be Crypto operational in Pharo. And all that follows from that (ParrotTalk, SSL, SSH, Signal, Raven). Is it possible for you to make these changes, please? I see this as more likely than Pharo accommodating #variableDoubleWordSubclass:. And other Smalltalks... k, r > Pharo simply failed to properly integrate DoubleWordArray. It's there but > it's disfunctional. Just wait until they fix it. > > > Levente > > P.S.: This is pretty much off topic on squeak-dev. > > On Sat, 28 Mar 2020, Robert wrote: > >> Hey Levente, >> >> I dug a little deeper into the Pharo issue with Cryptography and it IS a VM issue, I think. Primitive 61 is failing in DoubleWordArray>>#at:put:. Pharo seems totally uninterested in fixing this so I wanted to ask you, is there any way Cryptography can avoid reliance on DoubleWordArray? >> >> Kindly, >> Robert >> >> -- Kindly, Robert

1 1

DoubleWordArray broken in Pharo
by Robert 28 Mar '20

28 Mar '20

Hey Levente, I dug a little deeper into the Pharo issue with Cryptography and it IS a VM issue, I think. Primitive 61 is failing in DoubleWordArray>>#at:put:. Pharo seems totally uninterested in fixing this so I wanted to ask you, is there any way Cryptography can avoid reliance on DoubleWordArray? Kindly, Robert

1 0

[ParrotTalk] new release, better ThunkStack integration
by Robert 26 Mar '20

26 Mar '20

Hey y'all, I have just published a new version of ParrotTalk, running on top of ThunkStack. #CryptoGreen. > TSThunkSession now specifies protocol, cipher and encoder. So subclasses can default. With ParrotTalk loaded, use > > Session newOnHost: <host> port: <port> and it defaults to ::: > > ^ Session newOnHost: <host> port: <port> protocol: 'ParrotTalk v3.7' cipher: 'AESede' encoder: 'bytes' With Registers, Cryptography and ParrotTalk tests, there are 309 tests that pass green. Without SSL loaded. Still need ParrotTalk loaded, however. I am working out a registration from each package rather than hardcoding the ParrotTalk SessionOperations in SessionAgentMap, now in ThunkStack. So as each protocol package loads it registers with ThunkStack. Installer ss project: 'Cryptography'; install: 'ProCrypto-1-1-1'; install: 'ProCryptoTests-1-1-1'; install: 'SSLLoader'. -- Kindly, Robert

1 0

[ParrotTalk] [CryptoGreen] ParrotTalk is ported
by Robert 24 Mar '20

24 Mar '20

Hey all’y’all, I ported ParrotTalk onto the newly separated ThunkStack framework. ParrotTalk runs #CryptoGreen on ThunkStack. SSL on ThunkStack forthcoming... To load latest ThunkStack, ParrotTalk & SSL DoIt too: Installer as project: ‘Cryptography’; install: ‘ProCrypto-1-1-1’; install: ‘ProCrypto-1-1-1’; install: ‘SSLLoader’. Kindly, Robert

1 0

SSL migration...
by Robert 23 Mar '20

23 Mar '20

Hey everyone, I am porting the SSL implementation onto the ThunkStack framework. Currently looking at SecurityOps>>#installOn...:::: and understanding a fundamental differeence between SSL and ParrotTalk. To check it out doIt to: Installer ss project: 'Cryptography'; install: 'ProCrypto-1-1-1'; install: 'ProCryptoTests-1-1-1'; install: 'SSLLoader'. This SSLLoader config loads the new ThunkStack, ParrotTalk and SSL. In ParrotTalk, the immigration/cryptor/customs/encoding (ICCE) thunks are all installed after the handshake is complete. While in handshake mode, the SessionOperations is the top layer to see the handshakes and no layers above are yet needed. On #successfulConnection (or something) the securityOps installs the ICCE thunks on the stack, on top of the sessionOperations which passes data messages up the ICCE stack, now.In SSL, it installs Null ICCE on initialization. Not sure yet where the sessionOperations is I believe on top of the Null ICCE. The handshake msgs go through this null pipeline. On completion of handshaking, these ICCE are exchanged for the agreed configuration of negotiated non-null ICCE thunks. Now the session is encrypted. I am unsure which is best. Perhaps having examples of both options is of benefit. The first is like capabilities, if you don't have it you don't use it, in the absence of ICCE. The second is more an example of the Null pattern, it is there but doesn't do anything. Having a placeholder. Mmm...placeholder. Note that both sibling protocols are broken, SSL and ParrotTalk. The SessionProtocolSelector is a work in progress... -- Kindly, Robert

1 0

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

21 Mar '20

Hey Levente, On 3/20/20 7:19 PM, Levente Uzonyi wrote: > 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. It's good, you kept it running, running right, running fast. It is no different than before, depending on SecureHashAlgorithm. > >> 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. I understand your point, I went for overkill where every time it starts up it reinitializes. I'm not a big fan of postscript, it is like the initialization code is hiding. I touched it up. I can go either way. K, r > > > 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.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 >> >> -- Kindly, Robert

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Cryptography March 2020