Зачем вообще защищать данные при передаче?

Привет, Хабр!

Меня зовут Федор и я занимаюсь киберкриминалистикой. Не только на работе (в RTM Group), но и на досуге. Мне нравится исследовать, почему и как кого-то взломали, а еще думать, как сделать так, чтобы этого не происходило. В связи с COVIDом и прочими событиями гораздо больше важных данных все стали пересылать посредством электронной почты и мессенджеров. Соответственно, выросло и количество случаев кражи таких данных. И сегодня мы разберемся, как защищать важную информацию при передаче.

Понятно, что в мессенджерах, соцсетях и электронной почте есть уже необходимые инструменты ИБ. Но как быть с конфиденциальной корпоративной информацией? Ведь всегда существует риск утери устройства, перехвата пароля и другие векторы атак. Ниже мы опишем способы защиты данных при передаче, которые собрали за многолетнюю практику проведения аудитов ИБ, и покажем, какие из них более надежные, а какие – более быстрые. Сразу скажем, что излишняя паранойя в этом деле наверняка будет тормозить бизнес-процессы, поэтому предаваться ей не стоит, а лучше выбрать сбалансированный вариант самостоятельно.

1. Съемные носители и прочая классика

Первое, что может прийти в голову при необходимости обменяться конфиденциальной информацией, исключив риск компрометации, – обмен файлами через USB-накопитель, внешний жесткий диск, CD/DVD диск, дискету (привет, олд скул!) Но для этого нужно встречаться контрагентам (отправка по почте или курьером – явный риск). Это неудобно, поэтому способ приемлем для разового использования (частный случай нахождения аудитора и аудируемого в шаговой доступности не рассматриваем). А ведь информацию даже в рамках одного аудита приходится передавать часто.

Интересен вариант с CD/DVD дисками: после копирования информации их можно просто сломать и выкинуть – не жалко. Правда следует отметить, что привод компакт-дисков на офисных компьютерах теперь встретишь не часто.

Плюсы и минусы съемных носителей

Плюсы: стороны могут непосредственно идентифицировать друг друга, информация гарантировано попадает только на авторизованный компьютер.

Минусы: требует личного участия сторон.

2. Запароленные архивы и прочие облака

Использовать для передачи информации шифрование - очень хорошая идея. Криптография для этого и предназначена, ведь она преобразовывает осмысленное в бессмысленное и обратно.

Что делаем? Собираем папку с файлами, архивируем ее с паролем. Что у нас обычно под рукой? Правильно, и 7-zip. Паролить архивы умеют все, а кто еще нет – смотрим картинки ниже. Опция Lock archive исключит изменение архива.

А вот вопрос с криптостойкостью стоит рассмотреть подробнее. Справка Winrar сообщает: «archives are encrypted with AESAdvanced Encryption Standard, также Rijndael — симметричный алгоритм блочного шифрования, принятый в качестве стандарта шифрования правительством США в 2002 г.</p>" data-abbr="¹">¹-256 algorithm in CBC mode for RAR 5.0 archives and AES-128 in CBC mode for RAR 4.x archives. RAR 5.0 key derivation function is based on PBKDF2²… ». Переводим: на базе пользовательского пароля по алгоритму PBKDF2 формируется ключ длиной 256 бит для использования в алгоритме шифрования AES-256 в режиме сцепления блоков (Cipher Block Chaining).

Справка по 7-zip не требуется. Интерфейс как бы намекает, что единственный вариант – AES-256 без указания режима.

Хорошо это или плохо? Passware Kit Forensic 2022 v2 (64-bit) на офисном Core i5-10400F 2.90 GHz оценивает брутфорс пароля из 10 цифр для RAR 4 в 6 месяцев, для RAR 5 – в 3 года, для 7-zip – в 1 год и 10 месяцев.

Неплохо… и только цифры! Использование грамотного пароля (не из словаря и из разных групп символов) информацию вполне обезопасит.

Такой зашифрованный архив уже можно передавать по открытым каналам, например, отправив по электронной почте или разместив на общедоступном ресурсе (облаке), или на своем FTP-сервере. И все бы хорошо, но возникает вопрос: «Как передать пароль?» Любой механизм (кроме «с глазу на глаз») рискован, но есть очевидно провальные: разместить на том же ресурсе, в том же или следующем письме/сообщении и т.п. Компромиссное решение состоит в передаче пароля по иному каналу и с другого устройства.

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

Неплохой пример: архив переслать по емайл, пароль сообщить голосовым сообщением в мессенджере, которое потом удалить.

Плохой пример: указать пароль в том же письме, где ссылка на облако.

Плюсы и минусы архивации

Плюсы: можно передавать по открытым каналам

Минусы: проблема с передачей пароля

А кстати, если уж заговорили про облака, там ведь тоже можно установить пароль. Да, но есть нюанс! Это может быть пароль на доступ к ресурсу, где хранятся данные, а не к самим данным. Другими словами, со стороны облака или FTP-сервера эта информация будет открыта. Доверять ли операторам облачных хранилищ или FTP-серверов, каждый решает сам, но в случае утечки данных такой способ передачи явно расширит круг подозреваемых…

К тому же далеко не все распространенные облачные хранилища позволяют закрывать доступ паролем (icloud.com, drive.google.com, cloud.mail.ru) – у некоторых функция доступна только для определенных тарифов.

Плюсы: удобство доступа

Минусы: проблема с передачей пароля, доверия к хранилищам

Очевидное невероятное с использованием протокола Диффи-Хеллмана

Ну и нужно отметить, что проблема генерации секретного ключа по открытым каналам давно уже решена У. Диффи, М. Хеллманом и Р. Мерклом (U.S. Patent 4200770 Apr. 29, 1980). И это протокол Диффи-Хеллмана, который оперирует возведением в степень и нахождением остатка от деления. За несколько итераций пересылки друг другу больших чисел лица, успешно освоившие школьный курс математики, вполне могут сформировать пароль, известный только им. Информации много, в Википедии есть пример³.  Вперед, тем более, патента уже истек!

3) Шифрованые обменники (Seafile, Mega)

Стороннее шифрованное облачное хранилище

Для особо недоверчивых защитников информации существуют облачные ресурсы, хранящие данные в шифрованном виде. Рассмотрим в качестве примера mega.io (функционирует с 2013 года, предоставляет 20 ГБ бесплатно). Mega шифрует весь контент в браузере при помощи javascript с помощью уже знакомого нам AES и незнакомого RSA (см.ниже).

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

Сервис неоднократно подвергался критике из-за используемых технологий обеспечения безопасностиhttps://habr.com/ru/post/168025/, https://xakep.ru/2022/06/22/mega-e2e/</p>" data-abbr="⁴">⁴, в 2018 году было скомпрометировано Chrome-расширение Mega⁵. При этом случаи компрометации пользовательских данных в свободном доступе отсутствуют, а Mega регулярно рапортует об устранении выявленных уязвимостей.  Таким образом, если пренебречь угрозой намеренной атаки со стороны Mega для копирования/замены передаваемых данных, то сервис вполне рабочий.

Он позволяет отделить ссылку от ключа, что при пересылке по разным каналам может обеспечить дополнительный уровень безопасности. Платная версия позволяет защитить материалы паролем (тут уже 3 канала связи потребуется – ну очень надежно).

или

Важное про гибридную криптографию

RSA (Rivest-Shamir-Adleman) – один из алгоритмов асимметричной криптографии. Это революционное достижение криптографии 1970-х. Суть в генерации пары ключей (открытый – известен всем, закрытый – только владельцу). Ключи друг из друга вычислить нельзя, хотя они математически связаны и растут из одного корня. Шифруем открытым ключом - расшифровать можно только закрытым. Шифруем закрытым – открытым проверяем, кто зашифровал. Вкупе с контролем целостности получаем электронную подпись.

Может возникнуть резонный вопрос, почему появление такой схемы не привело к отмиранию традиционной симметричной криптографии. Во-первых, привязываться к двум ключам не всегда удобно и не всегда нужно. Во-вторых, для обеспечения криптостойкости на уровне симметричных алгоритмов, асимметричным требуется гораздо более длинный ключ (например⁶, 3072 бит RSA против 128 бит AES), что приводит к бОльшим вычислительным затратам.

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

Она применяется и в Mega. В корне иерархии ключей находится пользовательский пароль. Из этого пароля Мega извлекает ключ аутентификации и ключ шифрования. Ключ аутентификации используется для последующих подключений пользователя к Mega. Ключ шифрования шифрует случайно сгенерированный мастер-ключ, который, в свою очередь, шифрует остальной «ключевой материал⁷»:

• ключевая пара RSA-2048 (для обмена данными с другими пользователями. Симметричный ключ доступа к общему ресурсу расшифровывается открытым ключом RSA);

• симметричный ключ узла для каждого файла или папки.

Закрытые асимметричные ключи и ключи узлов шифруются мастер-ключом с использованием AES-ECB⁸ и хранятся, как и мастер-ключ, на серверах Mega для поддержки доступа с нескольких устройств.

Пользователь на новом устройстве может ввести свой пароль, пройти аутентификацию в Mega, получить зашифрованный «ключевой материал» и расшифровать его с помощью ключа шифрования, полученного из пароля.

Плюсы и минусы стороннего шифрованного облачного хранилища

Плюсы:

• Не требует затрат на обслуживание;

• Сервис не аффилирован с контрагентами (сторонами информационного обмена).

Минусы:

• Ограничения на объем и размер файла;

• Нет гарантии, что бесплатное не станет платным;

• Нужно доверять оператору хранилища.

Собственное шифрованное хранилище

Для тех, кто предпочитает самостоятельно реализовывать конфиденциальный обмен информацией с контрагентом, тоже есть решение – собственное шифрованное облачное хранилище. Пример – Open Source проект Seafile (www.seafile.com).

Seafile имеет простой веб-интерфейс, поддерживает русский язык, можно заменить логотип и фон. Есть клиентcкие приложения под Windows, Mac, Linux. В Google Play и AppStore присутствуют соответствующие мобильные приложения Seafile. Главное – гибкая настройка доступности материалов и журналирования.

Установка клиента делает работу с хранилищем похожим на работу с Git в части синхронизации с сервером и хранения истории изменений (возможность загрузки любой версии файла).

Корневые папки называются библиотеками, к ним можно применить шифрование и разрешить доступ на чтение/запись или только чтение.

Есть нюансы! Шифрованную библиотеку можно сделать доступной только зарегистрированным пользователям (группам пользователей). Библиотека без шифрования позволяет организовать общий доступ для пользователей (групп пользователей), сформировать ссылку на доступ или загрузку, защитив ее паролем и сроком действия.

На момент написания статьи документацияhttps://manual.seafile.com/security/security_features/</p>" data-abbr="⁹">⁹ Seafile предупреждает, что шифрование на стороне клиента не поддерживается веб-клиентом.

Рассмотрим процедуры шифрования при использовании десктопного или мобильного клиента. Он генерирует 256-битную последовательность (file key) для шифрования библиотеки. Библиотека шифруется клиентом с помощью AES-256 CBC и отправляется для хранения на сервер.

File key шифруется 256-битной производной пользовательского пароля (key/iv pair) с помощью AES-256 CBC. Полученный зашифрованный ключ сохраняется на сервере.

При доступе к зашифрованной библиотеке зашифрованный ключ расшифровывается производной от пароля пользователя. В целях безопасности клиент в рамках сессии сохраняет только key/iv pair, который используется для расшифровки данных. Забыв пароль, пользователь не сможет восстановить его или получить доступ к своим данным на сервере. Для синхронизации зашифрованной библиотеки с клиентом используется "волшебный токен" (magic token). Он создается на основе пароля и идентификатора библиотеки и хранится в библиотеке на стороне сервера. Клиент использует этот токен для проверки пользовательского пароля перед синхронизацией библиотеки. Не очень понятно, правда? Тем более, что термин «токен» в последнее время практически стал синонимом термина jack (какая-то штука). Думается речь идет о токене аутентификации¹⁰…

Волшебный токен генерируется алгоритмом PBKDF2 с 1000 итерациями хэша SHA256.

Важное про хэш и производные от пароля:

Мы уже встречали аббревиатуру PBKDF в справке по WinRar, но ограничились переводом. Теперь рассмотрим подробнее. Как можно заметить, ключи, используемые для шифрования, гораздо длиннее пользовательских паролей. Задача password-based key derivation function получить из короткого пароля длинный ключ с помощью псевдослучайной функции, причем, чем быстрее, тем лучше.  PBKDF2 сменил PBKDF1 с ограничением получаемого ключа 160 битами.

В реализации Seafile 1000 раз рекурсивно используется хэш-функция SHA-256. В свою очередь, хэш-функция реализует преобразование исходных данных в битовую строку фиксированной длины. Смысл хэш-преобразования в том, что получаемое значение очень чувствительно к изменению исходных данных. Так, изменение исходных даже на 1 бит приводит к существенному и, заранее непредсказуемому, изменению хэша. По этой причине хэш-значения используются в качестве дайджестов передаваемых данных при контроле целостности. Если отправленное и полученное сообщения имеют одинаковый хэш, делается вывод о неизменности данных при передаче.

Оценить интерфейс и попробовать поработать в Seafile без регистрации можно прямо в демонстрационном облаке https://demo.seafile.com/demo. Также можно зарегистрироваться на cloud.seafile.com (у меня получилось только в качестве организации), получить 1 Гб в облаке и потестировать функционал.

Плюсы и минусы собственного шифрованного облачного хранилища

Плюсы:

• Объем ограничен собственным желанием;

• Есть клиенты под распространенные ОС;

• Ограничения на размер файла регулируются лишь технологиями;

• Безопасность и конфиденциальность под контролем.

Минусы:

• Нужно покупать сервер с дисками или хранилище;

• Требует затрат на обслуживание, железо, электричество.

4. Шифрование файлов ГОСТ и прост) (Kleopatra, КриптоАрм)

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

Как осуществляется асимметричное шифрование, было рассмотрено выше. Но проверка личности абонента не менее важна! Здесь в игру вступают цифровые сертификаты. Их можно рассматривать как цифровой паспорт – логический контейнер, который содержит открытый ключ пользователя, его идентификационные данные и служебную информацию. Может возникнуть сомнение, как доверять сертификату. Чтобы разрешить его, есть два пути.

Наиболее широкое распространение получили системы PGP и PKI. В системе PKI подлинность валидируется в основном по вертикальной (иерархической) составляющей, когда сертификат подтверждается кем-то, имеющим более высокий статус. В системе PGP основной является горизонтальная составляющая. Образно можно представить, что в PKI доверие распространяется в виде дерева, а в PGP - в виде сети. Скорость шифрования на офисном компьютере для данного типа программ порядка 20-30 МБайт/с.

Децентрализованная сертификация

В 1991 году Ф. Циммерман написал программу Pretty Good Privacy (PGP), которая использовала шифрование с открытым ключом, и опубликовал её в Интернете для свободного доступа.

Несмотря на недостаток финансирования, отсутствие какого-либо оплачиваемого персонала, рекламной кампании и так далее, PGP стало наиболее широко используемым в мире программным обеспечением для шифрования и электронной подписи.

Первая версия системы называлась Сеть доверияhttps://en.wikipedia.org/wiki/Web_of_trust</p>" data-abbr="¹¹">¹¹, и противопоставлялась системе, использовавшей иерархический подход, основанной на удостоверяющих центрах. Действительно, небольшим группам людей, нуждающимся в защищённой связи, не составит труда обменяться файлами с открытыми ключами.

Сеть доверия предполагает, что, когда один пользователь подписывает ключ другого, он поручается за подлинность ключа и его принадлежность предполагаемому владельцу. Если я вижу сертификат, подписанный людьми, которым я доверяю (или теми, которым доверяют, те, кому я доверяю и т.д.), у меня есть основания считать его подлинным.

Сегодня такой сервис реализуют пакеты Gpg4win¹², GPGFrontend¹³ и пр. Функционал программного обеспечения примерно одинаков. Рассмотрим его на примере Gpg4win, т.к. GPGFrontend весьма неудачно переведен на русский.

Gpg4win содержит несколько компонентов:

• GnuPG – бэкэнд, фактический инструмент шифрования;

• Kleopatra – менеджер сертификатов и общих криптографических диалогов;

• GPA (GNU Privacy Assistant) – альтернатива Kleopatra. Разница в интерфейсе (у GPA функционал разбит на Диспетчер ключей и Менеджер файлов) и некоторых мелочах: например, Kleopatra позволяет выбрать алгоритм шифрования, а GPA – нет, по умолчанию использует RSA 2048; GPA позволяет создать открепленную ЭП, Kleopatra – нет.

• GpgOL – плагин для Microsoft Outlook;

• GpgEX – плагин для проводника Windows;

• Browser integration – расширение для браузеров (Безопасная электронная почта по стандарту OpenPGP для некоторых почтовых сервисов).

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

RSA 3072 соответствует по криптостойкости AES128. Криптостойкость RSA 2048, который заложен в GPA будет, на уровне 3DES¹⁴ (по оценкам Национального института стандартов и технологий 3DES остается надежным до 2030-х).

Для осуществления переписки абоненты должны обменяться сертификатами открытого ключа. Экспорт/импорт осуществляется через файл c расширением .asc.

Сертификат содержит подписи участников Сети доверия. На скриншоте Сертификат Roman подписан Алисой и Васей, а потом Алиса перестала доверять Roman и отозвала свою подпись:

Диалог передачи файлов допускает множественный выбор. По умолчанию файлы собираются в tar-архив, но можно шифровать по отдельности. Главное здесь – выбор адресата (сам, другие пользователи Сети доверия).

Открытие файла возможно закрытым ключом адресата. Со стороны пользователя это ввод пароля.

Также возможно зашифровать файлы для неопределенного круга лиц (красная рамка). И тогда можно будет открывать их либо личным паролем (закрытым ключом), если сертификат указан в списке получателей, либо общим для всех паролем. Сомнительная функция… Видимо, идея в том, что обычное симметричное шифрование подкрепляется дополнительной информацией о подписанте. Однако, если сертификат подписанта не импортирован, никакой информации получить не удастся.

Папку можно зашифровать в Kleopatra через пункт меню «Файл/Подписать и/или зашифровать папку» и контекстное меню проводника с установленным GpgEX. Папку с подпапками придется предварительно заархивировать.

К недостаткам Gpg4win можно отнести отсутствие сертификатов ФСБ России, но для целей передачи корпоративных материалов это ПО вполне подходит.

Плюсы и минусы использования Сети доверия

Плюсы

• ПО в свободном доступе;

• Обмен ведется автономно.

Минусы

• Необходимо обменяться сертификатами открытых ключей.

PKI (Public Key Infrastructure, инфраструктура открытых ключей)

Сертификат легитимен, если выдан легитимным органом — центром сертификации (удостоверяющим центром). Это организация, чья честность неоспорима, а открытый ключ широко известен. Задача центра сертификации — подтверждать, что лицо является тем, за кого себя выдает и сопоставлять ему ключи шифрования¹⁵. Бытовым синонимом сертификата является электронная подпись, хотя, строго говоря, это не одно и то же.

Итак, основные компоненты инфраструктуры открытых ключей:

Центр сертификации – выдает цифровые сертификаты, подписывает их своим открытым ключом и хранит в репозитории для справки;

Регистрирующий орган – идентифицирует личности будущих владельцев цифровые сертификаты;

Центр проверки – хранит базу данных сертификатов, контролирует действительность сертификатов.

В РФ корневым удостоверяющим центром является Минкомсвязь России, следующий уровень – Федеральное казначейство. Для использования сертификата (и ключевого носителя), полученного в казначействе, пользователь должен восстановить цепочку сертификации. Это происходит через импорт соответствующих действующих сертификатов в локальное хранилище.

Криптопровайдер, например, КриптоПро CSP 5.0 (https://cryptopro.ru/products), проверяет цепочку сертификатов, по пинкоду извлекает из ключевого носителя закрытый ключ пользователя.

Чтобы обеспечить шифрование или подпись материалов, необходим клиент, например, КриптоАРМ или КриптоАРМ ГОСТ (https://cryptoarm.ru/). Асимметричное шифрование предполагает расшифрование открытым ключом пользователя. В этом случае можно говорить не о конфиденциальности, а лишь о целостности и об авторстве материалов. Если нужно зашифровать что-либо для конкретного абонента, то необходимо предварительно импортировать его сертификат.

Основное преимущество работы с КриптоПро – легитимность. Обмен соответствует Федеральному закону от 6.04.2011 №63‑ФЗ «Об электронной подписи» и Федеральному закону от 27 июля 2006 г. N 152-ФЗ "О персональных данных".

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

Плюсы:

• Соответствие обмена законодательству РФ;

• Надежность и аутентичность обмена.

Минусы:

• Обе стороны должны поддерживать инфраструктуру открытых ключей с единым корневым центром сертификации.

5. Как делать не надо) (отправлять по email, в вотсап, ЯД и т.д.)

Оценка скорости работы способов защиты данных

Для оценки скорости работы криптоприложений был создан типовой набор материалов, направляемых на аудит. 543 файла форматов .doc, .docx, .xlxs, .pdf, .txt в папке с трехуровневой структурой общим размером 440 МБ.

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

Cleopatra не может принимать на вход папку со сложной структурой, поэтому для нее файлы были помещены в архив размером 402 МБ. Для чистоты эксперимента КриптоАРМ тоже протестирован с этим архивом.

Результат представлен в таблице:

Из таблицы видно, что временные характеристики приложений соизмеримы, и делать акцент на быстродействии приложений при выборе варианта бессмысленно.

Исключение – пофайловое шифрование КриптоАРМ с сохранением структуры каталогов, но использование эта функции в рамках темы статьи маловероятно.

Некий общий вывод

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

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

В последнее время все больше клиентов (особенно, субъекты КИИ) выбирает шифрованное хранилище RTM Group на решении Seafile, т.к. это делает обмен материалами прозрачным (сохраняющим историю) и конфиденциальным.

Наш опыт показывает, что единственный минус такого подхода в том, что на стороне заказчика не всегда возможно установить клиентскую составляющую Seafile, вследствие чего материалы у него не шифруются. Мы считаем это допустимым, т.к. взаимодействие заказчика с хранилищем Seafile происходит по протоколу HTTPS.

¹ Advanced Encryption Standard, также Rijndael — симметричный алгоритм блочного шифрования, принятый в качестве стандарта шифрования правительством США в 2002 г.

² password-based key derivation function (функция формирования ключа из пароля)

³ https://ru.wikipedia.org/wiki/ПротоколДиффи—Хеллмана

⁴ https://habr.com/ru/post/168025/, https://xakep.ru/2022/06/22/mega-e2e/

⁵ https://habr.com/ru/post/422553/

⁶ https://ru.wikipedia.org/wiki/Уровень_криптостойкости

⁷ https://mega-awry.io/

⁸ Electronic Codebook (ECB). В ГОСТ 28147—89 этот режим называется режимом простой замены

⁹ https://manual.seafile.com/security/security_features/

¹⁰ https://wiki.merionet.ru/servernye-resheniya/112/chto-takoe-autentifikaciya-na-osnove-tokena/

¹¹ https://en.wikipedia.org/wiki/Web_of_trust

¹² https://www.gpg4win.org/

¹³ https://www.gpgfrontend.pub

¹⁴ https://ru.wikipedia.org/wiki/Triple_DES

¹⁵ https://habr.com/ru/post/655135/