Какой алгоритм шифрования оптимален для коротких блоков данных (меньше 32 бит)?
Сразу скажу, в криптографии я почти дилетант. Могу применять готовые алгоритмы.
Есть система, в которой некие данные шифруются на сервере а расшифровываются на контроллере Arduino. Зашифрованные данные пользователь вводит в контроллер с цифровой клавиатуры, ввод отображается на 8-разрядном цифровом дисплее. Чтобы не слишком мучить пользователя длину данных желательно ограничить тем же 8 разрядами, что меньше 32 бит. Ключ в данном случае будет секретным и зашитым в контроллер, его длина не слишком критична.
Абсолютное Большинство современных алгоритмов шифрования оперируют 64-битными блоками данных, что слишком много.
Посоветуйте пожалуйста алгоритм с 32-битным или даже меньше блоком и который заведется на Arduino. Или метод, как адаптировать 64-битные алгоритмы под задачу.
Учитывая Ваш ответ про одноразовые действия ниже - те данные, которые зашифровываются - это только команда что-то сделать или у нее есть и какие-то параметры, которые должны быть переданы внутри текущей порции зашифрованных данных ?
Раз пользователь вводит руками, поток данных совсем небольшой. Используйте одноразовые ключи (шифр Вернама). Четырехмегабайтной флешки хватит на миллион блоков. Это два года непрерывной работы, если вводить данные раз в минуту.
Неудачная постановка задачи. Чтобы посоветовать что-то дельное нужна дополнительная информация, как минимум:
- какую цель преследует шифрование?
- как предполагается обрабатывать ошибочные данные? дублированные данные?
- какое состояние (кроме ключа) хранят/могут хранить сервер и контроллер? (например, количество зашифрованных/расшифрованных данных?)
1. Контроллер выполняет определенное действие если в него ввести корректный одноразовый пароль.
2. Нужно обеспечить возможность ввода в контроллер хотя бы ста тысяч одноразовых паролей.
3. Последовательность ввода одноразовых паролей в контроллер может не соответствовать последовательности их выдачи сервером.
4. На ошибочные данные контроллер выдает ошибку. Повтор ввода одноразового пароля - тоже ошибка. Надеюсь правильно понял вопрос про дублирвоание и ошибочные данные.
5. Сервер выдает разные пароли для нескольких разных контроллеров. Помнит кому и когда он выдавал пароли.
6. Контроллер хранит информацию о количестве сработавших ключей. И, очевидно, об уже введенных паролях.
> Контроллер выполняет определенное действие если в него ввести корректный одноразовый пароль
И зашифрованное число определяет, что это за действие, так?
Судя по написанному вам должен подойти любой блочный шифр в потоковом режиме (например, в режиме CTR), но крайне желательно вместе с зашифрованным числом (как вариант -- как часть этого числа, если вам нужны не все его биты) передавать уникальное значение для инициализации дешифровщика.
> На ошибочные данные контроллер выдает ошибку.
Вы будете определить ошибку сами, по расшифрованному 32-битовому значению, или ожидаете, что процедура расшифровки вернёт ошибку? Если второе, расшифровщику определённо нужно больше информации, чем 32 бита.
> Последовательность ввода одноразовых паролей в контроллер может не соответствовать последовательности их выдачи сервером.
> Повтор ввода одноразового пароля - тоже ошибка
Это означает, что для шифрования нельзя использовать количество выданных/принятых паролей.
Это также означает, что вам придётся учитывать сработавшие пароли на контроллере, и вы не сможете делать это нарастающим итогом, т.е. потребуется не меньше 100000 бит non-volatile памяти.
jcmvbkbc:
>>И зашифрованное число определяет, что это за действие, так?
Вообще-то нет. Действие всего одно.
>>Вы будете определить ошибку сами, по расшифрованному 32-битовому значению, или ожидаете, что процедура расшифровки вернёт ошибку?
Расчитываю вставить в сообщение некоторый признак. Если мы его сможем опознать после расшифровки - считаем что расшифровка успешна. Признак этот видимо тоже стоит держать в секрете.
>>потребуется не меньше 100000 бит
Да, видимо без внешней SD-шки не обойтись. Ну тогда можно не ограничиваться 100 000 битов. Но возникает другая проблема - 8 разрядов это 99 миллионов вариантов. Даже при 100 000 одноразовых паролей, одна из каждой тысячи случайных введенных комбинаций будет являться валидным паролем. Это не очень хорошо.
Возможно стоит ввести кроме цифр еще и буквы.
ncix: Использование длинного ключа говорит о более высоких требованиях к стойкости :-) 64/128 - хэширование ключа и XOR данных с хэшем. Либо дописывание данных нулями до 128 бит и применение AES (для 128 битного ключа).
Эм... Поправте меня если не так, у вас данные шифруются на сервере и расшифровываются на контроллере ключем, который там зашит. Получается ключ всегда один и не меняется?
Если не меняется, то от кого вы защищаете зашифрованные данные?
