| 1.1, Вы забыли заполнить поле Name (?), 12:59, 24/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
> все проголосовали "За", исключая Warren Kumari из Google, который проголосовал "не возражаю", пояснив, что не является экспертом в по обсуждаемому вопросу
Как можно быть в рабочей группе и не являться "экспертом"?
| | |
| |
| 2.2, lucentcode (ok), 13:09, 24/03/2018 [^] [^^] [^^^] [ответить]
| +9 +/– |
 >> все проголосовали "За", исключая Warren Kumari из Google, который проголосовал "не возражаю", пояснив, что не является экспертом в по обсуждаемому вопросу
> Как можно быть в рабочей группе и не являться "экспертом"?
Да запросто - если это лоббист крупной компании. Его прикрепили к комитету что-бы он транслировал пожелания компании членам комитета, а их фидбек - руководству и более осведомлённым в данном вопросе коллегам. Сам он при этом круто разбирается в DNSSEC, если верить его профилю. Вероятно и в криптографии он всё-таки разбирается, просто TLS не его профиль.
| | |
| 2.5, Аноним (-), 13:42, 24/03/2018 [^] [^^] [^^^] [ответить]
| +20 +/– |
Например, можно быть специалистам по сетевым протоколам, но при этом не разбираться в деталях криптографии.
| | |
| 2.22, пох (?), 09:44, 25/03/2018 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> Как можно быть в рабочей группе и не являться "экспертом"?
правильный вопрос - как можно быть представителем гугля и настолько честным?
полагаю, в этой "рабочей группе" традиционно, _экспертов_ - ноль.
В лучшем случае - несколько. Остальные - хорошо если хотя бы разбираются в вопросе, что не делает человека экспертом.
Учитывая "борьбу за 2rtt", возникают сомнения и в этом.
И засланы, как уже говорено, на деньги мегакорпораций, пропихивать удобные им рецепты (полагаю, NSA тоже имеет своего представителя. Или пяток.)
А этот Кумар возьми да и признайся... уволят, наверное.
| | |
| 2.33, Брюс Шнайер (?), 18:56, 26/03/2018 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> проголосовал "не возражаю", пояснив, что не является экспертом в по обсуждаемому вопросу
Знаем мы это, называется: "Не виноватая я, он сам пришел!..", - заранее якорь ставит.
Значит, гугл пропихнул очередной гнилой стандарт и делает невинную мину при плохой игре.
| | |
|
| 1.4, Retrosharer (?), 13:25, 24/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> совершенной прямой секретности
Совершенная секретность с упреждением!
Но лучше - совершенная приватность с упреждением
| | |
| |
| 2.6, Crazy Alex (ok), 13:47, 24/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 Лучше калька - кто на русском всё это осваивает - привыкнет, а кто знает на английском (а их, понятно, большинство) - сразу поймёт.
| | |
| 2.10, Ordu (ok), 16:29, 24/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Но лучше - совершенная приватность с упреждением
Лучше не надо. Есть слово privacy, которое естественным образом "переводится" как приватность, если переводить secrecy как "приватность", то могут возникнуть трудности с пониманием перевода.
| | |
| 2.21, Ю.Т. (?), 09:41, 25/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Эти слова даже по-английски трудноразличимы, и практически различаются только по употреблению. Два пути: (фактический) транскрипция и (трудный) перевод по смыслу.
Ради пояснения токмо:
secrecy - тайность
privacy - укрытость, скрытость (лица от мира)
| | |
|
| |
| 2.14, Аноним84701 (ok), 17:59, 24/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
 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
Кто-то немного переусердствовал при переводе :)
Закомитил поправку.
| | |
|
| 1.13, Слава (??), 17:52, 24/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Господа, а можно вопросы:
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?
Спасибо!
| | |
| |
| 2.15, Сергей (??), 19:11, 24/03/2018 [^] [^^] [^^^] [ответить]
| +16 +/– |
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.
| | |
| |
| 3.17, Слава (??), 20:14, 24/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Сергей, спасибо за развернутые ответы, оч помогли. К сожалению, могу оставить вам только веселый смайл (o^▽^o) :)
| | |
|
| 2.16, h31 (ok), 20:13, 24/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Добавлю своё мнение к предыдущему комментатору.
1) Они безопасные, но при реализации этих алгоритмов есть много мест, где можно накосячить (особенно если говорить про режим CBC). В этом плане AEAD делает жизнь проще для авторов библиотек шифрования. По скорости они хороши, но если есть аппаратное ускорение AES, то AES-GCM будет быстрее. А если его нет, то предлагается использовать ChaCha20.
| | |
| |
| 3.18, h31 (ok), 20:16, 24/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Конкретно AES-CTR тут особых проблем не вызывает, народ больше хотел отказаться от AES-CBC. CTR просто оказался не очень популярен, народ довольно быстро перескочил на GCM (который по своей сути CTR + MAC на основе AES).
| | |
|
| 2.23, пох (?), 10:00, 25/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> 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, "есть вопросы" (на самом деле нет, хотя выглядит этот алгоритм для типового применения просто на порядок лучше - но я тоже не эксперт, как тот Кумар, и возможно эта простота с полаганием на чужие данные может выйти боком)
| | |
|
| 1.20, barmaglot (??), 05:27, 25/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Поправьте: Ed25519 - это система цифровых подписей. А "система аутентификации", на самом деле протокол аутентификации это curve25519, стандартизован как x25519. Разработаны также Бернштейном.
Как мы долго этого ждали. Наконец-то !!!!!
| | |
| 1.24, Аноним (-), 11:25, 25/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ребят, можете написать "криптография для 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, которую использовали уже в согласовании ключей.
| | |
| |
| 2.25, Сергей (??), 11:44, 25/03/2018 [^] [^^] [^^^] [ответить] | +5 +/– | MAC функция принимает на входе ключ и сообщение На выходе выдаёт аутентификацио... большой текст свёрнут, показать | | |
|
| 1.26, Аноним (-), 13:06, 25/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Есть сообщение 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.
Но в любом случаи спасибо, Сергей, за лекцию.
| | |
| |
| 2.27, Сергей (??), 13:27, 25/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Всё верно описали. Одно но, придирка: лучше вычислять MAC над шифротекстом, а не открытым текстом. Когда-то TLS делал как вы и описали и это приводило к возможным атакам типа BEAST, позволяющим полностью дешифровать сообщение.
> К сожалению, я пока не понял как работает Диффи-Хельман, пресловутая цифровая подпись
> документа, https (или понял, потому что схема описанная выше очень сильно
> напоминает обмен браузера со Сбером) и электронная почта с PGP.
Конкретику работы DH или ЭЦП лучше погуглить о том как они устроены -- там много разновидностей. HTTPS фактически вы описали (ну, одно из подмножеств, так как в TLS тоже уйма всяких режимов работы).
PGP: симметричная часть схожая, хотя вместо MAC там используется просто хэш, находящийся внутри сообщения которое подписывается ЭЦП (это архаично, но и PGP в таком виде был создан чуть ли не четверть века назад). Диффи-Хельман там не применяется, а вместо него действительно асимметричное шифрование. Но суть схожая: шифр, какая-то аутентификация зашифрованного сообщения, асимметричная подпись для аутентификации собеседника, асимметричное шифрование для передачи симметричных ключей. Сейчас обсуждается и скоро должен увидеть свет новый стандарт OpenPGP -- в нём уже всё точно так же как и в TLS 1.3: *25519, AEAD (шифр и MAC вместе) режимы шифрования и всё по-современному.
| | |
|
| |
| 2.29, Сергей (??), 14:25, 25/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Вроде всё понятно, кроме этапа проверки. Расшифровка открытым ключом = расшифровка сертификатом?
Для объяснения на пальцах действительно часто применяют понятие расшифровки (для RSA например это буквально так и есть расшифровка), но правильнее применять "проверка подписи". Асимметричную криптографию, опять же для простоты, часто соотносят с симметричной и именно на функциях шифрования. Симметричная: один и тот же ключ применяется для шифрования и дешифрования. В асимметричной два ключа: если что-то зашифровали одним, то дешифровать можно другим (и наоборот). Один из ключей называют приватным, а другой публичным. Отсюда возникает два варианта использования частых: если зашифровать сообщение приватным ключом и дешифровать публичным, то мы получаем функцию подписи (подписать может только владелец приватного, а проверить (дешифровать) может кто-угодно). Если зашифровать публичным, а дешифровать приватным, то мы получим асимметричное шифрование (отправить шифрованное сообщение может любой, а прочитать только владелец приватного ключа). Для образования это показывают всегда именно так -- так проще понять. В RSA алгоритме буквально всё так и происходит. Однако в настоящих на практике используемых алгоритмах часто отсутствует шифрование как таковое и есть только создание подписи и проверка -- ECDSA, Ed25519, Ed448 алгоритмы например. А Диффи-Хельман вообще не вписывается в эти примеры с шифрованием/дешифрованием, поэтому о нём часто умалчивают, чтобы не усложнять объяснение в чём отличие асимметричной криптографии от симметричной.
Чисто технически, сертификат (публичный ключ из него) можно использовать для асимметричного дешифрования, например если используется RSA алгоритм. Просто такое применение крайне редко в Интернете.
| | |
| |
| 3.30, Аноним (-), 20:19, 25/03/2018 [^] [^^] [^^^] [ответить] | +/– | Есть отправитель с ключами Priv и Pub, который передаёт сообщение M 1 Функция ... большой текст свёрнут, показать | | |
| |
| 4.31, Сергей (??), 21:56, 25/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Это и есть так называемая цепочка доверия в системах PKI?
В принципе да, всё верно описали.
> Кажется я уже начинаю понимать, можно не шифровать сам файл, а допустим его хэш
Да, подписываются всегда хэши. Особенность большинства асимметричных функций подписи (или шифрования) -- они не могут работать с сообщениями больше размера своего ключа, грубо говоря. То есть могут подписать только 256 или там например 512 бит.
> Тут меня смущает аналогия с обыкновенной подписью - цифровая подпись каждый раз
> разная для разных файлов. Куда больше на цифровой аналог рукописной подписи
> подходят именно приватные ключи
Подпись настоящая тоже разная: всегда что-то меняется при написании, но написать всё-равно сможете только вы. Ваше умение -- ваш приватный ключ. Плюс не забывайте что материальная подпись ставится на каком-то материальном носителе, чернила наносятся поверх какого-то текста, какого-то листка. В цифровой приватный ключ применяется к чётко заданному (по хэшу) набору данных.
На правах саморекламы могу посоветовать вот такое видео небольшое: https://www.youtube.com/watch?v=Apl9QzuXUz8
| | |
|
|
|
|
