Comments 80
Спасибо! :)
Пользуйтесь!
Извините, но картинка с процедурой преобразования ключей в «нечто» — не очень подходит.
Пользователи обмениваются открытыми ключами и каждый шифрует сообщение открытым ключем собеседника. При получении сообщения зашифрованного его публичным ключем пользователь сможет расшифровать его своим приватным.
То, что изображено на картинке выглядит как процедура генерации сессионного симметричного ключа на основе криптографии с открытым ключем, что в свою очередь является частным случаем использования PGP и без информации об общем принципе функционирования PGP только запутывает читателя.
Пользователи обмениваются открытыми ключами и каждый шифрует сообщение открытым ключем собеседника. При получении сообщения зашифрованного его публичным ключем пользователь сможет расшифровать его своим приватным.
То, что изображено на картинке выглядит как процедура генерации сессионного симметричного ключа на основе криптографии с открытым ключем, что в свою очередь является частным случаем использования PGP и без информации об общем принципе функционирования PGP только запутывает читателя.
Вы ошибаетесь. Каждый шифрует своим закрытым и открытым ключом собеседника. Сооствественно достигается шифрование (прочитать может только собеседник) и электронная подпись (собеседник расшифровывает моим открытым ключом, то есть знает что отправил именно я)
не стоит писать такие статьи не разобравшись самому в предмете. А я могу с уверенностью сказать, что вы не знаете о чем пишете по фразе: «собеседник расшифровывает моим открытым ключом».
«Криптография с открытым ключом – это асимметричная схема, в которой применяются пары ключей: открытый (public key), который зашифровывает данные, и соответствующий ему закрытый (private key), который их расшифровывает. Вы распространяете свой открытый ключ по всему свету, в то время как закрытый держите в тайне. Любой человек с копией вашего открытого ключа может зашифровать информацию, которую только вы сможете прочитать. Кто угодно. Даже люди, с которыми вы прежде никогда не встречались.»
Прочитать о криптоалгоритмах и их реализациях можно здесь: www.pgpru.com
«Криптография с открытым ключом – это асимметричная схема, в которой применяются пары ключей: открытый (public key), который зашифровывает данные, и соответствующий ему закрытый (private key), который их расшифровывает. Вы распространяете свой открытый ключ по всему свету, в то время как закрытый держите в тайне. Любой человек с копией вашего открытого ключа может зашифровать информацию, которую только вы сможете прочитать. Кто угодно. Даже люди, с которыми вы прежде никогда не встречались.»
Прочитать о криптоалгоритмах и их реализациях можно здесь: www.pgpru.com
Вы уж тогда до конца дочитайте
https://www.pgpru.com/biblioteka/osnovy/vvedenievkripto/glava1/cifrovyepodpisi
А ещё тут прочитайте:
en.wikipedia.org/wiki/Public-key_cryptography
Картинку я взял от иллюстрации алгоритма Диффи — Хеллмана, но всё таки надо читать что под картинкой написано, а не только её саму.
https://www.pgpru.com/biblioteka/osnovy/vvedenievkripto/glava1/cifrovyepodpisi
А ещё тут прочитайте:
The most obvious application of a public key encryption system is confidentiality; a message which a sender encrypts using the recipient's public key can be decrypted only by the recipient's paired private key (assuming, of course that no flaw is discovered in the basic algorithm used).
Another type of applications in public-key cryptography are digital signature schemes. Digital signature schemes can be used for sender authentication and non-repudiation. In such a scheme a user who wants to send a message computes a digital signature of this message and then sends this digital signature together with the message to the intended receiver. Digital signature schemes have the property that signatures can only be computed with the knowledge of a private key. To verify that a message has been signed by a user and has not been modified the receiver only needs to know the corresponding public key.
…
To achieve authentication, and confidentiality, the sender could first sign the message using his private key, then encrypt the message and signature using the recipient's public key.
en.wikipedia.org/wiki/Public-key_cryptography
Картинку я взял от иллюстрации алгоритма Диффи — Хеллмана, но всё таки надо читать что под картинкой написано, а не только её саму.
Хорошо, попытаюсь объяснить все еще раз (на пальцах и простыми словами):
1. Есть шифрование сообщения.
2. Есть аутентификация сообщения.
Шифрование сообщения — преобразование его для приватности. При ассиметр. криптовании прочитать его может только владелец секретного ключа.
Аутентификация (подпись) сообщения — заключение его в контейнер с целью обезопасить от модификации при передаче.
Каждая из вещей выполняет только свою функцию. Аутентификация не шифрует, а шифрование не подписывает.
В вашей статье Вы рассказываете о ШИФРОВАНИИ сообщения (т.е. как сделать так, чтобы между 2мя собеседниками состоялся приватный диалог).
Как аутентифицировать собеседника в вашей статье нет ни слова, т.к. эта процедура включает в себя совместную с партнером ПРОВЕРКУ ИСТИННОСТИ КЛЮЧА (сходите же по ссылке из вашей статьи: en.wikipedia.org/wiki/Key_signing_party). Обычно валидация происходит посредством продиктовки друг другу хешей ключей по телефону. НО Вы должны удостоверится, что голос принадлежит Вашему другу, либо используется инфраструктура PKI (отдельный разговор).
Пример в статье легко подвержен атаке «человек по середине».
Надеюсь все описаные мной вещи понятны.
Что такое и зачем нужен DH (Diffie-Hellman). Этот алгоритм позволяет создать общий секретный ключ, используя защищенные от модицикации каналы связи (кстати в русской вики этот важнейший момент упущен). т.е. e-mail не пригоден для генерации общего секретного ключа (см. man-in-the-middle).
Это дает возможность создать ШИФРОВАННОЕ (но НЕ АУТЕНТИФИЦИРОВАННОЕ) соединение между 2мя узлами.
НО в вашем примере DH не испольуется, в силу того, что оба пользователя уже имеют публичные сертификаты друг друга и могут без прегенерации «общего секрета» начать защищенный (но не валидированный) обмен данными.
1. Есть шифрование сообщения.
2. Есть аутентификация сообщения.
Шифрование сообщения — преобразование его для приватности. При ассиметр. криптовании прочитать его может только владелец секретного ключа.
Аутентификация (подпись) сообщения — заключение его в контейнер с целью обезопасить от модификации при передаче.
Каждая из вещей выполняет только свою функцию. Аутентификация не шифрует, а шифрование не подписывает.
В вашей статье Вы рассказываете о ШИФРОВАНИИ сообщения (т.е. как сделать так, чтобы между 2мя собеседниками состоялся приватный диалог).
Как аутентифицировать собеседника в вашей статье нет ни слова, т.к. эта процедура включает в себя совместную с партнером ПРОВЕРКУ ИСТИННОСТИ КЛЮЧА (сходите же по ссылке из вашей статьи: en.wikipedia.org/wiki/Key_signing_party). Обычно валидация происходит посредством продиктовки друг другу хешей ключей по телефону. НО Вы должны удостоверится, что голос принадлежит Вашему другу, либо используется инфраструктура PKI (отдельный разговор).
Пример в статье легко подвержен атаке «человек по середине».
Надеюсь все описаные мной вещи понятны.
Что такое и зачем нужен DH (Diffie-Hellman). Этот алгоритм позволяет создать общий секретный ключ, используя защищенные от модицикации каналы связи (кстати в русской вики этот важнейший момент упущен). т.е. e-mail не пригоден для генерации общего секретного ключа (см. man-in-the-middle).
Это дает возможность создать ШИФРОВАННОЕ (но НЕ АУТЕНТИФИЦИРОВАННОЕ) соединение между 2мя узлами.
НО в вашем примере DH не испольуется, в силу того, что оба пользователя уже имеют публичные сертификаты друг друга и могут без прегенерации «общего секрета» начать защищенный (но не валидированный) обмен данными.
Естественно обмениваться ключами желательно через зашифрованный канал или банально переписать на CD-R/флешку.
Про сверку там всё написано, ниже в комментах тоже. Ещё раз, от DH там одна картинка, которая иллюстрирует что к сообщению применяются два ключа.
Все верно, только ключи применяются совершенно по-другому!
Картинка относится ТОЛЬКО к процедуре DH! Никакого shared secret в криптографии с открытым ключем НЕТ! Есть ОТДЕЛЬНО процедура ШИФРОВАНИЯ сообщения к Bob'у его публичным ключем и ПОДПИСЬ этого сообщения ключем Alice.
Из статьи в педивикии (en.wikipedia.org/wiki/Public-key_cryptography) Вам нужно было скопировать картинку 2 — для иллюстрации шифрования/дешифрования сообщения И картинку — 3 — для иллюстрации подписи.
Картинка относится ТОЛЬКО к процедуре DH! Никакого shared secret в криптографии с открытым ключем НЕТ! Есть ОТДЕЛЬНО процедура ШИФРОВАНИЯ сообщения к Bob'у его публичным ключем и ПОДПИСЬ этого сообщения ключем Alice.
Из статьи в педивикии (en.wikipedia.org/wiki/Public-key_cryptography) Вам нужно было скопировать картинку 2 — для иллюстрации шифрования/дешифрования сообщения И картинку — 3 — для иллюстрации подписи.
«фередеративная» сеть? :)
Есть одно существенное НО — хистори не шифруется.
Посему для конфедициальной переписки я бы рекомендовал использовать почту. Большинство почтовых клиентов сохраняет зашифрованную корреспонденцию в зашифрованном виде.
Посему для конфедициальной переписки я бы рекомендовал использовать почту. Большинство почтовых клиентов сохраняет зашифрованную корреспонденцию в зашифрованном виде.
Кстати, в джббере есть ещё E2E шифрование. Не раскажете о нем? (поддерживает по крайней мере Gajim)
UFO just landed and posted this here
>загрузка ПО и генерация *закрытого и закрытого* ключа
А мне интересно, как будут храниться хистори? Если в зашифрованном виде, то как можно их прочитать потом? (если на другом компе захочется прочитать).
PGP — это все-таки не алгоритм, а криптосистема. И основное ее предназначение как раз то, что вы назвали «весьма забавной процедурой» — управление ключами.
А алгоритм там используется RSA, если не комбинация с каким-либо блочным алгоритмом, в которой асимметричное шифрование ипользуется только для передачи сеансового ключа.
Поправьте заголовок.
«Шаг третьий. Обмениваемся шифрованными сообещниями»
очепяточки
А алгоритм там используется RSA, если не комбинация с каким-либо блочным алгоритмом, в которой асимметричное шифрование ипользуется только для передачи сеансового ключа.
Поправьте заголовок.
«Шаг третьий. Обмениваемся шифрованными сообещниями»
очепяточки
Алгоритм это последовательность действий и условий, а не обязательно программа, а тут в действия входят и обмен ключами.
Я и не говорил о PGP как о программном коплексе. Я говорил о PGP как о инфраструктуре открытых ключей, аналогами которой являются X.509, PKI и SPKI, и которая стандартизирована под именем OpenPGP.
В этом смысле PGP предусматривает самостоятельное урпавление ключами: пользователь берет на себя функции CA и подписывает открытые ключи других пользователей. Ключи, которым доверяет отдельный пользователь, объединяются в кольцо ключей, при этом каждый пользователь самостоятельно контролирует это кольцо. Проблема этой схемы — это проблема каскадного обновления колец в случае компроментации одного из ключей.
Называть это «алгоритмом» — подменять общепринятые понятия своими. То же самое, кстати, если рассматривать PGP как программный продукт. Так что заголовок все же лучше изменить
В этом смысле PGP предусматривает самостоятельное урпавление ключами: пользователь берет на себя функции CA и подписывает открытые ключи других пользователей. Ключи, которым доверяет отдельный пользователь, объединяются в кольцо ключей, при этом каждый пользователь самостоятельно контролирует это кольцо. Проблема этой схемы — это проблема каскадного обновления колец в случае компроментации одного из ключей.
Называть это «алгоритмом» — подменять общепринятые понятия своими. То же самое, кстати, если рассматривать PGP как программный продукт. Так что заголовок все же лучше изменить
Согласен, фраза «PGP алгоритм» звучит нелепо.
И про алгоритм — в приведенном сообщении используется Эль-Гамаль, а не RSA, плюс еще какой-то симметричный алгоритм.
И про алгоритм — в приведенном сообщении используется Эль-Гамаль, а не RSA, плюс еще какой-то симметричный алгоритм.
Поведайте пожалуйста какие еще джаббер клиенты можно подобным образом зашифровать??? а то к qip доверие пропало после известий о том что он пароли у себя на сервере хранит :)
По поводу «пароли у себя на сервере» — предложите сначала безопасную схему аутентификации с использованием пароля без хранения пароля на сервере, а потом уже критикуйте хранение паролей.
1) Хранить хеш пароля
2) Аутентификация по ключам, как в openvpn
3) Аутентификация по смарткартам (для криптоманьяков)
2) Аутентификация по ключам, как в openvpn
3) Аутентификация по смарткартам (для криптоманьяков)
1) А полностью схему покажите, при которой пароль не передаётся по сети в открытом виде и не хранится на сервере?
2 & 3) Я вопрос задал про парольную аутентификацию. У ключей есть свои плюсы и свои минусы.
2 & 3) Я вопрос задал про парольную аутентификацию. У ключей есть свои плюсы и свои минусы.
Передать хеш пароля, не?
У ключей только один недостаток — человеческая лень.
У ключей только один недостаток — человеческая лень.
Ну если мы просто храним хэш пароля и передаём тот же хэш пароля, то секретным является не сам пароль а хэш пароля, таким образом злоумышленнику не надо знать сам пароль, чтоб представится нами, достаточно знать хэш пароля.
У ключей еще один недостаток — запомнить 256 байт сложно, т.е. пароль вы можете просто ввести на любом компьютере и попасть в жаббераську, а ключ надо обязательно таскать с собой на каком-нибудь носителе.
У ключей еще один недостаток — запомнить 256 байт сложно, т.е. пароль вы можете просто ввести на любом компьютере и попасть в жаббераську, а ключ надо обязательно таскать с собой на каком-нибудь носителе.
Ну естественно хешировать при передаче не сам пароль, а, например, строку «текущее время+хеш пароля». Ну и мы считаем, что при регистрации пароль не был сворован. От этого спасут только ключи.
Ну и SSL никто не отменял тоже да.
Ну и SSL никто не отменял тоже да.
Ну а тогда если мы хэшируем не сам пароль, а «время+пароль», как сервер сможет сверить хэш с настоящим, не храня пароль у себя? ;-)
Я даже не спрашиваю про то, как вы собираетесь обеспечить совпадение времени на сервере и клиенте, эта проблема еще худо-бедно решаема.
Я даже не спрашиваю про то, как вы собираетесь обеспечить совпадение времени на сервере и клиенте, эта проблема еще худо-бедно решаема.
На сервере хранится хеш пароля. Он генерит hash(time+shadow), а на клиенте генерится hash(time+hash(password)). Если строки совпали — всё ok.
Можно не время использовать, а какую-то строку с сервера передавать к клиенту в качестве опорной.
Можно не время использовать, а какую-то строку с сервера передавать к клиенту в качестве опорной.
Если я правильно понимаю, что
А если достаточно знать хэш, а не пароль, то по факту паролем является то, что вы называли «хэш пароля».
shadow == hash(password), то вы просто подменили пароль его хэшем, т.е. злоумышленнику не нужно знать сам пароль, а достаточно знать его хэш для того, чтобы авторизоваться.А если достаточно знать хэш, а не пароль, то по факту паролем является то, что вы называли «хэш пароля».
Да, но откуда же он его возьмёт то этот хеш оригинальный?
Мы считаем что во время регистрации взлома нет.
Мы считаем что во время регистрации взлома нет.
Речь как я понимаю была о том, что сервер хранит у себя секрет, зная который, можно представится пользователем, разве не так? Ваша схема этот недостаток также содержит.
Например, зная соль+хэш из shadow-файла unix-системы представиться пользователем нельзя, т.к. пароль передаётся в открытом виде как во время ввода его с физического терминала, так и во время ssh-соединения. В случае ssh-соединения он передаётся по зашифрованному каналу и подлинность сервера проверяется по known_hosts.
Например, зная соль+хэш из shadow-файла unix-системы представиться пользователем нельзя, т.к. пароль передаётся в открытом виде как во время ввода его с физического терминала, так и во время ssh-соединения. В случае ssh-соединения он передаётся по зашифрованному каналу и подлинность сервера проверяется по known_hosts.
Идея в том, что один пароль некоторые юзеры используют для нескольких аккаунтов. И если ломанут базу квипа, например, то получат доступ к туевой хуче емайлов бландинок у которых один пароль, только и всего.
Если два сервиса используют ваш протокол авторизации получается опять таки ерунда, т.к. зная хэш сломавший базу квипа сможет авторизоваться на всех этих сервисах.
А если ваш протокол может использоваться только на одном сервисе — грош цена этому протоколу.
На самом деле я не знаю, возможна ли принципиально безопасная аутентификация по паролю как без передачи его в открытом виде и так и без хранения на сервере. Может быть в криптографии это доказывается, но в любом случае я не видал пока протоколов аутентификации по паролю, которые удовлетворяют обоим этим свойствам.
А если ваш протокол может использоваться только на одном сервисе — грош цена этому протоколу.
На самом деле я не знаю, возможна ли принципиально безопасная аутентификация по паролю как без передачи его в открытом виде и так и без хранения на сервере. Может быть в криптографии это доказывается, но в любом случае я не видал пока протоколов аутентификации по паролю, которые удовлетворяют обоим этим свойствам.
Ну никто и не говорит что пароль это секьюрно.
Итого, мы пришли к мнению, что ответом на вопрос
является простое «идеальной схемы с использованием паролей не существует», что я и подразумевал с самого начала.
:-)
… предложите сначала безопасную схему аутентификации с использованием пароля без хранения пароля на сервере, а потом уже критикуйте хранение паролей.
является простое «идеальной схемы с использованием паролей не существует», что я и подразумевал с самого начала.
:-)
О, сервер хранит hash(password + servername), тогда эти хеши никак не пригодятся на другом сервере.
Поздравляю, вы, если не ошибаюсь, изобрели Digest access authentication!
Там действительно пароль на стороне сервера хранится не обязан, и достаточно хранить
Это решает проблему блондинки с одним паролем на все случаи жизни, но не решает проблему с тем, что утечка базы данных ведет к возможности тривиального входа в систему от имени любого пользователя.
Там действительно пароль на стороне сервера хранится не обязан, и достаточно хранить
HA1 = hash(username + servername + password), таким образом получив базу данных HA1 злоумышленник действительно сможет залогиниться на сервис, но только на него.Это решает проблему блондинки с одним паролем на все случаи жизни, но не решает проблему с тем, что утечка базы данных ведет к возможности тривиального входа в систему от имени любого пользователя.
Чувствую себя великим :)
Я собственно к этому и клонил. Если базу квипа заломали, то понятно получили уже доступ ко всему квипу.
Я собственно к этому и клонил. Если базу квипа заломали, то понятно получили уже доступ ко всему квипу.
Не боги RFC пишут :-)
Я говорил про идеальный вариант — когда получение хэшей не даёт также и провести аутентификацию. Тот же самый пример в /etc/shadow — что после получения хэша пароль всё равно приходится брутфорсить.
Как показывает практика, возможность стянуть базу не равна рутовому доступу к серверу. Типичный пример — забыли обезопасить бэкапы базы.
Я говорил про идеальный вариант — когда получение хэшей не даёт также и провести аутентификацию. Тот же самый пример в /etc/shadow — что после получения хэша пароль всё равно приходится брутфорсить.
Как показывает практика, возможность стянуть базу не равна рутовому доступу к серверу. Типичный пример — забыли обезопасить бэкапы базы.
Вроде как под windows из юзабельных только psi.
От себя могу порекомендовать более простые и универсальные решения E2E криптования IM под Windows. Это IMsecure от ZoneAlarm и более распространенный и продвинутый Simp от Secway. Обе бесплатны при использовании с одним аккаунтом, например, с ICQ или Jabber, а Pro версии обеспечат шифрование всех клиентов всех сетей.
Также не стоит забывать плагины IMsecure для миранды и триллиана — они также прозрачно зашифруют сообщения.
И само собой не стоит забывать, что шифраторы должны стоять на обоих «концах», все-таки end-to-end
Также не стоит забывать плагины IMsecure для миранды и триллиана — они также прозрачно зашифруют сообщения.
И само собой не стоит забывать, что шифраторы должны стоять на обоих «концах», все-таки end-to-end
А нафига зашифрованный канал для передачи открытого ключа? :) В этом вроде и фишка такого шифрования, что можно не парица и передавать открытый ключ куда угодно. А если нужна идентификация от кого пришло — то ЕЦП в помощь :)
Нужно обеспечить достоверность открытого ключа, т.е. что он не был подменён при передаче.
Потому что в таком случае система подвержена Man In Middle атаке. Кто-то может перехватить открытый ключ и вместо него выслать подделку, которая соответсвует уже другому закрытому ключу. От этого должны спасть CA, но это уже перебор для личного общения, imho :)
Странно, что никто не написал про OTR: www.cypherpunks.ca/otr
Всё же описанный способ очень долог в настройке.
Всё же описанный способ очень долог в настройке.
Минут 15 не больше.
OTR настраивается где-то минуты 2, а то и меньше.
И имеет кучу недостатков.
А можно подробнее, очень интересно?
Да, пожалуй обе системы имеют право на существование.
Для сравнения минусы GPG/PGP
www.cypherpunks.ca/otr/otr-codecon.pdf
Вкратце: получив каким либо образом секретный ключ шифрования можно расшифровать всю предыдущую переписку.
В любом случае хорошо когда есть альтернатива.
www.cypherpunks.ca/otr/otr-codecon.pdf
Вкратце: получив каким либо образом секретный ключ шифрования можно расшифровать всю предыдущую переписку.
В любом случае хорошо когда есть альтернатива.
Така защита ни разу не оптимальна: в каждом сообщении посылается дополнительно 2кб данных (+30% изза Base64 кодирования), плюс шифрование/расшифровка каждого сообщения занимает достаточно времении. Гораздо умнее было бы сделатьодноразовый обмен сессионными симметричными ключами.
А кто говорил что система с открытым ключом оптимальна вообще?
Вопрос не в системе с открытым ключем, а способе ее использования.
Ктонибудь сталкивался с такой проблемой? В миранде использую плагин SecureIM + tabSRMM. Установили соединение с человеком. Ключами обменялись, всё окейно. Всё подтверждено, в этом плане всё ок.
Но сообщения от меня отсылаются крякозябрями (я так понимаю utf8), но почему такое происходит?
И как этого избежать, кто с такой проблемой сталкивался, помогите плз
Но сообщения от меня отсылаются крякозябрями (я так понимаю utf8), но почему такое происходит?
И как этого избежать, кто с такой проблемой сталкивался, помогите плз
Все ясновидящие в отпуске, хотя бы версии ядра и плагинов написали.
Почти всегде помогает: letmegooglethatforyou.com/?q=SecureIM+unicode
Почти всегде помогает: letmegooglethatforyou.com/?q=SecureIM+unicode
извиняюсь, забыл в порыве гнева версдамп скинуть, но, я уже разобрался, оказывается нужно было обновиться, обновления нашел на других сайтах, на addons.miranda-im.org не было(
Было:
Стало:
Было:
¤ cryptopp.dll v.1.0.2.2 [2008-04-23 08:54:26+0300] — Crypto++
¤ SecureIM.dll v.1.0.10.9 [2008-04-23 08:51:36+0300] — SecureIM (2in1)
Стало:
¤ cryptopp.dll v.1.0.3.0 [2008-09-17 15:27:48+0300] — Crypto++
¤ SecureIM.dll v.1.0.11.0 [2008-09-17 15:27:58+0300] — SecureIM (2in1)
Sign up to leave a comment.
Шифруем сообщения в сети XMPP/Jabber с помощью PGP