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