This is a hypothetical key-logger defeat. To test the protocol, consider any keylogger to be an intelligent M(an) I(n) the M(iddle.)
Proprietary keyboard that can
- track and use as many session keys as active secure applications.
- execute a Diffie-Hellman key exchange (with 64 bit arithmetic, to practically accommodate near term advances in computing.)
- calculate a computationally complex, standardized hash
- Applications compiled such that: focus kicks off a windows “event” to decrypt stream encrypted data from keyboard.
- A stream cipher with a large periodicity and good unicity distance.
When secure application A opens, it executes a Diffie-Hellman key exchange to negotiate a session key, using SSL.
Keyboard documents key for transmission to application A, and opens a data-stream for that application. When OS focus value shifts to another application, keyboard receives a request from the other application, and proceeds until returning to prior secure application A.
Upon resuming communications with application A, keyboard accepts the request for data from application A. This request is only intelligible using the session key. The session key hashed a large number of times, will do to embody and certify the request. Repetitive hashing does not add cryptographic entropy to the data, but it ensures that an intelligent MIM would need noticeable CPU resources, and wall time, to attempt a brute force deception of the keyboard.
If any characters are missed, the stream cipher fails, and presumably this is evident to the operator.
Periodicity of the chosen stream cipher should be large enough to compensate for the small vocabulary of transmissions – 26 to 255 characters.
This is hypothetical. It might only be useful to governments on workstations within a Faraday cage. A passive key-logger would collect an exhaustive tabulation of enciphered text, publicly exchanged Diffie-Hellman values (not useful for key data) and hashed session keys.