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

Im не человек, чтобы сказать Вам о скорости и использовании памяти, но рассмотрении переключателя statment является адской партией, легче понять тогда большое если оператор (особенно 2-3 месяца по линии)

7
задан Qiu 16 April 2015 в 12:37
поделиться

8 ответов

Используйте AES / OFB или любой другой потоковый шифр. Он сгенерирует ключевой поток псевдослучайных битов. Обычно вы выполняете XOR этих битов с открытым текстом. Вместо этого:

For every decimal digit in the plaintext
  Repeat
    Take 4 bits from the keystream
  Until the bits form a number less than 10
  Add this number to the plaintext digit, modulo 10

Чтобы расшифровать, сделайте то же самое, но вместо этого вычтите на последнем шаге.

Я считаю, что это должно быть так же безопасно, как при обычном использовании потокового шифрования. Если последовательность чисел 0-15 неотличима от случайной, подпоследовательность только тех из чисел, которые меньше 10, все равно должны быть случайными. Использование сложения / вычитания вместо XOR должно по-прежнему давать случайный результат, если один из входов является случайным.

7
ответ дан 7 December 2019 в 03:16
поделиться

Одним из потенциальных кандидатов является режим шифрования FFX ​​, который недавно был представлен в NIST.

1
ответ дан 7 December 2019 в 03:16
поделиться

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

Блочный шифр, используемый в потоковом режиме, имеет, по существу, ту же проблему: уникальный вектор инициализации должен быть включен в зашифрованный текст.

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

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

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

1
ответ дан 7 December 2019 в 03:16
поделиться

Вы можете использовать восьмеричный формат, в котором используются цифры 0-7, а три цифры составляют байт. Это не самое экономичное решение, но оно быстрое и простое.

Пример:

Text: Hello world!
Hexadecimal: 48 65 6C 6C 6F 20 77 6F 72 6C 64 21
Octal: 110 145 154 154 157 040 167 157 162 154 144 041

(для ясности между байтами добавлены пробелы)

0
ответ дан 7 December 2019 в 03:16
поделиться

Я не гуру шифрования, но возникает очевидный вопрос: разрешено ли вам использовать шифрование One Time Pad? Затем вы можете просто включить большой блок действительно случайных битов в свою систему декодирования и использовать случайные данные для преобразования десятичных цифр обратимым способом.

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

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

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

РЕДАКТИРОВАТЬ: Хорошо, с небольшим ободрением («вы можете что-то сказать»). расширяю свой ответ.

Идея состоит в том, что вы получаете блок случайности. Один из простых способов сделать это - просто извлечь данные из устройства Linux / dev / random . Теперь я собираюсь предположить, что у нас есть способ найти индекс в этом блоке случайности для каждого сообщения.

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

Вы можете думать об этом как о расположении цифр от 0 до 9 в кольцо. Сложение ведется по кругу по часовой стрелке, а вычитание - против часовой стрелки. Вы можете добавить или вычесть любое число, и это сработает. (Моя первоначальная версия этого ответа предлагала использовать только 3 бита на цифру. Недостаточно, как указано ниже @Baffe Boyois. Спасибо за это исправление.)

Если цифра обычного текста равна 6, а случайное число - 117, тогда: 6 + 117 == 123, по модулю 10 == 3. 3 - 117 == -114, по модулю 10 == 6.

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

Проблема поиска индекса также проста, если сообщение всегда доставляется; у вас может быть согласованная система генерации серии индексов и сказать: «Это четвертое сообщение, которое я получил, поэтому я использую четвертый индекс в серии». В качестве тривиального примера, если это четвертое полученное сообщение, вы можете согласиться использовать значение индекса 16 (4 для четвертого сообщения, умноженное на 4 байта на одноразовый блокнот). Но вы также можете использовать числа из утвержденного генератора псевдослучайных чисел, инициализированы согласованным постоянным значением в качестве начального числа, и тогда вы получите несколько непредсказуемый ряд индексов в пределах блока случайности.

В зависимости от ваших потребностей, у вас может быть действительно большой кусок случайных данных (сотни мегабайт или даже больше). Если вы используете 10 байт в качестве одноразового блокнота и никогда не используете перекрывающиеся или повторно используемые блокноты, то 1 мегабайт случайных данных даст более 100 000 одноразовых блокнотов.

1
ответ дан 7 December 2019 в 03:16
поделиться

Использование только 10 цифр в качестве ввода / вывода совершенно небезопасно. Это настолько небезопасно, что очень вероятно, что оно будет взломано в реальном приложении, поэтому рассмотрите возможность использования как минимум 39 цифр (эквивалент 128 бит). Если вы собираетесь использовать только 10 цифр, нет смысла использовать AES в этом случае у вас есть шанс изобрести свой собственный (небезопасный) алгоритм.

Единственный способ выйти из этого - использовать СТРИМ-шифр. Используйте 256-битный ключ «SecureKey» и вектор инициализации IV, которые должны быть разными в каждом начале стартового сезона. Переведите это число в 77-значное (десятичное) число и используйте «сложение с переполнением» по модулю 10 с каждой цифрой.

Например

 AES(IV,KEY) =      4534670 //and lot more
 secret_message =   01235
                          + and mod 10 
 ---------------------------------------------
 ciphertext     =   46571 // and you still have 70 for next message

, когда у вас заканчиваются цифры из потокового шифра -> AES (IV, KEY) увеличивают IV и повторить IV = IV + 1

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

Другая проблема также связана с создание потоков. Если вы сгенерировали число, превышающее 10 ^ 77, вам следует отказаться от этого числа, увеличивая IV и попробуйте снова с новым IV. В противном случае высока вероятность того, что у вас будут предвзятые числа и уязвимость.

Также очень вероятно, что в этой схеме есть изъян или он будет в вашей реализации

-1
ответ дан 7 December 2019 в 03:16
поделиться

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

AES (как и большинство алгоритмов шифрования) написан для работы с октетами (то есть 8-битными байтами), и он будет производить 8-битные байты. Как только это будет сделано, преобразование результата для использования только десятичных цифр или значений BCD будет невозможно. Следовательно, ваш единственный выбор - преобразовать ввод из десятичных или двоично-десятичных цифр в то, что заполняет октет как можно более полно. Затем вы можете зашифровать это и, наконец, перекодировать вывод, чтобы использовать только десятичные или двоично-десятичные цифры.

Когда вы конвертируете цифры ASCII для заполнения октетов, он несколько «сжимает» ввод. После этого шифрование даст тот же размер вывода, что и ввод. Вы' Затем я закодирую это, чтобы использовать только десятичные цифры, что расширит его примерно до исходного размера.

Проблема в том, что ни 10, ни 100 - это число, которое вы легко поместите в один байт. Числа от 1 до 100 могут быть закодированы в 7 бит. Таким образом, вы в основном будете рассматривать их как поток битов, размещая их по 7 бит за раз, но вынимая их по 8 бит за раз, чтобы получить байты для шифрования.

Это использует пространство несколько лучше, но это все еще не идеально. 7 бит могут кодировать значения от 0 до 127, а не только от 0 до 99, поэтому, даже если вы будете использовать все 8 бит, вы не будете использовать все возможные комбинации этих 8 бит. Аналогичным образом, в результате один байт превратится в три десятичных цифры (от 0 до 255), что явно занимает немного места. В результате ваш вывод будет немного больше, чем ваш ввод.

Чтобы приблизиться к этому, вы можете сжать ввод с помощью чего-то вроде сжатия Хаффмана или LZ * (или того и другого) перед его шифрованием. Затем вы сделаете примерно то же самое: зашифруете байты и закодируете байты, используя значения от 0 до 9 или от 0 до 99. Это позволит лучше использовать биты в байтах, которые вы зашифровываете, поэтому вы потратите очень мало пространства в этом преобразовании, но ничего не делает для улучшения кодирования на выходной стороне.

0
ответ дан 7 December 2019 в 03:16
поделиться

Для тех, кто сомневается в FFX режиме AES, пожалуйста, не стесняйтесь обращаться ко мне за более подробной информацией. Наша реализация является режимом AES, который эффективно сидит поверх существующих шифров. спецификация с доказательством/проверкой находится на сайте NIST режимов. Режим AES для FFSEM включен в режим FFX.

http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ffx/ffx-spec.pdf

Если он имеет значение, вы также можете напрямую поговорить со службой NIST об их статусе в отношении представления режимов/принятия режимов AES, чтобы ответить на ваш вопрос по FIPS. FFX имеет доказательства безопасности, независимую криптографическую экспертизу и не является "новым шифром". Тем не менее, она основана на методах, которые восходят к более чем 20-летней истории - проверенных методах. В реализации мы можем шифровать данные, сохраняя при этом их длину, структуру, целостность, тип и формат. Например, укажите эксплицитную политику форматирования, что на выходе будет NNN-NNNN.

Таким образом, в качестве режима AES мы можем, например, в мейнфреймовом окружении для реализации, просто использовать нативный процессор AES на z10. Аналогично на открытых системах с HSM устройствами - мы можем сидеть поверх существующей реализации AES.

Format Preserving Encryption (как его часто называют) таким образом уже используется в промышленности и доступен в готовых продуктах и довольно быстро развертывается - уже используется в POS устройствах и т.д., системах платежей, развертываниях на предприятиях и т.п.

Марк Бауэр вице-президент по управлению продукцией Защита от перенапряжения Оставьте записку по адресу info@voltage.com для получения дополнительной информации или посетите наш сайт для получения более подробной информации.

.
0
ответ дан 7 December 2019 в 03:16
поделиться
Другие вопросы по тегам:

Похожие вопросы: