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

Используйте 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 должно по-прежнему производить случайный вывод, если один из входных данных является случайным.

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

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

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

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

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

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

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

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

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

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

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

Идея в том, что вы получаете блок случайности. Один из простых способов сделать это — просто извлечь данные с устройства 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 одноразовых блокнотов.

Вы можете использовать восьмеричный формат, в котором используются цифры 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

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

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

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. Это позволит лучше использовать биты в зашифрованных байтах, поэтому вы потратите очень мало. пробел в этом преобразовании, но ничего не делает для улучшения кодирования на стороне вывода.

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

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

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

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

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

Марк Бауэр, вице-президент по управлению продуктами, защита от напряжения Отправьте сообщение по адресу [email protected], чтобы получить дополнительную информацию, или посетите наш веб-сайт, чтобы получить дополнительную информацию.

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

Самые большие трудности с шифром Фейстеля заключаются в том, чтобы найти функцию, которая обеспечивает хорошее шифрование с разумным количеством раундов, и выяснить, сколько раундов требуется для достижения хорошего шифрования. Если скорость не важна, можно, вероятно, использовать что-то вроде AES для выполнения функции скремблирования (поскольку она не обязательно должна быть биективной, вы можете произвольно дополнять данные перед каждым шагом AES и интерпретировать результат как большое двоичное число по модулю). 100 000 000). Что касается количества патронов, то 10, наверное, мало, а 1000, наверное, избыточно. Я не знаю, какое значение между ними было бы лучшим.

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

Единственный способ избежать этого — использовать шифр STREAM. Используйте 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. В противном случае высока вероятность того, что у вас будут необъективные цифры и уязвимость.

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