# Is a Test Vector feature a Security Hole?

I have a system where a block cipher key (likely AES) is entered via a 'command line' over a serial console, probably as hex. The system has no 'print key' feature, so the key is hopefully 'ingest only'.

I was considering offering a 'output of known test vector V with new key K and known/fixed IV is X', where X is printed over the console. This would give the key installer confirmation that the key had been transcribed correctly, since they would compare X with a pre-computed version. V could be e.g. the standard AES test vector 00 01 .. 0F. Its length would be 16 bytes, matching the cipher's block length.

So, although the key itself is not readable from the system, an output that USED the key is, in X. V is then a 'known plaintext'.

Is such a feature a bad idea? Does it allow an adversary, who might snatch the system, to obtain the key any faster than if the feature had not been present?

For now, I don't want to consider any other avenues the attacker might have to physically break into the system, I just want to consider the known plaintext question.

• I wouldn't use a plain SHA256(key) either. You never know when someone is going to decide to use the key for a hash-based KDF… Use something like SHA256("key check value 1:" + key). – Gilles 'SO- stop being evil' Jun 2 at 21:13