https://www.opennet.ru/openforum/vsluhforumID3/113916.html Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, утвердил (http://www.ietf.org/mail-archive/web/ietf-announce/current/msg17592.html) финальный вариант спецификации (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/), определяющей протокол TLS 1.3, в качестве "Предложенного стандарта" (Proposed Standard). Занимающиеся развитием протокола TLS участники рабочей группы (Transport Layer Security Working Group) смогли прийти к консенсусу и проголосовали за стандартизацию 28 черновика спецификации (все проголосовали "За", исключая Warren Kumari (https://research.google.com/pubs/WarrenKumari.html) из Google, который проголосовал "не возражаю", пояснив (https://www.ietf.org/mail-archive/web/tls/current/msg25562.html), что не является экспертом по обсуждаемому вопросу). Установка защищённых соединений с использованием TLS 1.3 уже поддерживается в Firefox и Chrome, и будет предложена в ветке OpenSSL 1.1.1.<br><br><br>Особенности TLS 1.3:<br><br><br>- Удаление устаре https://www.opennet.ru/openforum/vsluhforumID3/113916.html#34 Tue, 27 Mar 2018 13:57:51 GMT Ну в gnutls с TLS 1.3 всё в порядке, вроде...<br> https://www.opennet.ru/openforum/vsluhforumID3/113916.html#33 Mon, 26 Mar 2018 15:56:55 GMT &gt; проголосовал "не возражаю", пояснив, что не является экспертом в по обсуждаемому вопросу<br><br>Знаем мы это, называется: "Не виноватая я, он сам пришел!..", - заранее якорь ставит.<br>Значит, гугл пропихнул очередной гнилой стандарт и делает невинную мину при плохой игре.<br> https://www.opennet.ru/openforum/vsluhforumID3/113916.html#31 Sun, 25 Mar 2018 18:56:24 GMT &gt; Это и есть так называемая цепочка доверия в системах PKI?<br><br>В принципе да, всё верно описали.<br><br>&gt; Кажется я уже начинаю понимать, можно не шифровать сам файл, а допустим его хэш <br><br>Да, подписываются всегда хэши. Особенность большинства асимметричных функций подписи (или шифрования) -- они не могут работать с сообщениями больше размера своего ключа, грубо говоря. То есть могут подписать только 256 или там например 512 бит.<br><br>&gt; Тут меня смущает аналогия с обыкновенной подписью - цифровая подпись каждый раз <br>&gt; разная для разных файлов. Куда больше на цифровой аналог рукописной подписи <br>&gt; подходят именно приватные ключи<br><br>Подпись настоящая тоже разная: всегда что-то меняется при написании, но написать всё-равно сможете только вы. Ваше умение -- ваш приватный ключ. Плюс не забывайте что материальная подпись ставится на каком-то материальном носителе, чернила наносятся поверх какого-то текста, какого-то листка. В цифровой приватный ключ применяется к чётко заданному (по хэшу) набору данных.<br><br>На правах самор https://www.opennet.ru/openforum/vsluhforumID3/113916.html#30 Sun, 25 Mar 2018 17:19:57 GMT &gt;В асимметричной два ключа: если что-то зашифровали одним, то дешифровать можно другим (и наоборот). Один из ключей называют приватным, а другой публичным. Отсюда возникает два варианта использования частых: если зашифровать сообщение приватным ключом и дешифровать публичным, то мы получаем функцию подписи (подписать может только владелец приватного, а проверить (дешифровать) может кто-угодно). Если зашифровать публичным, а дешифровать приватным, то мы получим асимметричное шифрование (отправить шифрованное сообщение может любой, а прочитать только владелец приватного ключа)<br><br>Есть отправитель с ключами Priv и Pub, который передаёт сообщение M.<br>1) Функция crypt(M, Priv) = M_C1, M_C1 - шифрованное сообщение, но такое, что decrypt(M_C1, Pub) = M.<br>Успешная расшифровка публичным ключом Pub подтверждает факт того, что сообщение пришло именно от отправителя, а не кого-нибудь другого.<br><br>2) Функция crypt(M, Pub) = M_C2, M_C2 - такое шифрованное сообщение, что decrypt(M_C2, Priv) = M. [Тут вопрос, это те же самые ф https://www.opennet.ru/openforum/vsluhforumID3/113916.html#29 Sun, 25 Mar 2018 11:25:25 GMT &gt; Вроде всё понятно, кроме этапа проверки. Расшифровка открытым ключом = расшифровка сертификатом? <br><br>Для объяснения на пальцах действительно часто применяют понятие расшифровки (для RSA например это буквально так и есть расшифровка), но правильнее применять "проверка подписи". Асимметричную криптографию, опять же для простоты, часто соотносят с симметричной и именно на функциях шифрования. Симметричная: один и тот же ключ применяется для шифрования и дешифрования. В асимметричной два ключа: если что-то зашифровали одним, то дешифровать можно другим (и наоборот). Один из ключей называют приватным, а другой публичным. Отсюда возникает два варианта использования частых: если зашифровать сообщение приватным ключом и дешифровать публичным, то мы получаем функцию подписи (подписать может только владелец приватного, а проверить (дешифровать) может кто-угодно). Если зашифровать публичным, а дешифровать приватным, то мы получим асимметричное шифрование (отправить шифрованное сообщение может любой, а прочитать только https://www.opennet.ru/openforum/vsluhforumID3/113916.html#28 Sun, 25 Mar 2018 10:59:49 GMT &gt;Конкретику работы DH или ЭЦП лучше погуглить о том как они устроены -- там много разновидностей<br><br>Может прокомментируете коротко? https://ru.wikipedia.org/wiki/%D0%AD%D0%BB%D0%B5%D0%BA%D1%82%D1%80%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%8C#/media/File:Digital_Signature_diagram_ru.png<br>Вроде всё понятно, кроме этапа проверки. Расшифровка открытым ключом = расшифровка сертификатом?<br>И ещё раз спасибо за пояснения.<br> https://www.opennet.ru/openforum/vsluhforumID3/113916.html#27 Sun, 25 Mar 2018 10:27:49 GMT Всё верно описали. Одно но, придирка: лучше вычислять MAC над шифротекстом, а не открытым текстом. Когда-то TLS делал как вы и описали и это приводило к возможным атакам типа BEAST, позволяющим полностью дешифровать сообщение.<br><br>&gt; К сожалению, я пока не понял как работает Диффи-Хельман, пресловутая цифровая подпись <br>&gt; документа, https (или понял, потому что схема описанная выше очень сильно <br>&gt; напоминает обмен браузера со Сбером) и электронная почта с PGP.<br><br>Конкретику работы DH или ЭЦП лучше погуглить о том как они устроены -- там много разновидностей. HTTPS фактически вы описали (ну, одно из подмножеств, так как в TLS тоже уйма всяких режимов работы).<br><br>PGP: симметричная часть схожая, хотя вместо MAC там используется просто хэш, находящийся внутри сообщения которое подписывается ЭЦП (это архаично, но и PGP в таком виде был создан чуть ли не четверть века назад). Диффи-Хельман там не применяется, а вместо него действительно асимметричное шифрование. Но суть схожая: шифр, какая-то аутентификация зашифрова https://www.opennet.ru/openforum/vsluhforumID3/113916.html#26 Sun, 25 Mar 2018 10:06:56 GMT Есть сообщение M, которое необходимо передать.<br>Есть секретный ключ K, о котором договорились/знают оба конца - отправитель и получатель.<br><br>MAC-функция, принимает M и K на вход, и выдаёт MAC на выходе:<br>MAC_fun(M, K) = MAC<br><br>Функция потокового шифра, или просто потоковый шифр Cypher, который принимает на вход ключ K и выдаёт "длинную псевдослучайную строку" C:<br>Cypher(K) = C<br><br>Затем, используется функция XOR(M, C), результатом работы которой считаем зашифрованное сообщение M_C. Причём, XOR(M_C, C) = M. (могу предположить, подойдёт любая другая функция, обладающая этим свойством?)<br><br>Отправитель высылает M_C и MAC, получатель их принимает. У получателя уже есть ключ K, а потому он легко вычисляет Cypher(K) = C (т.е. "длинная псевдослучайная строка" потокового шифра становится известна, как только договорились о ключах и виде самой функции?)<br>Затем, получатель выполняет XOR(M_C, C) = M. Получив сообщение M, он подаёт его вместе с ключом на вход MAC_fun и проверяет с тем MACом, который ему прислал отправитель https://www.opennet.ru/openforum/vsluhforumID3/113916.html#25 Sun, 25 Mar 2018 08:44:52 GMT MAC функция принимает на входе ключ и сообщение. На выходе выдаёт аутентификационный тэг или который тоже называют MAC-ом (как хэш-функция выдаёт хэш). Заявленный отправитель проверяет тем фактом, что ключ от MAC согласуется на этапе handshake только между двумя участниками сессии. Ключ этот знают только двое. Без MAC-а любое шифрование становится просто бесполезным, так как, особенно в потоковых шифрах, сообщение можно изменить и подделать не проводя дешифровку.<br><br>Касательно ChaCha20 (да и любого потокового шифра, как например AES-CTR который тоже потоковый). Ключ применяется для выработки псевдослучайной последовательности. Грубо говоря, потоковый шифр это PRNG (генератор псевдослучайных чисел) на вход которому подаётся ключ, а на выходе выплёвывается длинная псевдослучайная строка. Эта строка просто XOR-ится с данными и результатом будет шифротекст. Из-за особенностей XOR-а, чтобы расшифровать её, то нужно снова сXOR-ить с этой PRNG последовательностью.<br><br>curve25519 -- очень быстрая, безопасная (http://s