Импортозамещение в I2P: подпись по ГОСТ Р 34.10-201206.04.2017 00:48

Типы подписей в I2P

1. ECDSA_SHA256_P256
2. ECDSA_SHA384_P384
3. ECDSA_SHA512_P521
4. RSA_SHA256_2048
5. RSA_SHA384_3072
6. RSA_SHA512_4096
7. EdDSA_SHA512_Ed25519
8. EdDSA_SHA512_Ed25519ph

Для ГОСТ-а нам, по моей просьбе, выделено два типа:
9 — GOSTR3410_GOSTR3411_256_CRYPTO_PRO_A
10 — GOSTR3410_GOSTR3411_512_TC26_A
для 256 и 512-битных ключей соответственно.

Длина публичного ключа для 9 составляет 64 байта (по 32 байта на каждую координату точки) и 128 байт для 10.

Реализация подписи ГОСТ Р 34.10

Используется обычная эллиптическая кривая, поэтому для работы с ней могут использоваться функции из криптографической библиотеки. В частности это EC_GROUP_* и EC_POINT_* из openssl, главная из которых это:

int EC_POINT_mul(const EC_GROUP *group, EC_POINT *r, const BIGNUM *n, const EC_POINT *q, const BIGNUM *m, BN_CTX *ctx)

Для кривой задаются 6 параметров: p — модуль, a и b — коэффициенты уравнения кривой, P (x, y) — базовая точка, q — простое число, умножение на которое базовой точки дает нуль.

p и q должны быть большими и близкими к максимальным, поскольку p ограничивает диапазон всех чисел, а q — диапазон секретных ключей. Базовая точка и q вычисляются одновременно.
Как правило используются общеизвестные и хорошо протестированные наборы параметров.

В нашей реализации мы будем использовать 2 набора параметров:

• GostR3410_2001_CryptoPro_A_ParamSet (OID 1.2.643.2.2.35.1) для 256-битных ключей, заимствован из ГОСТ Р 34.10–2001;
• id-tc26-gost-3410–12–512-paramSetA (OID 1.2.643.7.1.2.1.2.1) для 512-битных ключей, разработанный ТК26(tc26.ru) специально для ГОСТ Р 34.10–2012.

Для подписи (r, s) выбирается случайное число k, и вычисляется точка R=k*P, координата x которой становится компонентой r подписи. Компонента s = r*d + h*k, где d — секретный ключ, h — хэш подписи сообщения в Big Endian.

Для проверки подписи умножим обе части равенства на базовую точку P.

Действительно s*P = r*d*P + h*k*P = r*Q + h*R, где Q — публичный ключ. В этом равенстве нам неизвестна точка R, и хотя можно восстановить координату y по r, это является крайне медленной операцией. Поэтому перепишем равенство в виде h*R = s*P — r*Q, далее
R = (s*P -r *Q)/h и сравнение только координаты x.

bool GOSTR3410Curve::Verify (const EC_POINT * pub, const BIGNUM * digest, const BIGNUM * r, const BIGNUM * s)
{
	BN_CTX * ctx = BN_CTX_new ();
	BN_CTX_start (ctx);
	BIGNUM * q = BN_CTX_get (ctx);
	EC_GROUP_get_order(m_Group, q, ctx);
	BIGNUM * h = BN_CTX_get (ctx);
	BN_mod (h, digest, q, ctx); // h = digest % q
	BN_mod_inverse (h, h, q, ctx); // 1/h mod q
	BIGNUM * z1 = BN_CTX_get (ctx);
	BN_mod_mul (z1, s, h, q, ctx); // z1 = s/h
	BIGNUM * z2 = BN_CTX_get (ctx);				
	BN_sub (z2, q, r); // z2 = -r
	BN_mod_mul (z2, z2, h, q, ctx); // z2 = -r/h
	EC_POINT * C = EC_POINT_new (m_Group);
	EC_POINT_mul (m_Group, C, z1, pub, z2, ctx); // z1*P + z2*pub
	BIGNUM * x = BN_CTX_get (ctx);	
	GetXY  (C, x, nullptr); // Cx
	BN_mod (x, x, q, ctx); // Cx % q
	bool ret = !BN_cmp (x, r); // Cx = r ?
	EC_POINT_free (C);
	BN_CTX_end (ctx);
	BN_CTX_free (ctx);
	return ret;
}	

Хэш функция ГОСТ Р 34.11–2012(стрибог)

Подробное описание и примеры. Отметим основные моменты:

• Исходное сообщение разбивается на блоки по 64 байта. Если не сообщение не кратно 64, то первый блок дополняется слева нулевыми и единичным байтами.
• Каждый блок хэшируется отдельно с учетом хэша предыдущего блока. Для самого первого блока в качестве предыдущего хэша задается вектор инциализации (iv). Проход по блокам осуществляется в обратном порядке — от последнего к первому.
• Каждый блок «шифруется» 12 раундов заданными ключами, каждый раунд представляет собой применение трех преобразований S, P, L с использованием заданных таблиц и XOR с раундовым ключом.
• S представляет собой побайтную замену, P — транспонирование хэша как матрицы 8×8, L — умножение на заданную матрицу.
• 256-битный хэш представляет собой левую половину 512-битного хэша, однако используется другой iv, поэтому вычислять их одновременно не получится.

Подпись внешним криптопровайдером по протоколу I2CP

Вместо этого маршрутизатор отправляет сообщение RequestLeaseSetMessage (или RequestVariableLeaseSetMessage), ожидая в ответ сообщение CreateLeaseSetMessage, содержащее LeaseSet, подписанный секретным ключом адреса. Как можно заметить из описания протокола, в старых версиях I2P требовалось передавать этот ключ в сообщении, больше этого не требуется.
Таким образом, приложение, реализующее I2P адрес, может использовать для подписи API одного из существующих криптопровайдеров с ГОСТ, позволяя эффективно встроить I2P решение в существующую инфраструктуру.

Реализация

Комментарии (1)

• degs

  5 апреля 2017 в 20:02

  +1

  ↑

  ↓

  Красиво. Но дополнительный хаб «Ненормальное программирование» был бы тут не лишним.