Комментарии 42
Если сообщение шифруется Публичным, то его может расшифровать только соответствующий ему Приватный ключ.
И наоборот:
Если сообщение шифруется Приватным, то его может расшифровать только соответствующий ему Публичный ключ.
Приватный ключ никому не дается, Публичный — собственно, публичный.
Вам не показалось странным это ваше утверждение? Если говорить про RSA, то сообщение может быть зашифровано с использованием публичного ключа и расшифровано с помощью приватного, но не наоборот. Также RSA позволяет использовать приватный ключ для подписи сообщения, а публичный — для проверки этой подписи. Тот же DSA не предполагает шифрования, но только подпись.
CSR подписывается Приватным Ключем близжайшего по цепи Центра Сертификации. Собственно, так это и называется Certificate Chain, когда Центры Сертификации друг за другом подписывают следующий сертификат, вплоть до конечного — Сертификата Сервера.
CSR подписывается ключом того, кто делает запрос на сертификат (как подтверждение владения ключом для которого выпускается сертификат). На основе этого CSR (тех полей, которые проверил CA) создаётся сертификат, обогащается нужными полями, включая уже подпись CA.
Мне показалось, что автор как раз это и имел ввиду. Может просто потому, что я тоже как раз сейчас с криптографией разбираюсь и мне механизм уже знаком. С точки зрения человека, выполняющего
openssl x509 -req -in $1.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out $1.crt -days 5000он подписывает csr и получает сертификат.
Итак, когда обе стороны убедились, что их собеседники — те за кого себя выдают, можно начинать диалог.
Клиентская аутентификация в массе не используется. Обычно достаточно аутентификации сервера. Когда используется — с ServerHello придёт запрос на сертификат клиента и сервер будет так же проверять его цепочку в рамках PKI.
Но в дальнейшем асимметричное шифрование используется только один раз — когда клиент шифрует пароль публичным ключем сервера, и отправляет серверу — KlientKeyExchange. Далее уже этот пароль используется для симметричного шифрования сообщений, так как оно значительно быстрее и проще асимметричного.
Это только один из способов Kx (key exchange). Ещё активно используются схемы DH/ECDH. Редко всякая экзотика типа PSK (pre-shared key), параметров diffie-hellman'а из сертификата.
Мне не показалось. Технически при подписи осуществляется шифрование, только параметры отличаются от "настоящего" шифрования. Проводить такие различия — демагогия.
Основное отличие подписи и шифрования в случае RSA — семантическое. Технически экспоненты меняются местами и благодаря коммутативности операции возведения в степень по модулю (с соответствующим ограничениями; если правильно помню, она может быть некоммутативна в в общем случае) RSA можно использовать и для подписи.
В тех же DSA и ECDSA нет возможности реализовать шифрование — они могут использоваться только для подписи.
ЗЫ хотя на практике тот формат, в котором хранится приватный ключ, делает его именно что приватным и никаким другим.
А в ElGamal, DSA и ECDSA с вашей точки зрения тоже происходит шифрование?
Если говорить про RSA, то сообщение может быть зашифровано с использованием публичного ключа и расшифровано с помощью приватного, но не наоборот
Наоборот тоже можно — там же возведение в степень по основанию. Возводите в степень d по основанию n (из приватного ключа) и отдаете получателю. тот возводит в степень e по основанию n и получает расшифрованный вариант. Можно гонять в любом направлении, лишь бы сумма d и e была равна функции Эйлера от n.
Как я говорил выше, с моей точки зрения, это не по сути шифрование, а подпись.
Можно гонять в любом направлении, лишь бы сумма d и e была равна функции Эйлера от n.
Произведение d и e должно быть равно единице по модулю phi(n), такое странное ограничение на сумму откуда взялось?
Произведение d и e должно быть равно единице по модулю phi(n),
Нет, ЛЮБОЕ число (от 0 до n-1) в СТЕПЕНИ phi будет равно единице по модулю N, а соотв. в степени phi+1 будет равно самому себе. Но что бы взять эйлера надо знать разложение числа n. На этом и построен принцип ассиметричного шифрования. Тот кто составлял n — знает его эйлера. И он делит Эйлера на две части — d и e (phi = d + e) — одна часть публичная другая закрытая, и неважно какая из них какая. Как правило открытую делают достаточно маленькой а закрытую — достаточно большой (что бы нельзя было угадать или перебрать). И независимо от того кто шифрует сообщение, он возводит в какую то степень (d или e) а тот кто получил сообщение — продолжает возводить в то значение которое ему известно. В итоге оба участника возведут число в степень равную функции Эйлера (+1 если быть точным) и получат исходное число. Все операции естественно по модулю n.
Давайте возьмем числа из wiki: p = 61, q = 53 => n = 3233, phi(n) = 3120. Далее, при e = 17, получим d = 2753. Как легко проверить, d e mod phi(n) = 1, но d + e != phi(n). QED
Нет, ЛЮБОЕ число (от 0 до n-1) в СТЕПЕНИ phi будет равно единице по модулю N, а соотв. в степени phi+1 будет равно самому себе.
Во-первых, не любое. Только взаимнопростое с n, если вы говорите про теорему Эйлера. Например, p^phin(n) mod n при указанных выше параметрах будет равно 1220.
Во-вторых, какое утверждение вы оспариваете? Что e и d взаимнообратны по модулю phi(n)? В классическом RSA это так (можете прочитать в патенте). В PKCS1 предлагается другой вариант: e и d взамнообратны по модулю lcm(p-1,q-1) (наименьшее общее кратное).
Откуда возник вариант с e + d = phi(n) — я не ведаю. Выглядит он бредово, т. к. сообщение при шифровании возводится в степень d по модулю n. Полученный шифротекст возводится в степень e и получается m^(d*e) mod n для которого уже доказывается, что оно равно m mod n. Как легко увидеть, сумма d + e не возникает в этом процессе.
Вы что мне хотите продемонстрировать/доказать? Я вполне способен глянуть в википедию/стандарты и произвести элементарные вычисления, чтобы опровергнуть ваши утверждения. Если хотите дальше продолжить разговор — то стоит приводить строгие математические доказательства ваших утверждений или ссылки на работы, где они приведены.
Был не прав, вспылил. Я рассматривал ситуацию с точки зрения владельца плейн-текста. С точки зрения получателя шифр текста — совершено верно, он возводит в степень шифртекст, и тогда уже речь идет не о сумме степеней дающих Эйлера а о произведении. Признаю свою вину, меру, степень, глубину. Пойду сожгу Шнайера, посыплю голову пеплом.
В качестве основного минуса, https обычно обеспечивает меньшую пропускную способность, чем http, что особенно критично на медленных линиях типа сотовой телефонии. Кроме того, дальше начинаются вопросы с включением внешних ресурсов в защищённые страницы.
Настолько ли важно пользователю вообще различать малозначимые для него сайты vasya1.com и vasya2.com, чтобы защищать аутентичность одного из них – вопрос дискутируемый. Поэтому массовая миграция не содержащих критичной информации сайтов на https не вполне объяснима с рациональных позиций.
Спорно. Для обывателя замена получаемых по DHCP ДНС серверов является проблемой. А это просто может обернуться в замену хостов популярных рекламщиков на свои, подсовывая свои картинки вместо того же adriver.ru. Я бы не сказал, что проблема здесь именно во внедрении рекламы ибо обывателю под час на нее плевать, если она не занимает 100% пространства страницы.
Скорее проблема шире именно с точки зрения не простого подсовывания рекламы, а замены всего содержимого страницы. Или внедрение в нее вредоносного кода.
тогда сразу будет https://adriver.ru :-) в этом, собственно, и есть смысл https — нельзя просто так взять и подменить хост.
Цифровая подпись (Digital Signature) — это часть документа, зашифрованная Приватным ключем Подписчика (Issuer)
Обычно шифруется хэш документа. Если шифровать часть документа, то и обеспечить получится только целостность этой части документа.
Выбирается сообщение для шифровки (Message). Что именно шифровать, определяет алгоритм и версия SSL. Для конечного пользователя это неважно, так как все версии шифрования и хэширования также помещаются в сертификат, и при расшифровке эти же версии и используются.
Откуда у вас такая странная информация про создание самоподписанного сертификата? На всякий случай я посмотрел все ссылки, что у вас в источниках, но, к счастью, ничего подобного там не нашел.
Мне кажется, тут автор имел ввиду, что шифруемый хеш в принципе может быть произвольным ("хеш" — "алгоритм" у автора), но в версиях SSL указаны предпочтительные алгоритмы хешей. Автор просто попытался рассказать это простыми словами, "для домохозяек". Хорошо или нет получилось — вопрос спорный, но тут необходимо учитывать, что шифрование — это такой тугой клубок нитей, который расплести с наскока нереально. У меня иногда такое впечатление, словно специально пытались усложнить жизнь тем, кто в этом хочет разобраться.
Ага, ага. Безопасность через незнание?
А если речь идёт о корпоративной СБ, например (или ты — террорист), то нефиг домохозяек до обмена сообщениями допускать :)
Да кто вас спрашивать будет, если они до нее доберутся? Лучше пусть знают основы, а не бездумно вытворяют черти что. Лишнее знание никогда не мешает, если оно не устаревшее.
Похоже, вы слишком буквально восприняли слово "домохозяйка", а я ведь не зря кавычки поставил. Ну хорошо, заменим его на "чайников".
Ну зачем им вникать в подробности, если нужно обсудить схему полива кактуса в горшке?
Правильно, незачем, если они это не спрашивали. Но если уж заинтересовались и спросили, то как-то не гуманно сразу вываливать на них все эти ASN.1, BER, CER, DER, PKCS, PKI, RSA, DES, DH, KEK, CMS и прочая и прочая, вы не находите? Вы же не думаете, что людям, которым криптография в принципе неинтересна, читали статью?
Это для вас они «основы» и то, что вы знаете по определению. Попробуйте вынырнуть из хабромира в реальный — сильно удивитесь :)
С рождения вы ничего не знаете, но ведь научились же как-то клавиатурой пользоваться и даже этот сайт нашли :). И это — действительно основы, описанные простыми словами. Без всяких частностей, типа как тут упоминали выше, что DSA нельзя использовать для шифрования. Это как раз уже продвинутый уровень. Как в школе. Сначала вам говорят, что из меньшего нельзя вычитать большее. Потом вводят отрицательные числа и обнаруживается, что все-таки можно. Аналогичная история повторяется с дробями и корнями из отрицательных чисел, делением на 0 и т.п.
Зная основы, частности можно вывести. Например, я не знаю, что такое DSA (но знаю RSA), но попробую объяснить, почему шифровать им не годится.
Чтобы не было путаницы, договоримся, что ниже слово "шифрование" будет означать сокрытие информации от чужих глаз, в том время как "преобразование шифрования" — просто техническую процедуру преобразования чистого текста в шифрованный.
- Итак, мы знаем, что это асимметричная криптография, а асимметричная криптография всегда имеет 2 ключа — публичный и приватный. Первый отдаем всем, второй храним у себя.
- Шифрование — это преобразование чистого текста в шифротекст. Расшифровка — в обратную сторону. Для каждого преобразования нужен свой ключ.
- Если мы хотим использовать алгоритм (в данном случае DSA) для шифрования, то получить информацию должен только один участник. Так как он отличается от других только наличием приватного ключа, значит, приватным ключом нужно расшифровывать, а публичным шифровать (проводить преобразование шифрования).
- Если мы хотим использовать алгоритм для подписи, то проверять ее должны все, а создавать только один участник. Так как он отличается от других только наличием приватного ключа, значит, приватным ключом нужно шифровать (проводить преобразование шифрования), а публичным расшифровывать.
- Исходя из вышеперечисленного, можно предположить, что в алгоритм DSA использует какие-то данные из приватного ключа для преобразования шифрования, которых нет в публичном ключе. Этим объясняется, почему его можно использовать только в одном преобразовании. Для шифрования с помощью DSA в шифрующем ключе просто нет необходимых данных
- Но что мешает нам поменять местами приватный и публичный ключ, чтобы шифрование с использованием DSA стало возможным? Просто переназвать их и дело в шляпе! Попробуем это объяснить. Для RSA известно, что приватный ключ содержит в себе публичный. Т.е. обладая приватным ключом, мы обладаем обоими ключами. Если в DSA дела обстоят также, то нельзя просто поменять ключи местами и переназвать их. Ведь публичный ключ нужно отдавать всех, но не забываем, что изначально это был приватный ключ (мы ведь их переназвали) — таким образом, мы всем раздаем оба ключа. А это нарушает принцип асимметричной криптографии, поэтому шифрование с помощью DSA бессмысленно.
Это кажется очень смелым утверждением, если учесть, что нужно не просто доверять CA, но и всем Intermediate CA. Не в том смысле, доверять, что они — это они (это как раз делает криптография), а доверять в том смысле, что они не будут подписывать левые сертификаты, или что у них где-нибудь не сидит MITM, перешифровывающий трафик и складывающий его в своё хранилище.
И ещё в статье не указано, что всё это относится только к стандарту X.509 (S/MIME), в то время как (теоретически), существуют другие варианты реализации PKI, скажем, WebOfTrust.
Что значить защищенный канал связи?
Поправьте это "значить" при случае ))) никто правда пока не заметил, но все равно режет.
И еще:
Чтобы канал передачи данных считался защищенным, должны выполняться 3 основные принципа:
Доверие (Trust) — взаимная аутентификацию абонентов при установлении соединения.
Шифрование (Crypting) — защита передаваемых по каналу сообщений от несанкционированного доступа. То есть, говорить и слушать во время диалога можете только вы и ваш собеседник.
Обеспечение целостности — подтверждение целостности поступающих по каналу сообщений, т.е. сообщения не могут подвергаться полной или частичной замене информации.Вобще говоря, тут нужно понимать, защищенный от чего? Т.е. например, можно себе представить достаточно легко канал, защищенный от модификации, т.е. целостность в наличии, но не защищенный от прослушки. Типичный случай — это скажем репозиторий компонентов. Вы очевидно не хотите установить обновление OS с левого сайта, но при этом вам совершенно не нужно шифровать здоровенные получаемые оттуда архивы. Так что как минимум шифрование тут не является обязательным.
Насчет доверия корневому центру сертификации — по мне так это и есть самая проблемная часть. Скорее всего службы госбезоапсности имеют доступ к их приватным ключам, а значит и ко всем промежуточным, а значит вполне могут вмешиваться в траффик «защищенный» таким CA.
На данный момент есть технология blockchain, а значит возможно создание и работа с CA, корневые сертификаты которого никому не принадлежат и проверяются в распределенной сети. Если кто-то знает конкретные реализации и кейсы, с которыми сталкивался в этом плане, напишите.
Книга уже почти закончена, включает в себя все основные темы криптографии. А самое главное — написана очень простым и понятным языком.
Но имхо SSL в целом и TLS в частности не просто так усложнены — «законодатели» этих спецификаций ловят рыбку в мутной воде. Во благо «государства», естественно!
Опять же имхо, нужен Геракл, который сметёт это дерьмо новой простой и понятной спецификацией.
10,6% на данный момент используют его по умолчанию. Но тренд, безусловно, хороший.
Принцип Доверия (Trust) в HTTPS