Как вы скоро увидите, у PGP много проблем. Если не вдаваться в подробности, основная причина в том, что программа разработана в 90-е годы, до появления серьёзной современной криптографии. Ни один компетентный криптоинженер сегодня не станет разрабатывать систему в таком виде и не потерпит большинства её дефектов ни в какой другой системе. Серьёзные криптографы в основном отказались от PGP и больше не тратят на неё времени (за некоторыми заметными исключениями). Поэтому хорошо известные проблемы в PGP остаются нерешёнными более десяти лет.
Два небольших примечания. Во-первых, статья написана для инженеров, а не для юристов и активистов. Во-вторых, “PGP” может означать множество вещей, от стандарта OpenPGP до эталонной реализации в GnuPG. Мы используем термин “PGP” для всего этого.
Проблемы
Абсурдная сложность
По причинам, которые сейчас уже никто не понимает, PGP основан на пакетах. Сообщение PGP (в файле .asc) — архив типизированных пакетов. Существует по крайней мере восемь различных способов кодирования длины пакета, в зависимости от того, используете вы пакеты «нового» или «старого» формата. У пакетов «нового формата» вроде BER переменная длина (попробуйте написать реализацию PGP, и стандарт кодирования ASN.1 покажется вам конфеткой). У пакетов могут быть подпакеты. Некоторые варианты пакетов перекрываются друг с другом. Последняя атака на сервер ключей связана с тем, что из-за этого невменяемого формата парсинг ключей GnuPG случайно уходит в квадратичное время.
И это только кодировка. Реальная система гораздо сложнее. Есть ключи и подключи. Идентификаторы ключей, серверы ключей и подписи ключей. Ключи только для подписи и только для шифрования. Многочисленные «связки ключей». Аннулирование сертификатов. Три различных формата сжатия. Это мы ещё не добрались до поддержки смарт-карт.
Дизайн швейцарского армейского ножа
Если вы заблудились в лесу и… не знаю, например, вам нужно обрезать отвороты на джинсах — да, очень удобно, что на вашем ножике есть ножницы. Но для серьёзной работы никто не будет регулярно использовать такие ножнички.
Швейцарский армейский нож делает кучу вещей, и всё плохо. PGP — весьма посредственнй инструмент для подписи документов, он относительно плохо шифрует с помощью паролей, очень плохо работает с открытыми ключами. PGP не особенно хорош для безопасной передачи файлов. Это неуклюжий способ подписывать пакеты. Он не очень хорош для защиты бэкапов. Это исключительно опасный способ обмена защищёнными сообщениями.
Еще в эпоху MC Hammer, когда появился PGP, «шифрование» было особой вещью в себе; был один инструмент для отправки файлов, резервного копирования, для шифрования и подписи файлов. Современная криптография так не работает, нам нужны специализированные инструменты. Криптография для безопасного обмена сообщениями отличается от криптографии для резервного копирования или подписи пакетов.
Болото обратной совместимости
PGP предшествует современной криптографии и сильно устарел за это время. Если вам повезёт, у вашего GnuPG по умолчанию будет установлен 2048-битный ключ RSA, 64-битный шифр CAST5 в CFB и контрольная сумма OpenPGP MDC (о которой позже). Если шифрование производится паролем, а не открытым ключом, протокол OpenPGP установит для PGP алгоритм формирования ключа S2K. Мягко говоря, это не те примитивы, которые криптоинженер выберет для современной системы.
Мы многому научились с тех пор, как ботан Стив Уркель украсил прайм-тайм в эфире ABC. Мы узнали, что зашифрованные тексты следует аутентифицировать (и избегать режима CFB), что 64-битные блочные шифры плохи, что RSA не идеален, что сочетание сжатия и шифрования опасно и что KDF'ы должны строго генерироваться и по времени, и по памяти.
Что бы ни говорил OpenPGP RFC, вероятно, вы не делаете ничего из этого списка, если используете PGP, и невозможно сказать, когда рекомендации начнут выполняться. Возьмите шифры AEAD: Sequoia PGP на языке Rust по умолчанию перешла в режим AES-EAX AEAD. Это здорово. Но теперь никто не может прочитать их сообщения, потому что большинство версий PGP не знает, что такое режим EAX, и это не очень здорово. В каждой плохой криптосистеме в конечном итоге вырастает расширение RFC, которое поддерживает эллиптические кривые или AEAD, так что его сторонники могут кричать на форумах, что они поддерживают современную криптографию. RFC не имеет значения: только реальные установки. Мы изобрели аутентифицированное шифрование 20 лет назад, а PGP скоро на пенсию; хватит оправданий.
Или у вас обратная совместимость с программой 90-х годов, или у вас хорошая криптография; нельзя получить и то, и другое.
Неприятный UX
Трудно сформулировать это лучше, чем Тед Унангст:
Несколько лет назад было проведено исследование юзабилити PGP, в котором группу технических специалистов поместили в комнату с компьютером и попросили настроить PGP. Через два часа никто из них ещё не отозвался.
Если вам нужны собственные эмпирические данные, чтобы подтвердить это, вот эксперимент, который вы можете провести: найдите какого-нибудь далёкого от компьютеров юриста и по телефону помогите ему установить Signal. Наверное, он справится без истерики. А теперь попробуйте сделать это с PGP.
Долговременные секреты
PGP просит пользователей практически навсегда сохранять корневой ключ, привязанный к их личности. Генерации и обмен ключами обременительны с этими «вечеринками подписи ключей» и «сетью доверия», где ключи зависят от других ключей.
Долговременные ключи почти всегда неудобны. Если вы продолжаете использовать ключ, он в конечном итоге становится открытым. С точки зрения грамотного дизайна системы нужно минимизировать ущерб и гарантировать, что пользователь не будет ни секунды колебаться при мысли о генерации нового ключа, если есть хоть какие-то опасения по поводу безопасности текущего.
Фанаты PGP сразу ответят: «Вот почему нужно держать ключи на Yubikey». Но по беглой приблизительной оценке, почти никто в мире не использует дорогие Yubikey, и вряд ли это изменится в будущем (мы едва можем развернуть U2F, а те ключи одноразовые). Мы не можем принимать плохие криптосистемы только для того, чтобы ботанам Unix было приятнее играться со своими игрушками.
Сломанная аутентификация
Подробнее об архаичных примитивах PGP: ещё в 2000 году рабочая группа OpenPGP поняла, что нужно аутентифицировать зашифрованный текст и что подписи PGP этого не делают. Поэтому OpenPGP изобрела систему MDC: сообщения PGP с MDC присоединяют SHA-1 открытого текста к самому открытому тексту, который затем шифруется (как обычно) в режиме CFB.
Если вам интересно, как PGP справляется с этим, когда современные системы используют относительно сложные схемы AEAD (поскольку не могут просто прикрепить SHA-1 к открытому тексту), то это хороший вопрос. Как бы вам описать эту карикатуру? PGP MDC можно очистить от сообщений — он закодирован таким образом, что достаточно просто отрезать последние 22 байта зашифрованного текста. Чтобы сохранить обратную совместимость с небезопасными старыми сообщениями, PGP ввёл новый тип пакета, который сигнализирует о необходимости проверки MDC. Если вы используете неправильный тип, то MDC не проверяется. Даже если вы это сделаете, новый формат пакета SEIP достаточно близок к небезопасному формату SE, который потенциально обмануть получателя с понижением шифра; Тревор Перрин свёл SEIP всего к 16 битам безопасности.
Наконец, даже если всё пойдёт правильно, эталонная реализация PGP выдаст по запросу неаутентифицированный открытый текст, даже если MDC не совпадает.
Непоследовательные идентити
PGP — это и приложение, и набор интеграций с другими приложениями, и формат файла, и социальная сеть, и субкультура.
PGP выдвигает понятие криптографической идентичности (identity). Вы создаёте ключ, сохраняете его в связке ключей, печатаете его фингерпринт на визитке и публикуете на сервере ключей. Вы подписываете чужие ключи. Они, в свою очередь, могут полагаться или не полагаться на ваши подписи для проверки других ключей. Некоторые люди стараются встретиться с другими пользователями PGP лично, чтобы обменяться ключами и более надёжно прописаться в этой «сети доверия». Другие организуют «вечеринки подписи ключей». Если представить всю эту активность, то становится понятно, как трудно преданным фанатам PGP переключиться на новые технологии.
Но вся эта система не работает на практике. Ни сеть доверия с подписями ключей, ни серверы ключей, ни вечеринки. Обычные люди будут доверять всему, что выглядит как ключ PGP, независимо от того, откуда он взялся — как они могут не доверять, если даже эксперту трудно сформулировать, как оценить ключ? Эксперты не доверяют ключам, которые не получили лично. Все остальные полагаются на централизованные сервисы для распространения ключей. Механизмы распространения ключей PGP — это цирк.
Утечки метаданных
На секунду забудьте о фиаско с электронной почтой (вернёмся к этому позже). PGP сам по себе допускает утечку метаданных. При обычном использовании сообщения напрямую связаны с идентификаторами ключей, которые по всей сети доверия PGP связаны с идентификатором пользователя. Кроме того, довольно большая часть пользователей PGP использует серверы ключей, которые сами выдают в сеть, какие пользователи PGP обмениваются сообщениями друг с другом.
Нет прямой секретности
Наглядный пример: криптография для безопасного обмена сообщениями требует прямой секретности (forward secrecy). Прямая секретность означает, что если злоумышленник получит ваш ключ, то всё равно не сможет прочитать предыдущие сообщения. В современной криптографии мы предполагаем, что противник записывает всё в бесконечное хранилище. Заявленные противники PGP включают мировые правительства. Безусловно, некоторые из них делают это. Против серьёзных противников взлом криптографии без прямой секретности — лишь вопрос времени.
Чтобы на практике обеспечить прямую секретность, вы обычно храните два секретных ключа: краткосрочный сеансовый ключ и долгосрочный доверенный ключ. Ключ сеанса эфемерен (обычно продукт обмена DH), и доверенный ключ подписывает его, так что человек посередине не может применить собственный ключ. Теоретически, прямую секретность можно реализовать инструментами PGP. Конечно, почти никто этого не делает.
Топорные ключи
Открытый ключ OpenBSD signify — это строка Base64, достаточно короткая, чтобы поместиться в середине предложения в электронном письме; закрытый ключ, который не является форматом обмена, — просто строка или около того. А открытый ключ PGP — это целый гигантский документ Base64; если вы часто их использовали, вы, вероятно, уже привыкли прикреплять их в аттаче, а не вставлять в сообщения, чтобы не повредить. Ключ signify сгенерирован передовым алгоритмом Ed25519, а PGP — более слабым RSA.
Вы можете подумать, что это не имеет значения, но это важно; на порядки больше людей используют SSH и управляют SSH-ключами, чем PGP. Ключи SSH тривиальны для обработки; PGP — нет.
Согласование
PGP поддерживает ElGamal, RSA, p-кривые NIST, Brainpool, Curve25519, SHA-1, SHA-2, RIPEMD160, IDEA, 3DES, CAST5, AES. Это не полный список того, что поддерживает PGP.
Если за последние 20 лет мы узнали три важные вещи о криптографии, по крайней мере, две из них, это то, что согласование и совместимость — зло. Как правило, недостатки криптосистем появляются в реализациях, а не примитивах, и экспансивная криптосовместимость увеличивает количество реализаций. Современные протоколы, такие как TLS 1.3, стремятся избавиться от обратной совместимости с архаизмами вроде RSA, а не добавляют её. Новые системы поддерживают только один набор примитивов и простой номер версии. Если один из этих примитивов проваливается, вы избавляетесь от этой версии и бросаете сразу весь старый протокол.
Если нам не повезёт и через 20 лет люди всё ещё будут использовать PGP, он останется единственной причиной, по которой хоть где-то применяется стандарт CAST5. Мы не можем сказать это яснее, и это нужно многократно повторять: или у вас обратная совместимость с программой 90-х годов, или у вас хорошая криптография; нельзя получить и то, и другое.
Мусорный код
Де-факто стандартной реализацией PGP является GnuPG. Эта программа не очень аккуратно написана. Там обширная кодовая база на C — языка с дублированием функциональности (например, в описании недавней атаки типа «отказ в обслуживании» на парсинг SKS сказано, что у него есть несколько парсеров ключей) с длинным послужным списком CVE, начиная от повреждения памяти до криптографической атаки по сторонним каналам. Иногда можно было удалить из сообщений аутентификацию, а GnuPG не замечал этого. Можно было скормить ему ключи без правильного отпечатка. В 2018 году уязвимость Efail была вызвана тем, что GnuPG по запросу отдавал неаутентифицированный открытый текст. GnuPG — не есть хорошо.
GnuPG является и эталонной реализацией для PGP, и основой для большинства других инструментов, интегрирующих криптографию PGP. Он никуда не денется. Полагаться на PGP — значит, полагаться на GPG.
Ответы
Чтобы убедить человека отказаться от PGP, важно объяснить ему, что PGP нечем заменить, и это нормально. Альтернативный инструмент зависит от задачи.
Разговоры
Используйте Signal. Или Wire, или WhatsApp, или какой-то другой безопасный мессенджер на основе протокола Signal.
Современные безопасные мессенджеры созданы специально для обмена сообщениями. Они используют сохраняющие конфиденциальность аутентификационные рукопожатия, аннуляцию сообщений, криптографические храповики (ratchets), которые выдают ключ на каждый обмен сообщениями, и, конечно же, современные примитивы шифрования. Мессенджеры тривиально просты в использовании, никакой суеты с ключами и подключами. Если вы используете Signal, вы получаете даже больше: вы получаете систему, настолько параноидальную насчёт сохранения приватных метаданных с серверов, что она даже туннелирует поисковые запросы Giphy, чтобы избежать атак с анализом трафика, и до недавнего времени даже не поддерживала профили пользователей.
Шифрование электронной почты
Не делайте этого.
Электронная почта не безопасна. Даже с PGP это открытый текст по умолчанию, то есть даже если вы всё делаете правильно, какой-то совершенно разумный получатель письма, делая абсолютно разумные вещи, обязательно процитирует открытый текст вашего зашифрованного сообщения кому-то другому в CC (мы не знаем пользователя электронной почты PGP, который с этим не сталкивался). В электронной почте PGP отсутствует прямая секретность. Метаданные электронной почты, включая тему (которая буквально является содержимым сообщения), всегда передаются открытым текстом.
Если вам нужна другая причина, прочитайте статью об уязвимости Efail. Сообщество GnuPG, которое провалилось с раскрытием информации о Efail, бурно критикует эту статью, но её приняли в Usenix Security (один из лучших академических центров по безопасности программного обеспечения), а также на конференцию Black Hat USA (ведущая конференция по безопасности программного обеспечения). Это одна из лучших криптографических атак за последние пять лет — и довольно разрушительная бомба против экосистемы PGP. Как вы увидите из статьи, S/MIME не лучше.
Это никогда не исправят. Чтобы сделать реально безопасную электронную почту, вам придётся туннелировать по электронной почте другой протокол (вы всё равно будете уязвимы для атаки с анализом трафика). В том-то и дело, зачем прикидываться?
Шифровать электронную почту — это кликать беду. Рекомендовать пользователям шифровать электронную почту, если им что-то угрожает, — исключительная халатность. Любой, кто говорит вам о безопасности общения по электронной почте с PGP-шифрованием, ставит свои странные предпочтения выше вашей безопасности.
Отправка файлов
Используйте Magic Wormhole. Клиенты Wormhole используют одноразовый обмен ключами с парольной аутентификацией (PAKE) для шифрования файлов. Это легко (по крайней мере, для ботаников), безопасно и весело: всякий, кому мы показывали «кротовую нору», сразу начинал пропускать через неё все файлы подряд, как это делаем мы.
Кто-то сразу запускает инсталлятор под Windows на Rust или Go, это слишком классная программа, чтобы ею не пользоваться.
Если вы общаетесь с юристами, а не с инженерами, Signal отлично справляется с передачей файлов. Для получения отчётов об ошибках публикуйте номер Signal, а не ключ PGP.
Шифрование бэкапов
Используйте Tarsnap. Колин объяснит, как Tarsnap оптимизирован для защиты резервных копий. Или действительно, возьмите любой другой инструмент шифрования бэкапов; он не будет так хорош, как Tarsnap, но всё равно будет лучше PGP.
Нужны офлайновые бэкапы? Используйте шифрование образов дисков; оно встроено в современные версии Windows, Linux и macOS. Полное шифрование диска не очень хорошо, но отлично справляется с этой задачей, и оно проще и безопаснее, чем PGP.
Подпись пакетов
Используйте Signify/Minisign. Тед Унангст вам всё расскажет. Этот инструмент используется для подписи пакетов в OpenBSD. Он очень простой и применяет современные подписи. Minisign от Фрэнка Дениса (один из разработчиков libsodium) реализует тот же дизайн в Windows и macOS; у него есть привязки к Go, Rust, Python, Javascript и .NET; он даже совместим с Signify.
Шифрование данных приложений
Используйте libsodium: это универсальная библиотека с интерфейсом, в котором трудно допустить ошибку, а для работы не нужен бинарник.
Шифрование файлов
Это действительно проблема. Если у вас /не/ бэкап, /не/ архив для долгосрочного хранения в офлайне, /не/ шифрование файла для передачи и /не/ шифрование виртуальных дисков, которые вы монтируете/отмонтируете по мере необходимости, то нет ни одного хорошего инструмента, чтобы зашифровать файлы. Для других целей Филиппо Вальсорда разрабатывает инструмент age, он кажется многообещающим, но пока не готов.
Надеюсь, ясно, что это довольно узкий случай использования. Мы работаем в области безопасности программного обеспечения и обрабатываем конфиденциальные данные, включая отчёты об ошибках (ещё один очень распространённый случай, когда кричат «Нам нужен PGP!»), но почти никогда не используем PGP.
Комментарии (61)
E2v
21.07.2019 20:35Очень интересно. И полезно. Особенно про отсутствие в достаточной мере доверенного средства просто зашифровать файл (предпоследний абзац).
a0fs
21.07.2019 20:57+2Что-то в последнее время много наездов на RSA и инструментарий с ним связанный. У моего параноика это вызывает как минимум вопросы, как максимум приступы панических атак…
По статье:
- О громоздкости ключа: да, ключ RSA больше, но не надо его передавать на каждое сообщение, ключ должен быть получен отдельно от сообщения, по другому каналу, желательно кардинально другому. Иначе это не безопасность а фикция. Да, подписи им сделанные тоже не маленькие, ну так можно не использовать длинный ключ, ограничится на 2 кбита. Для передачи чего-то типа «Привет, Вася, пошли на рыбалку» этого вполне хватит. Всё равно не успеют разгрызть до того, пока не высохнет засоленная рыба, которую на той рыбалке наловили....
- Forward secrecy: я очень хочу посмотреть на реализацию его в инструменте не предполагающем прямое создание сессии и обмен «on-line», да так, чтобы сие не породило миллион возможностей по утечке сессионного ключа.
- Старые шифры: старое здесь не значит плохое. Если шифры создавались во времена, когда люди уже поняли, что машина будет ускорятся, а не во времена 70-х, то он вполне адекватен времени и в гражданском секторе актуален и будет актуален ещё долго. Если мы говорим о попытке предотвратить утечку данных в масштабе времени и ратуем за всё новое, нам ничего не стоит процедуре передачи данных применить несколько шифров на для каждого из слоёв. Особо страшное скопировать в архив, закрыть его любым любимым инструментом, а результат уже закрыть PGP-шкой. В чём проблема?
creker
22.07.2019 02:58Если шифры создавались во времена, когда люди уже поняли, что машина будет ускорятся, а не во времена 70-х, то он вполне адекватен времени и в гражданском секторе актуален и будет актуален ещё долго
3DES тоже получается? И ведь речь не только о шифрах в смысле алгоритмов шифрования. Речь о схемах, режимах, дизайне. Тот же AES имеет тучу режимов и далеко не все из них безопасны. TLS 1.3 вырезал поддержку практически всех, оставив лишь современные AEAD режимы.mpa4b
22.07.2019 17:18А давайте не путать блочные шифры и режимы, в которых они используются. Всяческие режимы ECB, CBC, OFD, CFB, CTR и проч. могут быть нахлобучены на любой блочный шифр.
creker
22.07.2019 23:27А давайте рассуждать не о сферических конях, а все таки об осязаемых вещах. Шифры применяются только в паре с различными режимами, которые, в свою очередь, составляют cipher suite'ы. И, как говорится в статье, тут либо безопасно, либо совместимо.
mpa4b
23.07.2019 17:58В определении режимов использования блочных шифров нигде нет указания на то, что в данном режиме можно применять только какой-то один блочный шифр. Пруф: en.wikipedia.org/wiki/Block_cipher_mode_of_operation. Фраза 'Тот же AES имеет тучу режимов и далеко не все из них безопасны.' относится исключительно к режиму, а не к самому AES. Если в таком же режиме использовать любой другой шифр, безопасности это не добавит. И это проблема именно режима а не самого блочного шифра.
Ну и наконец, причём тут cipher suit'ы из всяких там TLS? Это частные случаи.
Pro-invader
21.07.2019 21:01+1Используйте Signal. Или Wire, или WhatsApp, или какой-то другой безопасный мессенджер на основе протокола Signal.
С каких пор WhatsApp стал безопасным?QREdit
22.07.2019 00:10+3Автору статьи захотелось сделать его безопасным.
Закрытый код, сотрудничество с правительствами, кривая политика конфиденциальности — это ли не признаки настоящей безопасности?SuAlUr
22.07.2019 16:51-1«кривая политика конфиденциальности» не имеет отношения к шифрованию, закрытый код — защита прав на ПО (вы код антивируса Касперского тоже не знаете, как и Windows). «сотрудничество с правительствами» — в каких странах у WhatsApp не работает шифрование?
Blaine_Mono
22.07.2019 17:22Как можно доверяшь шифрование чего либо тому кто не доверяет мне исходный код утилиты для шифрования?
SuAlUr
22.07.2019 20:43Видимо, Microsoft специально включила BitLocker в Windows, чтобы им не пользовались — доверять то шифровальщику нельзя.
reablaz
22.07.2019 23:49Что-то мне подсказывает, что битлокер далёк от настоящего интрумента шифрования. Как то читал, что с использованием битлокера агрейды с перезапуском системы проходят без ввода пароля шифрования. А это намекает на какие-то мастер ключи итп итд.
п.с. виндой не пользуюсь, свечку не держал
Zoomerman
23.07.2019 02:38Видимо, Microsoft специально включила BitLocker в Windows, чтобы им не пользовались
доля правды в ваших словах есть… Windows для США и Windows для остальных — это сильно разные системы.
tmin10
22.07.2019 21:53Можно доверять сторонним аудитам безопасности, наверное. Крупные компании доверяют битлокеру, возможно за этим есть какие-то документы.
darii
22.07.2019 12:14Спасибо за этот комментарий. В этом деле меня сильно удивляет то, что ваш комментарий всего лишь четвертый по счету, т.е. перевод уже был в топе, к этому моменту статью прочли несколько тысяч раз, но почти 2 часа никто не обратил внимание на эту очевидно странную рекомендацию. Причем особенно эта рекомендация режет глаз из-за первого примечания: «first, we wrote this for engineers, not lawyers and activists».
При этом, не поленился проследовать в карму и проплюсовать m1rko за перевод. Несмотря на противоречивые выводы, сам материал действительно редкий, ценный и даёт прекрасную пищу для размышлений. Спасибо за то, что обратили на него внимание русскоязычной аудитории. Но впредь было бы здорово, если бы вы все-таки добавляли «примечания переводчика» при наличии таких поверхностных противоречий в переводимых материалах.
eugenschmidt
21.07.2019 22:25+7О да!
Купил новый телефон. Залогинился в Google. Бац — все приложения, которые были на старом, установились. WhatsApp установился. Захожу. Надо же, все мои сообщения (ага, шифрование, безопасность) — вот они. Даже с позапрошлого телефона. Значит, что? Значит, любой сисадмин Google, имеющий доступ к моему бекапу в облаке, тоже так может, а если не делает, то только оттого, что мои сообщения ему неинтересны…
Signal. Единственный способ верифицировать корреспондента и гарантировать себя от MITM-атаки — встретиться лично и сверить отпечатки. Чем это лучше PGP? Ничем, это даже хуже — в PGP хотя бы есть способ через цепочку верифицировать человека, с которым никогда не пересекался лично.
И прочая, и прочая… Собственно, чего, кроме чуши, можно ожидать от человека, который утверждает, что занимается безопасностью ПО, и при этом не прикасается к PGP? ;-)Siemargl
21.07.2019 23:25+3Чтобы навязать новые псевдошифрованные средства, нужно скомпрометировать репутацию надежных старых.
В этом смысл статьи.
И пожалейте майора, ему же неудобно…
sintech
22.07.2019 00:06+1Кто мешает вашему бекапу лежать на серверах гугл в зашифрованном виде, с ключом в виде вашего пароля или его производных? Понятно, что без E2E всегда будет место где можно перехватить пароль.
Меня вот если честно, больше интересует, что мешает злому сотруднику телеграм внедрить в клиент для андройд код, тупо отправляющий все незашифрованные сообщения на сторонний сервер. Или это невозможно в принципе?eugenschmidt
22.07.2019 00:12+3Если ключ — мой пароль или производная, то при смене пароля все бекапы превратятся в тыкву, чего как показывает практика, не случается. К тому же если ключ — мой пароль или производная (то есть для расшифровки ничего, кроме знания моего пароля и алгоритма, не нужно), то хаемый автором RSA — это на несколько (десятков, если не сотен) порядков более безопасное решение.
А защита от недобросовестных релизеров вообще возможна только одна: сочетание Open Source и Reproducible Builds. Любой другой вариант требует доверия к «сотруднику телеграм», которого, если мы тут про безопасность, быть не может a priori.
yleo
22.07.2019 02:12+2Нет.
Обычно используется другая схема.
Вашим паролем зашифрован другой "настоящий" ключ (обычно достаточно большой), которым зашифрованы данные. При смене пароля достаточно перешифровать этот рабочий ключ, а не все данные.
Аналогично шифруются содержимое дисков. Точнее говоря оттуда и пошло лет 20-30 назад.
eugenschmidt
22.07.2019 06:45Ваша правда, это я не сообразил. Остаётся минус, что вся эта система секьюрна лишь настолько, насколько секьюрен мой пароль от Google…
Кстати, интересно: а если поставить WhatsApp на новый телефон, не импортируя настройки из Google, старые сообщения не будут доступны? Надо потестить…arheops
22.07.2019 15:57Ну так а как вы хотели, любой с вашим паролем от гугла должен же иметь возможность ваши сообщения от гугла почитать, не? Или как доказать, что вы — это вы?
tmin10
22.07.2019 12:29А если я забыл пароль? Т.е. не могу предоставить старый для перешифровки? У гугла восстановление забытого пароля вполне возможно.
yleo
22.07.2019 12:39Не знаю как сейчас у гугла, но (как правило) хранение хешей паролей (включая механизм восстановления) и шифрование файлов обеспечиваются разными подсистемами.
При этом данные шифруются отдельным ключом (или ключами) которые шифруются паролем и перешифровываются при его смене. Это достаточно тривиальный подход, позволяющий не перешифровывать данные при смене пароля.
У гугла может быть иначе. В том числе потому, что почта и файлы индексируются (как минимум) для показа более релевантной рекламы, но не ради восстановления пароля.
TkWT
22.07.2019 13:09в прошлом году после восстановления пароля, гугль показал предупреждение о том что подпись не совпадает и некоторые данные не читабельны. точно не помню но вроде касалось данных автозаполнения, сохраненных паролей и данных приложений. Если нет доступа к синхронизированному до смены пароля пароля устройству — некоторые данные, очевидно, будут утеряны
tmin10
22.07.2019 13:11Да, это протухает хранение паролей в хроме, но файлы на гуглдрайве от сброса пароля не теряются. Бэкапы в облаке скорее всего тоже, можно проверить.
OlegAndr
22.07.2019 18:11kek шифруется паролями пользователей, и дополнительно шифруется паролем сервиса и депонируется в надежном месте. получается по записи на пользователя + запись в архиве. При процедуре сброса паролей он расшифровывается учеткой админа сервиса и перешифировывается на новом пользовательском пароле. Старый — удаляется. Если депонирования не будет, то забытый пароль = потерянные данные.
SuAlUr
22.07.2019 16:46НАДО ЖЕ! А неужели WhatsApp не предупреждает, что данные в облаке «не защищены сквозным шифрованием»?
vsb
22.07.2019 17:04Бэкапы в вотсаппе это опция. Можете не включать. Я, например, не включаю. После переустановки имею абсолютно чистые чаты.
mxms
22.07.2019 00:12+2Собственно, анамнез и диагноз у меня особенных возражений не вызывают.
Переусложнённость и груз наследия PGP, конечно же, не способствуют надёжности. Иллюстрация тех 100500 известных (и стольки же ещё неизвестных публике) способов компрометации есть в приведённой ссылке на "Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels".
Но к назначенному лечению вопросы имеются. Новые шифры, вроде бы, хороши. Но где стандартные протоколы с их использованием, например, для той же электронной почты? Почему Signal-like мессенджеры лучше принимая во вниманию серию скандалов по компрометации их реализаций или, иными словами, наличии тех же проблем что и в статье по взлому OpenPGP / S/MIME. PGP претендует, во многом, универсальную модель применения. Вырисовывается ли столь же универсальная альтернатива и нужна ли она? И проч., проч., проч.OlegAndr
22.07.2019 18:27Вообще утверждение что надежной защиты эл почты не существует и, главное, не должно существовать — достаточно провокационно.
С шифрования сообщений криптография началась. Сказать что это больше не нужно — прямо слишком сильно.mxms
22.07.2019 21:11Я это намеренно упустил что б не уводить в сторону, но вы правы, да — про почту там бред, в общем.
thesame
22.07.2019 00:26Собственно, меня смутило одно утверждение в статье, в самом начале: «программа разработана в 90-е годы, до появления серьёзной современной криптографии». Поэтому пришлось прочитать статью целиком, но ясности так и не добавилось, судя по всему, для автора криптография == алгоритмы шифрования. Так что чтение занимательное, но я бы не стал принимать на веру ни одно утверждение без проверки.
creker
22.07.2019 02:46+1В статье перечисляются шифрование, подпись, аутентификация, генерация ключей и прочее и прочее. Так что криптография тут означает криптографию в ее многочисленных проявлениях.
Zoomerman
22.07.2019 06:36-2Разве технологии уже доросли до возможности расшифровывать PGP в обозримом будущем?
Разве RSA — это не аналог PGP с обрезанной и вынесенной в отдельный процесс аутентификацией?
Да, PGP сложна для новичка. Но на мой взгляд это житейская сложность: чтобы понять, что можно доверять полученному сообщению, нужно проделать определенную цепочку действий. В жизни точно также.
"Информационная война — это целенаправленное обучение врага как снимать панцирь с самого себя" (с) Расторгуев (не певец).
BalinTomsk
22.07.2019 06:47+1Если статья про PGP то не лишне сказать что ее автор тов. Циммерман, ушедший работать в АНБ в 2003 году.
Tufed
22.07.2019 13:36И даже после этого они не нашли ничего лучше, чем дискредитировать PGP в пользу более лояльного протокола. Я не знаю замены PGP по надежности и защищенности. А все описанные проблемы мне смешны, хоть эти статьи и пишутся «спецами по безопасности».
eirnym
22.07.2019 09:50+1VCS, как много в этом слове… Наиболее популярные поддерживают подпись коммитов… GPG. И с реализацией поддержки там свои сложности, с изменением истории там сложности (люди любят менять историю), с проверкой доверия подпсей там тоже не всё просто…
Несколько статей на тему:
Cheater
22.07.2019 10:09+2Краткое содержание:
PGP сложен и нипанятен. Группу экспертов попросили "настроить PGP" (интересно что под этим подразумевается) и они за 2 часа не справились (видимо их отрубили от инета и не дали манов).
MDC: Обратно несовместимая надстройка над PGP обратно несовместима. ШОК.
SKS серверы выдают списки своих пользователей!!1
Нет perfect forward secrecy (единственный вменяемый аргумент)
EFAIL (9000+ раз оцененный как "not a vulnerability" и являющийся багом надстройки над PGP, а не PGP)
Используйте наши проприетарные мессенджеры с привязкой к телефонному номеру и ваша приватность будет гарантирована
Для передачи файлов используйте утилиту на петоне, написанную каким-то хреном с горы
Не используйте email, потому что "даже с PGP это открытый текст по умолчанию" и его может прочесть кто-то другой. Signal, разумеется, этой проблеме не подвержен
Для хранения бэкапов используйте tarsnap — централизованный проприетарный облачный сервис, использующий Amazon S3, это лучше всего для вашей приватности
Реальные проблемы экосистемы PGP наподобие флуда подписями? Мы о них не знаем и не будем упоминать
shadrap
22.07.2019 11:50На PGP все время «гнали» и видимо будут «гнать», потому как персональные секреты в современном мире никому не нравятся) я работал с PGP с середины 90х, на базе ее исходников была написана система шифрования банк-клиент одного довольно крупного банка.
К сожалению я «выпал» из темы и не могу похвастаться знанием современных систем, но идеология работы с дайджестом ключей, наличие нескольких уровней ключей представляется еще современным. Естественно, там есть и были дырки, на базе исходников 95года, которые Циммерман распространял через PGP-сообщество была такая дыра в использовании пары секретных ключей, с одним паблик, что… нам пришлось попотеть серьезно, что б как-то «залепить» эту дырку. Но смысл моего спича в том, что если я закрою файл даже 256-м ключом и привезу ключ другу на флэшке, а не буду забывать его на общедоступных ресурсах, то мы можем рассчитывать на определенный уровень приватности, по крайней мере на время жизни сообщения..)) Т.е главную функцию система до сих пор выполняет. Особенно, если у тебя несколько адресатов а ты для них источник информации и как то нужно ограничить возможность чтения капсулы соседом.
Gurturok
22.07.2019 12:35Неприятный UX
Все понятно, если в тексте появляется UX значит автор хипстер и не может осилить ПО вышедшее больше чем 5 лет назад и хочет все периписать по современным паттернам (которые меняются по нескольку раз в год), причем обязательно на js/go/rust.
Используйте Signal. Или Wire, или WhatsApp, или какой-то другой безопасный мессенджер на основе протокола Signal.
Угу, используйте проприетарное закрытое го-но которое с радостью сольет вас при первой возможности. И ведь мог написать про OMEMO, который является открытой реализацией того самого Signal, но нет только проприетарное го-но.
PAE
22.07.2019 14:14Статья более, чем наполовину, состоит из "Не осилили — значит, не нужно!" и "вот сейчас одной кнопкой можно, не то что в 90-х!"
По делу — отсутствие forward secrecy — действительно, важная проблема, т.к. сейчас хранить "на будущее" всё подряд можно за копейки, когда появился PGP, такой концепции не было.
Если кто знает, какие варианты решения есть — расскажите, пожалуйста.
А вот по поводу таких абзацев:
Используйте Signal. Или Wire, или WhatsApp, или какой-то другой безопасный мессенджер на основе протокола Signal.
Не стал бы доверять статье о безопасности, в которой рекомендуют WhatsApp, после этого момента читать расхотелось.
Serge3leo
22.07.2019 15:27«… Мы изобрели аутентифицированное шифрование 20 лет назад...»
Хм, строго говоря, его изобрели гораздо, гораздо, раньше, а двадцать лет назад вы таки поверили специалистам АНБ (КГБ/ФАПСИ/ФСБ), что шифрование без имитозащиты бессмысленно.
pae174
22.07.2019 15:41+1> сочетание сжатия и шифрования опасно
Кто-нибудь может пояснить, это действительно так?arheops
22.07.2019 16:02+1Зависит от алгоритма шифрования И алгоритма сжатия.
Если у вас алгоритм сжатия всегда дает одинаковый заголовок, то ТЕОРЕТИЧЕСКИ набрав 100тысяч+ файлов одновременно сжатых и зашифрованных(причем они почти все должны быть именно сжаты и вы должны быть в этом уверены, и одним методом), вы можете подобрать ключ основываясь на том, что у вас заголовок сжатых файлов одинаков.
В общем случае вы можете спокойно забить на данную фразу как и почти на все в этой статье от «экспертов».
Собственно после шифрования сжатие вообще не работает, потому обычная практика сжатие и шифрование.
creker
22.07.2019 23:32Да, почитайте про http2/spdy и зачем они выдумали HPACK вместо обычного GZIP для сжатия заголовков http2.github.io/faq/#why-hpack
pae174
23.07.2019 16:01+1CRIME применительно к PGP выглядит совершенно не реалистично.
Применительно к HTTPS — взломщик заставляет браузер жертвы запустить злонамеренный скрипт который делает ОЧЕНЬ БОЛЬШОЕ количество запросов и в каждый запрос к уже имеющимся данным подмешивает множество собственных фрагментов текста. Анализ размера зашифрованного потока позволяет сделать предположение о том, содержится ли в исходном коде подмешанный фрагмент или нет. Предполагается, что скрипт работает достаточно длительное время незаметно для жертвы.
Применять такое для PGP просто бессмысленно. Это же надо как-то заставить юзера запустить PGP и вместо шифрования одного письма зашифровать и отправить несколько миллионов писем в каждом из которых к исходному тексту будет приписан нужный взломщику фрагмент. Сделать такое можно только затроянив машины жертвы целиком. А если машину жертвы затроянили то вся эта возня с алгоритмами сжатия становится совершенно ненужной.creker
23.07.2019 21:51-1Кажущаяся нереалистичность атаки не повод ее игнорировать. Каждый раз, когда ты думаешь, что что-то невозможно, находится тот, кто это сделает. Тем более что неизвестно, что именно автор имел ввиду. CRIME просто вспомнился сразу.
Darkhon
22.07.2019 21:15Ключ signify сгенерирован передовым алгоритмом Ed25519, а PGP — более слабым RSA.
GnuPG уже довольно давно поддерживает алгоритм Ed25519.
pal666
23.07.2019 05:32совет использовать либсодиум применим только если вы отказываетесь от клиентов, которым нужен фипс
pishutin84
Что использовать для создания шифрованных контейнеров причём ключём, чтобы был один ключ на несколько контейнеров причём под Windows10?
Сейчас стоит Encryption Desktop Professional 10.4.2 MP2. Причём один раз словил открытый контейнер после включения/перезагрузки. Очевидно связано с тем что 10-ка ложит часть оси в сон для скорости загрузки…
Darkhon
VeraCrypt. Вероятно, это лучшее, что есть для зашифрованных контейнеров под Windows.
tmin10
А не под windows?
Soffort
VeraCrypt есть и под Linux, и под macOS, и под FreeBSD. Заодно решается проблема переноса контейнера из системы в систему.
tmin10
Это понятно, просто автор комментария отдельно выделил Windows и я сделал предположение, что под другие системы есть что-то лучшее.