Hi, Пишут, что реализация Streebog в libgcrypt с (давно исправленной в других реализациях) ошибкой. https://habr.com/ru/post/450024/
Спасибо, сейчас отправлю патчи.
Паралеллельно отмечу: эта ошибка не ловится тестом eeee...eeee1611...1116.
Тестовый вектор на эту ошибку (рекомендую добавить в тестовые векторы):
$ echo -ne '\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'
| openssl dgst -md_gost12_512
(stdin)= 90a161d12ad309498d3fe5d48202d8a4e9c406d6a264aeab258ac5ecc37a7962aaf9587a5abb09b6bb81ec4b3752a3ff5a838ef175be5772056bc5fe54fcfc7e
Реализации с ошибкой выдают:
(stdin)= c5e8ac156e3cd7f395fa9c8bf8fb3995dcfadc0ee539d56e5138804b488e17b846fc7bccf883b21914acfd0add48e55ac359a7564f39619cd6ad9d93a35bf9a9
чт, 2 мая 2019 г. в 15:41, Vitaly Chikunov <vt@altlinux.org>:
>
> Hi,
>
> Пишут, что реализация Streebog в libgcrypt с (давно исправленной в других
> реализациях) ошибкой.
>
> https://habr.com/ru/post/450024/
>
>
> _______________________________________________
> oss-gost-crypto mailing list
> oss-gost-crypto@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto
--
With best wishes
Dmitry
On Sun, May 05, 2019 at 12:50:03AM +0300, Dmitry Belyavsky wrote: > У меня там был какой-то тестовый вектор в gost-engine. Как назывался, ща не > помню. На нём разницы нет. > On Sun, May 5, 2019 at 12:33 AM Dmitry Eremin-Solenikov < > dbaryshkov@gmail.com> wrote: > > > Спасибо, сейчас отправлю патчи. > > > > Паралеллельно отмечу: эта ошибка не ловится тестом eeee...eeee1611...1116. > > > > Тестовый вектор на эту ошибку (рекомендую добавить в тестовые векторы): > > > > $ echo -ne > > '\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' > > | openssl dgst -md_gost12_512 > > (stdin)= > > 90a161d12ad309498d3fe5d48202d8a4e9c406d6a264aeab258ac5ecc37a7962aaf9587a5abb09b6bb81ec4b3752a3ff5a838ef175be5772056bc5fe54fcfc7e > > > > Реализации с ошибкой выдают: > > (stdin)= > > c5e8ac156e3cd7f395fa9c8bf8fb3995dcfadc0ee539d56e5138804b488e17b846fc7bccf883b21914acfd0add48e55ac359a7564f39619cd6ad9d93a35bf9a9 К слову, достаточно 64-х "\xff". libgcrypt (master)$ perl -E 'print "\xff" x 64'| openssl dgst -md_gost12_256 -r; perl -E 'print "\xff" x 64' | ./tests/gchash stribog256 - 964a5ab60286f106288743e2fe1a422d160898ca1bd535e831aa500cfe34d7e8 *stdin 6cad1fb10486524958e90756a6e72ab717d89842634004a0958582d256209818 -
Коллеги, вс, 5 мая 2019 г. в 00:33, Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>: > Спасибо, сейчас отправлю патчи. Вопрос от разработчиков gcrypt. Нужна ли кому-нибудь поддержка неправильного варианта Streebog (как сделано для whirlpool: https://dev.gnupg.org/rC94030e44aaff805d754e368507f16dd51a531b72) или нам это не нужно и достаточно просто исправленной версии. > чт, 2 мая 2019 г. в 15:41, Vitaly Chikunov <vt@altlinux.org>: > > Пишут, что реализация Streebog в libgcrypt с (давно исправленной в других > > реализациях) ошибкой. > > > > https://habr.com/ru/post/450024/ -- With best wishes Dmitry
On Sun, May 05, 2019 at 12:57:21AM +0300, Vitaly Chikunov wrote:
>
> К слову, достаточно 64-х "\xff".
>
> libgcrypt (master)$ perl -E 'print "\xff" x 64'| openssl dgst -md_gost12_256 -r; perl -E 'print "\xff" x 64' | ./tests/gchash stribog256 -
> 964a5ab60286f106288743e2fe1a422d160898ca1bd535e831aa500cfe34d7e8 *stdin
> 6cad1fb10486524958e90756a6e72ab717d89842634004a0958582d256209818 -
Заодно тест на реализацию add512:
~/infotecs$ perl -E 'print "\xff" x 64' > ff
~/infotecs$ xxd ff
00000000: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000010: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000020: ffff ffff ffff ffff ffff ffff ffff ffff ................
00000030: ffff ffff ffff ffff ffff ffff ffff ffff ................
~/infotecs$ ./vipnethashcalc-tool ff --hash-alg Gost12S256
Вычисленное значение хэш-функции: 6CAD1FB10486524958E90756A6E72AB717D89842634004A0958582D256209818
Значение хэша у ViPNet Hash Calculation Tool 5.2.1.1027 соответствует
реализации с ошибкой.
ps. На всякий случай:
~/infotecs$ ./vipnethashcalc-tool ff --hash-alg Gost94
Вычисленное значение хэш-функции: 8505D4623B76E757B63A4F9ADFF2413BAB457560A6A41A7D0056B909CDDD3D6C
On Sat, May 25, 2019 at 11:03:13PM +0300, Vitaly Chikunov wrote:
> On Sun, May 05, 2019 at 12:57:21AM +0300, Vitaly Chikunov wrote:
> >
> > К слову, достаточно 64-х "\xff".
> >
> > libgcrypt (master)$ perl -E 'print "\xff" x 64'| openssl dgst -md_gost12_256 -r; perl -E 'print "\xff" x 64' | ./tests/gchash stribog256 -
> > 964a5ab60286f106288743e2fe1a422d160898ca1bd535e831aa500cfe34d7e8 *stdin
> > 6cad1fb10486524958e90756a6e72ab717d89842634004a0958582d256209818 -
>
> Заодно тест на реализацию add512:
>
> ~/infotecs$ perl -E 'print "\xff" x 64' > ff
> ~/infotecs$ xxd ff
> 00000000: ffff ffff ffff ffff ffff ffff ffff ffff ................
> 00000010: ffff ffff ffff ffff ffff ffff ffff ffff ................
> 00000020: ffff ffff ffff ffff ffff ffff ffff ffff ................
> 00000030: ffff ffff ffff ffff ffff ffff ffff ffff ................
>
> ~/infotecs$ ./vipnethashcalc-tool ff --hash-alg Gost12S256
> Вычисленное значение хэш-функции: 6CAD1FB10486524958E90756A6E72AB717D89842634004A0958582D256209818
>
> Значение хэша у ViPNet Hash Calculation Tool 5.2.1.1027 соответствует
> реализации с ошибкой.
>
> ps. На всякий случай:
>
> ~/infotecs$ ./vipnethashcalc-tool ff --hash-alg Gost94
> Вычисленное значение хэш-функции: 8505D4623B76E757B63A4F9ADFF2413BAB457560A6A41A7D0056B909CDDD3D6C
~/cryptopro/linux-amd64$ /opt/cprocsp/bin/amd64/cryptcp
CryptCP 4.0 (c) "КРИПТО-ПРО", 2002-2018.
Утилита командной строки для подписи и шифрования файлов.
...
-hashAlg задать алгоритм хэширования
OID OID алгоритма хэширования: 1.2.643.2.2.9 для ГОСТ Р 34.11-94
1.2.643.7.1.1.2.2 для ГОСТ Р 34.11-2012 256 bit
1.2.643.7.1.1.2.3 для ГОСТ Р 34.11-2012 512 bit
...
~/cryptopro/linux-amd64$ perl -E 'print "\xff" x 64' > ff
~/cryptopro/linux-amd64$ /opt/cprocsp/bin/amd64/cryptcp -hash -hashAlg 1.2.643.7.1.1.2.2 ff
CryptCP 4.0 (c) "КРИПТО-ПРО", 2002-2018.
Утилита командной строки для подписи и шифрования файлов.
Папка './':
ff... OK.
[ErrorCode: 0x00000000]
~/cryptopro/linux-amd64$ xxd ff.hsh
00000000: 964a 5ab6 0286 f106 2887 43e2 fe1a 422d .JZ.....(.C...B-
00000010: 1608 98ca 1bd5 35e8 31aa 500c fe34 d7e8 ......5.1.P..4..
Значение хэша соответствует реализации без ошибки.
Hi, On Sat, May 25, 2019 at 10:53:35PM +0300, Dmitry Eremin-Solenikov wrote: > вс, 5 мая 2019 г. в 00:33, Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>: > > Вопрос от разработчиков gcrypt. Нужна ли кому-нибудь поддержка неправильного > варианта Streebog (как сделано для whirlpool: > https://dev.gnupg.org/rC94030e44aaff805d754e368507f16dd51a531b72) или нам это > не нужно и достаточно просто исправленной версии. Так как в ViPNet такой-же баг[1] и это сертифицированный продукт, то это может иметь смысл. [1] https://lists.altlinux.org/pipermail/oss-gost-crypto/2019-May/000250.html
(В копилку ошибочных реализаций.) В одном российском линуксе, хэш для данных с длинной кратной 64 считаются иначе чем у всех остальных: $ perl -E 'print "\x00" x 0' | gostsum --gost-2012 106c0c2070522f9ed0753e143809578a3b27711c5bc99553c3eaca250de2a30a - $ perl -E 'print "\x00" x 1' | gostsum --gost-2012 6f7305265dc0937440881f9493ef1260f61a9d47742d369e952d41bdb2a9edd1 - $ perl -E 'print "\x00" x 64' | gostsum --gost-2012 f69e7c846ee36c5363251bd89bc4b4794aa598d5092d952415bde2d314d85eba - $ perl -E 'print "\x00" x 65' | gostsum --gost-2012 ff494da4e950940619b06db49c4c3dac03a3823e134c22ff0b732599c85b321f - Сравнение с adegtyarev/streebog: $ perl -E 'print "\x00" x 0' | gost3411-2012 -2 3f539a213e97c802cc229d474c6aa32a825a360b2a933a949fd925208d9ce1bb $ perl -E 'print "\x00" x 1' | gost3411-2012 -2 6f7305265dc0937440881f9493ef1260f61a9d47742d369e952d41bdb2a9edd1 $ perl -E 'print "\x00" x 64' | gost3411-2012 -2 df1fda9ce83191390537358031db2ecaa6aa54cd0eda241dc107105e13636b95 $ perl -E 'print "\x00" x 65' | gost3411-2012 -2 ff494da4e950940619b06db49c4c3dac03a3823e134c22ff0b732599c85b321f Интересно что там могло пойти не так.
On 2020-01-13T08:07:25+0300, Vitaly Chikunov wrote: > (В копилку ошибочных реализаций.) > В одном российском линуксе, хэш для данных с длинной кратной 64 > считаются иначе чем у всех остальных: В каком? -- Regards, Wartan.
On Mon, Jan 13, 2020 at 09:51:18AM +0300, Dmitry Belyavsky wrote: > On Mon, Jan 13, 2020 at 8:07 AM Vitaly Chikunov <vt@altlinux.org> wrote: > > > (В копилку ошибочных реализаций.) > > > > В одном российском линуксе, хэш для данных с длинной кратной 64 > > считаются иначе чем у всех остальных: > > > > ... > > > > > Интересно что там могло пойти не так. > > > > Ну как. Финализация включает в себя дополнение непрохешированного остатка > до полного блока. > Вот если остаток не оставить, а всё равно дополнить - будет именно это > скорее всего. 1. По-моему мы так и делаем. А вот они не делают заполнение _пустого блока_. В ГОСТ (для полных блоков) они пропускают шаги 3.1, 3.2, 3.3, 3.4. В примерах сказано "длина сообщения меньше 512, _поэтому_ происходит заполнение неполного блока". А что же делать когда блок полный? Кто прав? Вот патч который дает результаты "как у них": diff --git a/gost3411-2012-core.c b/gost3411-2012-core.c index de582c6..55aad37 100644 --- a/gost3411-2012-core.c +++ b/gost3411-2012-core.c @@ -163,13 +163,15 @@ stage3(GOST34112012Context *CTX) buf.QWORD[0] = BSWAP64(CTX->bufsize << 3); #endif - pad(CTX); + if (CTX->bufsize) { + pad(CTX); - g(&(CTX->h), &(CTX->N), (const unsigned char *) &(CTX->buffer)); + g(&(CTX->h), &(CTX->N), (const unsigned char *) &(CTX->buffer)); - add512(&(CTX->N), &buf, &(CTX->N)); - add512(&(CTX->Sigma), (const union uint512_u *) &CTX->buffer[0], - &(CTX->Sigma)); + add512(&(CTX->N), &buf, &(CTX->N)); + add512(&(CTX->Sigma), (const union uint512_u *) &CTX->buffer[0], + &(CTX->Sigma)); + } g(&(CTX->h), &buffer0, (const unsigned char *) &(CTX->N)); 2. Кроме того, в нашем коде есть странность: | static inline void | pad(GOST34112012Context *CTX) | { | if (CTX->bufsize > 63) | return; | | memset(CTX->buffer + CTX->bufsize, | 0x00, sizeof(CTX->buffer) - CTX->bufsize); | | CTX->buffer[CTX->bufsize] = 0x01; | } `CTX->bufsize` никогда не может быть больше 63.