Quote from: Borilla on Today at 06:03:51 PM

Quote from: NotATether on Today at 11:20:20 AM

It would severely slow down keyboard input because the keyboard driver, which is usually small so that it runs and processes character input quickly, now has to do a round of encryption for every character, not to mention that since the data is just a single byte, you end up wasting more time padding a few hundred more zero bytes at the end just so the cipher can parse the input correctly.

It's not doing a round of so called encryption for every character. And yet you can "encrypt" characters one by one as you type.

Lets take AES256 as an example. It can encrypt 256 bytes of data at a time, which translates to 64 characters. But the problem with deferring the encryption until the 64th, or generally the Nth, character is:

1) if you do, then the user will not see any of their input until after the Nth character is typed and they're all encrypted at once. This also introduces a problem of "what if N characters are never typed but less than that, should user feedback wait forever?"
2) if you don't and you just pass the N-1 characters to the user before encrypting them all at once on the Nth char, then those characters may have been intercepted by another listening program.

Quote from: Borilla on Today at 06:03:51 PM

Quote from: NotATether on Today at 11:20:20 AM

Besides, the keyboard input is exposed directly in assembly code immediately after a device interrupt (i.e. you press a key), so the unencrypted value can still be obtained by reading the character from device memory and writing it somewhere else in memory, before the encryption even starts.

I don't understand this sentence. Could you explain?

Your keyboard sends a signal to your CPU when a key is pressed. This signal is processed as an interrupt which means the processor stops everything it's doing and reads the character from the keyboard. All of this is programmed in the code of the operating system you are running, in assembly language. It's not possible to encrypt anything while this assembly code is running because such functions do not exist in assembly.

There is nothing stopping someone from placing assembly code in that position to read the characters to their own memory.

Quote from: Borilla on Today at 06:03:51 PM

Quote from: NotATether on Today at 11:20:20 AM

Not to mention that the keyboard is used as an entropy source so encrypting everything you type isn't possible anyway, without running out of random entropy and then relying on a pseudorandom number generator for encryption instead.

The device would generate random numbers.

Just make sure it's using thermal/acoustic noise for its entropy and not keyboard presses, since lots of entropy is supposed to be gathered before encryption starts.