GRPlatform current secureHashFor: depends on the used String class

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

GRPlatform current secureHashFor: depends on the used String class

GLASS mailing list

I do not know, if this is an error - but I notice that secureHashFor: is based on the byte representation of the used string:


GRPlatform current secureHashFor: 'vorzimmer' = GRPlatform current secureHashFor: (Unicode16 withAll: 'vorzimmer' )


is false ....


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: GRPlatform current secureHashFor: depends on the used String class

GLASS mailing list
Marten,

this should be true on any platform. The hash is computed on a string of bit octets, IOW, binary values. The default encoding is probably going to be UTF-8, so the binary representation of the two string will be different, and therefore the hash. I don’t see any way around it other than forcing the default encoding to be UTF-16 which I don’t know how Grease handles in GLASS. 

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 23-07-2018, at 5:26 AM, Marten Feldtmann via Glass <[hidden email]> wrote:

I do not know, if this is an error - but I notice that secureHashFor: is based on the byte representation of the used string:


GRPlatform current secureHashFor: 'vorzimmer' = GRPlatform current secureHashFor: (Unicode16 withAll: 'vorzimmer' )


is false ....

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GRPlatform current secureHashFor: depends on the used String class

GLASS mailing list
On Mon, Jul 23, 2018 at 11:29 AM, Jerry Kott via Glass <[hidden email]> wrote:
Marten,

this should be true on any platform. The hash is computed on a string of bit octets, IOW, binary values. The default encoding is probably going to be UTF-8, so the binary representation of the two string will be different, and therefore the hash. I don’t see any way around it other than forcing the default encoding to be UTF-16 which I don’t know how Grease handles in GLASS. 

I think one could make a valid argument that the code points should be the source of the bits. e.g. ASCII characters in a Unicode16 string would only have their ASCII code points used, not the internal representation bits.


 

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 23-07-2018, at 5:26 AM, Marten Feldtmann via Glass <[hidden email]> wrote:

I do not know, if this is an error - but I notice that secureHashFor: is based on the byte representation of the used string:


GRPlatform current secureHashFor: 'vorzimmer' = GRPlatform current secureHashFor: (Unicode16 withAll: 'vorzimmer' )


is false ....

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: GRPlatform current secureHashFor: depends on the used String class

GLASS mailing list

Yes, but this should be made *very* clear in the documentation ...


Marten


I think one could make a valid argument that the code points should be the source of the bits. e.g. ASCII characters in a Unicode16 string would only have their ASCII code points used, not the internal representation bits.


 Richard Sargent via Glass <[hidden email]> hat am 23. Juli 2018 um 21:02 geschrieben:


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: GRPlatform current secureHashFor: depends on the used String class

GLASS mailing list
On Tue, Jul 24, 2018 at 1:33 PM, Marten Feldtmann <[hidden email]> wrote:

Yes, but this should be made *very* clear in the documentation ...


I agree. In retrospect, it isn't surprising. It also is unlikely to be changed.

The recommended way to do this is to convert the source "string" to UTF-8 and then compute the hash, secure digest, whatever. This is the way to ensure you get the same results from the Smalltalk image as you do from the operating system command line for the same string.


Marten


I think one could make a valid argument that the code points should be the source of the bits. e.g. ASCII characters in a Unicode16 string would only have their ASCII code points used, not the internal representation bits.


 Richard Sargent via Glass <[hidden email]> hat am 23. Juli 2018 um 21:02 geschrieben:



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass