|
|
|
|
|
by NovemberWhiskey
1515 days ago
|
|
I mean it's worse from several points of view from the best-case implementation, other than just the grossly-insufficient iteration count. First of all, every single devices shares a common, constant salt. Although that doesn't simplify a single instance of an attack on the key-derivation function, it permits the construction of rainbow tables to trade off storage against time and attack all devices simultaneously. Secondly, the key-derivation function has a flawed construction. In PBKDF2, if you need more key bits than the hash function outputs, you repeat the process varying a value that's concatenated to the salt as the initial input. This means the cost to generate a key to test scales with the length of the key. In this implementation, the salt + constant is not actually an input in the hash function at all, but instead XOR'd against the result of the hash. As a result, you get no increase in work factor at all. There are other problems in the implementation of the actual cipher (AES-CTR is malleable, not authenticated; keys longer than 128 bits are only actually using half of the additional key bits - "AES-1024" only uses 576 bits of the generated key) but the KDF is the real problem. |
|