Шифрование и открытый исходный код - PullRequest
0 голосов
/ 25 апреля 2009

Недавно я столкнулся с понятием Identity Based Encryption (IBE), которое кажется новой идеей. Тем не менее, я не заметил, что многие в криптографическом сообществе пытаются найти способы его взломать. Я не прав?

Аналогично, я верю, что, если вы не сможете распространять реализации с открытым исходным кодом, где толпа черных шляп может атаковать его, у этого может не быть достоинств?

Полагаю, мне хотелось бы понять опыт сообщества в целом при использовании этого подхода и насколько легко включить его в свое приложение и распространять?

(Изменить: вот статья в Википедии о шифровании на основе идентификатора.)

Ответы [ 5 ]

4 голосов
/ 25 апреля 2009

Мне неясно, что вы пытаетесь спросить, поэтому я собираюсь придумать пару вещей и ответить на них. Дайте мне знать, если я согреюсь

Во-первых, «идентификация на основе шифрования» на самом деле не схема шифрования, а схема управления ключами. В любом публичном / частном - или, технически, "асимметричном" - шифровании, есть два ключа. Один из них используется для шифрования, другой для дешифрования, и у них есть специальное свойство, что если вы знаете один из них, все еще экспоненциально сложно (или считается экспоненциально сложным) построить другой. Так, например, я могу зашифровать вам письмо, используя мой личный ключ; Я публикую свой открытый ключ. Если вы можете расшифровать письмо, используя открытый ключ, у вас есть уверенность, что именно я его отправил. Это основная идея схем цифровой подписи.

Проблема в том, что у вас должен быть способ генерации и управления этими ключами, и это оказывается сложным, потому что схема эффективна только в том случае, если вы защищаете свой закрытый ключ. Есть несколько способов сделать это.

Шифрование на основе идентификатора пытается упростить эту проблему управление ключами , предлагая специальные алгоритмы, которые создают закрытые ключи из известной общедоступной части информации: например, адреса электронной почты. Чтобы сделать это способом, который все еще затрудняет определение частной стороны, вам нужно иметь доверенную сущность, которая создает закрытый ключ на основе некоторого другого секрета, который они знают. Итак, чтобы установить ваше общение с кем-то, кто знает ваш адрес электронной почты. Вы идете к доверенному поставщику и запрашиваете закрытый ключ, который будет сгенерирован. Человек, с которым вы хотите общаться, знает, каким провайдером вы пользуетесь, и получает главный открытый ключ от этого провайдера.

Теперь человек, которому вы хотите отправить сообщение, может затем создать открытую сторону из вашего идентификатора, ничего не зная, кроме информации о главном ключе от поставщика; ключ никогда не передается в направлении.

Другими словами, это выглядит так: Алиса хочет отправить Бобу письмо в зашифрованном виде. Они оба доверяют провайдеру, Том.

  • Алиса отправляет запрос Тому со своим адресом электронной почты "alice@example.com" и возвращает закрытый ключ P . Существует соответствующий открытый ключ p , но Том не отправляет его никому.
  • Боб отправляет запрос Тому и получает главный открытый ключ Тома m .
  • Алиса шифрует свое сообщение "x" своим закрытым ключом, давая {"x"} P . (Это обозначение просто "message" x "" упаковано "или шифрование ключом P .) Алиса затем отправляет это сообщение Бобу.
  • Бон использует свои знания адреса электронной почты Алисы и главного ключа Тома m и вычисляет. p = f ("alice@example.com", m ). Теперь он применяет расшифровку, расшифровывает ({"x") P, p) и poof, выходит сообщение Алисы.

Суть этих схем в том, что они упрощают некоторые ключевые вопросы управления, но лишь в некоторой степени. Вам все еще нужно сгенерировать ключи, и, что еще хуже, вы должны действительно доверять Тому, потому что он знает все: он может сгенерировать ваш закрытый ключ и зашифровать его, чтобы любое сообщение выглядело как полученное вы. Это означает, что он создает внутреннюю схему условного депонирования ключей; Ваш личный ключ можно узнать.

В некоторых отношениях это хорошо; это решает проблему потерянных ключей. Но по большинству причин люди хотят использовать шифрование, это плохо. Теперь кто-то может вызвать в суд Тома или просто избить его и получить ваши личные данные.

Результатом является то, что само по себе шифрование на основе идентификатора является изящной идеей, но не имеет большого рынка.

2 голосов
/ 26 апреля 2009

Шифрование на основе идентичности будет трудно осуществить в проекте с открытым исходным кодом, особенно такого рода, который не просто бесплатный, как на свободе, но бесплатный, как в пиве. Как уже упоминалось, вся система полагается на доверенную третью сторону для выдачи ключей. Для этого требуется инфраструктура, как для аппаратного, так и для программного обеспечения, которая является дорогостоящей для приобретения и обслуживания. Кроме того, это накладывает большую ответственность на сторону, которая занимается выдачей ключей. Люди, которые используют систему, будут ожидать, что эмитент возьмет на себя ответственность, когда что-то пойдет не так (и они будут); этот вид ответственности недешев и часто неосуществим для проекта с открытым исходным кодом.

2 голосов
/ 25 апреля 2009

Чарли на правильном пути, но я хочу подчеркнуть некоторые другие моменты. (Мои комментарии были написаны на основе более ранней, более короткой версии ответа Чарли.) IBE - это скорее схема управления ключами, чем подход к шифрованию, и его подход к управлению ключами охватывает важные вопросы в русле. Попытка использовать личность в качестве основы чревата проблемами, потому что ни у кого нет действительно хорошего решения для проверки личности в электронных приложениях, будь то в сети или в физическом мире. Без хорошего решения для идентичности эти схемы IBE падают на глаза, как только вы подчеркиваете идентичность, на которую они опираются.

Большинство систем IBE, о которых я слышал, содержат технические подробности о том, чтобы действительно «доверять поставщику», что не масштабируется и не обеспечивает реальной безопасности, когда вы действительно заботитесь об этом. Провайдер пытается установить идентичность по сети, а затем действует как доверенная третья сторона, храня ключи шифрования для всех. У доверия третьей стороне есть много известных недостатков.

Современная криптография - это поиск путей, чтобы не полагаться на третьих лиц. Сеть доверия - это один из подходов, главный недостаток в том, что она оставляет управление ключами конечным пользователям, а управление ключами стоит дорого. Доверие к эмитентам сертификатов - это еще один подход, но там ясно, что эмитенты являются доверенными третьими сторонами. Несколько лет назад одна из главных проблем, которой доверяли все браузеры, обанкротилась и была куплена банкротом игроком, который явно не заслуживал доверия, давая понять, что слабость этой схемы лежит в основе цепочек сертификатов. .

1 голос
/ 25 апреля 2009

Есть ли конкретная схема, которую вы имеете в виду? «Шифрование на основе идентичности» - это довольно широкий термин.

Но в любом случае, возможно, вы не заметили такого большого внимания, потому что это не криптографически так уж само по себе. Будут применяться общие принципы криптографии, например, сколько битов энтропии содержится в ключе шифрования? Каковы риски столкновительных атак и других атак, связанных с наличием большого объема открытого текста / зашифрованного текста, если один и тот же ключ будет использоваться в течение практически неопределенного периода времени??

0 голосов
/ 03 января 2017

Попробуйте это . Хорошее и простое решение.

...