Dsa ключи что это
Аутентификация на сетевом оборудовании через SSH с помощью публичных ключей
По умолчанию инженеры подключаются к сетевому оборудованию с помощью имени пользователя и пароля. По протоколу Telnet учетные данные пользователя передаются в открытом виде, а по протоколу SSH в зашифрованном. Чтобы не передавать секретную часть по сети, используется аутентификация по публичным ключам. При такой аутентификации публичный ключ пользователя заранее прописывается пользователю на оборудовании. Секретный ключ по сети не передается.
Это руководство поможет вам быстро начать использовать публичные ключи для аутентификации при подключении к сетевому оборудованию по протоколу SSH. Руководство применимо как для Windows, так и для Mac OS X. Я постарался сделать его максимально простым и информативным. Оно не перегружено, но отвечает на основные вопросы:
Содержание
Введение
Кроме стандартной аутентификации по паролю (password/keyboard) в протоколе SSH существует также аутентификация по публичному ключу (RSA).
Аутентификация с помощью RSA-ключей состоит из нескольких этапов:
Документ Secure Shell Configuration Guide, Cisco IOS Release 15E:
Secure Shell Configuration Guide, Cisco IOS Release 15E
Restrictions for Secure Shell Version 2 Support
Rivest, Shamir, and Adleman (RSA) key generation is an SSH server-side requirement. Devices that act as SSH clients need not generate RSA keys.
Попытка ввести данные DSA-ключа:
Создание публичного RSA-ключа
Пару RSA-ключей можно создать с помощью различных утилит: SecureCRT, PuTTYgen или любым другим ПО. При создании ключа можно задать Passphrase (защита ключа с помощью пароля).
Генерирование RSA-пары в SecureCRT
SecureCRT → Tools → Create Public Key…:
Чуть-чуть теории → кнопка “Next >”:
Тип сертификата RSA/DSA → Выбираем RSA → кнопка “Next >”:
Пароль шифрования для секретного ключа (необязательно, можно оставить пустым и не шифровать) + Комментарий → кнопка “Next >”:
Выбираем длину ключа (в версии SecureCRT 6.1.0 максимальная длина ключа равна 2048 бит, в версии 8.5.4 — 16 384 бит):
Генерирование ключа → кнопка “Next >”:
Для генерирования случайных чисел нужно просит поводить мышкой в рамках окна.
Сохранение пары ключей → Выбор места хранения → Выбор формата сохраняемого ключа (VanDuke Private format, OpenSSH legacy, OpenSSH new) → кнопка “Finish”:
SecureCRT спрашивает, делать ли данный ключ ключом по умолчанию для SecureCRT:
Генерирование RSA-пары в PuTTYgen
Выбираем параметры (тип пары: RSA; битная размерность ключа: 2048; по желанию задаём Passphrase (защита ключа с помощью пароля)) → Generate:
Для гарантирования случайных чисел просит поводить мышкой в рамках окна. Это защита от псевдослучайных чисел.
Сохраняем RSA-ключи → Кнопка «Save private key»:
Обратите внимание: RSA-ключи, сохраненные в частном формате в одном ПО, нельзя использовать в ПО другого производителя. То есть пара RSA-ключей, созданных в PuTTYgen и сохраненных в формате Putty Private Key, не подходит для использования в SecureCRT, и наоборот. PuTTY поддерживает только формат Putty Private Key. Универсальным решением для распространения ключей является конвертирование ключей в формат OpenSSH (Смотри ссылку 2: “Conversion from Putty to SecureCRT with auth. keys”). Т. к. SecureCRT свободно работает с форматом OpenSSH. А ПО PuTTYgen преобразует формат OpenSSH в формат Putty Private Key.
Конвертирование RSA-ключа из формата Putty Private Key (PuTTY) в формат OpenSSH (SecureCRT)
Чтобы использовать в SecureCRT RSA-ключи, которые сгенерированы в PuTTYgen и сохранены в формате Putty Private Key (*.ppk), экспортируем их с помощью PuTTYgen в формат OpenSSH:
Конвертирование RSA-ключа из формата VanDyke Private Key (SecureCRT) в формат Putty Private Key (PuTTY)
Чтобы использовать в PuTTY RSA-ключи, которые сгенерированы в SecureCRT и сохранены в формате VanDyke Private Key (файл публичного ключа — *.pub, файл секретного ключа *. (без расширения)), экспортируем их с помощью SecureCRT в формат OpenSSH, а затем с помощью PuTTYgen экспортируем в формат Putty Private Key (*.ppk):
Генерирование публичных ключей на MAC OS X средствами операционной системы
Будем использовать встроенную утилиту ssh-keygen (man ssh-keygen).
Генерируем RSA-ключ с длиной 2048 бит с указанием имени ключа, путем к папке с местом хранения ключа:
Во время выполнения программа спросит пароль для защиты RSA-ключа:
Генерируем RSA-ключ с длиной 4096 бит в с указанием имени ключа, путем к папке с местом хранения ключа, пароль задаем в явном виде в параметрах генерации ключа (-N «cisco»):
Не рекомендуемые параметры генерации ключей: ненадёжный ключ длиной 1024 бита, с указанием имени ключа, путем к папке с местом хранения ключа, пароль задаем в явном виде в параметрах генерации ключа (-N «» – без пароля):
Итак, мы создали три ключа в с указанием имен ключей и указанием места хранения ключей (по умолчанию все ключи сохраняются в /Users/[Username]/.ssh).
По умолчанию, при подключении по SSH с аутентификацией по публичному ключу, происходит последовательный перебор всех публичных ключей, которые хранятся в папке /Users/[Username]/.ssh.
Ключ R6: переименуем ключ в “id_rsa” (по умолчанию имя файла генерируемого ключа “id_rsa”) и перенесем в папку с SSH-ключами (
/.ssh/) (Т. е. выполним все действия, чтобы ключ R6 использовался как основной ключ для подключений по SSH по умолчанию):
Преобразуем публичный OpenSSH-ключ в формат RFC4716 (экспорт в Cisco IOS):
Применение публичного ключа на оборудовании
Как на различном оборудовании привязать открытый ключ к пользователю?
Процесс привязки публичного ключа к пользователю не стандартный и меняется от оборудования к оборудованию, поэтому приведены примеры для каждого типа оборудования, которое чаще всего применяется в сети.
Cisco IOS XE, Catalyst (с версии 15.1 и выше), IOS
Cisco ASA
Весь ключ вставляем в одну строчку (OpenSSH формат).
Маршрутизаторы и коммутаторы Huawei
Типы форматов ключей, импортируемых на Huawei:
“The SecureCRT and PuTTY generate RSA keys in PEM format.”
“The OpenSSH generates RSA keys in OpenSSH format.”
“The OpenSSL generates RSA keys in DER format.”
По умолчанию — в шестнадцатеричном виде:
Примечание: оборудование Huawei поддерживает не только ключи в формате RSA, но и другие форматы:
Можно жестко задать тип аутентификации для пользователя по SSH:
То есть мы разрешаем доступ с помощью либо пароля, либо публичных и приватных ключей, либо и того, и другого.
Huawei USG (6000)
Конфигурация полностью аналогична настройкам на маршрутизаторе, но имеет некоторые особенности.
По умолчанию уровень привилегий после журналирования с использованием сертификатов равен 0 и повышению не поддается. Поэтому уровень приоритета задается с помощью
Cisco Nexus 9.3
Вариант 1: предустанавливаем файл публичного ключа на устройство и привязываем файл публичного ключа к пользователю.
Вариант 2: копируем публичный ключ пользователю:
Использование секретного ключа для подключения по SSH
Этот раздел посвящен настройке SSH-клиентов для аутентификации по RSA-ключам на сетевом оборудовании (или другом оборудовании, при условии, что оборудование и ПО поддерживает аутентификацию по публичным ключам).
Мы рассмотрим настройку использования публичного ключа в самых популярных программах: SecureCRT и PuTTY.
SecureCRT
В окне настроек SSH есть список Authentication. В нём необходимо увеличить приоритет PublicKey до самого высокого — сделать верхним в списке.
Затем перейдите в параметры PublicKey и выберите файл приватного ключа. Самый верхний переключатель позволяет использовать глобальные настройки секретного ключа или сеансовые настройки — другой секретный ключ (ключ не по умолчанию) — только для этого подключения.
Настраиваем глобальный публичный ключ: в меню Options → Global options → Категория SSH2.
PuTTY
В настройках SSH (Connection → SSH → Auth) в поле “Private key file for authentication” укажите файл Putty Private Key (*.ppk):
MAC OS X
Настройка стандартного клиента для использования публичных ключей:
Как упростить работу с SSH на MAC OS X:
Заполняется таким образом:
Примечание: у меня некорректно настроено подключение по умолчанию (как правильно, я не знаю), потому что подключение к хосту R6 (10.31.73.31) выполняется очень долго. Рекомендуется указать сразу указать путь к ключу по умолчанию.
Пример подключения по ssh используя публичные ключи и файл config:
Заключение
RSA-ключи могут использоваться для замены аутентификации по паролю, но не во всех случаях:
На некотором оборудовании одному пользователю может соответствовать несколько пар публичных ключей, на другом оборудовании одному пользователю соответствует только один публичный ключ.
Также разнятся форматы, в которых хранится пара из публичного и секретного ключа. Но это руководство поможет вам экспортировать ключи в разные форматы.
Сегодня оптимально использовать ключи длиной 2048 бит, но для некоторого оборудования это максимально возможная длина ключа (быть может, в новых прошивках это исправят). Например:
Рекомендуется использовать публичные ключи для замены паролей, если пароли вводятся с помощью скриптов (пример: autologon в SecureCRT).
Рекомендуется использовать публичные ключи для защиты от передачи пароля по сети.
Некоторое ПО по умолчанию использует публичные ключи для аутентификации по SSH вместо пароля (пример: Ansible).
Повышаем безопасность закрытых ssh-ключей
Вы когда-нибудь интересовались механизмом работы ssh-ключей? Или тем, насколько безопасно они хранятся?
По ходу изложения встретится много аббревиатур. Они не помогут понять идеи, но будут полезны в том случае, если вы решите погуглить подробности.
Итак, если вам доводилось прибегать к аутентификации по ключу, то у вас, скорее всего, есть файл
/.ssh/id_dsa в домашнем каталоге. Это закрытый (он же приватный) RSA/DSA ключ, а
/.ssh/id_dsa.pub — открытый (он же публичный) ключ. На сервере, на котором вы хотите залогиниться, должна быть копия открытого ключа в
/.ssh/authorized_keys есть открытый ключ, и вы получаете доступ.
Что же хранится внутри закрытого ключа?
Незашифрованный формат закрытого ключа
Закрытый ключ рекомендуется защищать паролем (парольной фразой), иначе злоумышленник, которому удалось украсть у вас закрытый ключ, сможет без проблем залогиниться на вашем сервере. Сначала взглянем на незашифрованный формат файла, а с зашифрованным разберемся позже.
Незашифрованный ключ выглядит примерно так:
Закрытый ключ содержит данные в формате ASN.1, представленные в виде последовательности байт согласно стандарту X.690 и закодированные в Base64. Грубо говоря, ASN.1 можно сравнить с JSON (он поддерживает различные типы данных, такие как INTEGER, BOOLEAN, строки и последовательности, которые могут формировать древовидную структуру). ASN.1 широко распространен в криптографии, хотя слегка вышел из моды с пришествием веба (я не знаю почему — он выглядит как вполне достойный формат (с этим можно поспорить — прим. пер.))
Структура данных в ASN.1 довольно проста: это последовательность из девяти целых чисел. Их назначение определено в RFC2313. Первое и третье числа — это номер версии (0) и открытая экспонента e. Второе и четвертое числа (длиной 2048 бит) — это модуль n и секретная экспонента d. Эти числа являются параметрами ключа RSA. Остальные пять можно получить, зная n и d — они кэшированы в файле для ускорения некоторых операций.
Структура DSA-ключей похожа и включает шесть чисел:
Формат закрытого ключа, защищенного паролем
Теперь усложним жизнь потенциальному злоумышленнику, который смог украсть закрытый ключ — защитим его паролем. Что произошло с файлом?
Заметим, что добавились две строки с заголовками, а результат декодирования Base64-строки больше не является валидным ASN.1. Дело в том, что структура ASN.1. зашифрована. Из заголовков узнаем, какой алгоритм использовался для шифрования: AES-128 в режиме CBC. 128-битная шестнадцатеричная строка в заголовке DEK-Info — это вектор инициализации (IV). Ничего необычного здесь нет, все распространенные криптографические библиотеки умеют работать с используемыми здесь алгоритмами.
Но как из пароля получается ключ AES? Я не нашел этого в документации и поэтому был вынужден разбираться в исходниках OpenSSL. Вот что я выяснил насчет получения ключа шифрования:
Эта команда выведет параметры ключа RSA. Если вы хотите просто увидеть ключ, есть способ и проще:
Но я хотел показать, как именно ключ AES получается из пароля, чтобы обратить внимание на два уязвимых места:
Это плохая новость: защита ключа паролем не так хороша, как можно было предположить. Но есть и хорошая новость: вы можете перейти на более надежный формат закрытого ключа.
Повышаем защиту ключа с использованием PKCS#8
Итак, нам нужен алгоритм получения симметричного ключа шифрования из пароля, который работал бы медленно, чтобы злоумышленнику потребовалось больше вычислительного времени для подбора пароля.
Для ssh-ключей существует несколько стандартов с неуклюжими названиями:
Если попробовать использовать новый файл ключа в формате PKCS#8, можно обнаружить, что все работает так же как и раньше. Посмотрим, что теперь находится внутри файла.
Обратите внимание на то, что первая и последняя строки изменились ( BEGIN ENCRYPTED PRIVATE KEY вместо BEGIN RSA PRIVATE KEY ), а заголовки Proc-Type и DEK-Info исчезли. Фактически, в файле хранятся данные во все том же формате ASN.1:
Воспользуемся JavaScript-декодером, чтобы рассмотреть структуру ASN.1:
Здесь упоминаются OID (Object identifier) — глобально-уникальные цифровые идентификаторы. По ним мы узнаем, что используется схема шифрования pkcs5PBES2, функция получения ключа PBKDF2 и алгоритм шифрования des-ede3-cbc. Функция хеширования не указана явно, значит, по умолчанию используется hMAC-SHA1.
Хранение OID в файле хорошо тем, что ключи можно обновить без смены формата контейнера (если, например, будет изобретен лучший алгоритм шифрования).
Также мы видим, что в ходе получения ключа шифрования выполняется 2048 итераций. Это гораздо лучше, чем однократное применение хеш-функции при использовании традиционного формата ssh-ключей — перебор паролей потребует больше времени. В настоящий момент количество итераций прописано в коде OpenSSL, я надеюсь, в будущем его можно будет настраивать.
Заключение
Если вы установили сложный пароль на закрытый ключ, то преобразование его из традиционного формата в PKCS#8 можно сравнить с увеличением длины пароля на пару символов. Если же вы используете слабый пароль, PKCS#8 сделает его подбор заметно сложнее.
Поменять формат ключей очень просто:
Команда openssl pkcs8 запрашивает пароль три раза: один раз для разблокировки существующего ключа и два раза при создании нового файла ключа. Вы можете придумать новый пароль или использовать старый, это не имеет никакого значения.
Не весь софт может читать формат PKCS#8, но в этом нет ничего страшного — доступ к закрытому ssh-ключу нужен только ssh-клиенту. С точки зрения сервера, хранение закрытого ключа в другом формате вообще ничего не меняет.
Переводчик будет рад услышать замечания и конструктивную критику.
Linux.yaroslavl.ru
Автор: Инга Захарова, arlantine@lnx.ru
Опубликовано: 8.6.2002
Перевод статьи Дэниэла Робинса (Daniel Robbins) OpenSSH key management, Part 1
Из этой серии статей вы узнаете, как действует RSA и DSA-аутентификация и как правильно настроить беспарольную аутентификацию. В первой статье цикла Дэниел Робинс уделяет внимание представлению протоколов аутентификации RSA и DSA и демонстрирует, как применять их для работы в сети.
Что такое RSA/DSA-аутентификация?
Хотя ssh действительно замечательная программа, среди функций ssh существует определенная компонента, часто обделяемая вниманием и катастрофически неиспользуемая, или просто недопонятая. Эта компонента – система ключей аутентификации RSA/DSA для OpenSSH, являющаяся альтернативой стандартной системе аутентификации безопасных паролей, которая в OpenSSH используется по умолчанию.
Хотя основанные на ключах протоколы аутентификации относительно безопасны, в случае, если пользователь воспринимает быстрый вход как всего лишь удобное приспособление и не полностью осознает ее прямую связь с безопасностью, то могут возникнуть проблемы. В данной статье мы внимательно рассмотрим как правильно использовать протоколы RSA- и DSA-аутентификации и при этом не подвергать собственную безопасность ненужному риску. В своей следующей статье я продемонстрирую вам, как использовать ssh-agent для кэширования дешифрованных личных ключей, и представлю вашему вниманию keychain – программу-надстройку над ssh-agent который обеспечивает целый ряд полезных преимуществ, не жертвуя при этом безопасностью. Если вы всю жизнь мечтали докопаться до сути самых крутых примочек, тогда продолжайте читать.
Как работают ключи RSA/DSA.
Два нюанса.
Существует два немаловажных нюанса, касающихся RSA/DSA-аутентификации. Первое – то, что нам в действительности понадобится генерировать всего лишь пару ключей. Далее мы можем скопировать публичный ключ на удаленные машины, к которым хотим получить доступ, и все они будут успешно аутентифицировать нас по нашему личному ключу. Другими словами, нам не понадобится своя пара ключей для каждой системы, к которой мы хотим получить доступ. Будет достаточно одной единственной пары.
Конечно, разработчики ssh осознают важность личного ключа, и в ssh и генераторе ключей ssh-keygen предпринят ряд мер безопасности для того чтобы не нарушался режим использования личного ключа. Во-первых, ssh настроен таким образом, чтобы выводить большое предупредительное сообщение, если кто-либо кроме вас имеет доступ «чтение» к файлу личного ключа. Во-вторых, когда вы при помощи ssh-keygen создаете вашу пару ключей личный/публичный, ssh-keygen попросит вас ввести ключевую фразу. Если вы это делаете, то ваш личный ключ будет зашифрован с использованием этой ключевой фразы, таким образом даже если ключ будет похищен, он будет абсолютно бесполезен в руках того, кто этой фразы не знает. Вооруженные этим знанием, давайте посмотрим как настроить ssh на использование протоколов RSA- и DSA-аутентификации.
ssh-keygen при «ближайшем рассмотрении».
Когда ssh-keygen запрашивает местонахождение ключа по умолчанию, нажимаем ввод в знак принятия указанного по умолчанию /home/drobbins/.ssh/identity. ssh-keygen будет хранить личный ключ под приведенным выше паролем, а публичный ключ будет храниться рядом с ним в файле с именем identity.pub.
Обратите внимание, что ssh-keygen советовал вам ввести ключевую фразу. Следуя совету вы ввели хорошую фразу (состоящую из семи или более труднопредсказуемых символов). После этого ssh-keygen зашифровал ваш личный ключ (
/.ssh/identity) используя эту фразу, таким образом ваш личный ключ будет бесполезен для того, кто этой фразы не знает.
Быстрый компромисс.
Знаю, о чем вы подумали. Беспарольная аутентификация, несмотря на несколько повышенную степень риска, все же кажется воистину привлекательной. Я полностью с этим согласен. Но существует лучший выход! Оставайтесь со мной, и я покажу вам, как получить все преимущества беспарольной аутентификации, не подвергая риску безопасность вашего личного ключа. В своей следующей статье я покажу вам, как мастерски использовать ssh-agent (ту самую штуку, которая в первую очередь делает возможной безопасную беспарольную аутентификацию). А сейчас давайте приготовимся использовать ssh-agent для настройки RSA- и DSA-аутентификации. Вот вам пошаговые указания на этот счет.
Генерирование пары RSA-ключей.
Для того, чтобы настроить RSA-аутентификацию понадобится один раз выполнить действие по созданию пары ключей личный/публичный. Делаем это, набирая:
Подтвердите месторасположение ключа по умолчанию (как правило, для публичного ключа это
/.ssh/identity.pub) в строке предложения и снабдите ssh-keygen надежной ключевой фразой. Когда ssh-keygen завершит процесс, у вас в наличии будет публичный ключ, а также зашифрованных с помощью ключевой фразы личный ключ.
Установка публичного ключа RSA.
/.ssh/authorized_keys вот таким образом:
Генерирование DSA-ключей.
Если RSA-ключи используются протоколом ssh версии 1, то DSA-ключи используются для 2-го уровня и обновленной версии протокола. Любая из современных версий OpenSSH должна поддерживать работу как RSA так и DSA ключей. Генерирование DSA-ключей посредством ssh-keygen для OpenSSH можно осуществить аналогично той же процедуре в RSA следующим образом:
И опять мы получим приглашение ввести ключевую фразу. Введите какую-нибудь понадежнее. Мы также получим приглашение указать место, куда будут сохранены наши DSA-ключи. Обычно предлагаемый по умолчанию файл
/.ssh/id_dsa.pub вполне подойдет. Генерирование ключей DSA завершено, и теперь самое время установить публичный DSA-ключ в удаленной системе.
Установка публичного DSA-ключа.
И снова мы сталкиваемся с тем, что установка публичного DSA-ключа практически идентична такой же процедуре в RSA. Для DSA мы скопируем наш файл
/.ssh/id_dsa.pub в удаленную систему remotebox и добавим его в файл
В следующий раз.
Теперь у вас имеется работающая RSA- или DSA-аутентификация, но вам все еще приходится вводить ключевую фразу для каждого нового соединения. В моей следующей статье вы увидите, как использовать ssh-agent – действительно классную систему, позволяющую устанавливать соединения без предоставления пароля, но при этом также позволяющую хранить наши личные ключи зашифрованными на диске. Я также представлю вашему вниманию keychain – весьма полезного клиента ssh-agent ‘а, который делает ssh-agent еще более надежным, удобным и прикольным. А пока ознакомьтесь с полезными источниками, приведенными ниже, дабы войти в курс дела.
Сертификаты цифровых подписей RSA vs DSA: кто победит в бою?
Что такое RSA?
RSA — одна из первых систем шифрования с открытым ключом, созданная в 1977 году. RSA был открыт Роном Ривестом, Ади Шамиром и Леонардом Адлеманом, чьи фамилии и составляют аббревиатуру RSA. Этот алгоритм разрабатывался долгое время, прежде чем нашел свое место. Однако, на заре интернета, RSA распространился как лесной пожар. Это был не просто еще один алгоритм шифрования, а совершенно новый способ удаленного обмена секретами. RSA также поставляется с цифровой подписью.
Что такое DSA?
DSA — это также алгоритм шифрования с асимметричным ключом, который появился намного позже RSA. С момента его разработки в 1991 году Национальный институт стандартов и технологий настоял на принятии алгоритма на федеральном уровне. Несмотря на широкую популярность RSA в частном секторе, DSA стал стандартом для многих правительственных учреждений.
DSA vs RSA: битва цифровых подписей
Криптография с асимметричным ключом основана на обмене двумя ключами — частным и открытым. Поскольку открытый ключ доступен всем, любой человек может получить его, выдавая себя за вас. К счастью, проблемы аутентификации были решены с помощью цифровых подписей.
Две основные части цифровой подписи в криптографии с открытым ключом — это частный ключ отправителя и хэш. Проще говоря, это сокращенная версия сообщения. Независимо от типа файла и его размера, хэш имеет длину всего 5-20 символов. Имейте в виду, что хэширование — односторонний процесс, то есть вы не можете превратить эти символы обратно в сообщение. Его единственная цель — защитить вас от поддельных версий файла. Даже если хакер внес мельчайшие изменения, хэш тоже изменится, что говорит о том, что сообщение больше не будет считаться подлинным.
В чем разница между RSA и DSA?
Во-первых, это использование алгоритмом математических задач. Оба алгоритма используют модульную арифметику, но сертификат RSA основан на простой факторизации, в то время как DSA использует задачу дискретного логарифма. На данный момент оба считаются полностью безопасными.
Еще одним отличием DSA от RSA является скорость. Первое — это более быстрая подпись, а второе — более эффективная при проверке. Но поскольку аутентификация требует и того, и другого, расхождения в скорости могут быть не такими значительными, как кажется.
Кроме того, DSA работает только с более безопасным, вторым изданием сетевого протокола Secure Shell (SSH). RSA работает с SSH2, но также совместим с оригинальным SSH, который теперь считается неполноценным. Поэтому, если вас беспокоит случайное использование SSH, DSA может быть лучшим выбором.
Как видите, что различия между RSA и DSA довольно незначительны. Поэтому не стоит слишком беспокоиться о выборе между ними, к тому же с точки зрения совместимости они равны. RSA и DSA используются для одних и тех же интернет-протоколов и сертификатов, таких как Nettle, OpenSSL, wolfCrypt, Crypto++ и cryptlib.