Как можно создать безопасную и самоуничтожающуюся электронную почту?

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

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

Шифрование, в обычном смысле этого слова, вводит в вашу систему части, которые трудно понять и, следовательно, трудно проверить. (подумайте о типичном волшебстве openssl, которое все просто выполняют, но 99% людей действительно понимают; если бы какой-то шаг X в HOWTO сказал бы «теперь перейдите на сайт X и загрузите *.cer *.pem и *.csr», чтобы проверить шаги от 1 до X-1, я думаю, 1 из 10 человек просто сделает это)

Объединив два наблюдения, я предлагаю безопасную (*) и понятную систему:

Скажем, у вас есть сообщение M размером 10 кб. Возьмите N раз по 10 КБ из /dev/(u)random, возможно, из аппаратных случайных источников, назовите это от K (0) до K (N-1). Используйте простую операцию xor для вычисления

K(N) = M^K(0)^K(1)^...^K(N-1)

сейчас по определению

M = K(0)^K(1)^...^K(N)

то есть, чтобы понять сообщение, вам нужны все K. Храните K с N разными (более или менее доверенными) сторонами, используя любой протокол, который вам нравится, под случайными 256-битными именами.

Чтобы отправить сообщение, отправьте N ссылок на K.

Чтобы уничтожить сообщение, убедитесь, что удален хотя бы один K.
(*) что касается безопасности, система будет так же безопасна, как самая безопасная сторона, принимающая K.

Не берите фиксированное N, не используйте фиксированное количество K на одном узле для каждого сообщения (т. е. помещайте 0-10 K одного сообщения на один и тот же узел), чтобы усложнить атаку грубой силы, даже для тех, кто иметь доступ ко всем узлам, хранящим ключи.

NB: это, конечно, потребует некоторого дополнительного программного обеспечения, как и любое решение, но сложность необходимых плагинов/инструментов минимальна.

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

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

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

На мой взгляд, GnuPG (или альтернативно S/MIME) следует использовать все время, потому что это также поможет затруднить рассылку спама. Но это, наверное, только одна из моих глупых мечтаний ;)

Есть так много разных способов сделать это, у всех есть свои плюсы и минусы, вам просто нужно выбрать правильный для вашего сценария. Я думаю, что лучший способ сделать это такой же, как и ваше «наиболее распространенное» решение. Доверенной третьей стороной действительно должны быть вы — вы создаете собственный веб-сайт с использованием собственной аутентификации. Тогда вам не придется никому отдавать свои гипотетические ключи.

Вы можете использовать метод двусторонней сертификации, создав собственное клиентское программное обеспечение, которое может читать электронные письма, при этом пользователь имеет собственный сертификат. Лучше быть в безопасности, чем сожалеть!

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

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

Одним из способов может быть использование самоуничтожающегося оборудования, как в «Миссия невыполнима» — оборудование будет отображать сообщение, а затем уничтожать его, но, как вы видите, это тоже неудобно — получатель должен будет понять сообщение, просматривая его. только один раз, что не всегда возможно.

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

Если используется формат HTML, у вас могут быть активы ссылки на сообщение, которые вы можете удалить позже. Если сообщение открыто позже, пользователь должен увидеть неработающие ссылки.

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

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

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

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

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

Поэтому лучшим вариантом, вероятно, будет дождаться Vanish версии 2. С программным обеспечением для обеспечения безопасности развертывание собственного программного обеспечения почти никогда не является хорошей идеей, а получить что-то от авторитетной академической группы безопасности намного безопаснее.

IMO, наиболее практичным решением в этой ситуации является использование клиента обмена мгновенными сообщениями Pidgin с Off-the-Record (без регистрации) и pidgin-encrypt (сквозное асимметричное шифрование). Сообщение будет уничтожено, как только окно чата будет закрыто, и в экстренной ситуации вы можете просто отключить компьютер, чтобы закрыть окно чата.