Protonmail ch что это

С почтовыми клиентами для персональных компьютеров ситуация сложнее. В теории сервис совместим со сторонними почтовыми клиентами типа Microsoft Outlook. На практике для нормальной работы придется установить программу-посредник ProtonMail Bridge. Она доступна в версиях для Windows и MacOS.

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

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

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

Двойная защита почтового ящика

Пользователю необходимо придумать два пароля. Один нужен чтобы доказать, что почтовый ящик принадлежит именно ему. Он передается на сервера компании. Второй — остается у пользователя. Он открывает доступ к почтовому ящику и расшифровывает его содержимое на компьютере или смартфоне. Этот пароль не отправляется на сервер, так что сотрудники ProtonMail не получат доступа к письмам, даже если очень захотят.

В настройках активируется еще один слой защиты от несанкционированного доступа — двухфакторная аутентификация при помощи временных одноразовых кодов (TOTP). Она требует установки на смартфон приложения Google Authenticator, что безопаснее, чем подтверждения по SMS. Ведь, чтобы получить доступ к сообщениям, злоумышленнику достаточно перевыпустить SIM-карту.

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

Неполное восстановление аккаунта

Слабая защита от спама

Нет интеграции с другими почтовыми ящиками

Ограниченные возможности бесплатной версии

И все же, ProtonMail не идеален. Он имеет ряд недостатков в функционале и реализации шифрования. Кроме того, сервис больше нацелен на безопасность данных, а не на анонимность пользователей. Это следует учитывать, принимая решение о регистрации нового аккаунта.

ProtonMail — хороший выбор для базового e-mail адреса, на который будут зарегистрированы учетные записи в банковских системах, социальных сетях и на других важных ресурсах. Использование ProtonMail в таком качестве — важный шаг на пути к личной цифровой безопасности.

Источник

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

Вам нужно будет придумать и запомнить 2 пароля: первый пароль будет вводиться для авторизации на сайте, но НЕ будет давать доступ к почтовому ящику. Чтобы просмотреть ящик, понадобится второй пароль, одновременно служащий для дешифровки писем. Операция шифрования проводится на стороне клиента, а на сервер отправляются уже зашифрованные данные, что исключает MITM атаку. Ключей от вашего ящика на серверах нет, так что, даже в случае визита людей с погонами, сотрудники сервиса смогут выдать только зашифрованные данные.

Архитектура такова благодаря использованию open source front-end encryption, что означает шифрование данных на стороне пользователя. Вы сможете познакомиться с OpenPGPjs библиотеками, используемыми сервисом, на этой страничке Github.

В end-to-end шифровании конечные точки это: отправитель и предназначенное устройство получателя. Сообщение шифруется локально на устройстве отправителя, после чего может быть расшифровано только на устройстве получателя. «End-to-end шифрование» обычно называется «шифрованием на стороне клиента» или «нулевым допуском», из-за факта обработки письма при помощи не централизованных серверов, а конечных устройств пользователей. Для end-to-end шифрования используется 2 алгоритма: симметричный и асимметричный.

Ребята из ProtonMail не рекомендуют таким людям, как Эдвард Сноуден, пользоваться их сервисом, но данное предупреждение скорее выглядит культурной отмазкой, мол «не хотим иметь дело с американской агентурой, извините».

Среди многочисленных «плюшек», которыми почта завлекает пользователей, стоит выделить:

1. Бесплатно (и без смс)

2. Свобода от законодательства Евросоюза, обязывающего выдавать информацию пользователей (Швейцария не является частью ЕС)

3. Свобода от аналогичного законодательства США

4. Свобода от властей самой Швейцарии — локальные законы охраняют неприкосновенность серверов и без особенной «боли в заднице» какой-нибудь правительственный тюфяк не имеет права даже смотреть на них.

5. Все сервера расположены в Швейцарии, постоянно идет процесс улучшения техники: добавления памяти, функций

6. При входе нужно вводить 2 пароля (второй пароль автоматически включается, если вы закрыли вкладку или переводили ноутбук в «спящий» режим)

7. В разработке полный контроль над приватными ключами

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

9. Если вы потеряли пароль от ящика, восстановить его уже не возможно. Сброс пароля возможен, но тогда вы навсегда потеряете письма. Не забывайте пароли!

Вот так примерно выглядет протон изнутри:

Когда много слов «свобода» и «независимость», всегда возникает вопрос, в чем подвох? Да и смешно говорить о приватности в интернете, ее вообще не существует.

у меня, уж простите, ну никак не получается…

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

ИБ на пальцах. Не перегнули ли со слежкой из-за covid? Ч.1

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

Для начала взглянем на проблему. Вдруг её нет и мне просто давит шапочка из фольги? Итак, на фоне пандемии государства в едином порыве принялись решать различные вопросы. Нас касается тот, который про контроль за заболевшими. С одной стороны, полезно было бы выявить всех тех, с кем контактировал заболевший. С другой стороны, нужно контролировать. Контролировать соблюдение самоизоляции самоизолированными, ношение масок, комендантский час и т.д. Я сейчас не только про РФ, если что. Разберёмся поочерёдно с обеими сторонами. В целом, необходимость и полезность раннего выявления всех контактировавших с заболевшим можно объяснить картинкой:

Во-первых, расстояние. Разные источники пишут про безопасное расстояние в 1,5-2 метра. Отсюда вывод: все, кто находится дальше, не интересны. Для этого «дальнобойность» блютуса подходит (она небольшая). Кроме того существует связь между мощностью сигнала и дальностью. Поэтому можно будет оставить только «ближний круг».

Но что мешает генерировать «позывные» чаще? Раз в 10 минут, в 5, в 1? С одной стороны, снова упираемся в ограничение технологий. Приведу цитату из поста на хабре:

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

Представьте, что в какой-то день в большой стране о заражении сообщили 10K человек.Это 140K дневных ключей или 140K*144

20М временных ключей (каждый день генерируется 144 временных ключей 24*60/10), которые нужно сгенерировать на девайсе.

Можно оптимизировать матчинг, если не генерировать все возможные временные ключи, а производить сравнение для каждого своего локально сохраненного контакта, перебирая все новые дневные ключи зараженных, соответствующие номеру дня этого контакта. Тогда, если у вас было в среднем 10 контактов в день, т.е. 140 контактов за 2 недели, то получится 140*10K=1,4M операций, что тоже очень много.

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

По состоянию на середину апреля точно было известно, что 28 стран уж запустили приложения для отслеживания граждан и ещё 11 готовились сделать это. Вот ссылка на первоисточник заморский. Тут может возникнуть вопрос: зачем каждая страна делает свой персональный цирк с конями, если «добрые» Ябл и Гугл внедряют всё сами на уровне своих операционок? Как по мне, ответ кроется в предыдущем абзаце.

И вообще, вот Ябл отказал Франции с их приложением StopCovid и они сильно обиделись. Можно даже подумать, что Ябл и Гугл хорошие раз публично заявляют, что не пустят к данным всяких редисок. И я бы в это поверил, если бы в решении от техногигантов не было к чему доколупаться.

Первое и главное: когда создаётся «позывной», в его составе есть непонятная штука: 4 байта метаинформации Associated Encrypted Metadata (AEM). Мякота в том, что никто не поясняет, что именно в этих 4 байтах. Эксперты делают предположение, что это может быть:* Код модели телефона или мощность Bluetooth передатчика, необходимые для оценки расстояния.

* Код приложения или организации/страны, выпустившей приложение, чтобы понять, кто подтверждал диагноз.

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

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

Прошу прощения, но придётся бить тему на части. Следующий пост будет про то, чем контролируют нарушителей режима и психологический аспект.

ИБ на пальцах. Вводный пост

Здравствуйте, товарищи пикабушники. Без малого почти 10 лет я занимаюсь вопросами информационной безопасности в разрезе утечек информации (уверен, ника уже достаточно, чтобы Лига Детективов устроила полный деанон, но я и не шифруюсь вроде). И с течением времени всё больше начала напрягать ситуация, когда люди попадают в неприятности из-за пробелов в вопросах инфобеза. Вы можете возразить, что не обязаны это знать. Увы, лет 5-10 назад, когда интернет был более дружелюбным, этот аргумент бы прокатил. Но не сегодня. Цифровизация, бигдата, машинное обучение и прочие умные слова понравились большим политикам и технологии стремительно врываются в нашу жизнь. Горящие сроки (внедрения) превращаются в горящие сраки со всеми вытекающими. В общем, можно было бы много ворчать на тему, что всё плохо. Но я решил попробовать хоть что-то изменить.

Так и родилась идея проекта «ИБ на пальцах». Суть проста: быть этаким капитанам-очевидностью от ИБ. Пояснять простым языком для неспециалистов, что хорошо, а что плохо в этих ваших интернетах. Поднимать темы, над которыми вы не задумывались или не хотели задумываться.

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

Смартфоны. Выбор пал на них, потому что сегодня это самый распространённый девайс, который человек таскает с собой везде и всюду. Уверен, кто-то сейчас этот пост читает сидя верхом на белом «друге». Вот на столько близок сегодня человек и смартфон.

Но сперва данные надо собрать. Сделать можно двумя способами: либо берём у операторов, либо из приложений. Таки есть разница. У сотовых операторов взять проще. Вот только будет ли достаточно точности? Хорошо растыканные базовые станции обеспечивают точность 3-5 метров сегодня. Вот только учитывают ли такие данные то, что мы живём в как минимум трёхмерном мире. Грубо говоря, я могу определить дом, в котором живёт заражённый. А этаж? Не говоря уже о квартире. Кого изолировать? Подъезд заварить что ли? Да ну, бред какой-то.

Поэтому рассмотрим вопрос с приложением. Задумка со сбором данных из приложений лучше, потому что те же условные неяндекс.карты используют гибридный способ определения местоположения пользователя: по GPS\Глонасс, wi-fi, базовым станциям. В итоге получается более точная картина. Но есть одна проблема: надо заставить условный неяндекс делиться этой информацией. Кроме того, не до конца понятно, достаточно ли данных собирают они, чтобы строить графы связей пользователей (кто с кем контактировал). Поэтому мысль о создании собственного приложения не стоило бы сбрасывать со счетов. Со всех сторон удобнее: собираем что хотим (на самом деле, нет) и ни с кем не делимся. Google и Apple даже совместный протокол разработали и внедряют его на уровне своих операционных систем. Что собирает и передаёт этот протокол и уже ли мы все под колпаком техногигантов здесь разбирать не буду. Давайте оставим это на следующий пост.

Скажу лишь, что их идее уже лет 10 как. Как по мне, главной проблемой любого из подходов к сбору данных является достоверное определение контактирующих с заражённым. Для этого надо, чтобы смартфоны встретившихся людей автоматически общались друг с другом, фиксируя продолжительность и «близость» контакта. То есть как долго и на каком расстоянии друг от друга общались люди. Можно ли сделать такую штуку? Да. Причём нечто похожее уже не раз использовалось. Технология uXDT (ultrasound cross-device tracking), опирается ультразвуковые маячки. Активно её используют как минимум с 2017 года.

Цитата из-под гиперссылки для лл: «Идея в том, что во время воспроизведения рекламы по ТВ, на мобильном устройстве или в офлайновом магазине/ресторане издаётся неслышимый уху ультразвуковой сигнал. Обычно он добавляется к музыкальному клипу или джинглу. Этот сигнал регистрируется микрофонами окружающих электронных устройств (ноутбуки, ПК, смартфоны, планшеты) — и после этого рекламодатель знает, что этот конкретный пользователь одновременно владеет перечисленными устройствами. Это нужно в том числе для связывания рекламных профилей и отслеживания пользователя, который выходит в интернет с разных устройств».

А теперь собираем всё в кучу. Технология себя зарекомендовала. Внедряем маячки в приложение. Оно с заданной неравной периодичностью генерирует сигнал. Остальное время слушает его. Услышало – образовало пару. Как по мне, графы связей, построенные на таких данных, будут гораздо более точными. При этом исчезают пляски с бубном относительно детекта людей в помещениях. Ну и наконец, вся эта вундервафля может работать в офлайне, накапливая данные и отправляя их на сервер при доступной сети. А сеть рано или поздно станет доступна.

Это было описание принципа. Что реально умеют (а не могли бы) делать такие приложения, предлагаю расписать в следующем посте. Обратная связь от вас приветствуется. У меня, конечно, есть какая-то тактика и я её придерживаюсь, но интересные темы из комментов тоже можно раскрыть.

Источник

ProtonMail или что же это на самом деле?

ProtonMail

История ProtonMail, сервиса защищенной веб-почты, о котором уже было довольно много написано (в том числе и здесь), началась летом 2013 года, когда группа ученых из CERN (Европейская организация по ядерным исследованиям) объединила усилия в работе над улучшением ситуации с безопасностью в Интернете. Их стартап ProtonMail вышел в полуфинал 2014 MIT 100K. С этого момента и началось очень бурное развитие проекта. Именно данная победа послужила серьезным шагом для того, чтобы о них заговорили по всему миру.

История развития

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

17 июня команда ProtonMail запустили кампанию по сбору средств на развитие проекта на indiegogo.com — https://www.indiegogo.com/projects/protonmail/. Целью кампании являлся сбор US$ 100 000, которые пойдут на закупку серверов и позволят команде полностью сконцентрироваться на разработке сервиса. Были разосланы письма с предложением поддержать их всем пользователям, оставившим заявку на регистрацию. Всего за несколько дней цель была достигнута. На момент написания данной статьи собрано US$ 231 088 (за первые 7 дней). Основным бонусом в благодарность за поддержание проекта является незамедлительное получение доступа к сервису.

Получение доступа к ProtonMail

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

Через 6 часов на мой почтовый ящик поступило сообщение со ссылкой, по которой я активировал аккаунт. Регистрация заняла около минуты.

Создание аккаунта ProtonMail

Для создания аккаунта предлагается задать два пароля: для доступа к аккаунту и почтовый пароль.

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

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

Can I change or reset my Mailbox password? No. Your MailBox Password is tied to all of your emails because it’s used to encrypt all of your messages. If you were allowed to change this, then all of your current and past messages would be undecryptable and unreadable.

Пароль для входа в аккаунт можно изменить на странице настроек в личном кабинете.

Для входа необходимо сначала авторизоваться с использованием основного пароля, а затем ввести почтовый пароль, который будет использоваться для дешифровки содержимого писем уже прямо на вашем компьютере. Это позволяет обеспечить отсутствие доступа к содержимому писем со стороны сервиса и делает это физически невозможным. Здесь стоит скептически отметить, что это “в теории”, а “на практике”…

Как же выглядит и работает ProtonMail?

ProtonMail является исключительно веб-почтой. Поддержки POP3/IMAP/SMTP нет, так как вся криптография реализована на стороне веб-браузера на JavaScript.

Заходим в аккаунт и видим приветственное сообщение от команды ProtonMail. В нем кратко объясняется, какая информация шифруется, можно ли использовать ProtonMail для общения с пользователями других почтовых сервисов (например, Gmail или Hotmail).

Интерфейс

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

Все письма распределяются по папкам: полученные, отправленные и черновики. Просмотреть можно только отдельно выбранное письмо. Отображение отдельной переписки целиком (в виде списка) отсутствует.

Можно задать получателей копии письма: CC (все видят, кому отправлена копия) и BCC (получателей из данного списка другие получатели не видят в списке копий).

Стоимость сервиса

Сервис предоставляется бесплатно, но имеются ограничения на объем хранимых писем (100 мегабайт) и ежемесячное общее количество писем (500 писем). Планируется запустить платные бизнес-аккаунты, у которых будет доступен 1 гигабайт для хранения писем и не будет ограничений на количество писем. В будущем планируется добавить возможность использовать собственный домен для бизнес-аккаунтов.

Интеграция с другими сервисами и приложениями

Интеграция с другими сервисами и приложениями отсутствует. Весь функционал реализован на стороне веб-браузера на JavaScript. Открытого API нет.

Хранение писем

Полученные и отправленные письма между пользователями ProtonMail хранятся на сервере в зашифрованном виде. На стороне клиента ничего не кешируется и не сохраняется.

Если письмо получено в открытом виде со стороннего сервиса, то даже после его прочтения оно все равно остается в Inbox в открытом виде.

Если письмо отправлено на сторонний сервис в открытом виде, то оно сохраняется в папке с отправленными письмами сразу в зашифрованном виде.

Возможность экспорта писем в архив для скачивания отсутствует.

Поиск

Поиск по письмам ищет по имени отправителя, теме письма и по тексту писем, которые хранятся в открытом виде. Напомню, что в открытом виде хранятся только письма, полученные со сторонних сервисов (в незашифрованном виде).

Хранение ключей шифрования

Закрытый ключ хранится на серверах сервиса, но защищен вашим почтовым паролем. Это требуется, чтобы была возможность использовать различные устройства (и/или веб-браузеры) для доступа к почте ProtonMail. На стороне веб-браузера клиента в Local Storage ключ не сохраняется.

Возможность импорта / экспорта ключа отсутствует.

Техническая реализация

Основой сервиса стала библиотека OpenPGPjs. На время рабочей сессии почтовый пароль хранится в полностью открытом виде (без обфускации) в Session Storage.

Сервис использует асимметричное шифрование (систему шифрования с использованием открытых ключей), реализованную на стороне веб-браузера пользователя на JavaScript.

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

Безопасность

Про безопасность подобных решений на стороне пользователя, когда программный код выдается сервисом при каждом обращении, в интернете можно найти массу обсуждений и статей. Например, статья на английском http://matasano.com/articles/javascript-cryptography/ от Matasano security.

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

Команда ProtonMail подчеркивает, что они находятся в Швейцарии, где, как они пишут, законодательно их не могу обязать установить backdoor. Полный текст их объяснения доступен по адресу https://protonmail.ch/blog/switzerland/. Но это “в теории”, а “на практике” пока нет широко известных публичных прецедентов.

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

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

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

В начале июня была найдена уязвимость у сервиса ProtonMail, позволяющая исполнить произвольный JavaScript код на компьютере ничего неподозревающего пользователя и получить полный доступ к его почтовому ящику.

Данную уязвимость нашел Mike Cardwell, о чем сообщил команде ProtonMail. После исправления уязвимости он опубликовал информацию об этом на ycombinator.com. ProtonMail разместил его имя в списке благодарностей на своем сайте — https://protonmail.ch/blog/protonmail-security-contributors/, что подтверждает данный факт.

Сейчас данная проблема в безопасности ProtonMail уже исправлена, но сколько еще таких возможностей для хакеров таит в себе реализация криптографии на стороне браузера на JavaScript?

Подобные проекты

Mailpile — проект с открытым исходным кодом, активно развивается, является почтовым веб-клиентом (аналогично ProtonMail работает в веб-браузере на JavaScript), который должен сделать доступным использование криптографии пользователям без специальных технических навыков.

Отдельно следует отметить уникальную возможность данного проекта — поддержку полноценного поиска по зашифрованным сообщениям. На https://www.mailpile.is/faq/ пишут, что создается индекс, а само содержимое индекса хранит в виде хешей.

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

Lavaboom — сервис безопасной веб-почты аналогично ProtonMail. Криптография реализована на JavaScript, код исполняется в веб-браузере.

Scramble — открытый исходный код, реализован на базе OpenPGPjs (аналогично ProtonMail), но относительно молодой проект и не так бурно развивается. Я указал его в этом списке, чтобы дать более полное представление о имеющихся сервисах на рынке.

OpenMailBox — шифрование реализовано при помощи плагина OpenPGP к проекту почтового веб-клиента Roundcube. Закрытый ключ сохранятся в Local Storage браузера.

Unseen — использует свою собственную реализацию, есть сервис обмена текстовыми сообщениям и голосовые звонки. Имеются клиенты для мобильных платформ и десктопов.

Unseen используется также Roundcube с плагином OpenPGP.
Из десктопных клиентов смотрел версию для Ubuntu и Mac. Это нативные приложения-обертки, в которые внутри встроен “веб-сайт”.

Что же делать?

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

Кто сможет реализовать использование криптографии с открытыми ключами в доступном (легком) виде для обычных рядовых пользователей с использованием известных почтовых клиентов (Apple Mail, Microsoft Outlook, встроенные в мобильные ОС почтовые клиенты и другие), тот завоюет любовь пользователей и, безусловно, станет самым успешным сервисом!

UPD: Большое спасибо за комментарии к статье и вопросы! Дополнил статью.

Источник