Camellia 1.2.0：鍵表中帶有 0 的單詞

測試使用 Camellia 1.2.0原始碼的程式碼，從輸入鍵生成 keyTable 時，使用：

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 歸零。現在我已經將所有字節都設置為 0xFF 並且歸零的字變成了：0xFFFFFFFF。害怕。這些詞（總是相同的）沒有被函式觸及。

嘗試使用標準類型求解。我還切換到 -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 <stdint.h> // 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;

我在這裡上傳了一個最低限度的測試程序。

當 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 密碼（Apache License 2.0）的 OpenSSL 埠沒有這個問題：程序集和c可用。

更新：

我已經將上面的兩個埠與問題中連結的 NTT 程式碼進行了比較，如下所示：

1. 生成一個隨機的 256 位密鑰
2. 生成一個隨機的 16 字節塊
3. 使用 3 個實現中的每一個來加密塊以比較密文

總結：儘管 NTT 實現的 keyTable 中有未使用的單詞，但在測試的所有數百萬個密鑰/塊對中，3 個實現生成的所有密文都匹配。

使固定：

由於它不影響加密/解密，因此該修復僅將 keyTable 大小從 68 個字減少到 64 個字。由於程式碼非常乾淨，並且所有訪問都使用上面的兩個宏執行，因此只需要更改 16 行（僅使用 256 位密鑰測試）：

1. 查找所有訪問索引 24 的宏並將其更改為 1
2. 查找所有訪問索引 32 的宏並將其更改為 24

我已經在上述過程中對此進行了測試。

引用自：https://crypto.stackexchange.com/questions/98904