Шифрование документа несколькими ключами и привлечение людей к ответственности за эти ключи.


4

Гипотетический здесь. У вас есть высокочувствительный файл, который вы не хотите публиковать никогда, другие люди также не хотят, чтобы он был общедоступным. Чтобы уменьшить вероятность быть убитым, вы публикуете зашифрованную версию файла на bittorrent и предоставляете ключи шифрования доверенным сторонам («держателям ключей») с инструкциями по публикации, если вас убили. Затем вы обнародуете, что ваши опубликованные файлы являются подлинными. (Да, мы говорим о ситуации с Мэннингом.)

Вы хотите избежать возможности того, что один держатель ключа будет скомпрометирован и выполняет следующий набор из трех вещей:

  1. Опубликовать открытый текст документа
  2. Используйте заявление об аутентификации, которое вы опубликовали, чтобы довести до сведения общественности, что открытый текст является подлинным (то есть удалите ваше правдоподобное отрицание)
  3. Оставаться анонимным

Например, вот один из способов сделать это.

  1. Создайте N симметричных ключей, по одному для каждого держателя ключей
  2. Для каждого владельца ключа сделайте копию открытого текста и добавьте к нему «Этот документ был выпущен:» и личность этого владельца ключа
  3. Зашифруйте каждую копию с помощью соответствующего симметричного ключа
  4. Распределить ключи соответственно
  5. Опубликуйте полный файл

Однако это требует N * size_of_plaintextместа. Этот вопрос задает, есть ли более эффективный способ .

Для начала я исследовал gpg-шифрование с несколькими ключами. См. Https://stackoverflow.com/questions/597188/encryption-with-multiple-different-keys (спасибо, @terdon). GPG работает следующим образом:

gpg --encrypt --recipient alice@example.com --recipient bob@example.com doc.txt
  1. GPG выбирает симметричный ключ ( X)
  2. GPG шифрует открытый текст с X
  3. GPG шифрование Xс ключами партии P_alice, P_bob... и Алиса, Боб и т.д. каждый может расшифровать один из них

Это уязвимо для атаки, которую мы хотим избежать:

  1. Боб использует P_bobдля расшифровкиX
  2. Боб публикует Xанонимно
  3. Общественность расшифровывает ваш опубликованный текст с помощью X

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

Возможно, мне следовало добавить к этому вопросу. Но функция, которую я ищу, это ответственность, а не (просто) шифрование.
Уильям Энтрикен

Даунвот отозван, но не могли бы вы отредактировать заголовок (а также вопрос), чтобы уточнить, о чем вы просите?
тердон

Ответы:


3

Вы можете опубликовать подходящий набор криптографических хэшей открытого текста. Например, если опубликовать набор хешей открытого текста [ MD5 , SHA-1-160 , SHA-3-512 , RIPEMD-320 ], то найти любой открытый текст, который одновременно будет соответствовать всем этим хэшам , будет чрезвычайно сложно. Обратите внимание, что такая атака будет значительно сложнее, чем первая или вторая атака с прообразом против любого из задействованных алгоритмов хеширования, поскольку одни и те же данные должны хешировать правильное значение для всех задействованных алгоритмов, иимеет смысл, когда читаешь. Кроме того, из них, согласно Википедии, по крайней мере, SHA-3-512 и RIPEMD-320 в настоящее время, как известно, не имеют каких-либо атак лучше, чем грубая сила, по всему выходному пространству, и в то время как MD5 имеет столкновительную атаку сложности 2 ^ 21, Атаки с прообразом по-прежнему составляют 2 ^ 123, что лишь незначительно менее сложно, чем тотальная атака на полном выходном пространстве 2 ^ 128. (В основном, при столкновительной атаке вы выбираете оба входа и ищете пару разных входов, которые генерируют идентичные хэши, так что хеш для одного также действителен для другого; атака с прообразом - это когда у вас есть хеш и ищем некоторый ввод, предпочтительно тот, который отличается от исходного ввода, который производит данный хеш.)Эти хэш-значения сами по себе ничего не скажут о незашифрованных данных.

Чтобы еще больше усложнить атаку, вы можете использовать по крайней мере один криптографический алгоритм хеширования, который не основан на конструкции Меркле-Дамгарда с традиционной функцией сжатия (которую перечисленные выше алгоритмы хеширования, возможно, за исключением SHA-3, представляют собой: ) если такой зверь существует; Я не знаю ничего о моей голове, но это не исключает возможности. По-видимому, Keccak / SHA-3 использует дизайн, который, по крайней мере, отличается в некоторых частях, что, по-видимому, делает его хорошим кандидатом для включения в такой набор алгоритмов хеширования.

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

Тем не менее, я не думаю, что вы сможете получить реальную ответственность за то, кто слил ключ дешифрования, не распространяя несколько копий открытого текста с различным шифрованием. Любой множественным ключ схема шифрования , которая не требует отдельного зашифрованного блока данных для каждого блока открытого текста и получателя ключа потребует открытого текста шифруется с помощью данного ключа , K_0который затем , в свою очередь шифруется с каждым из множества ключей реципиентов K_1через K_n, для nполучатели, и это полный набор зашифрованных мастер-ключейE(using K_n)(K_0)включен в зашифрованный текст. (В любое время, когда вы этого не хотите, вам нужно несколько шифротекстов для каждого открытого текста, что представляет собой увеличенную поверхность атаки для злоумышленника, что вызывает беспокойство, если вас зовут Мэннинг или Сноуден.) Следовательно, каждый получатель по необходимости имеет доступ к «мастер» ключ дешифрования K_0, представляющий именно тот сценарий, от которого вы ищете защиту.

О единственном способе, которым я могу придумать, было бы использование алгоритма, подобного DES (читайте дальше, прежде чем понизить этот ответ, потому что я упомянул старого динозавра), который учитывает неиспользуемые биты четности в ключевом материале, устанавливая эти биты уникальными для каждого получателя, и вести записи о том, какие биты четности были для каждого ключевого получателя. (Поскольку вы устанавливаете эти «биты четности» независимо от оставшегося ключевого материала, а не в качестве фактической четности, и эти биты в любом случае не влияют на безопасность, это не приводит к ухудшению безопасности.) Для разумной безопасности используется схема, подобная EDE 3DES.может быть использован. Однако любой, кто имеет доступ к зашифрованному тексту и знает об алгоритме и имеет некоторые знания о криптографии, либо знает, либо может легко узнать об этом свойстве алгоритма шифрования, и может установить биты неиспользуемой / четности на любые значения, которые им нравятся. прежде чем публиковать ключ дешифрования, отмените любые возможные меры ответственности и, возможно, указывайте пальцем на кого-то еще.

Обратите внимание, что ничего из этого не предполагает использования симметричного (или, в этом отношении, асимметричного) шифрования. Это может быть сделано полностью с любым из них, хотя подход только с симметричным алгоритмом, вероятно, намного более практичен, чем подход только с асимметричным алгоритмом. Это легче (в смысле решения ключевой проблемы распределения) и более практичным (с точки зрения, например размер зашифрованного) использовать симметричное шифрование данных , а затем асимметричного шифрования ключей дешифрования - это путь АСИММЕТРИЧЕСКИЙ шифрования обычно делается - но ничто не говорит о том, что вам абсолютно необходимо делать это таким образом, и вам все же нужно каким-то образом доверять открытому ключу, для которого вы шифруете ключ дешифрования.


Хорошо, я признаю, что в настоящее время криптография на самом деле просто симметрична относительно открытого текста и асимметрична против ключей. Но ваше решение определенно креативно и заслуживает доверия. Ура!
Уильям Энтрикен,

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

0

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

Нечто подобное тому, что описано здесь, я полагаю, поскольку вы используете gpg: http://www.tutonics.com/2012/11/gpg-encryption-guide-part-3-digital.html

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

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


Обратите внимание, что «отправитель» - это тот, кто готовит и распространяет зашифрованный файл, а «получатель» - тот, кто получает зашифрованный файл от отправителя. В этом случае получатель, в свою очередь, дешифрует файл и распространяет открытый текст или распространяет ключ для расшифровки зашифрованного текста другим пользователем, а операционному оператору требуется способ выяснить, кто из набора получателей распространил открытый текст или расшифровку. ключ. В этой ситуации подпись бесполезна, поскольку подпись может быть удалена во время расшифровки зашифрованного файла.
CVN

0

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.