Комментарии 71
По статье:
- О громоздкости ключа: да, ключ RSA больше, но не надо его передавать на каждое сообщение, ключ должен быть получен отдельно от сообщения, по другому каналу, желательно кардинально другому. Иначе это не безопасность а фикция. Да, подписи им сделанные тоже не маленькие, ну так можно не использовать длинный ключ, ограничится на 2 кбита. Для передачи чего-то типа «Привет, Вася, пошли на рыбалку» этого вполне хватит. Всё равно не успеют разгрызть до того, пока не высохнет засоленная рыба, которую на той рыбалке наловили....
- Forward secrecy: я очень хочу посмотреть на реализацию его в инструменте не предполагающем прямое создание сессии и обмен «on-line», да так, чтобы сие не породило миллион возможностей по утечке сессионного ключа.
- Старые шифры: старое здесь не значит плохое. Если шифры создавались во времена, когда люди уже поняли, что машина будет ускорятся, а не во времена 70-х, то он вполне адекватен времени и в гражданском секторе актуален и будет актуален ещё долго. Если мы говорим о попытке предотвратить утечку данных в масштабе времени и ратуем за всё новое, нам ничего не стоит процедуре передачи данных применить несколько шифров на для каждого из слоёв. Особо страшное скопировать в архив, закрыть его любым любимым инструментом, а результат уже закрыть PGP-шкой. В чём проблема?
Если шифры создавались во времена, когда люди уже поняли, что машина будет ускорятся, а не во времена 70-х, то он вполне адекватен времени и в гражданском секторе актуален и будет актуален ещё долго
3DES тоже получается? И ведь речь не только о шифрах в смысле алгоритмов шифрования. Речь о схемах, режимах, дизайне. Тот же AES имеет тучу режимов и далеко не все из них безопасны. TLS 1.3 вырезал поддержку практически всех, оставив лишь современные AEAD режимы.
Ну и наконец, причём тут cipher suit'ы из всяких там TLS? Это частные случаи.
Используйте Signal. Или Wire, или WhatsApp, или какой-то другой безопасный мессенджер на основе протокола Signal.
С каких пор WhatsApp стал безопасным?
Закрытый код, сотрудничество с правительствами, кривая политика конфиденциальности — это ли не признаки настоящей безопасности?
Как можно доверяшь шифрование чего либо тому кто не доверяет мне исходный код утилиты для шифрования?
п.с. виндой не пользуюсь, свечку не держал
Насколько мне известно, если какой-то апдейт не даст битлокеру загрузиться нормальным образом, система сама сделает suspend protection. Пользователь ничего не заметит и останется в неведении относительно того, что его данные до окончания апдейта являются незашифрованными.
Видимо, Microsoft специально включила BitLocker в Windows, чтобы им не пользовалисьдоля правды в ваших словах есть… Windows для США и Windows для остальных — это сильно разные системы.
При этом, не поленился проследовать в карму и проплюсовать m1rko за перевод. Несмотря на противоречивые выводы, сам материал действительно редкий, ценный и даёт прекрасную пищу для размышлений. Спасибо за то, что обратили на него внимание русскоязычной аудитории. Но впредь было бы здорово, если бы вы все-таки добавляли «примечания переводчика» при наличии таких поверхностных противоречий в переводимых материалах.
Купил новый телефон. Залогинился в Google. Бац — все приложения, которые были на старом, установились. WhatsApp установился. Захожу. Надо же, все мои сообщения (ага, шифрование, безопасность) — вот они. Даже с позапрошлого телефона. Значит, что? Значит, любой сисадмин Google, имеющий доступ к моему бекапу в облаке, тоже так может, а если не делает, то только оттого, что мои сообщения ему неинтересны…
Signal. Единственный способ верифицировать корреспондента и гарантировать себя от MITM-атаки — встретиться лично и сверить отпечатки. Чем это лучше PGP? Ничем, это даже хуже — в PGP хотя бы есть способ через цепочку верифицировать человека, с которым никогда не пересекался лично.
И прочая, и прочая… Собственно, чего, кроме чуши, можно ожидать от человека, который утверждает, что занимается безопасностью ПО, и при этом не прикасается к PGP? ;-)
В этом смысл статьи.
И пожалейте майора, ему же неудобно…
Кто мешает вашему бекапу лежать на серверах гугл в зашифрованном виде, с ключом в виде вашего пароля или его производных? Понятно, что без E2E всегда будет место где можно перехватить пароль.
Меня вот если честно, больше интересует, что мешает злому сотруднику телеграм внедрить в клиент для андройд код, тупо отправляющий все незашифрованные сообщения на сторонний сервер. Или это невозможно в принципе?
А защита от недобросовестных релизеров вообще возможна только одна: сочетание Open Source и Reproducible Builds. Любой другой вариант требует доверия к «сотруднику телеграм», которого, если мы тут про безопасность, быть не может a priori.
Нет.
Обычно используется другая схема.
Вашим паролем зашифрован другой "настоящий" ключ (обычно достаточно большой), которым зашифрованы данные. При смене пароля достаточно перешифровать этот рабочий ключ, а не все данные.
Аналогично шифруются содержимое дисков. Точнее говоря оттуда и пошло лет 20-30 назад.
Кстати, интересно: а если поставить WhatsApp на новый телефон, не импортируя настройки из Google, старые сообщения не будут доступны? Надо потестить…
А если я забыл пароль? Т.е. не могу предоставить старый для перешифровки? У гугла восстановление забытого пароля вполне возможно.
Не знаю как сейчас у гугла, но (как правило) хранение хешей паролей (включая механизм восстановления) и шифрование файлов обеспечиваются разными подсистемами.
При этом данные шифруются отдельным ключом (или ключами) которые шифруются паролем и перешифровываются при его смене. Это достаточно тривиальный подход, позволяющий не перешифровывать данные при смене пароля.
У гугла может быть иначе. В том числе потому, что почта и файлы индексируются (как минимум) для показа более релевантной рекламы, но не ради восстановления пароля.
Значит, любой сисадмин Google, имеющий доступ к моему бекапу в облаке, тоже так может
Не обязательно. Например, ключ для дешифровки может храниться в облаке в зашифрованном виде и дешифроваться только на устройстве при вводе пароля.
Собственно, анамнез и диагноз у меня особенных возражений не вызывают.
Переусложнённость и груз наследия PGP, конечно же, не способствуют надёжности. Иллюстрация тех 100500 известных (и стольки же ещё неизвестных публике) способов компрометации есть в приведённой ссылке на "Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels".
Но к назначенному лечению вопросы имеются. Новые шифры, вроде бы, хороши. Но где стандартные протоколы с их использованием, например, для той же электронной почты? Почему Signal-like мессенджеры лучше принимая во вниманию серию скандалов по компрометации их реализаций или, иными словами, наличии тех же проблем что и в статье по взлому OpenPGP / S/MIME. PGP претендует, во многом, универсальную модель применения. Вырисовывается ли столь же универсальная альтернатива и нужна ли она? И проч., проч., проч.
Мне тоже немного обидно за криптографию в целом, но, думаю, автор имел в виду именно развитие компьютерного шифрования во всех его проявлениях
Разве RSA — это не аналог PGP с обрезанной и вынесенной в отдельный процесс аутентификацией?
Да, PGP сложна для новичка. Но на мой взгляд это житейская сложность: чтобы понять, что можно доверять полученному сообщению, нужно проделать определенную цепочку действий. В жизни точно также.
"Информационная война — это целенаправленное обучение врага как снимать панцирь с самого себя" (с) Расторгуев (не певец).
VCS, как много в этом слове… Наиболее популярные поддерживают подпись коммитов… GPG. И с реализацией поддержки там свои сложности, с изменением истории там сложности (люди любят менять историю), с проверкой доверия подпсей там тоже не всё просто…
Несколько статей на тему:
Краткое содержание:
PGP сложен и нипанятен. Группу экспертов попросили "настроить PGP" (интересно что под этим подразумевается) и они за 2 часа не справились (видимо их отрубили от инета и не дали манов).
MDC: Обратно несовместимая надстройка над PGP обратно несовместима. ШОК.
SKS серверы выдают списки своих пользователей!!1
Нет perfect forward secrecy (единственный вменяемый аргумент)
EFAIL (9000+ раз оцененный как "not a vulnerability" и являющийся багом надстройки над PGP, а не PGP)
Используйте наши проприетарные мессенджеры с привязкой к телефонному номеру и ваша приватность будет гарантирована
Для передачи файлов используйте утилиту на петоне, написанную каким-то хреном с горы
Не используйте email, потому что "даже с PGP это открытый текст по умолчанию" и его может прочесть кто-то другой. Signal, разумеется, этой проблеме не подвержен
Для хранения бэкапов используйте tarsnap — централизованный проприетарный облачный сервис, использующий Amazon S3, это лучше всего для вашей приватности
Реальные проблемы экосистемы PGP наподобие флуда подписями? Мы о них не знаем и не будем упоминать
К сожалению я «выпал» из темы и не могу похвастаться знанием современных систем, но идеология работы с дайджестом ключей, наличие нескольких уровней ключей представляется еще современным. Естественно, там есть и были дырки, на базе исходников 95года, которые Циммерман распространял через PGP-сообщество была такая дыра в использовании пары секретных ключей, с одним паблик, что… нам пришлось попотеть серьезно, что б как-то «залепить» эту дырку. Но смысл моего спича в том, что если я закрою файл даже 256-м ключом и привезу ключ другу на флэшке, а не буду забывать его на общедоступных ресурсах, то мы можем рассчитывать на определенный уровень приватности, по крайней мере на время жизни сообщения..)) Т.е главную функцию система до сих пор выполняет. Особенно, если у тебя несколько адресатов а ты для них источник информации и как то нужно ограничить возможность чтения капсулы соседом.
Неприятный UX
Все понятно, если в тексте появляется UX значит автор хипстер и не может осилить ПО вышедшее больше чем 5 лет назад и хочет все периписать по современным паттернам (которые меняются по нескольку раз в год), причем обязательно на js/go/rust.
Используйте Signal. Или Wire, или WhatsApp, или какой-то другой безопасный мессенджер на основе протокола Signal.
Угу, используйте проприетарное закрытое го-но которое с радостью сольет вас при первой возможности. И ведь мог написать про OMEMO, который является открытой реализацией того самого Signal, но нет только проприетарное го-но.
Статья более, чем наполовину, состоит из "Не осилили — значит, не нужно!" и "вот сейчас одной кнопкой можно, не то что в 90-х!"
По делу — отсутствие forward secrecy — действительно, важная проблема, т.к. сейчас хранить "на будущее" всё подряд можно за копейки, когда появился PGP, такой концепции не было.
Если кто знает, какие варианты решения есть — расскажите, пожалуйста.
А вот по поводу таких абзацев:
Используйте Signal. Или Wire, или WhatsApp, или какой-то другой безопасный мессенджер на основе протокола Signal.
Не стал бы доверять статье о безопасности, в которой рекомендуют WhatsApp, после этого момента читать расхотелось.
Хм, строго говоря, его изобрели гораздо, гораздо, раньше, а двадцать лет назад вы таки поверили специалистам АНБ (КГБ/ФАПСИ/ФСБ), что шифрование без имитозащиты бессмысленно.
Кто-нибудь может пояснить, это действительно так?
Если у вас алгоритм сжатия всегда дает одинаковый заголовок, то ТЕОРЕТИЧЕСКИ набрав 100тысяч+ файлов одновременно сжатых и зашифрованных(причем они почти все должны быть именно сжаты и вы должны быть в этом уверены, и одним методом), вы можете подобрать ключ основываясь на том, что у вас заголовок сжатых файлов одинаков.
В общем случае вы можете спокойно забить на данную фразу как и почти на все в этой статье от «экспертов».
Собственно после шифрования сжатие вообще не работает, потому обычная практика сжатие и шифрование.
Применительно к HTTPS — взломщик заставляет браузер жертвы запустить злонамеренный скрипт который делает ОЧЕНЬ БОЛЬШОЕ количество запросов и в каждый запрос к уже имеющимся данным подмешивает множество собственных фрагментов текста. Анализ размера зашифрованного потока позволяет сделать предположение о том, содержится ли в исходном коде подмешанный фрагмент или нет. Предполагается, что скрипт работает достаточно длительное время незаметно для жертвы.
Применять такое для PGP просто бессмысленно. Это же надо как-то заставить юзера запустить PGP и вместо шифрования одного письма зашифровать и отправить несколько миллионов писем в каждом из которых к исходному тексту будет приписан нужный взломщику фрагмент. Сделать такое можно только затроянив машины жертвы целиком. А если машину жертвы затроянили то вся эта возня с алгоритмами сжатия становится совершенно ненужной.
Ключ signify сгенерирован передовым алгоритмом Ed25519, а PGP — более слабым RSA.
GnuPG уже довольно давно поддерживает алгоритм Ed25519.
несколько дней назад на сервера GPG была трудно устранимая атака. Здесь есть описание
Проблема PGP