Pandor — end-to-end шифрование емейл переписки

[Delfino]

А что если АНБ придет в гости к pandor?

[GMint]

Мы собираемся находиться под юрисдикцией Монако, так что придти им будет не просто. И в любом случае, мы делаем ставку, что все приватные ключи будут у пользователей и мы их хранить не будем, таким образом у нас ничего не будет интересного для АНБ.

[GMint]

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

[GMint]

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

[Maximus43]

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

[GMint]

Реализация в процессе становления, отдельного хранилища и HSM еще нет, мы лишь к этому подходим. Если можете дать нам направления по опыту, буду благодарен.

[YevgenyY]

IMHO есть некоторое противоречие в этих двух утверждениях:

Первое:

мы делаем ставку, что все приватные ключи будут у пользователей и мы их хранить не будем, таким образом у нас ничего не будет интересного для АНБ.

Второе:

просто синхронизация приватных ключей происходит через сервер

[GMint]

Это противоречие заключается в удобстве, что мы хотим создать для пользователя и возможностью быть полностью в безопасности. Мы хотим найти некий баланс, по умолчанию, мы предлагаем синхронизацию ключей через наш сервер, но если пользователь боится АНБ, мы предложим не хранить ключ у нас.

[Delfino]

Вся Европа уставлена базами НАТО. Почему непросто? Вообще, вопрос не в этом. Если что-то может быть украдено, это будет сделано.

[Delfino]

Минусующие, такие минусующие =) Для вас простым языком:

1. если plain пароль где-то хранится (даже в надежном месте), то это дает возможность его украсть;
2. если приватный ключ хранится не только у владельца, но и где-то на «надежном» сервере, то это дает возможность его украсть.

Иначе зачем шифрование? Вы что google-у не доверяете?

Законодательство Монако не является инвариантом во времени. Это относится к любой стране, компании.

Видимо, я говорю слишком очевидные вещи, потому и минусуют. Ну, значит, так надо =)

[toxicdream]

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

[GMint]

Генерация ключа происходит на машине клиента, но, я думаю мы можем позволить их и самостоятельно создавать. А вот, создавать ключ «за кого-то» и ему отправлять, интересное предложение, а зачем это?
С хранениями как самих ключей, так и сертификатов, здесь мне кажется большое поле для работы и совершенствования системы.

[ksenofor]

> А вот, создавать ключ «за кого-то» и ему отправлять, интересное предложение, а зачем это?

Видимо чтобы помнить, о чем писал ))

[Maximus43]

Все уже придумали и сделали до вас.
GPG — вот расширение для Хрома, а вот сервер для обмена публичными ключами — keys.gnupg.net

[GMint]

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

[Maximus43]

А в GPG ничего сложного и нет.
Вы проведите анализ и выложите сравнительную таблицу вашего решения и аналогов. Тогда все будет наглядно и понятно.

[GMint]

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

[constnw88]

А что если сделать систему, похожую на контакты Viber. Т.е. на своих серверах хранить лишь связку адрес электронной почты — открытый ключ? Соответственно, при отправке можно будет автоматически отправлять в зашифрованном виде по полученному электронному ключу.

[GMint]

Фактически Pandor так и работает, сервис по емейлу выдает публичный ключ, и сообщения отправляются в защифрованном виде от отправителя к получателю.

[vlado]

Павел, из статьи не понятно в чём «бизнес». Не проясните этот важный момент?

[GMint]

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

[ValdikSS]

Я сейчас ограничен в интернете и, к сожалению, не могу протестировать ваш аддон, но звучит неплохо.
Проясните, пожалуйста пару моментов:

1) Зачем свой keyserver? Почему не использовать тот же сервер gnupg или mit? Уж там-то явно больше ключей будет.
2) В комментариях говорили, что вы генерируете приватные ключи на сервере, или зраните их. Так ли это? Если да, то что это еще за говно?
3) Собственно, какие технические трудности с шифрованием файлов?
4) Есть ли защита от создания фейковых ключей для конкретного адреса почты?

[GMint]

1) Я думаю мы подключим поиск и по открытым серверам, но свой сервер нужен из-за пункта 2
2) Мы генерируем ключи и на данный момент для удобства пользователя, мы их храним у нас, но мы предложим возможность удаления их с сервера
3) Пока это просто не реализовано, сложность во времени и некоторых моментах интерфейса
4) Я бы не назвал решение «защитой», но у нас есть активация почты для профиля и мы таким образом хотим верифицировать емейл адреса

[ValdikSS]

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

Удобства. Ну да, ну да.
Сделайте нормально — генерацию и хранение ключей исключительно на клиенте. У вас неплохая идея, и реализация в виде расширения (а не javascript на сайте), но вот это вот сводит все преимущества на нет.

[bromium]

Зашёл в надежде увидеть возможность шифрования аттачментов, а оказывается, это планируемый способ монетизации. Особых причин уходить с Mailvelope пока не вижу.

[mars1983]

В корпоративном сегменте есть значительный спрос на функционал по шифрованию сообщений с использованием web-интерфейса Gmail. Десять-двадцать раз в год точно приходится отвечать на такой запрос. Но хорошего решения пока нет (как нет и ни одной продажи такого решения в России). Ни одна служба безопасности не согласится использовать внешний неконтролируемый сервис для генерации ключей и обмена ими. Единственный вектор развития для привлечения больших клиентов — обеспечить интеграцию с существующими у компаний PKI решениями. На SMB я бы даже не рассчитывал.

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

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