[squeak-dev] [Vm-dev] SHA512 squeak implementation?

Robert robert.withers at pm.me
Sat Mar 7 18:14:22 UTC 2020


I renamed HASHA512 to SHA512 and renamed the tests, and moved the 
register tests to Cryptography-Hash-Tests. The latest:

Name: Cryptography-v5.3-rww.123
Author: rww
Time: 7 March 2020, 1:11:11.701898 pm
UUID: 06ce3c17-4c09-45b0-b7de-c22fc6242589
Ancestors: Cryptography-v5.3-rww.122

recategorized Register tests.

---

I am prepped to fragment all of Cryptography and setup required packages.

k, r

On 3/7/20 12:27 PM, 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 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.
>
> - 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



More information about the Squeak-dev mailing list