Smalltalk › Squeak › Squeak - Dev

Fixing SecureHashAlgorithm without plugins

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

timfelgentreff

Fixing SecureHashAlgorithm without plugins

Hi,

we're running the fallback code for SecureHashAlgorithm, LargePositiveInteger, and lots of the optional primitives. In the fallback code of SecureHashAlgorithm>>finalHash there is a call that looks like this:

(LargePositiveInteger new: result size)
replaceFrom: 1
to: result size
with: result
startingAt: 1;
normalize

Here, result is a ByteArray. The replaceFrom:to:with:startingAt: goes to call primitive 105, which is marked as optional in the comment, so we do not implement it. However, the fallback code in Integer>>replaceFrom:to:with:startingAt: sends digitAt: to the replacement object, and ByteArray doesn't understand that message.

Clearly the fallback code behaves differently from the primitive.

1) One way to fix it would be to check the object type in the fallback code. If it is a byte object, we simply use at: (which is the same as digitAt: for Large*Integer).

2) Another fix is to add digitAt: to ByteArray. This feels very wrong to me.

3) Alternatively, we might say that calling replaceFrom:to:with:startingAt: on an integer with any byte object is illegal. In that case, we could instead fix the fallback code in SecureHashAlgorithm>>finalHash to do this in the end:

LargePositiveInteger adoptInstance: result.
^ result normalize

This will fix the problem, but the fallback code will still be inconsistent with the primitive.

I'm torn between 1 and 3, so what do you say?

Cheers,
Tim

Levente Uzonyi

Re: Fixing SecureHashAlgorithm without plugins

Hi Tim,

I made a workaround using #adoptInstance: instead of copying in
System-ul.831. Hopefully you have one of the primitives (160, 115) it uses
implemented.
I think it would be worth moving the fallback code from Integer down to
LargePositiveInteger, because that way SmallInteger receivers would
signal DNU instead of 'You can''t store in a SmallInteger'.

Levente

On Thu, 19 May 2016, timfelgentreff wrote:

> Hi,
>
> we're running the fallback code for SecureHashAlgorithm,
> LargePositiveInteger, and lots of the optional primitives. In the fallback
> code of SecureHashAlgorithm>>finalHash there is a call that looks like this:
>
> (LargePositiveInteger new: result size)
> replaceFrom: 1
> to: result size
> with: result
> startingAt: 1;
> normalize
>
> Here, result is a ByteArray. The replaceFrom:to:with:startingAt: goes to
> call primitive 105, which is marked as optional in the comment, so we do not
> implement it. However, the fallback code in
> Integer>>replaceFrom:to:with:startingAt: sends digitAt: to the replacement
> object, and ByteArray doesn't understand that message.
>
> Clearly the fallback code behaves differently from the primitive.
>
> 1) One way to fix it would be to check the object type in the fallback code.
> If it is a byte object, we simply use at: (which is the same as digitAt: for
> Large*Integer).
>
> 2) Another fix is to add digitAt: to ByteArray. This feels very wrong to me.
>
> 3) Alternatively, we might say that calling replaceFrom:to:with:startingAt:
> on an integer with any byte object is illegal. In that case, we could
> instead fix the fallback code in SecureHashAlgorithm>>finalHash to do this
> in the end:
>
> LargePositiveInteger adoptInstance: result.
> ^ result normalize
>
> This will fix the problem, but the fallback code will still be inconsistent
> with the primitive.
>
> I'm torn between 1 and 3, so what do you say?
>
> Cheers,
> Tim
>
>
>
> --
> View this message in context: http://forum.world.st/Fixing-SecureHashAlgorithm-without-plugins-tp4895951.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>

timfelgentreff

Re: Fixing SecureHashAlgorithm without plugins

Hi Levente,

thank you, that change works great for me :)

Cheers,
Tim

Levente Uzonyi wrote

Hi Tim,

I made a workaround using #adoptInstance: instead of copying in
System-ul.831. Hopefully you have one of the primitives (160, 115) it uses
implemented.
I think it would be worth moving the fallback code from Integer down to
LargePositiveInteger, because that way SmallInteger receivers would
signal DNU instead of 'You can''t store in a SmallInteger'.

Levente

On Thu, 19 May 2016, timfelgentreff wrote:

> Hi,
>
> we're running the fallback code for SecureHashAlgorithm,
> LargePositiveInteger, and lots of the optional primitives. In the fallback
> code of SecureHashAlgorithm>>finalHash there is a call that looks like this:
>
> (LargePositiveInteger new: result size)
> replaceFrom: 1
> to: result size
> with: result
> startingAt: 1;
> normalize
>
> Here, result is a ByteArray. The replaceFrom:to:with:startingAt: goes to
> call primitive 105, which is marked as optional in the comment, so we do not
> implement it. However, the fallback code in
> Integer>>replaceFrom:to:with:startingAt: sends digitAt: to the replacement
> object, and ByteArray doesn't understand that message.
>
> Clearly the fallback code behaves differently from the primitive.
>
> 1) One way to fix it would be to check the object type in the fallback code.
> If it is a byte object, we simply use at: (which is the same as digitAt: for
> Large*Integer).
>
> 2) Another fix is to add digitAt: to ByteArray. This feels very wrong to me.
>
> 3) Alternatively, we might say that calling replaceFrom:to:with:startingAt:
> on an integer with any byte object is illegal. In that case, we could
> instead fix the fallback code in SecureHashAlgorithm>>finalHash to do this
> in the end:
>
> LargePositiveInteger adoptInstance: result.
> ^ result normalize
>
> This will fix the problem, but the fallback code will still be inconsistent
> with the primitive.
>
> I'm torn between 1 and 3, so what do you say?
>
> Cheers,
> Tim
>
>
>
> --
> View this message in context: http://forum.world.st/Fixing-SecureHashAlgorithm-without-plugins-tp4895951.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>