Пока NTT изучает это, я публикую это как «решение»:
По проверке функции
void camellia_setup256 (const unsigned char *key, u32 *subkey)
понятно, что все обращения к выходному вектору 'подключу' выполняются с помощью макросов
#define CamelliaSubkeyL(INDEX) (подключ[(INDEX)*2])
#define CamelliaSubkeyR(INDEX) (подключ[(INDEX)*2 + 1])
Нигде в функции не найти ссылок на индексы 1 и 33. Эти индексы будут записывать слова в позиции 2, 3, 66 и 67. Это именно те 4 слова, которые не записываются в тестах.
Порт OpenSSL шифра Camellia (лицензия Apache 2.0) не имеет этой проблемы: сборка и с имеется в наличии.
Обновлять:
Я сравнил два приведенных выше порта с кодом из NTT, указанным в вопросе, следующим образом:
- сгенерировать случайный 256-битный ключ
- генерировать случайный 16-байтовый блок
- с каждой из трех реализаций зашифруйте блок, чтобы сравнить зашифрованный текст
Резюме: несмотря на неиспользованные слова в таблице ключей для реализации NTT, во всех миллионах проверенных пар ключ/блок все шифротексты, сгенерированные тремя реализациями, совпали.
Исправить:
Поскольку это не влияет на шифрование/дешифрование, исправление только уменьшает размер таблицы ключей с 68 до 64 слов.Так как код очень чистый и все обращения выполняются с помощью двух макросов выше, нужно изменить только 16 строк (проверено только с 256-битными ключами):
- Найдите все макросы, обращающиеся к индексу 24, и измените его на 1.
- Найдите все макросы, обращающиеся к индексу 32, и измените его на 24.
Я проверил это в процессе, описанном выше.