mayton2019

Идеальным считается Шифр Вернама. В принципе это идея Книги Кодов или одноразового блокнота.
При его использовании Алиса и Боб могли-бы спокойно переписываться и быть уверенными что никто
их не читает. Но здесь возникает вопросы.

Как Алиса и Боб ей обменяются?. Совершенно очевидно что
классические цифровые каналы здесь не подходят. Нужна личная встреча. Иначе слабым местом
в протоколе становится не Вернам а тот способ которым произошел обмен.

Как ее сгенерируют? Нельзя использовать классические ГПСЧ иначе они станут еще
одним слабым местом. Очевидно что книга кодов должна создаваться очень оригинальным
и неповторимым методом который не дает злоумышленнику (Кларку например) никаких
гипотез. Аналоговый шум радиоэфира. Рулетка. Игральные кости. Карты. Короче
любые источники энтропии которые никак не связаны с цифровым миром где Кларк
может строть гипотезы. Кроме того книга кодов (КК) должна быть достаточно
длинной (я-бы рекомендовал терабайты) чтобы Алиса и Боб хотя-бы на пару
лет могли не встречаться повторно для обмена новой книгой.

И надежность самого десктопа Алисы и Боба. Наука криптография (К) полностью
не изучает этот вопрос. Тоесть К является как-бы частью ИБ и полностью доверяется ей.
И любой троян на десктопе Алисы может полностью обнулить все наши утверждения
о надежности Вернама и книги кодов потому что книга кодов уже скомпрометирована
и Алисе с Бобом надо договариваться снова о следующем протоколе.

Когда ты купил (устнановил себе ОС) в ней уже был браузер и в этом браузере прописаны центры сертификации. Это что-то вроде нотариальных контор. Ты им доверяешь по умолчанию. И они по цепочке являются гарантами сертификатов других доменов или других контор. И связка сет доменов + публичный ключ являются реквизитами сертификата. Ты их можешь увидеть в настройках безопасности браузера. И по протоколам TLS/SSL когда ты заходишь на сайт происходит быстрая проверка что интернет домен подтвержден и между вами устанавливается доверительный канал по которому вся инфа от сервера - прогарантирована. Но еще пока не скрыта. Но ввиду того что ассиметричка работает медленно и дорого, на самом деле эта процедура обрамляет другой протокол - создание симметричного канала с временным сеансовым ключом где дальше ты уже работаешь по обычному быстрому симметричному AES например до следующего сеанса обновления ключа. Этот канал уже скрытый от постороеннего наблюдателя. Если запускать openssl с некоторыми
параметрами то эта процедура рукопожатия будет трассироваться на экран и можно подсмотреть что реально
происходит у тебя на локалхосте.

По поводу что там и где устарело. SSL/TLS это просто версии алгоритмов вот этого рукопожатия.

Существуют стандартные файловые форматы для хранения ЭЦП ключей. Для RSA, PGP и прочее.
Это текстовые файлы оформленные соотв образом и хранящие внутри себя закодированный
в Base64 ключ. Это то что касается публичной части криптографии там где важно оповестить
как можно больше респонентов и где нужна открытость. Я также видел аналогичные XML-форматы
в эпоху SOAP. Но они как-то не особо популярны. Они скорее часть SOAP чем криптографии.

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

Что еще. Для этой-же симметрички может быть полезен padding. Это специальное оформление
последнего блока шифро-текста. Чтоб подбить вариативный размер файла под размер кратный
блоку. Например если вы решили шифровать через AES-256 то вам нужен блок в 256 бит
и алгоритм паддинга для хвостового блока. Padding известен и его методы описаны в wiki.
Берите перебирайте. Который совпадет - тот и ваш. Вот. Паддинг - это не файловый формат
а просто инженерный трюк чтоб уйти от блоков или прийти к блокам.

Похоже на это?

scala> java.util.UUID.randomUUID().toString().replace("-","")
val res2: String = 2cf05b81a5694a32ae39c6d3c8d01089

scala> java.util.UUID.randomUUID().toString().replace("-","")
val res3: String = 0181ca262a2e40e8928c74d234ef71ae

scala> java.util.UUID.randomUUID().toString().replace("-","")
val res4: String = 90eb83a8216748c5bf6d475d09be41d1

scala> java.util.UUID.randomUUID().toString().replace("-","")
val res5: String = 94eab5fd1f174f08998bd9e4a12aee9a

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

Но если, допустим, два человека ведут беседу в текстовом чате, а во время обмена публичными ключами, "по середине" незаметно вторгнется еще один человек (MITM - Man In The Middle)

Давай в этой схеме я выброшу двух людей. И заменю их на браузер и сайт. Там на самом деле и просиходит такой-же чат. Браузер спрашивает и сайт отвечает. Так вот. Эта схема защищена цифровыми сертификатами. И центром сертификации. Тоесть еще до того как вы начали хоть какой-то обмен работают протоколы установки соединения по TLS/SSL когда браузер может удостоверится что центр сертификации одобрил одного из людей и подтвердил его личность. Это Боб проверяет что Алиса - это действительно Алиса. И также получает ее public key который вобщем-то публичен и тоже является частью сертификата.

Вот придумай где подпихнуть твоего человека-Кларка посередине.

Я слышал про "квантовое шифрование", но это уже следующий век.

Квантового шифрования не существует. Есть алгоритм быстрог разложения длинного числа на множители который является частью протоколов RSA. Но все успехи в науч-попе пока ограничены тем что создали комп очень малой разрядности который и близко не подошел к нужным границам и комп сам представляет собой физ-лабораторию с криогеном и защитой от всеговсего. И нет даже надежды что такой комп вставят в телефон или десктоп. Физика - здесь наука злая и циничная. Более того даже если будут успехи в этой области у КК - то у нас в запасном кармане есть эллиптическая криптография EDSA на которую пока еще ничего не придумано. Поэтому насчет КК и криптографии нам можно вообще не беспокоиться. И нашим детям тоже. И внукам.

Кстати я вижу что qna.habr для меня использует алгоритм EDSA + SHA256