В криптографии заполненный однородный случайный блок данных ( PURB) — это дисциплина для зашифрованных форматов данных, разработанная для минимизации непреднамеренной утечки информации либо из метаданных формата шифрования, либо из его общей длины. [1]
При правильном создании содержимое PURB неотличимо от однородной случайной строки битов для любого наблюдателя без соответствующего ключа дешифрования. Таким образом, PURB не допускает утечки информации через заголовки или другие метаданные открытого текста, связанные с форматом зашифрованных данных. Эта практика минимизации утечек «гигиены» контрастирует с традиционными форматами зашифрованных данных, такими как Pretty Good Privacy , которые включают информацию о кодировании метаданных открытого текста, такую как приложение, создавшее данные, версию формата данных, количество получателей, для которых зашифрованы данные, идентификаторы или открытые ключи получателей, а также шифры или наборы, которые использовались для шифрования данных. Хотя такие метаданные шифрования считались неконфиденциальными, когда разрабатывались эти зашифрованные форматы, современные методы атак нашли множество способов использовать такие случайно утекшие метаданные для содействия атакам, например, путем идентификации данных, зашифрованных с помощью слабых шифров или устаревших алгоритмов, снятия отпечатков пальцев с приложений для отслеживания пользователей или определения версий программного обеспечения с известными уязвимостями, или методов анализа трафика , таких как идентификация всех пользователей, групп и связанных открытых ключей, участвующих в разговоре, из зашифрованного сообщения, наблюдаемого только между двумя из них.
Кроме того, PURB дополняется до ограниченного набора возможных длин, чтобы минимизировать объем информации, которую зашифрованные данные могут потенциально утекать наблюдателям через свою общую длину. Без дополнения зашифрованные объекты, такие как файлы или битовые строки длиной до бит, могут утекать до бит информации наблюдателю, а именно, количество бит, необходимое для точного представления длины. PURB дополняется до длины, представимой в виде числа с плавающей точкой , мантисса которого не длиннее (т. е. не содержит больше значимых бит), чем его экспонента. Это ограничение ограничивает максимальный объем информации, которую общая длина PURB может утекать в биты, значительное асимптотическое сокращение и наилучшее достижимое в целом для зашифрованных форматов переменной длины, мультипликативные накладные расходы которых ограничены постоянным множителем размера неуказанной полезной нагрузки. Эта асимптотическая утечка такая же, как и та, которую можно было бы получить, дополняя зашифрованные объекты до степени некоторого основания, например, до степени двойки. Однако разрешение некоторых значимых бит мантиссы в представлении длины вместо простого показателя значительно снижает накладные расходы на заполнение. Например, заполнение до следующей степени двойки может наложить до 100% накладных расходов, почти удваивая размер объекта, в то время как заполнение PURB налагает накладные расходы максимум в 12% для небольших строк и постепенно уменьшается (до 6%, 3% и т. д.) по мере увеличения объектов.
Экспериментальные данные показывают, что в наборах данных, содержащих такие объекты, как файлы, пакеты программного обеспечения и онлайн-видео, оставление объектов без дополнения или дополнение их до постоянного размера блока часто делает их однозначно идентифицируемыми только по общей длине. [2] [3] [1] Дополнение объектов до степени двойки или до длины PURB, напротив, гарантирует, что большинство объектов неотличимы по крайней мере от некоторых других объектов и, таким образом, имеют нетривиальный набор анонимности . [1]
Поскольку PURB — это дисциплина для разработки зашифрованных форматов, а не конкретный зашифрованный формат, не существует единого предписанного метода для кодирования или декодирования PURB. Приложения могут использовать любую схему шифрования и кодирования, при условии, что она создает строку битов, которая кажется равномерно случайной для наблюдателя без соответствующего ключа, при условии, что соответствующие предположения о стойкости выполнены, и при условии, что PURB дополнен до одной из допустимых длин. Поэтому правильно закодированные PURB не идентифицируют приложение, которое их создало, в своем зашифрованном тексте. Поэтому приложение для декодирования не может легко определить до расшифровки, был ли PURB зашифрован для этого приложения или его пользователя, кроме как попытавшись расшифровать его с помощью любых доступных ключей дешифрования .
Кодирование и декодирование PURB представляет технические проблемы эффективности, поскольку традиционные методы анализа неприменимы, поскольку PURB по определению не имеет маркеров метаданных , которые традиционный анализатор мог бы использовать для различения структуры PURB перед его расшифровкой. Вместо этого PURB должен быть сначала расшифрован без учета его внутренней структуры, а затем проанализирован только после того, как декодер использовал соответствующий ключ расшифровки, чтобы найти подходящую криптографическую точку входа в PURB.
Кодирование и декодирование PURB, предназначенных для расшифровки несколькими различными получателями, открытыми ключами и/или шифрами, представляет собой дополнительную техническую проблему, поскольку каждый получатель должен найти другую точку входа в отдельном месте в PURB, не перекрывающемся с точками других получателей, но PURB не предоставляет никаких метаданных открытого текста, указывающих позиции этих точек входа или даже их общее количество. В статье, в которой предлагались PURB [1], также были включены алгоритмы для шифрования объектов для нескольких получателей с использованием нескольких наборов шифров. С помощью этих алгоритмов получатели могут находить свои соответствующие точки входа в PURB только с логарифмическим числом пробных расшифровок с использованием криптографии с симметричным ключом и только одной дорогостоящей операцией с открытым ключом на набор шифров.
Третья техническая проблема заключается в представлении криптографического материала с открытым ключом, который необходимо закодировать в каждой точке входа в PURB, например, эфемерного открытого ключа Диффи-Хеллмана, который нужен получателю для получения общего секрета, в кодировке, неотличимой от равномерно случайных битов. Поскольку стандартные кодировки точек эллиптической кривой легко отличимы от случайных битов, например, для этой цели должны использоваться специальные неотличимые алгоритмы кодирования, такие как Elligator [4] и его последователи. [5] [6]
Основное преимущество конфиденциальности, которое предлагают PURB, — это надежная гарантия того, что правильно зашифрованные данные не будут случайно утекать через внутренние метаданные, которые наблюдатели могут легко использовать для выявления слабых мест в данных или программном обеспечении, используемых для их создания, или для идентификации приложения или пользователя, создавшего PURB. Это преимущество конфиденциальности может трансформироваться в преимущество безопасности для данных, зашифрованных слабыми или устаревшими шифрами или программным обеспечением с известными уязвимостями, которые злоумышленник может использовать на основе тривиально наблюдаемой информации, почерпнутой из метаданных открытого текста.
Основным недостатком дисциплины шифрования PURB является сложность кодирования и декодирования, поскольку декодер не может полагаться на обычные методы анализа перед расшифровкой. Вторичным недостатком являются накладные расходы , которые добавляет заполнение, хотя схема заполнения, предложенная для PURB, несет максимум несколько процентов накладных расходов для объектов значительного размера.
Padme padding, предложенный в статье PURB, создает только файлы определенных, очень разных размеров. Таким образом, зашифрованный файл часто может быть идентифицирован как зашифрованный PURB с высокой степенью уверенности, поскольку вероятность того, что любой другой файл будет иметь ровно один из этих размеров padding, очень мала. Другая проблема padding возникает с очень короткими сообщениями, где padding не скрывает эффективно размер содержимого.
Одной из критических замечаний по поводу сложности и накладных расходов на шифрование PURB является то, что контекст , в котором хранится или передается PURB, в любом случае может часто приводить к утечке метаданных о зашифрованном контенте, и такие метаданные находятся вне сферы действия или контроля формата шифрования и, таким образом, не могут быть устранены одним форматом шифрования. Например, выбор приложением или пользователем имени файла и каталога для хранения PURB на диске может указывать на то, что наблюдатель может сделать вывод о приложении, которое, вероятно, создало его, и с какой целью, даже если само содержимое данных PURB этого не делает. Аналогичным образом, шифрование тела электронного письма как PURB вместо традиционного формата PGP или S/MIME может устранить утечку метаданных формата шифрования, но не может предотвратить утечку информации из заголовков открытого текста электронного письма или из хостов конечных точек и серверов электронной почты, участвующих в обмене. Тем не менее, для ограничения такой утечки контекстных метаданных обычно применяются отдельные, но взаимодополняющие меры, такие как соответствующие соглашения об именовании файлов или использование псевдонимных адресов электронной почты для конфиденциальных сообщений.
