1030
0.3
2014-06-04
Google предложит пользователям GMail использовать end-to-end шифрование
Корпорация Google готовится выпустить специальное расширение для браузера Google Chrome, которое позволит пользователям сервиса GMail зашифровывать сообщения перед отправкой, чтобы исключить возможность перехвата сообщений. Расширение под простым названием End-to-End использует стандарт OpenPGP, но пока не готово к выпуску, так как Google просит помощи у сообщества.
Команда Google Security приняла решение выпустить сначала исходный код расширения под лицензией Apache 2.0, прежде чем расширение будет опубликовано в Chrome Web Store. Причина этому проста — Google пришлось столкнуться с целым рядом трудностей, поэтому в компании пока не уверены, что их реализация OpenPGP надёжна. В Google отмечают, что рантайм JavaScript архитектурно не отличается надёжностью, так как не может контролировать то, что происходит на нативном уровне, поэтому есть риск утечки данных. Отмечая причины появления данного проекта, в компании заявили, что в настоящее время существуют GnuPG и PGP, но они требуют от пользователя знаний в области шифрования, тогда как расширение от Google попытается провести процесс шифрования как можно более дружелюбно к пользователю. Что касается собственно JavaScript, то в FAQ Google даёт некоторые пояснения.
Чтобы исправить по возможности все изъяны в проектировании расширения, Google включает свой новый продукт в список доступных для вознаграждения за нахождение и эксплуатацию уязвимостей. Таким образом, помощь Google просит не безвозмездную, а с возможностью получить награду от $500 до $20 тысяч.
Google также просит пользователей при использовании расширения отключить отправку анонимной статистики в компанию, так как в некоторых случаях (как падение браузера) в Google могут отправиться данные, позволяющие восстановить приватный ключ пользователя.
FAQРаз вы опубликовали исходный код, то я мог сам опубликовать расширение в Webstore?
Пожалуйста, не делайте этого.
Команда разработчиков понимает, что потенциально этим расширением могут пользоваться журналисты, борцы за права людей и другие, кто могут не быть технически подкованными, следовательно это расширение может стать причиной неприятных последствий.
Мы выпускаем исходный код в надежде выявить уязвимые места, которые могла пропустить наша компанда. Поэтому как только мы получим достаточно подтверждений, что наша реализация надёжна, мы сами выпустим расширение в каталог и обеспечим дальнейшую поддержку.
Работает ли шифрование с вложениями или только с самим текстом письма в GMail?
Только с текстом. Помните также, что тема письма и список получателей также не будут зашифрованы.
Почему вы используете генерацию ключей только на эллиптических кривых?
RSA-генерация медленнее, чем на эллиптических кривых.
Будет ли End-to-End работать на мобильных устройствах?
На данный момент Chrome на Android и iOS не поддерживают расширения, поэтому нет.
Какие спецификации вы используете в расширении?
RFC4880 — формат сообщений OpenPGP
RFC6637 — OpenPGP-криптография на эллиптических кривых
К сожалению, расширение пока не поддерживает спецификации по MIME-защите с OpenPGP и по алгоритму Camellia.
У меня крякозябры!
Мы пытались избежать отображения крякозябр для не-романских языков, но не удивляйтесь, если встретите крякозябры, особенно в служебных областях. Автоматические проверки кодировок мы реализовывать не стали.
Находятся ли приватные ключи в памяти, очищаются ли они после каждой операции, или есть кэш для кодовой фразы?
Приватные ключи хранятся незашифрованными в памяти. Мы рекомендуем, чтобы ваш «брелок» обладал кодовой фразой. В этом случае приватные ключи хранятся в зашифрованном localStorage.
Ну и насколько они там защищены?
Так как ключи находятся в localStorage, то необходимо их шифровать. Если просто в памяти незашифрованными, то полагайтесь только на песочницу Chromium.
JavaScript? SRSLY?
Да, когда мы начинали работу над End-to-End, все предыдущие JS-либы нам не подходили, поэтому пришлось нагородить свою. Мы прекрасно понимаем все угрозы, что таит в себе JS для шифрования, поэтому приняли все пришедшие нам в голову меры по смягчению и устранению рисков.
В javaScript нет поддержки многоядерности. Куда же без неё в шифровании?
Современные движки, такие как V8 в Chrome, поддерживают типизированные массивы, а WebCrypto обеспечивает криптостойкий генератор псевдослучайных чисел.
Крипто-проекты на JavaScript в прошлом уже не раз ломались, уменьшив доверие к языку для реализации таких серьёзных вещей.
Верное утверждение. Но на практике ни один распространённый язык программирования не даёт 100% защиты от уязвимостей.
Мы прекрасно знаем обо всех примерах, поэтому мы с самого начала поставили для себя высокую планку качества. Мы начали с нуля создали современную криптографическую либу, покрытую тестами. В ней обеспечена поддержка методов BigInteger, модулярной арифметики, эллиптических кривых, как и симметричного и на открытых ключах шифрования. Сделав это, мы разработали OpenPGP-оболочку поверх библиотеки. Часть кода библиотеки используется внутри нашей компании в продакшене.
Полный FAQ на Google Code.
Для справки. Ранее на Хабре уже обсуждался пример похожего расширения от сторонних разработчиков.
Источник: habrahabr.ru/post/225147/
Команда Google Security приняла решение выпустить сначала исходный код расширения под лицензией Apache 2.0, прежде чем расширение будет опубликовано в Chrome Web Store. Причина этому проста — Google пришлось столкнуться с целым рядом трудностей, поэтому в компании пока не уверены, что их реализация OpenPGP надёжна. В Google отмечают, что рантайм JavaScript архитектурно не отличается надёжностью, так как не может контролировать то, что происходит на нативном уровне, поэтому есть риск утечки данных. Отмечая причины появления данного проекта, в компании заявили, что в настоящее время существуют GnuPG и PGP, но они требуют от пользователя знаний в области шифрования, тогда как расширение от Google попытается провести процесс шифрования как можно более дружелюбно к пользователю. Что касается собственно JavaScript, то в FAQ Google даёт некоторые пояснения.
Чтобы исправить по возможности все изъяны в проектировании расширения, Google включает свой новый продукт в список доступных для вознаграждения за нахождение и эксплуатацию уязвимостей. Таким образом, помощь Google просит не безвозмездную, а с возможностью получить награду от $500 до $20 тысяч.
Google также просит пользователей при использовании расширения отключить отправку анонимной статистики в компанию, так как в некоторых случаях (как падение браузера) в Google могут отправиться данные, позволяющие восстановить приватный ключ пользователя.
FAQРаз вы опубликовали исходный код, то я мог сам опубликовать расширение в Webstore?
Пожалуйста, не делайте этого.
Команда разработчиков понимает, что потенциально этим расширением могут пользоваться журналисты, борцы за права людей и другие, кто могут не быть технически подкованными, следовательно это расширение может стать причиной неприятных последствий.
Мы выпускаем исходный код в надежде выявить уязвимые места, которые могла пропустить наша компанда. Поэтому как только мы получим достаточно подтверждений, что наша реализация надёжна, мы сами выпустим расширение в каталог и обеспечим дальнейшую поддержку.
Работает ли шифрование с вложениями или только с самим текстом письма в GMail?
Только с текстом. Помните также, что тема письма и список получателей также не будут зашифрованы.
Почему вы используете генерацию ключей только на эллиптических кривых?
RSA-генерация медленнее, чем на эллиптических кривых.
Будет ли End-to-End работать на мобильных устройствах?
На данный момент Chrome на Android и iOS не поддерживают расширения, поэтому нет.
Какие спецификации вы используете в расширении?
RFC4880 — формат сообщений OpenPGP
RFC6637 — OpenPGP-криптография на эллиптических кривых
К сожалению, расширение пока не поддерживает спецификации по MIME-защите с OpenPGP и по алгоритму Camellia.
У меня крякозябры!
Мы пытались избежать отображения крякозябр для не-романских языков, но не удивляйтесь, если встретите крякозябры, особенно в служебных областях. Автоматические проверки кодировок мы реализовывать не стали.
Находятся ли приватные ключи в памяти, очищаются ли они после каждой операции, или есть кэш для кодовой фразы?
Приватные ключи хранятся незашифрованными в памяти. Мы рекомендуем, чтобы ваш «брелок» обладал кодовой фразой. В этом случае приватные ключи хранятся в зашифрованном localStorage.
Ну и насколько они там защищены?
Так как ключи находятся в localStorage, то необходимо их шифровать. Если просто в памяти незашифрованными, то полагайтесь только на песочницу Chromium.
JavaScript? SRSLY?
Да, когда мы начинали работу над End-to-End, все предыдущие JS-либы нам не подходили, поэтому пришлось нагородить свою. Мы прекрасно понимаем все угрозы, что таит в себе JS для шифрования, поэтому приняли все пришедшие нам в голову меры по смягчению и устранению рисков.
В javaScript нет поддержки многоядерности. Куда же без неё в шифровании?
Современные движки, такие как V8 в Chrome, поддерживают типизированные массивы, а WebCrypto обеспечивает криптостойкий генератор псевдослучайных чисел.
Крипто-проекты на JavaScript в прошлом уже не раз ломались, уменьшив доверие к языку для реализации таких серьёзных вещей.
Верное утверждение. Но на практике ни один распространённый язык программирования не даёт 100% защиты от уязвимостей.
Мы прекрасно знаем обо всех примерах, поэтому мы с самого начала поставили для себя высокую планку качества. Мы начали с нуля создали современную криптографическую либу, покрытую тестами. В ней обеспечена поддержка методов BigInteger, модулярной арифметики, эллиптических кривых, как и симметричного и на открытых ключах шифрования. Сделав это, мы разработали OpenPGP-оболочку поверх библиотеки. Часть кода библиотеки используется внутри нашей компании в продакшене.
Полный FAQ на Google Code.
Для справки. Ранее на Хабре уже обсуждался пример похожего расширения от сторонних разработчиков.
Источник: habrahabr.ru/post/225147/
Bashny.Net. Перепечатка возможна при указании активной ссылки на данную страницу.
