(Извините, я изначально неправильно прочитал требования, полагая, что это входные данные, которые должны были быть 6 байтов.)
Я не думаю, что вы можете делать именно то, что вы хотите с помощью стандартных криптографических алгоритмов:
- проблема с потоковыми шифрами состоит в том, что стандартные эффективно работают, генерируя поток псевдослучайных битов из ключа и затем XOR, обрабатывая эти биты открытым текстом; фактически это означает, что вы никогда не должны использовать один и тот же поток битов дважды (например, если вы это сделаете, то XOR при использовании двух зашифрованных текстов даст тот же результат, что и XOR соответствующих открытых текстов; и в любом случае с 48 битами возможно только 2 ^ 48 возможных битовые потоки, так что вы можете просто проверить их все грубой силой);
- проблема с блочными шифрами в том, что, насколько я знаю, стандартного не существует, у которого размер блока составляет 48 бит.
Так вот, это не значит, что 48-битный блочный шифр не может быть разработан - и, на самом деле, я осмелюсь сказать, что есть некоторые из них - только то, что ни один из стандартных болотных шифров не прошел годами у криптографического сообщества есть такой размер блока.
Итак, я бы предложил следующие варианты:
- ослабить требование 48-битного зашифрованного текста; например, TripleDES имеет 64-битный размер блока и является «довольно» безопасным (эквивалентно 112-битной безопасности) [*];
- в принципе, вы могли бы реализовать свой собственный блочный шифр с любым размером блока, который вам нужен, придерживаясь как можно ближе к стандартной конструкции, например сеть Фейстеля, следуя некоторым общепринятым принципам проектирования - в качестве отправной точки см. Шнайер, «Прикладная криптография», с. 346ff, «Теория проектирования блочных шифров».
Очевидная проблема с последним вариантом состоит в том, что, хотя стандартные блочные шифры, как правило, основаны на общих общих принципах, они принимают конкретные проектные решения, которые подверглись тщательному анализу; ваш, вероятно, не будет.
Я бы также рекомендовал немного отойти от проблемы (или, возможно, объяснить немного больше, что вы пытаетесь сделать), потому что, похоже, он основан на требованиях, которые обычно идут вразрез с хорошей практикой безопасности (имея такую же Например, открытый текст всегда шифруется до одного и того же зашифрованного текста, чего обычно следует избегать). Таким образом, у вас может быть самый лучший в мире шифр Фейстеля, но вы можете использовать еще одну уязвимость в том, как вы его используете.
[*] TripleDES, как правило, не рекомендуется, потому что AES обеспечивает более высокую безопасность более эффективно (вы можете увидеть некоторые сравнительные тайминги блочных шифров , которые я взял в Java, чтобы увидеть, насколько это плохо). Однако это может не иметь значения в вашем конкретном приложении.
Нет, просто «дополняйте» свои данные некоторыми байтами, которые вам не нужны (но всегда одинаковы, если это ваше требование), чтобы вы достигли размера блока. (Если вы используете соответствующий режим заполнения , тогда это будет сделано за вас.)