I have not received any meaningful response to the issue of grandma storing her keys on an encrypted drive. The WG must have considered it the first time it came up, but still I found no real answer in the reflector. It is a real issue for mass market products. Even if only one user out of a thousand makes the mistake to store keys in binary form on the encrypted disk, or the OS swaps critical memory to disk while generating the keys in a PC, or, while for any reason just having loaded them to memory, it is still a huge problem. In a market of 100 million devices it translates to 100,000 possible victims, lawsuits, bad press, etc.
The solution is, of course, trivial: don't let the user know the actual key K2. We don't have to keep it in secret from him, but if it had to be computed from a user supplied K2' key, in a way never happens accidentally, they will not be innocent victims. It has to be in the standard, because of the following two reasons: 1. Implementers don't know how actual attacks work (no real attack is described in the annex or anywhere else in the proposed standard), so they may choose an insecure function, which could a. still leak (like shifting the key) b. can accidentally be executed by the user (like reversing the byte order, which happens if the key is treated as a number and stored in little endian encoding for a big endian module, or vice versa) 2. If we want interoperability, different modules have to use the same function, to arrive at the same encryption from the archived K = {K1,K2'} key. Therefore, replace #8 in the list I sent for our Open Issues spreadsheet, with a requirement of a definition of one or more key transforms F(K1,K2') --> {K1,K2}. We ought to discuss some candidate functions, which are simple, fast, yet secure. Here are some ideas: (1) F(x,y) = {x, x <xor> y} (2) F(x,y) = {x, bit_reverse(y)} [many fix points] (3) F(x,y) = {x, y + magic_constant} [may still leak] (4) F(x,y) = {x, AES(x, y)} [slow] (5) F(x,y) = {x, x (*) y} with Galois product [slow] Any thoughts? Laszlo