Хэш Oracle m5 возвращает строку, отличную от Postgresql и bash md5sum(1)

#postgresql #oracle #oracle12c #postgresql-12 #md5sum

Вопрос:

Оракул 12с:

 SQL> select UTL_RAW.CAST_TO_RAW('Tom') as hex_val, 
  2         dbms_crypto.hash(src=>UTL_RAW.CAST_TO_RAW('Tom'), typ=>2) as hex_hash
  3  from dual;
546F6D
D9FFACA46D5990EC39501BCDF22EE7A1
 

Postgresql 12.5:

 sides=> select upper(encode('Tom', 'hex')), md5(upper(encode('Tom', 'hex')));
 upper  |               md5                
-------- ----------------------------------
 546F6D | f679fe36c1c908fa2547e6915026b0af
(1 row)
 

md5sum с новой строкой:

 -bash-4.2$ echo "546F6D" | md5sum   
ef81d9f3f3e1305c92ce84efdecfd1bc  -
 

md5sum без новой строки:

 -bash-4.2$ echo -n "546F6D" | md5sum
f679fe36c1c908fa2547e6915026b0af  -
 

Как вы можете видеть, функция MD5() Postgres соответствует функции md5sum(1) без новой строки. Именно этого я и ожидал. Однако Oracle 12c также не соответствует и не соответствует сумме md5 с новой строкой?

Что за странность делает Oracle (или я совершаю ошибку PEBKAC)?

(Конечная цель состоит в том, чтобы показать клиенту, что xml-данные успешно перенесены из Oracle в Postgres. Вот почему допустимо слабое хеширование.)

Редактировать:

Использование функции RAWTOHEX() возвращает то же значение, что и функция CAST_TO_RAW().

 SQL> select UTL_RAW.CAST_TO_RAW('Tom') as hex_val
  2       , dbms_crypto.hash(src=>UTL_RAW.CAST_TO_RAW('Tom'), typ=>2) as hex_hash
  3       , dbms_crypto.hash(src=>RAWTOHEX('Tom'), typ=>2) as raw_hash
  4  from dual;

HEX_VAL
--------------------------------------------------------------------------------
HEX_HASH
--------------------------------------------------------------------------------
RAW_HASH
--------------------------------------------------------------------------------
546F6D
D9FFACA46D5990EC39501BCDF22EE7A1
D9FFACA46D5990EC39501BCDF22EE7A1

SQL> select UTL_RAW.CAST_TO_RAW('Tom') as hex_val
  2       , dbms_crypto.hash(src=>UTL_RAW.CAST_TO_RAW('Tom'), typ=>2) as hex_hash
  3       , dbms_crypto.hash(src=>RAWTOHEX('Tom'), typ=>2) as raw_hash
  4       , standard_hash(rawtohex('Tom'), 'MD5') as std_hash
  5  from dual;

HEX_VAL
--------------------------------------------------------------------------------
HEX_HASH
--------------------------------------------------------------------------------
RAW_HASH
--------------------------------------------------------------------------------
STD_HASH
--------------------------------
546F6D
D9FFACA46D5990EC39501BCDF22EE7A1
D9FFACA46D5990EC39501BCDF22EE7A1
F679FE36C1C908FA2547E6915026B0AF
 

Ответ №1:

Ваша команда Oracle хеширует шестнадцатеричное значение, но ваши команды Postgres и bash хешируют шестнадцатеричное представление. Чтобы Oracle хэшировал строку шестнадцатеричного значения, используйте RAWTOHEX :

 SQL> select standard_hash(rawtohex('Tom'), 'MD5') from dual;

STANDARD_HASH(RAWTOHEX('TOM'),'M
--------------------------------
F679FE36C1C908FA2547E6915026B0AF
 

DBMS_CRYPTO и STANDARD_HASH работают так же, за исключением того, что DBMS_CRYPTO принимают только RAW тип данных.Чтобы запутать ситуацию, иногда используются неявные преобразования, и SQL*Plus может отображать разные типы данных по-разному. Но согласно документации UTL_RAW.CAST_TO_RAW, «Сами данные никоим образом не изменяются, но их тип данных преобразуется в НЕОБРАБОТАННЫЙ тип данных».

Чтобы сравнить исходные значения в обеих базах данных, сравните select select dbms_crypto.hash(src=>utl_raw.cast_to_raw('Tom'), typ=>2) from dual; в Oracle с select upper(md5('Tom')); Postgres — они оба возвращают D9FFACA46D5990EC39501BCDF22EE7A1.

Комментарии:

1. Вы хотите сказать, что CAST_TO_RAW() это генерирует двоичные данные, которые sqlplus затем интерпретирует как шестнадцатеричные?

2. Смотрите мой отредактированный вопрос. Функция RAWTOHEX() возвращает то же самое, что и функция CAST_TO_RAW(). Обратите также внимание, что я должен использовать dbms_crypto.hash (), потому что xml-данные могут составлять более 4000 байт.

3. Проблема, похоже, в том, что dbms_crypto.hash() и STANDARD_HASH() делать разные вещи.

4. Да, я думаю, что SQL*Plus просто отображает данные по-другому; согласно руководству : «Сами данные никоим образом не изменяются, но их тип данных преобразуется в необработанный тип данных». На стороне Postgres вы получите значение «D9…», если удалите ENCODE функцию.