Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"TLS 1.3 получил статус предложенного стандарта "	+/–
Сообщение от opennews on 24-Мрт-18, 12:59
Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, утвердил (http://www.ietf.org/mail-archive/web/ietf-announce/current/m...) финальный вариант спецификации (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. Особенности TLS 1.3: -  Удаление устаревших и ненадёжных криптографических примитивов (MD5, SHA-224) и возможностей (сжатие, повторное согласование, не-AEAD шифры, статический обмен ключами RSA и DH, указание unix-времени в Hello-сообщениях и т.п.); -  Работа только в режиме  совершенной прямой секретности  (PFS, Perfect Forward Secrecy (https://ru.wikipedia.org/wiki/Perfect_forward_secrecy)), при котором компрометация одного из долговременных ключей не позволяет расшифровать ранее перехваченный сеанс. Оставление поддержки только PFS вызвало много споров (https://www.opennet.dev/opennews/art.shtml?num=46902) и стало камнем предкновения в достижении консенсуса, так как ряд производителей указывали на возможное негативное влияние PFS на корпоративные системы, в которых применяется инспектирования проходящего трафика, например, для обеспечения отказоустойчивости; -  Поддержка режима 0-RTT (https://blog.cloudflare.com/introducing-0-rtt/) для устранения задержек при возобновлении ранее установленных HTTPS-соединений. При установке HTTPS-соединения выполняются 4 фазы: запрос DNS, TCP Handshake (1 RTT), TLS Handshake (2 RTT на согласование ключей и параметров шифрованного канала) и отправка запроса HTTP (1 RTT). По сравнению с TLS 1.2 в новом стандарте число RTT для TLS Handshake сокращено с 2 до 1, т.е. для установки и возобновления соединения требуется запрос DNS и 3 цикла обмена данными (RTT) вместо 4.  0-RTT позволяет сохранить ранее согласованные параметры TLS  и снизить до 2 число RTT при  возобновлении ранее установленного соединения; -  Поддержка потокового шифра ChaCha20 (http://cr.yp.to/chacha.html) и алгоритма аутентификации сообщений (MAC) Poly1305 (http://cr.yp.to/mac.html), разработанных Дэниелом Бернштейном (Daniel J. Bernstein (http://cr.yp.to/djb.html)), Таней Ланге (Tanja Lange) и Питером Швабе (Peter Schwabe). ChaCha20 и Poly1305 можно рассматривать, как более быстрые и безопасные аналоги AES-256-CTR и HMAC,  программная реализация которых позволяет добиться фиксированного времени выполнения без задействования специальных аппаратных ускорителей; -  Поддержка защищённых ключей аутентификации Ed25519 (http://ed25519.cr.yp.to/), которые обладают более высоким уровнем безопасности, чем  ECDSA и DSA, и при этом отличаются очень высокой скоростью верификации и создания подписей. Стойкость к взлому для Ed25519 составляет порядка 2^128 (в среднем для атаки на Ed25519 потребуется совершить 2^140 битовых операций), что соответствует стойкости таких алгоритмов, как NIST P-256 и RSA с размером ключа в 375 байт или 128-битному блочному шифру. Ed25519 также не подвержен проблемам с коллизиями в хэшах, не чувствителен к атакам через определение скорости работы кэша (cache-timing attacks (http://cr.yp.to/antiforgery/cachetiming-20050414.pdf)) и атакам по сторонним каналам (side-channel attacks); -  Поддержка  обмена ключами на основе алгоритмов x25519 (https://en.wikipedia.org/wiki/Curve25519) (RFC 7748 (https://tools.ietf.org/html/rfc7748)) и x448 (RFC 8031 (https://tools.ietf.org/html/rfc8031)); -  Поддержка HKDF (https://en.wikipedia.org/wiki/HKDF) (HMAC-based Extract-and-Expand Key Derivation Function). URL: http://www.ietf.org/mail-archive/web/ietf-announce/current/m... Новость: https://www.opennet.dev/opennews/art.shtml?num=48324
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "TLS 1.3 получил статус предложенного стандарта "	+3 +/–
Сообщение от Вы забыли заполнить поле Name on 24-Мрт-18, 12:59
> все проголосовали "За", исключая Warren Kumari из Google, который проголосовал "не возражаю", пояснив, что не является экспертом в по обсуждаемому вопросу Как можно быть в рабочей группе и не являться "экспертом"?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "TLS 1.3 получил статус предложенного стандарта "	+9 +/–
	Сообщение от lucentcode (ok) on 24-Мрт-18, 13:09
	>> все проголосовали "За", исключая Warren Kumari из Google, который проголосовал "не возражаю", пояснив, что не является экспертом в по обсуждаемому вопросу > Как можно быть в рабочей группе и не являться "экспертом"? Да запросто - если это лоббист крупной компании. Его прикрепили к комитету что-бы он транслировал пожелания компании членам комитета, а их фидбек - руководству и более осведомлённым в данном вопросе коллегам. Сам он при этом круто разбирается в DNSSEC, если верить его профилю. Вероятно и в криптографии он всё-таки разбирается, просто TLS не его профиль.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "TLS 1.3 получил статус предложенного стандарта "	+20 +/–
	Сообщение от Аноним (??) on 24-Мрт-18, 13:42
	Например, можно быть специалистам по сетевым протоколам, но при этом не разбираться в деталях криптографии.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	22. "TLS 1.3 получил статус предложенного стандарта "	–3 +/–
	Сообщение от пох on 25-Мрт-18, 09:44
	> Как можно быть в рабочей группе и не являться "экспертом"? правильный вопрос - как можно быть представителем гугля и настолько честным? полагаю, в этой "рабочей группе" традиционно, _экспертов_ - ноль. В лучшем случае - несколько. Остальные - хорошо если хотя бы разбираются в вопросе, что не делает человека экспертом. Учитывая "борьбу за 2rtt", возникают сомнения и в этом. И засланы, как уже говорено, на деньги мегакорпораций, пропихивать удобные им рецепты (полагаю, NSA тоже имеет своего представителя. Или пяток.) А этот Кумар возьми да и признайся... уволят, наверное.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	33. "TLS 1.3 получил статус предложенного стандарта "	–2 +/–
	Сообщение от Брюс Шнайер on 26-Мрт-18, 18:56
	> проголосовал "не возражаю", пояснив, что не является экспертом в по обсуждаемому вопросу Знаем мы это, называется: "Не виноватая я, он сам пришел!..", - заранее якорь ставит. Значит, гугл пропихнул очередной гнилой стандарт и делает невинную мину при плохой игре.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "TLS 1.3 получил статус предложенного стандарта "	–2 +/–
Сообщение от Retrosharer on 24-Мрт-18, 13:25
> совершенной прямой секретности Совершенная секретность с упреждением! Но лучше - совершенная приватность с упреждением
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	6. "TLS 1.3 получил статус предложенного стандарта "	+/–
	Сообщение от Crazy Alex (ok) on 24-Мрт-18, 13:47
	Лучше калька - кто на русском всё это осваивает - привыкнет, а кто знает на английском (а их, понятно, большинство) - сразу поймёт.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	9. "TLS 1.3 получил статус предложенного стандарта "	+1 +/–
	Сообщение от Аноним (??) on 24-Мрт-18, 16:01
	Совершенно секретный Retrosharer.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	10. "TLS 1.3 получил статус предложенного стандарта "	+1 +/–
	Сообщение от Ordu (ok) on 24-Мрт-18, 16:29
	> Но лучше - совершенная приватность с упреждением Лучше не надо. Есть слово privacy, которое естественным образом "переводится" как приватность, если переводить secrecy как "приватность", то могут возникнуть трудности с пониманием перевода.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	21. "TLS 1.3 получил статус предложенного стандарта "	–1 +/–
	Сообщение от Ю.Т. on 25-Мрт-18, 09:41
	Эти слова даже по-английски трудноразличимы, и практически различаются только по употреблению. Два пути: (фактический) транскрипция и (трудный) перевод по смыслу. Ради пояснения токмо: secrecy - тайность privacy - укрытость, скрытость (лица от мира)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

12. "TLS 1.3 получил статус предложенного стандарта "	+1 +/–
Сообщение от X4asd (ok) on 24-Мрт-18, 17:22
> RSA с размером ключа в 375 байт чего?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "TLS 1.3 получил статус предложенного стандарта "	+1 +/–
	Сообщение от Аноним84701 (ok) on 24-Мрт-18, 17:59
	http://ed25519.cr.yp.to/ > breaking it has similar difficulty to breaking NIST P-256, RSA with ~3000-bit keys, strong 128-bit block ciphers Кто-то немного переусердствовал при переводе :) Закомитил поправку.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

13. "TLS 1.3 получил статус предложенного стандарта "	–1 +/–
Сообщение от Слава (??) on 24-Мрт-18, 17:52
Господа, а можно вопросы: 1) Действительно ли  AES-256-CTR и HMAC можно считать небезопасными/медленными, раз вместо этих примитивов предлагается использовать новые? 2) Насколько ускорится соединение TLS, при сокращении TLS Handshake с 2 до 1? 3) "Поддержка защищённых ключей аутентификации Ed25519, которые обладают более высоким уровнем безопасности, чем ECDSA и DSA" - опять же, ECDSA уже взломали? Есть теории? 4) Поддержка x25519 (RFC 7748) и x448 (RFC 8031), зачем? Чтобы было или реально польза? 5) HKDF так необходима как и PBKDF? Спасибо!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "TLS 1.3 получил статус предложенного стандарта "	+16 +/–
	Сообщение от Сергей (??) on 24-Мрт-18, 19:11
	1) Никто не говорил что AES-CTR/HMAC не безопасны. Просто не нужно использовать по отдельности два примитива: шифрование и аутентификацию. Они должны быть всегда вместе и поэтому TLS 1.3 говорит что используются только AEAD режимы (аутентифицированного шифрования). Как минимум AES-CTR/HMAC медленный и не имеет его использовать когда есть AES-CCM, AES-GCM или ChaCha20-Poly1305. 2) Достаточно сделать ping чтобы увидеть время одного round-trip-а чтобы увидеть насколько ускорится соединение. 3) 25519 как минимум не требует подкармливанием энтропии во время формирования подписи. Это убирает множество возможных атак. 25519 кривую существенно проще реализовать правильно, без диких side-channel утечек. ECDSA/DSA можно использовать безопасно -- но сложно и лучше не связываться. https://safecurves.cr.yp.to/ 4) 25519/448: снова советую посмотреть ссылку из предыдущего пункта про safecurves. Они безопаснее. Плюс 25519 существенно более быстрый на практике. Реально польза которую пользователи жаждят. 5) HKDF хорошая проверенная простая функция вовсю используемая за пределами TLS. TLS-PRF используемый раньше просто бесмысленнен. HKDF это более простая реализация. Упоминание PBKDF я не нашёл в TLS 1.3.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	17. "TLS 1.3 получил статус предложенного стандарта "	+/–
	Сообщение от Слава (??) on 24-Мрт-18, 20:14
	Сергей, спасибо за развернутые ответы, оч помогли. К сожалению, могу оставить вам только веселый смайл (o^▽^o) :)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	16. "TLS 1.3 получил статус предложенного стандарта "	+2 +/–
	Сообщение от h31 (ok) on 24-Мрт-18, 20:13
	Добавлю своё мнение к предыдущему комментатору. 1) Они безопасные, но при реализации этих алгоритмов есть много мест, где можно накосячить (особенно если говорить про режим CBC). В этом плане AEAD делает жизнь проще для авторов библиотек шифрования. По скорости они хороши, но если есть аппаратное ускорение AES, то AES-GCM будет быстрее. А если его нет, то предлагается использовать ChaCha20.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	18. "TLS 1.3 получил статус предложенного стандарта "	+2 +/–
	Сообщение от h31 (ok) on 24-Мрт-18, 20:16
	Конкретно AES-CTR тут особых проблем не вызывает, народ больше хотел отказаться от AES-CBC. CTR просто оказался не очень популярен, народ довольно быстро перескочил на GCM (который по своей сути CTR + MAC на основе AES).
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	23. "TLS 1.3 получил статус предложенного стандарта "	–1 +/–
	Сообщение от пох on 25-Мрт-18, 10:00
	> 1) Действительно ли  AES-256-CTR и HMAC можно считать небезопасными/медленными, раз вместо нет. NIH. > 2) Насколько ускорится соединение TLS, при сокращении TLS Handshake с 2 до соединение - как и написано, в два раза. Скорость открытия страницы твоим браузером - нинасколько, она не этим вообще ограничена. > 3) "Поддержка защищённых ключей аутентификации Ed25519, которые обладают более высоким > уровнем безопасности, чем ECDSA и DSA" - опять же, ECDSA уже > взломали? Есть теории? NIH, причем НЕТ ни одного подтвержденного независимыми экспертами исследования протоколов и алгоритмов djb. Даже экспертами NSA. Все просто ему и компании поверили. > 4) Поддержка x25519 (RFC 7748) и x448 (RFC 8031), зачем? это просто спецификация эллиптических кривых - в смысле, инструкция для программиста, как их считать. Учитывая что от nist'овских "из трубки что-то жареным потянуло" еще в 2010м, нужны хоть какие-то. > 5) HKDF так необходима как и PBKDF? вместо. Опять же потому, что ко всему, что наразрабатывала RSA, "есть вопросы" (на самом деле нет, хотя выглядит этот алгоритм для типового применения просто на порядок лучше - но я тоже не эксперт, как тот Кумар, и возможно эта простота с полаганием на чужие данные может выйти боком)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

19. "TLS 1.3 получил статус предложенного стандарта "	–1 +/–
Сообщение от ктота on 25-Мрт-18, 03:18
"RTFM Inf." а с таким названием точно пропустят?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "TLS 1.3 получил статус предложенного стандарта "	+/–
Сообщение от barmaglot (??) on 25-Мрт-18, 05:27
Поправьте: Ed25519 - это система цифровых подписей. А "система аутентификации", на самом деле протокол аутентификации это curve25519, стандартизован как  x25519. Разработаны также Бернштейном. Как мы долго этого ждали. Наконец-то !!!!!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

24. "TLS 1.3 получил статус предложенного стандарта "	+/–
Сообщение от Аноним (??) on 25-Мрт-18, 11:25
Ребят, можете написать "криптография для dummies"? Вот, например, Poly1305 это вариант MAC. >Message authentication code (MAC), sometimes known as a tag, is a short piece of information used to authenticate a message — in other words, to confirm that the message came from the stated sender (its authenticity) and has not been changed. Я так понимаю, на вход MAC-функция принимает сообщение, а на выходе выдает уникальный хэш? этого сообщения. Но как в этой цепочке, проверяется заявленный  отправитель - нипанятна... Также, непонятны практические схемы применения, какие задачи этим средством решаются. Или вот ChaCha20 - потоковый шифр. >A stream cipher is a symmetric key cipher where plaintext digits are combined with a pseudorandom cipher digit stream (keystream). In a stream cipher, each plaintext digit is encrypted one at a time with the corresponding digit of the keystream, to give a digit of the ciphertext stream. Базово хватаюсь за "symmetric key cipher" - симметричное шифрование с ключом (ключ один и тот же на шифровку и расшифровку). Ну и тут мои полномочия всё. Символ текста шифруется 1 раз соответствующим ему числом из [псевдо]случайного шифропотока (keystream). Бред и шизофазия. А где ключ? В какой момент он применяется? Чем так хороша Curve25519? Почему её используют для согласования ключей (Key-agreement protocol - что за сущность, из-за чего возникла?) по схеме Elliptic-curve Diffie–Hellman. Edwards-curve Digital Signature Algorithm (EdDSA), вариантом которой является Ed25519. Digital signature (цифровая подпись), Public-key cryptography (криптосистема с открытым ключом), где-то здесь появляется асимметричное шифрование (почему?), и снова Curve25519, которую использовали уже в согласовании ключей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "TLS 1.3 получил статус предложенного стандарта "	+5 +/–
	Сообщение от Сергей (??) on 25-Мрт-18, 11:44
	MAC функция принимает на входе ключ и сообщение. На выходе выдаёт аутентификационный тэг или который тоже называют MAC-ом (как хэш-функция выдаёт хэш). Заявленный отправитель проверяет тем фактом, что ключ от MAC согласуется на этапе handshake только между двумя участниками сессии. Ключ этот знают только двое. Без MAC-а любое шифрование становится просто бесполезным, так как, особенно в потоковых шифрах, сообщение можно изменить и подделать не проводя дешифровку. Касательно ChaCha20 (да и любого потокового шифра, как например AES-CTR который тоже потоковый). Ключ применяется для выработки псевдослучайной последовательности. Грубо говоря, потоковый шифр это PRNG (генератор псевдослучайных чисел) на вход которому подаётся ключ, а на выходе выплёвывается длинная псевдослучайная строка. Эта строка просто XOR-ится с данными и результатом будет шифротекст. Из-за особенностей XOR-а, чтобы расшифровать её, то нужно снова сXOR-ить с этой PRNG последовательностью. curve25519 -- очень быстрая, безопасная (http://safecurves.cr.yp.to/), проще многих других в реализации. Асимметричного шифрования, шифрования как такового, не появляется вообще. Именно шифровать асимметрично уже давно перестали за ненадобностью. Из асимметричных примитивов используются: согласование ключей (Диффи-Хельман) и подпись. Без подписи нельзя аутентифицировать противоположную сторону: подписью (с предоставлением сертификата (публичный ключ подписанный третьей доверенной стороной)) оборачивается весь handshake где согласуются симметричные ключи, которые уже шифруют и MAC-аутентифицируют. DH используется для выработки этих симметричных ключей. Вообще именно DH стал первой на практике используемым асимметричным алгоритмом. Всё очень просто. Каждое сообщение нам нужно зашифровать и аутентифицировать. Значит нужен шифр и MAC. Берём AES-CTR и HMAC, или ChaCha20 и Poly1305, или AES в GCM режиме (и шифр и MAC одновременно) или AES в CCM режиме (тоже шифр и MAC одновременно). Для этих двух функций нам нужны ключи, симметричные. И удалённой стороне нужны точно такие же. Значит нужен протокол согласования ключей, key agreement или, как это стало нарицательным, Диффи-Хельман, DH. Но DH уязвим к MitM атаке, где мы понятия не имеем что говорим именно со Сбербанком, а не с третьим лицом по-середине. Поэтому нужно (асимметрично) аутентифицировать противоположную сторону и в TLS используется инфраструктура публичных ключей (PKI) где у каждого есть сертификат (публичный ключ) подписанный доверенной третьей стороной. Сообщения DH просто подписываются приватным ключом этого сертификата противоположной стороны. Имеем: подтверждение (через третье лицо) что обмен handshake данными идёт со Сбербанком, согласование симметричных ключей, шифрование и аутентификация. Асимметричное шифрование банально просто не нужно чтобы point-to-point устанавливать зашифрованный/аутентифицированный канал связи. curve25519 это Диффи-Хельман, а Ed25519 это подпись. Внутри по сути используется такая же кривая (быстрая, безопасная, итд) и поэтому "25519" однокоренное.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

26. "TLS 1.3 получил статус предложенного стандарта "	+/–
Сообщение от Аноним (??) on 25-Мрт-18, 13:06
Есть сообщение M, которое необходимо передать. Есть секретный ключ K, о котором договорились/знают оба конца - отправитель и получатель. MAC-функция, принимает M и K на вход, и выдаёт MAC на выходе: MAC_fun(M, K) = MAC Функция потокового шифра, или просто потоковый шифр Cypher, который принимает на вход ключ K и выдаёт "длинную псевдослучайную строку" C: Cypher(K) = C Затем, используется функция XOR(M, C), результатом работы которой считаем зашифрованное сообщение M_C. Причём, XOR(M_C, C) = M. (могу предположить, подойдёт любая другая функция, обладающая этим свойством?) Отправитель высылает M_C и MAC, получатель их принимает. У получателя уже есть ключ K, а потому он легко вычисляет Cypher(K) = C (т.е. "длинная псевдослучайная строка" потокового шифра становится известна, как только договорились о ключах и виде самой функции?) Затем, получатель выполняет XOR(M_C, C) = M. Получив сообщение M, он подаёт его вместе с ключом на вход MAC_fun и проверяет с тем MACом, который ему прислал отправитель вместе с зашифрованным сообщение M_C. Если MACи совпали, то сообщение именно от того отправителя, и не было подменено/искажено во время передачи. Осталось только согласовать ключ. Вот здесь и торчит асимметричный Диффи-Хельман, для тех целей, чтобы Ева не знала, о каком ключе договорятся Алиса и Боб. Я правильно себе представляю картину в общих чертах? К сожалению, я пока не понял как работает Диффи-Хельман, пресловутая цифровая подпись документа, https (или понял, потому что схема описанная выше очень сильно напоминает обмен браузера со Сбером) и электронная почта с PGP. Но в любом случаи спасибо, Сергей, за лекцию.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "TLS 1.3 получил статус предложенного стандарта "	+1 +/–
	Сообщение от Сергей (??) on 25-Мрт-18, 13:27
	Всё верно описали. Одно но, придирка: лучше вычислять MAC над шифротекстом, а не открытым текстом. Когда-то TLS делал как вы и описали и это приводило к возможным атакам типа BEAST, позволяющим полностью дешифровать сообщение. > К сожалению, я пока не понял как работает Диффи-Хельман, пресловутая цифровая подпись > документа, https (или понял, потому что схема описанная выше очень сильно > напоминает обмен браузера со Сбером) и электронная почта с PGP. Конкретику работы DH или ЭЦП лучше погуглить о том как они устроены -- там много разновидностей. HTTPS фактически вы описали (ну, одно из подмножеств, так как в TLS тоже уйма всяких режимов работы). PGP: симметричная часть схожая, хотя вместо MAC там используется просто хэш, находящийся внутри сообщения которое подписывается ЭЦП (это архаично, но и PGP в таком виде был создан чуть ли не четверть века назад). Диффи-Хельман там не применяется, а вместо него действительно асимметричное шифрование. Но суть схожая: шифр, какая-то аутентификация зашифрованного сообщения, асимметричная подпись для аутентификации собеседника, асимметричное шифрование для передачи симметричных ключей. Сейчас обсуждается и скоро должен увидеть свет новый стандарт OpenPGP -- в нём уже всё точно так же как и в TLS 1.3: *25519, AEAD (шифр и MAC вместе) режимы шифрования и всё по-современному.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

28. "TLS 1.3 получил статус предложенного стандарта "	–1 +/–
Сообщение от Аноним (??) on 25-Мрт-18, 13:59
>Конкретику работы DH или ЭЦП лучше погуглить о том как они устроены -- там много разновидностей Может прокомментируете коротко? https://ru.wikipedia.org/wiki/%D0%AD%D0%... Вроде всё понятно, кроме этапа проверки. Расшифровка открытым ключом = расшифровка сертификатом? И ещё раз спасибо за пояснения.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "TLS 1.3 получил статус предложенного стандарта "	+2 +/–
	Сообщение от Сергей (??) on 25-Мрт-18, 14:25
	> Вроде всё понятно, кроме этапа проверки. Расшифровка открытым ключом = расшифровка сертификатом? Для объяснения на пальцах действительно часто применяют понятие расшифровки (для RSA например это буквально так и есть расшифровка), но правильнее применять "проверка подписи". Асимметричную криптографию, опять же для простоты, часто соотносят с симметричной и именно на функциях шифрования. Симметричная: один и тот же ключ применяется для шифрования и дешифрования. В асимметричной два ключа: если что-то зашифровали одним, то дешифровать можно другим (и наоборот). Один из ключей называют приватным, а другой публичным. Отсюда возникает два варианта использования частых: если зашифровать сообщение приватным ключом и дешифровать публичным, то мы получаем функцию подписи (подписать может только владелец приватного, а проверить (дешифровать) может кто-угодно). Если зашифровать публичным, а дешифровать приватным, то мы получим асимметричное шифрование (отправить шифрованное сообщение может любой, а прочитать только владелец приватного ключа). Для образования это показывают всегда именно так -- так проще понять. В RSA алгоритме буквально всё так и происходит. Однако в настоящих на практике используемых алгоритмах часто отсутствует шифрование как таковое и есть только создание подписи и проверка -- ECDSA, Ed25519, Ed448 алгоритмы например. А Диффи-Хельман вообще не вписывается в эти примеры с шифрованием/дешифрованием, поэтому о нём часто умалчивают, чтобы не усложнять объяснение в чём отличие асимметричной криптографии от симметричной. Чисто технически, сертификат (публичный ключ из него) можно использовать для асимметричного дешифрования, например если используется RSA алгоритм. Просто такое применение крайне редко в Интернете.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	30. "TLS 1.3 получил статус предложенного стандарта "	+/–
	Сообщение от Аноним (??) on 25-Мрт-18, 20:19
	>В асимметричной два ключа: если что-то зашифровали одним, то дешифровать можно другим (и наоборот). Один из ключей называют приватным, а другой публичным. Отсюда возникает два варианта использования частых: если зашифровать сообщение приватным ключом и дешифровать публичным, то мы получаем функцию подписи (подписать может только владелец приватного, а проверить (дешифровать) может кто-угодно). Если зашифровать публичным, а дешифровать приватным, то мы получим асимметричное шифрование (отправить шифрованное сообщение может любой, а прочитать только владелец приватного ключа) Есть отправитель с ключами Priv и Pub, который передаёт сообщение M. 1) Функция crypt(M, Priv) = M_C1, M_C1 - шифрованное сообщение, но такое, что decrypt(M_C1, Pub) = M. Успешная расшифровка публичным ключом Pub подтверждает факт того, что сообщение пришло именно от отправителя, а не кого-нибудь другого. 2) Функция crypt(M, Pub) = M_C2, M_C2 - такое шифрованное сообщение, что decrypt(M_C2, Priv) = M. [Тут вопрос, это те же самые функции, или сопряжённые с ними, допустим crypt2 и decrypt2?] Если есть желание передать секретное сообщение человеку (получателю), отправитель берёт его публичный ключ, пропускает через crypt(M, Pub), и уже передаёт, в том числе и через посредников, шифрованное сообщение M_C2. Получатель делает decrypt(M_C2, Priv), у него же есть приватный ключ Priv, и может даже оформленный в сертификат, и читает секретное сообщение. 3) Приватный ключ Priv пользователя/клиента хранится в сертификате, выданным УЦ, вместе с дополнительный полями, такими как даты и время начала и конца действия этого сертификата. Сам сертификат подписан УЦ той же (а можно иной) функцией crypt. УЦ это такой большой мальчик, которому все верят, также предоставляет свой публичный ключ, оформленный в сертификат. А сертификат большого мальчика подписал, например его папа, а папе - товарищ из милиции и т.д. Это и есть так называемая цепочка доверия в системах PKI? Верим большим дядям с их сертификатам (и хранящимся в них публичным ключам), и по цепочке сверху вниз делаем decrypt(M_C1, Pub) , где M_C1 - сертификаты, которые проверяем и начинаем доверять, если всё в порядке. >Однако в настоящих на практике используемых алгоритмах часто отсутствует шифрование как таковое и есть только создание подписи и проверка -- ECDSA, Ed25519, Ed448 алгоритмы например. Кажется я уже начинаю понимать, можно не шифровать сам файл, а допустим его хэш (если предположить, что хэши уникальны для разных файлов). Получили хэш, пропустили его через криптофункцию и получили цифровую подпись: crypt(hash, Priv) = sign. https://en.wikipedia.org/wiki/Electronic_signature#/media/Fi... Тут меня смущает аналогия с обыкновенной подписью - цифровая подпись каждый раз разная для разных файлов. Куда больше на цифровой аналог рукописной подписи подходят именно приватные ключи (рукописная подпись не меняется, за исключением небольших вариаций и отклонений из-за непостоянства почерка). Но приватные ключи показывать не стоит. Да и в таких схемах (и в схеме с MACами) и не нужно. >А Диффи-Хельман вообще не вписывается в эти примеры с шифрованием/дешифрованием, поэтому о нём часто умалчивают, чтобы не усложнять объяснение в чём отличие асимметричной криптографии от симметричной. Идею DH я в целом понял - безопасно согласовать ключ (ну или передать сообщение в целом), когда есть посредник, который ещё по совместительству и злоумышленник. Буду пересматривать https://www.youtube.com/watch?v=F3zzNa42-tQ до просветления.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	31. "TLS 1.3 получил статус предложенного стандарта "	+/–
	Сообщение от Сергей (??) on 25-Мрт-18, 21:56
	> Это и есть так называемая цепочка доверия в системах PKI? В принципе да, всё верно описали. > Кажется я уже начинаю понимать, можно не шифровать сам файл, а допустим его хэш Да, подписываются всегда хэши. Особенность большинства асимметричных функций подписи (или шифрования) -- они не могут работать с сообщениями больше размера своего ключа, грубо говоря. То есть могут подписать только 256 или там например 512 бит. > Тут меня смущает аналогия с обыкновенной подписью - цифровая подпись каждый раз > разная для разных файлов. Куда больше на цифровой аналог рукописной подписи > подходят именно приватные ключи Подпись настоящая тоже разная: всегда что-то меняется при написании, но написать всё-равно сможете только вы. Ваше умение -- ваш приватный ключ. Плюс не забывайте что материальная подпись ставится на каком-то материальном носителе, чернила наносятся поверх какого-то текста, какого-то листка. В цифровой приватный ключ применяется к чётко заданному (по хэшу) набору данных. На правах саморекламы могу посоветовать вот такое видео небольшое: https://www.youtube.com/watch?v=Apl9QzuXUz8
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

34. "TLS 1.3 получил статус предложенного стандарта "	+/–
Сообщение от Ne01eX (ok) on 27-Мрт-18, 16:57
Ну в gnutls с TLS 1.3 всё в порядке, вроде...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема