Вы находитесь на странице: 1из 178

Прикладная

криптография: основы
Ограничение ответственности

Этот материал является кратким обзором


популярных техник и не претендует на полноту,
внесены упрощения.
Разговор будет в контексте Java.
Криптография
κρυπτός (скрытно) + γράφω (пишу)

Обеспечивает защиту информации:


› Конфиденциальность
› Целостность
› Проверку подлинности
Шифр древней Спарты

› Скитала (σκυτάλη) — жезл


› Полоса пергамента или кожи,
наматываемая на цилиндр

› Сообщение пишется слева-


направо

› Диаметр жезла и количество


граней определяют ключ
шифрования
Enigma
› Использовалась для коммуникации немецких
войск во второй мировой войне
› Содержит от 3 до 5 дисков
› Порядок установки дисков, их начальное
положение и состав перемычек определяют
ключ шифрования




https://www.cryptomuseum.com/crypto/enigma/i/index.htm
Содержание

1. Хэш-функции (Hash functions)


2. Случайные числа (Random numbers)
3. Шифры с симметричным ключом (Symmetric key ciphers)
4. Электронная подпись (Digital signature)
5. Шифрование с асимметричным ключом (Asymmetric key encryption)
6. PKI и сертификаты
7. Transport Layer Security (TLS/SSL)
Hash functions
Хэш-функции
Hash function (хэш-функция)

Вычисляет отпечаток фиксированной длины (digest) от данных


произвольного размера

Пример

hash(The quick brown fox jumps over the lazy dog):


D7A8FBB307D7809469CA9ABCB0082E4F8D5651E46D3CDB762D02D0BF37C9E592
Hash function

Свойства хэш-функций:


› Необратимость: зная digest невозможно вычислить исходные данные


› Повторяемость: одинаковые данные порождают одинаковый digest
› Разные данные могут сформировать одинаковый digest (hash collision)
› Изменение любого бита исходного сообщения полностью изменяет
значение digest (лавинный эффект)
Типовые применения хэш-функций

› Контрольные суммы данных (checksum)


› Ассоциативные массивы (хэш-таблицы)
› Отпечатки ключей (certificate/key fingerprint)
› Хранение паролей
› Аутентификация и контроль целостности сообщений
› Формирование ключей для шифрования
Хэш-функции применять с осторожностью

› Как уникальный идентификатор (возможны коллизии)


› Для хранения паролей и задач аутентификации (подбор по
словарю заранее вычисленных хэшей, есть готовые словари
в интернете)
› Многократное хэширование не дает преимуществ (но
увеличивает вероятность коллизии)
Hash functions
Устаревшие, не рекомендуются к применению:
› MD*, MD5, SHA-0, ГОСТ Р 34.11-94, SHA-1

Широко используемые:
› семейство SHA-2 (SHA-256, SHA-384, SHA-512)
› ГОСТ Р 34.11-2012 (Стрибог)

Перспективные:
› SHA-3 (SHA3-256, SHA3-512), BLAKE2b, BLAKE2s
Свойства SHA-2, SHA-3, BLAKE2

› Быстро вычисляются
› Значение digest 512 бит при 64 машинном слове
› Значение digest 256 бит при 32 машинном слове
› Значение digest можно усекать до необходимого размера
› Значения SHA*-160, SHA*-224, SHA*-256, SHA*-384 это фрагмент
оригинального digest
Хранение паролей и аутентификация

Необходимо соблюсти условия:


1. Невозможность подбора по готовому словарю хэшей
(dictionary lookup attack)
2. Невозможность перебора паролей (brute-force attack)

https://www.freerainbowtables.com
Невозможность подбора по словарю хэшей

Невозможность использования предварительно вычисленного


словаря обеспечивается добавлением случайных данных (salt)
к аргументу хэш-функции

Требования:
› salt это случайные данные
› salt достаточной длины (min 128 bit или больше)
› salt уникален для каждого хэша
Невозможность brute-force attack

Невозможность перебора обеспечивается применением “тяжелой”


вычислительной хэш-функции, делающей затраты ресурсов на
перебор неприемлемыми

Специализированные хэш-функции:
› RFC-8018 (PKCS#5 v2.1) PBKDF2-SHA2
› RFC-7914 scrypt
› RFC draft-irtf-cfrg-argon2-04 Argon2
PBKDF2/scrypt/argon2 usage
PBKDF2(password, salt, iterations, keyLen)
scrypt(password, salt, costFactor, blockSize, parallelizationFactor, keyLen)
argon2(password, salt, parallelizationFactor, tagLen, memSize, iterations, keyLen)
Где:
› password - пароль пользователя
› salt - случайные данные
› keyLen - желаемый размер полученного хэша, бит
› iterations, costFactor, blockSize, parallelizationFactor, tagLen, memSize
подбираются экспериментально для максимальной приемлемой загрузки
CPU/GPU/RAM
Хранение паролей

Рекомендации:

› Используйте тяжелые хэш-функции PBKDF2, scrypt, argon2


› Уникальная случайная salt для каждого пароля
› Время вычисления хэш-функции подбирайте максимально
приемлемое для вашего оборудования
Аутентификация сообщений: HMAC

Hash-based Message Authentication Code (имитовставка)


Позволяет добавить к сообщению контрольный код для проверки:
› Аутентичности сообщения
› Целостности сообщения

Стороны коммуникации используют общий секретный пароль


HMAC authentication
Почему HMAC?
Обычные хэш-функции уязвимы для length extension attack: добавляя
блоки данных к сообщению можно подобрать нужное значение хэша,
если аргумент хэш-функции это конкатенированные пароль и
сообщение.

https://en.wikipedia.org/wiki/Length_extension_attack Пример

count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo\x80\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x28&waffle=liege
RFC-2104 HMAC

Задача подбора хэша усложняется многократно за счет сокрытия состояния


внутренней хэш-функции
› H - хэш-функция c размером блока B (512 бит для SHA-2)

› m - сообщение, K - секретный пароль

› K’ - нормализованный по размеру блока B пароль K

› opad - массив байт 0x5C, ipad - массив байт 0x36, zpad - массив байт 0x00, длина соответствует размеру B
Аутентификация: Replay Attack

Свойства хэш-функций:
› Повторяемость: одинаковые данные порождают одинаковый digest


Один и тот же аутентификационный hash/hmac digest можно


использовать для повторного исполнения операций

Аутентификация: Replay Attack

Как защититься:
Добавлять уникальные данные к каждому сообщению
Подходы:
› Время создания сообщения и ограничение на срок давности сообщения
› Уникальный серийный номер сообщения и контроль повторных
запросов по серийному номеру
› Уникальное случайное число и контроль повторных запросов
HMAC recap

Рекомендации:
› min SHA-2 в качестве базовой хэш-функции
› Каждое сообщение должно содержать уникальные данные
Java recap
› Hash: java.security.MessageDigest
› HMAC: javax.crypto.Mac
› PBKDF2: javax.crypto. [SecretKeyFactory & spec.PBEKeySpec]
https://docs.oracle.com/en/java/javase/11/security/java-cryptography-
architecture-jca-reference-guide.html
https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-
names.html#messagedigest-algorithms
https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-
names.html#mac-algorithms
Random numbers
Случайные числа
Применение случайных чисел

› Создание ключей и секретов


› Зашумление данных для затруднения анализа
› Статистическое моделирование
Свойства случайных чисел

› Непредсказуемость (unpredictable)
› Равномерное распределение (uniform
distribution)
› Отсутствие связи с предыдущими
значениями (non-deterministic)

https://www.random.org/randomness/
Hardware Random Number Generators (HRNG)
Основаны на физических процессах:
› Тепловой шум полупроводников
› Радиошум атмосферы
› Фотоэлектрические эффекты
полупроводников
› Квантовый шум радиоактивных
материалов
HRNG имеют ограниченную
производительность, но высокий
randomness
Pseudo-Random Number Generator (PRNG)

› PRNG это программная реализация генератора


› Неограниченная производительность
› Для инициализации используются истинно случайные данные (seed),
последующие значения вычисляются
Основные виды PRNG
› Linear congruential generator (java.util.Random, many Math.random() impls)


› Mersenne Twister
› WELL
› На основе хэш-функций (java.security.SecureRandom)
› На основе блочных и потоковых шифров
› Сбор энтропии из операционной системы (/dev/(u)random,
java.security.SecureRandom)
HRNG vs PRNG
Linux PRNG

The random number generator gathers environmental noise from device


drivers and other sources into an entropy pool.
@see: man 4 random


Устройства:
› /dev/random — выборка из entropy pool, чтение блокируется до
накопления энтропии, малое количество данных
› /dev/urandom — выборка из entropy pool и использование хэш-функций,
чтение не блокируется, количество данных неограниченно
java.security.SecureRandom

› Является PRNG по умолчанию


› Может обращаться к HRNG через PKCS#11 драйвер
› Реализация зависит от платформы на которой выполняется JVM
› Thread-safe but synchronized
› Для инициализации как правило использует /dev/random
› Создание множества экземпляров SecureRandom может заблокировать
JVM на неопределенное время (ожидание накопления entropy pool)
Рекомендации

› Всегда используйте SecureRandom


› Используйте экземпляры SecureRandom повторно
› Создайте пул экземпляров SecureRandom в многопоточной среде
› Периодически обнуляйте данные экземпляра
SecureRandom.reseed(), но не одновременно всех экземпляров
UUIDv4 в качестве идентификатора

› UUIDv4 (random UUID) содержит 122bit случайное число


› Создается из PRNG способом специфичным конкретной реализации
› Можно использовать как идентификатор в ограниченном промежутке
времени в рамках ограниченного контекста
› Нельзя использовать как глобально уникальный идентификатор
› Вероятность дубля для идеального randomness


Проверяйте на основе какого PRNG сделана реализация UUID


Java recap

› java.util.Random
› java.security.SecureRandom
› https://docs.oracle.com/en/java/javase/11/security/java-
cryptography-architecture-jca-reference-guide.html
› https://docs.oracle.com/en/java/javase/11/docs/specs/security/
standard-names.html#securerandom-number-generation-algorithms
› https://www.random.org/randomness/
Symmetric key ciphers
Шифры с симметричным
ключом
Шифрование

› Шифрование решает задачу соблюдения конфиденциальности обмена


информацией
› Только получатель, обладающий секретным ключом, может прочитать
сообщение


https://en.wikipedia.org/wiki/Encryption
Symmetric key ciphers

Фундаментальная проблема: как безопасно передать ключ?


Шифр Цезаря
› Каждый символ текста заменяется
символом алфавита с фиксированным
сдвигом
› Величина сдвига это секретный ключ
Symmetric key ciphers

Разновидности:
› Блочные шифры (Block ciphers)
› Потоковые шифры (Stream ciphers)

Разделение довольно условное


Block cipher
› Сообщение шифруется блоками
фиксированного размера
› Шифротекст это последовательность блоков
› Размер блока определяется алгоритмом и не
всегда соответствует размеру ключа
› Если размер сообщения не кратен размеру
блока, последний блок дополняется до
границы блока (padding)
Выравнивание по границе блока (Padding)

Padding — это заполнение свободного пространства последнего блока


шифротекста, если размер данных не кратен размеру блока

› NoPadding/Zero — заполнение нулями


› PKCS5/PKCS7 — заполнение числом оставшихся байт до границы блока
› ISO 10126 — заполнение случайными числами
Stream cipher

› Основаны на генерации псевдослучайного


потока данных (keystream) и объединения
данных сообщения с ним (XOR)
› Keystream определяется алгоритмом
шифрования
› Keystream формируется из ключа (key),
параметра инициализации (iv) и счетчика
последовательности
Output Feeback (OFB) block cipher mode
› Блочный шифр в режиме генерации keystream
› Данные объединяются с блоками key stream
Алгоритмы шифрования

Устаревшие, не рекомендуются к применению:


› DES, 3DES, Blowfish, RC*, IDEA
Широко используемые:
› AES (Rijndael), ГОСТ 28147-89
Перспективные:
› ChaCha20 (RFC-8439), Кузнечик (ГОСТ Р 34.12-2015)
Deterministic encryption

› Детерминизм — предопределенность
› Шифр для тех же данных и ключа формирует тот же шифротекст. Это
приводит к повторению характерных последовательностей исходных
данных в шифротексте.


Determinism is the philosophical idea that all events, including moral choices,
are determined completely by previously existing causes.
https://en.wikipedia.org/wiki/Determinism
Deterministic encryption
Результат deterministic encryption:

Сообщение Шифротекст
Non-deterministic encryption
Данные шифра должны стать псевдослучайными, для этого применяются
приемы с подмешиванием случайных данных

Сообщение Шифротекст
Initialization Vector (IV)

› Случайные данные для инициализации шифра


› Размер IV равен размеру блока шифра
› Не являются секретом, передаются вместе с шифротекстом
› IV должен быть уникален для каждого шифротекста
Cipher Block Chaining (CBC) mode
› Для инициализации шифра используются случайные данные
(initialization vector)
› Псевдослучайный результат шифрования блока используется для
инициализации следующего блока
Output Feeback (OFB) mode
› Для инициализации шифра используются случайные данные
(initialization vector)
› Блочный шифр в режиме генерации псевдослучайного keystream
› Процедуры шифрования и дешифрования одинаковы
Counter (CTR) mode
› Для инициализации шифра используются случайные данные (nonce)
› Блоки независимы друг от друга (параллелизация шифра)
› Процедуры шифрования и дешифрования одинаковы
Authenticated Encryption (AE)

› Как проверить целостность шифротекста?


› Как обеспечить невозможность добавления посторонних данных?
Authenticated Encryption (AE)
К шифротексту добавляется 

authentication tag (имитовставка) как
результат расчета контрольного значения
(Message Authentication Code — MAC) от:
› Encrypt-then-Mac — от шифротекста
› Encrypt-and-Mac — от сообщения
› Mac-then-Encrypt — зашифровывается
сообщение и mac от сообщения
Authenticated Encryption with Associated Data (AEAD)

Возможность прикрепить к шифротексту открытые данные и


проверить их аутентичность

Например, логин или IP-адрес получателя шифропакета
javax.crypto.Cipher.updateAAD() [Additional Authentication Data]
Алгоритм AES Galois/Counter Mode (AES-GCM)
› Реализует CTR mode и AEAD
› Индустриальный стандарт
› Эффективный алгоритм + hardware


На схеме:
› iv — Initialization Vector

› Auth data — Associated Authentication Data

› Ek — функция шифрования блока

› mult — Galois field multiplication function 



(GMAC)
Алгоритм ChaCha20-Poly1305 (RFC-8439)
› Реализует CTR mode и AEAD
init counter init counter
› ChaCha20 алгоритм шифрования
› Poly1305 функция MAC

mac key plaintext


› Быстрее AES-GCM

ciphertext
› Включен в TLSv1.3

ciphertext len(plaintext) || len(ciphertext)

mac key

Auth tag
Рекомендации для общего случая

› Используйте AES-GCM или ChaCha20-Poly1305 с размером ключа 256 бит


и IV размером 128 бит
› IV должен быть уникален для каждого шифропакета
Java recap
› javax.crypto.Cipher
› javax.crypto.spec.GCMParameterSpec & ChaCha20ParameterSpec
› java.security.AlgorithmParameterSpec
› https://docs.oracle.com/en/java/javase/11/security/java-
cryptography-architecture-jca-reference-guide.html
› https://docs.oracle.com/en/java/javase/11/docs/specs/security/
standard-names.html#cipher-algorithm-names
› https://docs.oracle.com/en/java/javase/11/docs/specs/security/
standard-names.html#cipher-algorithm-modes
Digital signature
Электронная подпись
Электронная подпись

Добавляется к сообщению и позволяет его получателю удостоверить:


› Авторство сообщения (Authentication)
› Целостность и неизменность сообщения (Integrity)
› Невозможность отказа от авторства (Non-repudiation)
› Невозможность подделки сообщения (Forgery/Tampering)

Электронная подпись не шифрует данные, они остаются открытыми


63-ФЗ “Об электронной подписи”

Статья 5. Виды электронных подписей


› Простая электронная подпись


› Усиленная неквалифицированная электронная подпись
› Усиленная квалифицированная электронная подпись

http://legalacts.ru/doc/FZ-ob-jelektronnoj-podpisi/
63-ФЗ “Об электронной подписи”, Статья 5

2. Простой электронной подписью является электронная подпись, которая


посредством использования кодов, паролей или иных средств
подтверждает факт формирования электронной подписи
определенным лицом

63-ФЗ “Об электронной подписи”, Статья 5

3. Неквалифицированной электронной подписью является электронная 



подпись, которая:
1. получена в результате криптографического преобразования
информации с использованием ключа электронной подписи;
2. позволяет определить лицо, подписавшее электронный документ;
3. позволяет обнаружить факт внесения изменений в электронный
документ после момента его подписания;
4. создается с использованием средств электронной подписи.
63-ФЗ “Об электронной подписи”, Статья 5

4. Квалифицированной электронной подписью является электронная 



подпись, которая соответствует всем признакам неквалифицированной 

электронной подписи и следующим дополнительным признакам:
1. ключ проверки электронной подписи указан в квалифицированном
сертификате;
2. для создания и проверки электронной подписи используются средства
электронной подписи, имеющие подтверждение соответствия
требованиям, установленным в соответствии с настоящим
Федеральным законом.
63-ФЗ “Об электронной подписи”, Статья 6

1. Информация в электронной форме, подписанная квалифицированной


электронной подписью, признается электронным документом,
равнозначным документу на бумажном носителе, подписанному
собственноручной подписью, и может применяться в любых
правоотношениях в соответствии с законодательством Российской
Федерации, кроме случая, если федеральными законами или
принимаемыми в соответствии с ними нормативными правовыми
актами установлено требование о необходимости составления
документа исключительно на бумажном носителе.
63-ФЗ “Об электронной подписи”, Статья 6

2. Информация в электронной форме, подписанная простой электронной


подписью или неквалифицированной электронной подписью,
признается электронным документом, равнозначным документу на
бумажном носителе, подписанному собственноручной подписью, в
случаях, установленных федеральными законами, принимаемыми в
соответствии с ними нормативными правовыми актами или
соглашением между участниками электронного взаимодействия.
Виды электронных подписей

Простая подпись:
› Логин-пароль, токен авторизации, HMAC, OTP
Усиленная неквалифицированная подпись:
› Алгоритмы асимметричной криптографии
Усиленная квалифицированная подпись:
› Алгоритмы асимметричной криптографии с использованием
сертифицированных средств криптографической защиты информации
(СКЗИ) и сертификата уполномоченного удостоверяющего центра (УЦ)
Digital signature with asymmetric cryptography
Создается пара ключей:

› Private (закрытый), остается у


отправителя как секрет
› Public (открытый), отправляется
получателю в открытом виде

Должен использоваться генератор


случайных чисел с высоким randomness
Digital signature with asymmetric cryptography

К сообщению добавляется подпись:

› Подпись формируется закрытым


(private) ключом
› Подпись проверяется открытым
(public) ключом
Алгоритмы электронной подписи

Устаревшие, не рекомендуются к применению:


› ElGamal, DSA, ГОСТ Р 34.10-94, ГОСТ Р 34.10-2001, RSA
Широко используемые:
› RSA, ECDSA (NIST), ГОСТ Р 34.10-2012
Перспективные:
› ECDSA & EdDSA curves (Curve25519, Curve41417, Ed448-Goldilocks, M-383)
Алгоритм RSA (Rivest-Shamir-Adleman)

› Предложен в 1977г
› Основан на вычислительной сложности задачи
факторизации произведения двух больших
простых чисел
› Факторизацией натурального числа
называется его разложение в произведение
простых множителей (простых чисел)
› Простое число не может быть разложено в
произведение целых чисел больших 1
RSA: Создание ключей

1. Выбираются два различных случайных простых числа p и q заданного


размера
2. Вычисляется d которое называется modulus
3. Вычисляется значение функции Эйлера:
4. Выбирается число e ( ), взаимно простое со значением
5. Вычисляется число
6. PublicKey состоит из n (modulus) и e (public exponent)
7. PrivateKey состоит из n (modulus), d (private exponent) и e
RSA Private key
Пример

$ openssl rsa -in CA-rsa/private/server1-rsa-key.pem -noout -text


RSA Private-Key: (2048 bit, 2 primes)
modulus:
00:a1:51:37:4b:3b:d7:6e:17:c3:5e:b0:65:6c:0e:
.....
04:92:be:cb:72:69:93:b1:0e:c6:70:3c:f7:02:11:
fc:ab
publicExponent: 65537 (0x10001)
privateExponent:
7e:a9:88:62:f8:2f:a4:ef:df:a4:ff:98:03:0a:40:
.....
48:a6:ae:a6:4a:17:e1:c0:4d:a9:de:a1:ad:e5:3b:
f1
Алгоритм RSA
› Для целых чисел e, d, n при условии выполняются
соотношения:

› При известных e, n, m (сообщение) чрезвычайно сложно вычислить


значение d (закрытый ключ)
› Размер сообщения (m) не может превышать modulus (n), поэтому
алгоритм применяется к digest от сообщения
RSA: Формирование подписи
1. Сформировать digest сообщения:
h = hash (message)
2. Сформировать подпись (s) при помощи закрытого ключа (n, d):
RSA: Проверка подписи
1. Сформировать digest сообщения:
h = hash (message)
2. Вычислить прообраз digest из подписи (s) при помощи открытого
ключа (n, e):


3. Проверить условие

RSA: Разновидности подписей

Размер digest обычно меньше размера modulus, данные выравниваются по


размеру modulus:


› RSASSA-PKCS1-v1_5: deterministic подпись, выравнивается


фиксированными байтами по границе modulus


› RSASSA-PSS (probabilistic signature scheme): подпись зашумлена


случайными данными (salt)
RFC-8017 RSASSA-PSS
› Алгоритм кодирования данных до
размера modulus перед
формированием подписи
› Зашумляет сообщение (M) и его
digest случайными данными (salt)
› MGF — Mask Generation Function
› EM подписывается алгоритмом RSA
› Размер salt выбирается для
получения EM равному modulus
› https://rsapss.hboeck.de/rsapss.pdf
RSA: Рекомендации

› Размер ключа min 2048 bit


› Digest фунция min SHA-2 (SHA-256)
› RSASSA-PSS
› SecureRandom для создания ключей
› Уникальные данные сообщения для каждой подписи
Алгоритмы ECDSA и ГОСТ Р 34.10-2012

Реализации Elliptic Curve Cryptography (ECC, 1985г) является основой


стандартов:
› Elliptic Curve Digital Signature Algoritm (ECDSA, США, ANSI X9.62 1998г,
NIST FIPS 186-2 2000г, FIPS 186-3 2009г, SECG-1 2009г)
› ГОСТ Р 34.10-2001 (РФ, 2001г)
Алгоритмы ECDSA и ГОСТ Р 34.10-2012

› Длительное время был закрыт патентами


› Основан на решении сложной вычислительной задачи вычисления
дискретного логарифма в группе точек эллиптической кривой (elliptic
curve discrete logarithm problem, ECDLP)
Elliptic Curves (EC)
Эллиптические кривые описываются
уравнением:

Вид кривой определяется


коэффициентами a и b.
Для задач криптографии должно
выполняться условие:

(отсутствие пересечений кривой)


Elliptic Curves

Свойства эллиптической кривой:


1. Если провести линию через две точки
(P и Q), то линия обязательно
пересечет третью точку (R)
2. Третьей точке всегда соответствует
симметричная точка на кривой (-R),
которая определяет операцию
сложения точек кривой:
Elliptic Curves
Если принять что Q = P, то можно определить
операцию удвоения точки:
Elliptic Curves
Определим операцию умножения точки
-2P на степень двойки (2, 4, 8, 16,…) 

P
как последовательное удвоение точки
-4P 8P
необходимое число раз

-8P
4P
2P
Elliptic Curves
Определим операцию умножения точки на целое число как совокупность
операций удвоения и сложения точек (double and add multiplication method)

Например:
Elliptic Curves
› Для криптографических задач подходят
целые положительные числа
› Криптографические операции производятся
в конечном поле целых чисел Fp, то есть в
множестве целых чисел от 0 до p-1
› Значения a и b выбираются в поле Fp, тогда


› Координаты точек P, Q, R будут в поле Fp


Elliptic Curves
› Операция умножения точек кривой


› Координаты произведения точек циклически


повторяются относительно базовой точки G
(generator/base point) и образуют циклическую
группу порядка n
› Кофактор группы
Elliptic Curves
Определение эллиптической кривой (EC domain parameters) содержит:

› Целое число p (prime) — порядок поля Fp


› Коэффициенты a и b в поле значений Fp
› Координаты базовой точки кривой G (generator point)
› Относительно которой образуется циклическая группа точек порядка n
(order) кофактора h (cofactor)
Elliptic Curves Discrete Logarithm Problem
Если известны координаты точек P и Q, то каким будет число d, такое что

в поле значений координат точек эллиптической кривой?


› При известных d и P точка Q вычисляется тривиально


› При известных P и Q найти число d, то есть вычислить

потребует нахождения огромного количества комбинаций
Elliptic Curves
Поиск и определение параметров эллиптических кривых это сложная
математическая задача. Криптостойкость системы зависит от выбранных
параметров кривой и координат базовой точки.
› Наборы параметров эллиптических кривых стандартизованы
› Имеют стандартные идентификаторы, например “secp256r1”
› TLS / OpenSSL / Java содержат пакет определений параметров
› Существуют классы слабых эллиптических кривых
› Параметры эллиптических кривых для СКЗИ по ГОСТ Р 34.10-20*
непубличны, определяются поставщиками СКЗИ
Идентификаторы определений кривых
Пример

$ openssl ecparam -list_curves


secp256k1 : SECG curve over a 256 bit prime field
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field
prime239v3: X9.62 curve over a 239 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field
brainpoolP192r1: RFC 5639 curve over a 192 bit prime field
brainpoolP192t1: RFC 5639 curve over a 192 bit prime field
brainpoolP224r1: RFC 5639 curve over a 224 bit prime field
brainpoolP224t1: RFC 5639 curve over a 224 bit prime field
brainpoolP384r1: RFC 5639 curve over a 384 bit prime field
Параметры Elliptic Curves

Устаревшие, не рекомендуются к применению:


› SECG/NIST/ANSI порядка менее 256 bit
Широко используемые:
› NIST P-256 (secp256r1, prime256v1), secp256k1 (Bitcoin),
Curve25519/x25519, brainpoolP*
Перспективные:
› Curve41417, Ed448-Goldilocks/x448, M-383
Elliptic Curves: Создание ключей
1. Выбрать эллиптическую кривую (curve) с параметрами (p, a, b, G, n, h)
2. Выбрать случайное число d, такое что
3. Вычислить координаты точки
4. PrivateKey содержит число d и идентификатор кривой
5. PublicKey содержит координаты точки и идентификатор кривой
6. Размерность ключей определяется размерностью параметра кривой p
EC Private key
Пример

$ openssl ec -in server1-secp256r1-key.pem -text -noout


Private-Key: (256 bit)
priv:
3c:df:a3:88:ed:02:30:29:0f:b7:ab:ca:97:98:e5:
d0:8c:a0:f7:ee:f0:4e:d7:64:ee:cc:bf:31:8f:83:
0a:9d
pub:
04:e4:d0:ec:11:d8:54:6c:14:d8:0a:6e:95:0b:ed:
fb:57:86:b4:fa:3b:ef:f1:f1:b9:bf:94:14:f7:3b:
61:99:9a:57:da:de:38:2f:82:41:8b:c3:d7:aa:7e:
16:5f:6d:b3:cd:0b:aa:d7:0b:db:f1:3b:2b:40:90:
aa:6a:5f:c9:71
ASN1 OID: prime256v1
NIST CURVE: P-256
Elliptic Curves Digital Signature Algorithm
Определим сумму двух точек:
› Message point (h = hash (message))
› Random point (k случайное число, Q - public key)

› Подпись это Random point и Signature Point (сумма)


› Проверка подписи: проверка координат Random point по
известным Signature point и Message point
ECDSA: Формирование подписи
1. Сформировать digest сообщения размерности n
h = hash (message)
2. Сформировать случайное число
3. Вычислить координаты Random point
4. Вычислить
5. Вычислить Signature factor используя Private key (d)


6. Подпись это пара чисел r и s


ECDSA: Проверка подписи
1. Сформировать digest сообщения размерности n
h = hash (message)
2. Вычислить 


3. Вычислить координаты verification point используя Public key (Q)


4. Проверить условие 

(verification point = random point)
ECDSA: Рекомендации

› Выбирайте публичные и проверенные сообществом параметры


эллиптических кривых
› Выбирайте хэш-функцию размерности не менее порядка группы
точек эллиптической кривой (n)
› Используйте SecureRandom для создания ключей
› Используйте уникальные данные для каждой подписи
ECDSA vs RSA
› Ключи меньшего размера (256bit vs 2048bit)
› Подписи меньшего размера (512bit vs 2048bit)
› Формирование подписи быстрее в 26 раз
› Проверка подписи медленнее в 2,7 раз
› Ключи RSA не совсем случайны
Данные для ECDSA NIST P-256 vs RSA-2048

$ openssl speed -multi 4 rsa2048 ecdsap256


OpenSSL 1.1.1a / Darwin Kernel Version 18.2.0
ECDSA vs RSA
Алгоритм EdDSA

› Разновидность ECDSA на основе Twisted


Edwards Curves, 2011г
› Основан на тех же принципах, но использует
другое определение кривой
(Curve25519(x25519), Ed448-Goldilocks(x448))
› Вычисления несколько быстрее ECDSA
(примерно в 1,86 раз для Ed25519 vs NIST
P-256)
› Community альтернатива NSA/NIST
Аутентификация: Replay Attack

Для одних и тех же данных и ключей формируется та же электронная


подпись. Старую подпись можно использовать повторно.
Аутентификация: Replay Attack

Как защититься:
Добавлять уникальные данные к каждому сообщению
Подходы:
› Время создания сообщения и ограничение на срок давности
сообщения
› Уникальный серийный номер сообщения и контроль повторных
запросов по серийному номеру
› Уникальное случайное число и контроль повторных запросов
Java recap

› java.security.Signature
› java.security.PublicKey & java.security.PrivateKey
› java.security.KeyPairGenerator
› https://docs.oracle.com/en/java/javase/11/security/java-
cryptography-architecture-jca-reference-guide.html
› https://docs.oracle.com/en/java/javase/11/docs/specs/security/
standard-names.html#signature-algorithms
Asymmetric key encryption
Шифрование с
асимметричным ключом
Проблема шифров с симметричным ключом

Как безопасно передать ключ шифрования удаленной стороне?


Asymmetric key encryption
Создается две пары ключей для сторон обмена
(Alice & Bob):
› Private (закрытые) ключи остаются у сторон
как секрет
› Стороны обмениваются Public (открытыми)
ключами по открытым каналам связи


Должен использоваться генератор случайных


чисел с высоким randomness
Asymmetric key encryption

› Для зашифровывания нужен открытый ключ получателя и приватный


ключ отправителя
› Для расшифровывания нужен открытый ключ отправителя и приватный
ключ получателя
› Используются те же базовые алгоритмы что и для электронных
подписей (RSA и EC)
Asymmetric key encryption

Ограничения:
› Для RSA возможно зашифровать блок данных размера modulus
открытого ключа
› Для ECC операция шифрования не определена
RSA encryption
› Операция зашифровывания

› Операция расшифровывания

› PublicKey(e, n), PrivateKey(d, n)


› m — сообщение размера не более n, c — шифротекст
Проблема: это deterministic encryption, для тех же данных и ключа
формирует тот же шифротекст, это приводит к повторению характерных
последовательностей в данных
RFC-8017 RSA-OAEP encryption
› Optimal Asymmetric Encryption Padding (OAEP,
RFC-8017) зашумляет сообщение (m)
случайными данными (r)
› G — Mask Generation Function (MGF1-SHA-512)
› H — хэш-функция (SHA-512)
› Конкатенация X|Y зашифровывается RSA
› Для каждого сообщения — уникальный r
› Можно зашифровать не более

байт

(1008 бит для 2048 бит ключа при SHA-512)
Asymmetric key encryption

› Как шифровать данные произвольного


размера?
› Как шифровать данные в потоковом режиме?
Asymmetric key encryption
Ответ:


› Шифрование с симметричным
ключом, используя протокол
выработки общего секрета (shared
secret) из двух пар ключей (private,
public) сторон обмена (key agreement
protocol)
Key Agreement Protocol
Разновидности:


› Key encapsulation method (KEM)


› Diffie-Hellman (DH)
› Elliptic Curve Diffie-Hellman (ECDH)
Key Encapsulation Method (KEM)
1. Используется совместно с RSA encryption
2. Отправитель создает симметричный ключ как случайное число
3. Отправитель шифрует симметричный ключ на публичный ключ
получателя
4. Получатель расшифровывает симметричный ключ своим приватным
ключом
5. Стороны используют шифр с общим симметричным ключом
Diffie-Hellman (DH) Key Agreement

› Основан на тех же принципах, что и RSA — вычислительной сложности


задачи факторизации произведения больших простых чисел (1976г)
› Стороны заранее выбирают случайные простые числа p и g так, чтобы
они образовывали мультипликативную группу — множество целых
чисел взаимно простых с g по модулю p
Diffie-Hellman (DH) Key Agreement
1. Стороны используют общие параметры мультипликативной группы: p и g
2. Сторона А создает секретное число и вычисляет
3. Сторона B создает секретное число и вычисляет
4. Стороны обмениваются числами A и B
5. Сторона A вычисляет
6. Сторона B вычисляет
7. стороны обладают общим секретом (shared secret)
Elliptic Curve Diffie-Hellman (ECDH)
1. Стороны выбирают определение кривой (p, a, b, G, n, h)
2. Стороны обмениваются открытыми ключами
3. Стороны вычисляют произведение своего приватного ключа (d) и
открытого ключа другой стороны (Q) в поле координат точек кривой


4. Общий секрет (shared secret) это координата точки x


Key Derivation Function (KDF)

› Размер shared secret определяется алгоритмом KeyAgreement и


параметрами ключей, например 414 bit
› Размер симметричного ключа шифра определяется алгоритмом
шифрования, например 256 bit
› Повторный KeyAgreement формирует тот же shared secret — это
deterministic операция
› Для каждого сеанса связи должен создаваться новый симметричный
ключ
Key Derivation Function (KDF)

› Популярный вид KDF — на основе HMAC

› shared secret в качестве password


› Информация о сессии/контексте коммуникации в качестве message
› Базовая хэш-функция разрядности размера ключа шифра

см. RFC-5869 HMAC-based Extract-and-Expand Key Derivation Function


Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)
› Способ реализации non-deterministic key agreement
› В рамках сеанса связи private key после выработки shared secret не нужен
› Для каждого сеанса связи отправитель создает новую пары ключей
(private, public) — ephemeral keys (сеансовые ключи), таким образом
симметричный ключ для каждого сеанса связи псевдослучаен
› Сообщение зашифровывается, используя сеансовый приватный и
известный открытый ключ получателя, сеансовый открытый ключ
добавляется к сообщению
› Для взаимной аутентификации сторон используются постоянные пары
ключей (private, public)
Asymmetric key encryption recap

Итого, для сеанса связи необходимо:


1. Обменяться публичными ключами
2. Выработать shared secret путем KeyAgreement protocol из двух пар
ключей (private, public)
3. Выработать симметричный ключ при помощи Key Derivation Function
из shared secret и информации о сессии связи
4. Использовать шифр с симметричным ключом для передачи данных
Java recap

› javax.crypto.KeyAgreement
› java.security.AlgorithmParameters
› java.security.PublicKey & java.security.PrivateKey
› java.security.KeyPairGenerator
› https://docs.oracle.com/en/java/javase/11/security/java-
cryptography-architecture-jca-reference-guide.html
› https://docs.oracle.com/en/java/javase/11/docs/specs/security/
standard-names.html#keyagreement-algorithms
Pretty Good Privacy (PGP)
› Программа для обмена файлами
› Разработана Philipp Zimmermann в 1991г
› Шифрование и электронная подпись
› P2P обмен ключами
› В декабре 1997г стал закрытым
коммерческим продуктом Network
Associates
› Разные версии несовместимы между
собой
GnuPG

› 1998г: появление стандарта RFC-2440 OpenPGP Message Format


› 1999г: появление открытого ПО The GNU Privacy Guard
› Время было уже упущено: появился OpenSSL

https://www.gnupg.org/
PKI и сертификаты
Public key certificate

› Удостоверяет факт принадлежности открытого ключа определенному


лицу/ресурсу
› Выдается удостоверяющим центром (УЦ, Certificate Authority, CA)
› Пользователи доверяют удостоверяющим центрам и сертификатам
ими выданным
› Это аналог заверения документа нотариусом
› Иерархия доверия образует Public Key Infrastructure (PKI)
Public key certificate

and signs it
Public key certificate
Структура определяется стандартом ITU-T X.509 / RFC-5280 и содержит:
› Открытый ключ (Public Key)
› Информацию об алгоритме, для которого этот ключ предназначен
› Информацию о владельце ключа (Subject)
› Информация об удостоверяющем центре (Issuer)
› Электронную подпись удостоверяющего центра
› Срок действия сертификата (Validity)
› Дополнительные данные (X.509v3 extensions: key usage, certificate policies)
Порядок создания сертификата

1. Сформировать ключевую пару: приватный и публичный ключи.


Приватный ключ хранить как секрет.
2. Сформировать заявку на сертификат (CSR, Certificate Signing Request) из
публичного ключа и информации о владельце ключа (Subject), отправить
CSR в удостоверяющий центр.
3. Удостоверяющий центр выпускает сертификат, добавляя к нему подпись
УЦ и информацию об УЦ.
Пример
Публичные доверенные УЦ
› Операционные системы на устройствах клиентов содержат список
доверенных удостоверяющих центров (Ubuntu Linux)

/etc/ca-certificates.conf
/etc/ssl/certs/*
man update-ca-certificates
Публичные доверенные УЦ
› Операционные системы на устройствах клиентов содержат список
доверенных удостоверяющих центров (MacOS, Keychain access)
Публичные доверенные УЦ
› Операционные системы на
устройствах клиентов
содержат список
доверенных
удостоверяющих центров
(Windows, Control Panel)
Публичные доверенные УЦ
› ПО на устройствах клиентов может содержать собственный список
доверенных удостоверяющих центров (Java, keystore)

$JAVA_HOME/lib/security/cacerts

https://docs.oracle.com/en/java/javase/11/tools/keytool.html
Публичные доверенные УЦ
› ПО на устройствах клиентов может содержать собственный список
доверенных удостоверяющих центров (Mozilla Firefox)
Цепочка доверия (chain of trust)
› Удостоверяющий центр может передоверить
выдачу сертификатов в ограниченном
контексте третьему лицу
› Образуется цепочка доверия с
промежуточным удостоверяющим центром
› Сертификат промежуточного
удостоверяющего центра выдан корневым
удостоверяющим центром
› Конечный сертификат проверяется по
цепочке на принадлежность доверенному УЦ
Certificate Revocation List (CRL)
› Сертификат может быть отозван
› Удостоверяющий центр публикует список отозванных сертификатов (CRL)
› Адрес CRL находится в конечном сертификате
Online Certificate Status Protocol (OCSP)
› CRL может быть довольно большим
› Можно проверить статус конкретного сертификата онлайн по OCSP
› Адрес сервера OCSP находится в конечном сертификате
Extended Validation (EV) certificates
› Отмечаются зеленым цветом и названием организации в строке браузера
› УЦ особо тщательно проверяет юридическое лицо, личности его
представителей и их полномочия в части владения и управления доменом
› Только УЦ, прошедшие независимый аудит, могут выдавать EV сертификаты
А можно сертификат бесплатно?

› https://letsencrypt.org/how-it-works/
› Пакет letsencrypt для Ubuntu
› Запуск агента letsencrypt на сервере для
проверки владения доменом и получения/
обновления сертификатов
› Сертификат выдается на 3 месяца
А все ли хорошо на самом деле?

› В августе 2011г взломан корневой УЦ DigiNotar


› Были выпущены сертификаты для *.google.com
› Браузеры и производители ОС экстренно выпускали обновление с
удалением DigiNotar из списка доверенных УЦ


https://security.googleblog.com/2011/08/update-on-attempted-man-in-
middle.html
https://slate.com/technology/2016/12/how-the-2011-hack-of-diginotar-
changed-the-internets-infrastructure.html
Порядок проверки сертификата

› Сертификат выдан доверенным УЦ по цепочке доверия


› Срок действия сертификата уже начался, но еще не истёк
› Сертификат не отозван УЦ по CRL или OCSP
› Данные сертификата соответствуют ресурсу, который его предъявляет
› Для веб поле CN сертификата содержит доменное имя сервера
› Данные сертификата соответствуют операции которую предполагается
совершить с ресурсом (Key usage, Certificate policies)
Java recap

› java.security.cert.X509Certificate
› java.security.cert.CertificateFactory
› java.security.cert.CertPathBuilder & CertPathValidator
› java.security.cert.CertStore
› https://docs.oracle.com/en/java/javase/11/security/java-
cryptography-architecture-jca-reference-guide.html
› https://docs.oracle.com/en/java/javase/11/tools/keytool.html
Transport Layer Security

(TLS/SSL)
Transport Layer Security (TLS)

› Протокол аутентификации подключения и


защищенной передачи данных
› HTTPS = HTTP + TLS
› Ранее назывался SSL (Secure Sockets Layer)
› Работает поверх TCP
› Для работы по UDP 

существует DTLS (Datagram TLS)
Протоколы TLS/SSL
Устаревшие, запрещены к применению:
› SSLv2, SSLv3, TLSv1
Широко используемые:
› TLSv1.1 (RFC-4346), TLSv1.2 (RFC-5246)
Внедряемые:
› TLSv1.3 (RFC-8446)
TLS session

› Логический сеанс связи


› TLS handshake — это процедура установления TLS сессии
› Одна сессия может быть использована для множества TCP-подключений
› Одна сессия может быть использована для повторных TCP-подключений
› Время жизни сессии определяется настройками сервера
› TLS handshake это “тяжелая” операция, сессии должны использоваться
повторно
TLS handshake
Процедура установления TLS сессии включает:
› Согласование используемых сторонами крипто-алгоритмов
› Взаимная аутентификация сторон обмена — проверка сертификатов
› Процедура Key Agreement — выработка симметричного ключа
шифрования
› Digest сообщений процедуры handshake подписан приватным ключом
сертификата сервера

Интерактивная схема TLSv1.3 handshake: https://tls13.ulfheim.net
TLS authentication

В рамках TLS handshake аутентификацией сторон может быть:


› Аутентификация сервера клиентом (one-way)
› Аутентификация сервера клиентом + аутентификация клиента
сервером (two-way)
TLS one-way authentication
Сервер предъявляет сертификат клиенту, клиент проверяет подлинность
сервера:
› Сертификат сервера выдан доверенным для клиента УЦ
› Сертификат сервера действителен
› Сертификат сервера соответствует запрашиваемому ресурсу и операции
› Для веб проверяется соответствие доменного имени данным
сертификата

На один IP адрес сервера можно установить только один сертификат 



(один домен)
TLS two-way authentication (client auth)

TLS one-way authentication, плюс клиент предъявляет сертификат серверу,


сервер проверяет подлинность клиента:
› Сертификат клиента выдан УЦ, которому доверяет сервер
› Сертификат клиента действителен
› Сертификат клиента соответствует запрашиваемому ресурсу и операции
(key usage, certificate policies)

Клиент может предъявлять несколько сертификатов


TLS SNI (Server Name Indication)

› Расширение протоколов TLSv1.2 и TLSv1.3, RFC-6066


› Позволяет на один IP адрес разместить несколько доменных имен
(несколько сертификатов)
› Имя домена указывается в сообщениях при TLS handshake
› Работает если поддерживается реализациями сервера и клиента
OCSP Stapling
› Расширение протоколов TLSv1.2 и TLSv1.3, RFC-6066
› Сокращение количества OCSP запросов клиентов за счет их кэширования
на сервере, OCSP ответ содержит подпись УЦ и действует конечное время
Man-in-the-Middle (MitM) attack

1. Сервер подменяется фиктивной копией, например, через запись в DNS


2. Фиктивная копия предъявляет пользователю поддельный сертификат
3. Клиент производит TLS handshake с фиктивной копией
4. Фиктивная копия прослушивает трафик пользователя


Типовой кейс: wi-fi сети ресторанов, аэропортов, гостиниц…


Man-in-the-Middle (MitM) attack

Соблюдайте правила гигиены:


› Всегда проверяйте сертификат сервера
› Не добавляйте неизвестные сертификаты в какие-либо настройки
› Не открывайте файлы сертификатов скачанные с веб-сайтов, в том числе
при регистрации в wi-fi сетях
› Не отключайте проверку сертификатов в ПО
› Своевременно обновляйте ПО (список доверенных УЦ)
TLS(SSL) certificate pinning

› Используется, когда нужно, чтобы клиент считал доверенным сертификат


сервера, выданный только определенным УЦ
› Системный список доверенных УЦ переопределяется пользовательским
списком УЦ или конечных сертификатов
› Помните о сроках действия сертификатов, при их истечении TLS
handshake перестанет работать
› RFC-7469 Public Key Pinning Extension for HTTP
CVE-2014-0160 Heartbleed
› Уязвимость в OpenSSL и Microsoft реализациях TLS,
2014г
› Некорректная обработка TLS heartbeat сообщения
(memory buffer boundary check) позволяющая
получить доступ к оперативной памяти, в частности
к приватному ключу сервера
› Риск компрометации ключей шифрования
› Риск компрометации трафика пользователей
› Был массовый перевыпуск сертификатов в 2014г
› https://nvd.nist.gov/vuln/detail/CVE-2014-0160
TLS [Perfect] Forward Secrecy (PFS)

› Компрометация приватного ключа/сертификата сервера не дает


возможности расшифровать трафик
› Для каждого TLS handshake сервер и клиент создают сеансовые
ключевые пары (ephemeral keys)
› Используется ECDHE key agreement
› Сеансовые ключевые пары уничтожаются после key agreement
TLS cipher suite (шифронабор)
› Набор криптоалгоритмов для установления сессии связи
› Клиент и сервер совместно выбирают cipher suite при TLS handshake
Пример

$ openssl s_client -connect money.yandex.ru:443


Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384

$ openssl s_client -connect google.com:443


Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-CHACHA20-POLY1305
TLS cipher suite (шифронабор)
› Формат: KeyAgreement-Authentication-Cipher-Mac
› https://www.owasp.org/index.php/TLS_Cipher_String_Cheat_Sheet
Пример

$ openssl s_client -connect money.yandex.ru:443


Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384

$ openssl s_client -connect google.com:443


Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-CHACHA20-POLY1305
HTTP/2 и TLS

› RFC-7540 Hypertext Transfer Protocol (HTTP) version 2


› Использует RFC-7301 ALPN extension протокола TLSv1.2+ для установки
сессии HTTP/2
› Обязательный TLSv1.2+ для работы по HTTP/2
Что TLSv1.3 грядущий нам готовит?

› RFC-8446 утвержден в августе 2018г


› Оптимизирована структура протокола, handshake стал быстрее
› Обязательный Forward Secrecy (ECDHE, DHE)
› Обязательный Authenticated Encryption 

(AEAD шифры: AES-GCM и ChaCha20-Poly1305)
› Static RSA и Diffie-Hellman KeyAgreement запрещены как устаревшие
› EdDSA кривые для сертификатов и KeyAgreement: x25519, x448
Java recap

› java.net.ssl.X509TrustManager
› javax.net.ssl.SSLSocketFactory
› javax.net.ssl.SSLContext
› javas.net.ssl.SSLSession
› https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-
extension-jsse-reference-guide.html
› https://docs.oracle.com/en/java/javase/11/docs/specs/security/
standard-names.html#sslcontext-algorithms
Рекомендации
Всегда проверяйте сертификат сервера
Перед тем как вводить ваши пароли, особенно в финансовых сервисах
Выбирайте публичные алгоритмы
› Алгоритм и его параметры описаны и объяснены в открытых источниках
› Проверены открытым сообществом на отсутствие уязвимостей


I no longer trust the constants. I believe the NSA has manipulated them
through their relationships with industry.
If researchers don't go public, things don’t get fixed. Companies don't see it as
a security problem; they see it as a PR problem.
Bruce Schneier


https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number
Читайте индустриальные стандарты

› https://www.ietf.org/standards/rfcs/
› https://www.gost.ru/portal/gost/home/standarts

Где отсутствует точное знание, там действуют 



догадки, а из десяти догадок девять — ошибки.
Максим Горький
Дополнительно почитать

TLSv1.3
https://tools.ietf.org/html/rfc8446
https://tools.ietf.org/html/rfc8447
Дополнительно почитать

AES-GCM
https://csrc.nist.gov/publications/detail/sp/800-38d/final

ChaCha20/Poly1305
https://tools.ietf.org/html/rfc8439
Дополнительно почитать

RSA
https://tools.ietf.org/html/rfc8017 


Elliptic Curve Crypto (ECC) & ECDSA


http://www.secg.org/sec1-v2.pdf
http://docs.cntd.ru/document/gost-r-34-10-2012
https://www.math.brown.edu/~jhs/Presentations/WyomingEllipticCurve.pdf
https://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-
gentle-introduction/
Дополнительно почитать

EdDSA
https://tools.ietf.org/html/rfc8032
https://tools.ietf.org/html/rfc8410
Благодарю за внимание
Роман Цирульников
Архитектор ИТ-решений

romanvt@yamoney.ru
@romanvt