[oss-gost-crypto] ГОСТ 34.10 и CryptoAPI (FYI progress update)

[Vitaly Chikunov]

Hi,

1. Я сделал рабочую реализацию проверки подписи ГОСТ 34.10 для ядра
в очень _черновом_ варианте:

  https://github.com/vt-alt/linux/commits/ecrdsa
  https://github.com/vt-alt/linux/blob/ecrdsa/crypto/ecrdsa.c

2. CryptoAPI ядра RSA-центрично и поэтому сделать поддержку ECDSA
не меняя его не возможно. Поэтому, там есть пара коммитов со сменой
akcipher API (вводится новый вызов verify2). Я отсылал RFC патчсет и его
восприняли без негатива. (Правда этого все равно будет не достаточно для
out-of-tree реализаций. Но наша планируется in-tree, так что это не
проблема).

3. По кривым. Рекомендовано использовать 7 кривых:

4. Поддержку двух скрученных кривых Эжвардса я не стал делать, так как
gost-engine их не поддерживает. Это

    id-tc26-gost-3410-2012-256-paramSetA
    id-tc26-gost-3410-2012-512-paramSetC

Из оставшихся:

    id-GostR3410-2001-CryptoPro-A-ParamSet (256-bit)
    id-tc26-gost-3410-12-512-paramSetA

Работают (более менее) оптимизированные алгоритмы, но надо ещё точнее
проверить скорость. Субъективно 512-битный вариант работает "быстрее
чем 0.1 в секунду", что можно оценить как "очень плохо".

5. Смышляев (2015) в выступлении "Российская криптография: так ли всё
грустно?" (слайды https://www.slideshare.net/phdays/ss-48934331 страница
22) приводит статистику (без указания мощностей на которых производилось
тестирование): 256-битная подпись 9700 проверок в секунду, 512-битная
подпись 1850 проверок в секунду.

6. В статье Комарова, Менщиков, Коробейников. Анализ и сравнение алгоритмов
электронной цифровой подписи ГОСТ Р 34. 10-1994, ГОСТ Р 34. 10-2001 и ГОСТ Р
34. 10-2012 // Вопросы кибербезопасности. 2017. №1 (19). URL:

  https://cyberleninka.ru/article/n/analiz-i-sravnenie-algoritmov-elektronnoy-tsifrovoy-podpisi-gost-r-34-10-1994-gost-r-34-10-2001-i-gost-r-34-10-2012

приводится статистика (для Core i5-3317U, реализация Pygost на питоне:
оба теста для подписей 256 бит: ГОСТ 2012 дал 100 проверок
подписи за 35 секунд, ГОСТ 2001 года (то есть по сути одинаковый с
2012) дал 100 проверок за 8 секунд.

7. Для сравнения, `openssl speed ecdsa` дает:

                                    sign    verify    sign/s verify/s
 256 bits ecdsa (nistp256)        0.0001s   0.0002s  16439.1   5080.8
 256 bits ecdsa (brainpoolP256r1) 0.0010s   0.0008s   1005.5   1202.2
 256 bits ecdsa (brainpoolP256t1) 0.0010s   0.0008s    996.3   1260.9
 521 bits ecdsa (nistp521)        0.0060s   0.0039s    167.1    259.5
 253 bits EdDSA (Ed25519)         0.0001s   0.0002s  17557.8   5296.4

 456 bits EdDSA (Ed448)           0.0002s   0.0009s   4400.9   1167.3
 571 bits ecdsa (nistk571)        0.0084s   0.0171s    118.5     58.6
 571 bits ecdsa (nistb571)        0.0096s   0.0185s    104.4     54.1
 512 bits ecdsa (brainpoolP512r1) 0.0041s   0.0030s    245.0    336.2
 512 bits ecdsa (brainpoolP512t1) 0.0041s   0.0028s    242.7    356.9

8. Для этих двух кривых используется не эффективное разложение по модулю,
но это я планирую исправить, чтоб стало как у предыдущих двух:

  id-GostR3410-2001-CryptoPro-B-ParamSet (256-bit)
  id-tc26-gost-3410-12-512-paramSetB

7. Реализация в ядре умножения скаляра на точку (сделанная по статье Matthieu
Rivain, 2011) оказалась не способна правильно умножить если у точки в
координате X содержится 0. Поэтому, эта кривая вообще не работает, так как там
в генераторе X=0.

  id-GostR3410-2001-CryptoPro-C-ParamSet (256-bit)

Пожалуй, я эту кривую просто выкину до лучших времен.

8. После анализа производительности и вылизывания кода планирую заняться
прикручиванием этого к IMA.

Спасибо за внимание.