On 2020-08-10 21:43, Leyne, Sean wrote:
That old form is kept for backward compatibility. If your suggestion comes true
(hope not) some idiot may try to use PJW as cryptographic hash.
To summarize - I withdraw my initial agreement to add CRC32 calculation to
function HASH(). The only argument for this is same name in plain english for
different purpose things.
I believe that many of you are all too narrowly linking HASH and whether it is
appropriate for cryptography.
What about particular CRC32 - it produces output value with length just
4 bytes, even using SHA1 with 20 bytes returned was accepted as security
risk in some places (like SRP), making us move to hashes with longer
output. Sean, I do not know under what condition can it be used as
cryptographic hash. In our favorite tomcrypt hashes usable for crypto
purporses are collected together and may be interchangeably used in
other (higher level) crypto functions like RSA signing messages. But
CRC32 is standalone, it can not be used for something like signing messages.
Further, you are not considering how the developer/user would want to use the
output.
I've tried to take it into an account...
I believe that:
1- While strictly speaking, CRC32 is not a "hash", it is commonly thought of as
one.
Yes. But as hash-function for various hash tables it's pretty nice, btw
widely used inside firebird code internally.
2- the general functions should be referred to as HASH_xxx.
Yes - and current approach with HASH(something USING XXX) is just syntax
sugar in SQL style, suggested not by me.
On the other hand it makes possible if needed in the future use tightly
related form HASH(something USING 'XXX') , pay attention that hash type
became SQL string, not identifier. This is close to approach used in
tomcrypt (they use special objects called handles or descriptors of hash
type, but it's C, for SQL text string should be OK).
The fact that the usage is appropriate for cryptography is something the
developer/user needs to worry about.
Ohh - I do not want to get CVE 'Firebird suggests unreliable hashes for
crypto purposes'.
A HASH is a HASH is a HASH.
3- That there should be separate 'implementations' for the different datatype
that is returned: Hex (i.e. String/varchar) and Integer (Octal?).
Eg. HASH_ToHex, or HASH_AsInteger
I'm afraid that even new INT128 is not enough for old SHA1 with it's 160
bytes. The only one that may return it's result as integer is CRC32. And
as long as we already have separate function for it... what for change
something?
HASH_AsInteger(something USING CRC32)
instead
CRC32(something)
?
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
