Нужен очень быстрый один-к-одному алгоритм, возможно шифрование

Question

Мне нужен очень, очень быстрый один-к-одному алгоритм. Алгоритм не должен быть нерушимым. Достаточно сильной, но молниеносной. Я буду реализовывать это аппаратно. Область тоже вызывает беспокойство, поэтому она не должна использовать слишком много логики.

Это должна быть функция f_N (x), чей вход - это N-разрядное число, а чей вывод - N-разрядное число. N является константой, вероятно, между 20-70. Функция должна быть взаимно-однозначной. (то есть обратимый, что означает, что расшифровка возможна. Скорость дешифрования не имеет значения.)

Мне нужно зашифровать до 3 нс, что составляет около 333 млн входов в секунду. DES, например, делает около 50 Мбит в секунду. Мне нужно 333M входов в секунду.

До сих пор я использовал шифр Фейстеля примерно с 6 раундами. Кажется, это займет около 3 нс.

Предложения

Дополнительные заметки

Были некоторые вопросы, поэтому я объясню. Мне нужно положить ключи в хэш-таблицу. Стандартный метод заключается в хешировании ключа ввода и использовании результата в качестве индекса в таблице. Каждая строка в таблице должна хранить исходный ключ. Теория информации говорит нам, что строки таблицы на самом деле не должны быть такими же широкими, как клавиша ввода, а такими же широкими, как клавиша ввода меньше количество бит в адрес таблицы. Например:

• вход: x (N бит)
• хеш: x% 128 (8 бит)
• верификатор: пол (х / 128) (N-8 бит)

Было бы глупо на процессоре, где целые числа обычно имеют одинаковую ширину, но я делаю это аппаратно.

x% 128 - легко взломать хеш. Фактически, если клавиши ввода отличаются только в первых нескольких битах, вы случайно сломаете хеш. Я хочу хэш, который не будет взломан случайно, и его даже может быть сложно умышленно сломать. Я также попробовал LFSR . LFSR бывают быстрыми, но два LFSR одинаковой длины генерируют результаты хеширования, которые коррелируют линейно. (Если f (x) и g (x) дают одинаковый хеш для двух разных полиномов, f (x + 1) и g (x + 1) легко коррелируют.)

Итак, мне нужна функция с N-битным входом и V-битным, H-битным выходом (V + H = N), где трудно найти два входа длиной N, так что оба будут выдавать один и тот же H. Шифрование подходит для счета в том смысле, что оно оставляет выходной файл той же длины, что и входной, и его трудно повернуть вспять. Может также сработать что-то кроме шифрования, хотя мне кажется, что то, что я хочу, - это почти само определение шифрования.

Извините, что не объяснил все это заранее. Надеюсь, что это проясняет ситуацию.

Answer 1

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

Answer 2

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

Если задержка не так важна, как пропускная способность, есть ли причина, по которой вы не можете использовать стандартный шифр Фейстеля , который, как известно, является безопасным, и вместо того, чтобы иметь полное количество раундов например, как 16 в Blowfish) вывод из комбинационной логики, вставлять регистр между каждым раундом, так что вы конвейер алгоритма шифрования? По существу, для этого потребуется такое же количество оборудования (немного больше, чтобы добавить несколько триггеров для регистров), что и для известного алгоритма безопасного шифрования, но задержка распространения будет только задержкой одного раунда сети Фейстеля + задержка распространения шлепанцы.

Answer 3

Вот некоторые тесты с некоторыми алгоритмами: http://gd.tuwien.ac.at/privacy/crypto/libs/cryptlib/benchmarks.html

Обратите внимание, что эти тесты тестируют реализации алгоритмов, поэтому это может быть не то, что вы ищете.

Answer 4

Я бы порекомендовал моему старому другу алгоритм Tiny Encryption

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

Answer 5

Если вы делаете это аппаратно, почему бы вам просто не использовать стандартный блочный шифр на DSP?

Насколько высококачественные DSP подходят для алгоритмов AES?

Answer 6

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

Примерно самый быстрый аппаратный алгоритм, который я бы назвал "манипулированием", заключается в том, чтобы концептуально обрабатывать ваши входные данные как битовый поток, а XOR - с помощью выходного потока битового криптографически безопасного и восстанавливаемого битового генератора - реконструируемый, если вы хотите расшифровать его. Одним примером, который прост и молниеносен, но сам по себе небезопасен, является регистр сдвига с линейной обратной связью (LFSR). Выберите длительный период (2 ¹²⁸ - 1 или 2 ²⁵⁶ - 1 или что-то подобное). Страница википедии предлагает изменения для повышения безопасности. Вы также можете иногда пытаться (например, один раз каждые M бит, где M = 4096, 16384, 65536 и т. Д.) XORing состояние LFSR с выходом более медленного, но более безопасного потока битов (либо потокового шифра, либо блочного шифра, шифрующего предопределенный набор входных данных, например, инкрементная последовательность или отсроченный моментальный снимок состояния LFSR) - хотя это относится к криптографическому методу «не изобретай сам», идея состоит в том, что известные криптографические методы имели большой количество энергии, потраченное на проверку наличия уязвимостей.

Answer 7

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

64-битный ключ может быть 8-символьным паролем или 8-байтовым хэшем парольной фразы.

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