Camellia 1.2.0:关键字为0的单词

Question

在从输入键生成一个源代码时，测试使用Camellia 1.2.0 C0的代码，使用：

void Camellia_Ekeygen(const int keyBitLength, 
          const unsigned char *rawKey, 
          KEY_TABLE_TYPE keyTable)

输出在同一位置显示几个“零”字。256位的两个随机示例：

E1AE67E4 07AE952B 94B0FCD1 CD366E1C 5160F1A8 45893AE8 0994EC20 1B5782AF

52027468 D2CEEB8F 00000000 00000000 5A44D15D 533F0EF8 E441183F 960616CE
B492E69C C71899DB 1C149A9E DA2EF3F9 C590DF1D 8ECE1AA3 5BF4C76A 517A719B
BA4E6211 083B6502 ABE0D506 6A3C58D4 32B152A6 C7D2AD48 2338FC75 4B1C4805
6FB9B4E4 4E14DA25 46CEF6AA D655F3C1 E89A9073 87CCF090 098D9E8F C73283B7
CD0F4BB9 E166D31C 7EE61ACE 52E97A40 0F5B9E82 4F98AEDE 91D08211 2E660D02
01506F57 40F9E4BA C2AB1164 196A9DE8 6E870140 C0A16094 F462E486 D98FF34F
F8543532 5ACAA32E 0046EFC7 06E9A0B9 42409189 9D9C0A16 EF580EC8 03E52B67
4D99620A B6A40197 3999A1B9 A9B45F27 6AE83BF0 7351AF36 6AEDF2EC 0A050076
B50EBD28 B9A2B34C 00000000 00000000


BE276A07 021C223F 40262C4B 2B07D216 AB51C522 C919C184 BBAD4565 B3050C87

93759D00 1DCE4C1F 00000000 00000000 91C6EBE1 47BE73E0 A1ECCAB9 B997E1E5
DEB11931 C13C15D2 EA9E2B5B 892BC368 BFD5F521 7B61B763 CB8C58B7 0AE271F1
617046B2 5951EB2E 2143C16C 4871D4EA 8AA8E801 3CD1E79E D64B23F5 DA983076
D6232073 5364BDE7 77FFE6AE B967FDE4 FDD26694 1720ECF0 6FC56EEE 3B618822
C46202F4 217DB0B2 A076E26B 23C22170 AD07C5E8 890AE608 EFC78526 F0F62449
7C712F1A D7CC710B C0FDB367 E97D2186 437CA739 F93D0CBF C90FF6E2 C879AA2B
511B3CF8 2E25C89E 7B745E74 CA705CCE 3DFD612D 1BE56472 FA45E7EA 4B3B85B0
95F84DCF 4C14FC95 20310BF7 A353A328 0E505958 A56CB1A1 007D2357 CC0239C8
4EFF9C31 2B9BEF19 00000000 00000000

这是意料之中吗？

说明:上面的“十六进制”转储显示了函数的两个调用。对于每一个keyBitLength设置为256个，较短的序列(适合一行)是一个随机的256位键，下面是函数的输出(复制到keyTable缓冲区)。

另一个测试:在调用函数之前，我对keyTable进行了零化。现在，我设置了所有字节do 0xFF，零字变为:0xFFFFFF。太可怕了。这些词(总是相同的)没有被函数所触及。

尝试使用标准类型解决问题。为了避免任何优化问题，我还转到了-O0编译：

//typedef unsigned int KEY_TABLE_TYPE[CAMELLIA_TABLE_WORD_LEN];
/* u32 must be 32bit word */
//typedef unsigned int u32;
//typedef unsigned char u8;

#include  // this is the only change to the original  code (kept above):
typedef uint32_t KEY_TABLE_TYPE[CAMELLIA_TABLE_WORD_LEN];
typedef uint32_t u32;
typedef uint8_t u8;

我上传了一个最低测试程序这里。

Answer 1

当NTT对此进行调查时，我将此作为“解决方案”发布：

通过对功能的检查

void camellia_setup256(const unsigned char *key, u32 *subkey)

很明显，所有对输出向量‘子键’的访问都是使用宏执行的。

#define CamelliaSubkeyL(INDEX) (subkey[(INDEX)*2])
#define CamelliaSubkeyR(INDEX) (subkey[(INDEX)*2 + 1])

函数中没有对索引1和33的引用。这些索引将写入位置2、3、66和67。这些是测试中没有写出来的确切的4个单词。

Camellia密码的OpenSSL端口(ApacheLicense2.0)没有这个问题：组件和C可用。

更新：

我将以上两个端口与问题中链接的NTT代码进行了比较，如下所示：

1. 生成随机256位密钥
2. 生成一个随机的16字节块
3. 对三个实现中的每一个进行加密，以比较密文。

摘要:尽管NTT实现在keyTable中未使用单词，但在所有测试的数百万密钥/块对中，由3种实现生成的所有密文都匹配。

修正：

由于它不影响加密/解密，所以修复只将keyTable大小从68字减少到64字。由于代码非常干净，所有访问都是用上面的两个宏执行的，因此只需要更改16行(tested只需256个位键)：

1. 查找所有访问索引24的宏并将其更改为1
2. 查找访问索引32的所有宏并将其更改为24。

我在上面描述的过程中对此进行了测试。