I've been trying to understand the crypto layer, and it's a bit of a struggle because I'm trying to learn how it's supposed to work by reading the code, and I keep finding code I want to fix. ansi_cprng.c is the current itch I'm eager to scratch. Other than enough implementation stupidities to make me scream (particularly the "rand_data_valid" variable name which is actually a count of INvalid data, and keeping 5 blocks of state, including sensitive previous output, when only 3 are needed), one thing I can't help noticing is that this is definitely NOT conformant with the X9.17/X9.31 spec. That's because the spec requires a timestamp for each output block to provide additional entropy, and a counter won't cut it. I'm fixing the obvious things, but on this point, I have two choices: 1. Add some comments clarifying that the "Based on" part of the header is anything but a claim of compliance; those specs are for an RNG, while this is a PRNG. And probably delete all the FIPS stuff, as there's no spec to claim compliance with. Or 2. Fix the code to use random_get_entropy() and jiffies for the DT seed vector. In the latter case, I'd have to leave the current deterministic code as an option for self-testing, but I'd drop the recommended seedsize to DEFAULT_PRNG_KSZ + DEFAULT_BLK_SZ (one key and one IV), and have an internal flag indicating whether to use an incrementing DT vector or generate it fresh. If some code (like the current self-test code) provides an extra DEFAULT_BLK_SZ of seed material, it would go into determinsitic mode, but if it's missing, DT would be generated dynamically. But that's a question of design intent, and I can't intuit that from the code. Can someome enlighten me as to which option is preferred? -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
