AESSHA256 result has wrong CodePage

danielkuettner · 2016-03-05 13:43:57

after updating mORMot

AESSHA256(RawByteString('plain-password'), RawByteString('cjeroupvbewrf'),true)

has CodePage of 1252 instead of 65001.

(Delphi XE6, 32bit, $USE_SYNCOMMONS)

Last edited by danielkuettner (2016-03-05 13:44:40)

ab · 2016-03-05 18:28:53

What do you mean?

danielkuettner · 2016-03-05 19:57:27

var
s: RawByteString;
w: Word;

s:= AESSHA256(RawByteString('plaintextpassw'), RawByteString('cjeroupvbewrf'),true);
w:= StringCodePage(s);<--1252 instead of 65001

ab · 2016-03-05 20:55:07

Does SetString(result,nil,length(s)) return the wrong code page, when result is a RawByteString?
It is a Delphi bug, IMHO, in this case.

danielkuettner · 2016-03-05 21:06:33

I use AESSHA256 since a long time for storing passwords in DB. But after mORMot update the encrypted string has wrong code page and ColumnUTF8 gets wrong string, because it was not encoded as UTF8/RawByteString by inserting.
My Delphi has never changed in the last two years, so I would guess it's not a Delphi bug.

ab · 2016-03-05 21:14:45

Just try:

var
  s: RawByteString;
begin
  SetString(s,nil,10);
  writeln(StringCodePage(s));

or even:

var
  s: RawByteString;
begin
  SetLength(s,10);
writeln(StringCodePage(s));

This sounds like a bug, no?
If it is not a bug, it is a feature...
This is how it is expected to work.

danielkuettner · 2016-03-05 21:37:22

Ok, it's a bug. But why this bug comes now and was never in past?
And when using AESSHA256 I expect a code page of 65001. Perhaps you could use SetStringCodePage(result, 65001,false) in AESSHA256.

ab · 2016-03-05 22:35:10

This is how it is supposed to work.
See http://docwiki.embarcadero.com/Librarie … ByteString

> RawByteString should only be used as a parameter type, and only in routines which otherwise would need multiple overloads for AnsiStrings with different codepages. Such routines need to be written with care for the actual codepage of the string at run time.

danielkuettner · 2016-03-06 09:26:36

When a result type of a function is RawByteString and the parameter of the function is RawByteString, then I'm surprised if the CodePage is not 65001 after calling this function.

I can call PWord(PByte(S) - 12)^ := 65001 after every call of such functions (like AESSHA256), but when I forget it, my encrypted passwords written in DB, after read from DB and decrypted are not the same and I debug through the ZEOS sources, to find out why.

Therefore it were very cool, if PWord(PByte(S) - 12)^ := 65001 would be called in such functions, that using SetString or SetLength, to guarantee, codepage doesn't change without need.

miab3 · 2016-03-06 10:30:06

@danielkuettner,

Which ZEOS?, which svn?, which DB?, which client?, which Server?

Michal

Last edited by miab3 (2016-03-06 10:33:53)

danielkuettner · 2016-03-06 11:09:17

@Michal

It's not a Zeos issue. SynDB/Zeos gets already an wrong encoded string.

http://svn.code.sf.net/p/zeoslib/code-0 … esting-7.3

ab · 2016-03-06 12:05:23

As stated by the Delphi documentation, RawByteString is to be used only for parameters.
You should NOT expect anything about the code page of a RawByteString variable.
Delphi set a RawByteString variable to the current system code page.
There is no way of creating a string with the 65535 code page. They should not exist as such.

So IMHO it is not a wrong encoded string, this is a string encoded as expected.
What is wrong is your expectation about such RawByteString variables.

danielkuettner · 2016-03-06 13:59:35

var
w: Word;
s: RawUTF8;
begin
s:= '++++++++';
w:= StringCodePage(s); <-- w = 65001 as expected
s:= AESSHA256(s, 'skbcinOIENCUOebäÜöß', true);
w:= StringCodePage(s); <-- w = 1252 as unexpected

Is this an issue of my wrong expecting, or is this a bug/feature of Delphi's SetString? If you would agree with me, that this is bug/feature of Delphi's SetString, than the caller of such a function has to reset the CodePage to the original value.
Thats my POV, not more and not less.

ab · 2016-03-06 14:08:31

There is no way of known the code page declared for s.
So if you create a new RawByteString, it would create a new AnsiString.
You should not use the code page of the returned "RawByteString" instance.

IMHO the caller should not reset the codepage to any "original" value, since there is no such "original" value.

mORMot Open Source

#1 2016-03-05 13:43:57

AESSHA256 result has wrong CodePage

#2 2016-03-05 18:28:53

Re: AESSHA256 result has wrong CodePage

#3 2016-03-05 19:57:27

Re: AESSHA256 result has wrong CodePage

#4 2016-03-05 20:55:07

Re: AESSHA256 result has wrong CodePage

#5 2016-03-05 21:06:33

Re: AESSHA256 result has wrong CodePage

#6 2016-03-05 21:14:45

Re: AESSHA256 result has wrong CodePage

#7 2016-03-05 21:37:22

Re: AESSHA256 result has wrong CodePage

#8 2016-03-05 22:35:10

Re: AESSHA256 result has wrong CodePage

#9 2016-03-06 09:26:36

Re: AESSHA256 result has wrong CodePage

#10 2016-03-06 10:30:06

Re: AESSHA256 result has wrong CodePage

#11 2016-03-06 11:09:17

Re: AESSHA256 result has wrong CodePage

#12 2016-03-06 12:05:23

Re: AESSHA256 result has wrong CodePage

#13 2016-03-06 13:59:35

Re: AESSHA256 result has wrong CodePage

#14 2016-03-06 14:08:31

Re: AESSHA256 result has wrong CodePage

Board footer