I actually answered on a related bug report, but in the end encryption should be performed byte (bit) wise and a programmer should be discouraged to use encryption on the basis of "string type xxx".
That is usually only a valid concept for AnsiString or UCS2: fixed length stringtypes.
I agree with you.
It would be much clearer if all those "string" interfaces would be replaced by streams.
That is the case we have here.
It is much easier to teach such a proper concept than explaining every time that a char is not always a byte size.
Yes.
Actually: all those string types are legacy and assume AnsiString. Suggest to mark all of them as deprecated or rename to AnsiString or RawByteString. And even then deprecate them....
Understandable.
Proper encryption is on the binary level. Bits and bytes... Not "strings" whatever that may mean.
Yes, the encryption/decryption is on binary level.
Just an honest opinion. "Strings" are too often affected by code rot (what is it? Ansi?, UTF8 (Laz only), WideString? UnicodeString?...) and what you want is byte level, not char level.
True.
It is not too difficult to explain SizeOf() and a Buffer cast.
Correct.
Now, to do the encryption on a binary level we need to use streams. Michael had changed
TStringSteam1 to support encoding, Delphi compatibility, you know (Thank you Michael, wonderful job).
After decryption we need the data in its original format (image, text, file, etc.) which in our example here is a UTF8 encoded string. So again we use
TStringSteam2.
TStringSteam1,
2:
Thaddy, see? we are using streams, right? That is binary, for encryption and decryption.
THE PROBLEM:TStringSteam uses
TEncoding.Default which, under Windows where Lazarus changes
DefaultSystemCodePage from ANSI to UTF8, has a different encoding than UTF8. That is expected because the change to using
TEncoding in
TStringStream happened fairly recent.
I am suggesting that Lazarus should correct
TEncoding.Default when it changes
DefaultSystemCodePage to UTF8. What do you think?
Maybe in the initialization section of $(Lazarus)\components\lazutils\
fpcadds.pasor more probable in
SetMultiByteConversionCodePage in that unit.
What do you think Thaddy? as you can see, the real problem has nothing to do with encryption. It is disagreement between
TEncoding.Default and
DefaultSystemCodePage. Both should represent the same encoding. That is not the case in the trunk under Windows when using LazUtils.
Juha are you reading this?