Topic: cancel the post - page 2. (Read 306 times)

I don't think that using any device is needed in this case and there are already some software solutions that encrypt anything you type with your keyboard.
Some of them are included in various antivirus packages and there are separate software options like Ghostpress for example, and for Wireless keyboards there are AES encrypted devices.
Using on-screen virtual keyboards like Oxynger KeyShield or something similar also help to protect from different keylogger attacks.

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.


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.


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.

Interesting.
I have always thought about something similar for my devices.
A very simple solution to this would be to type things with normal keys but represents the matching numbers/symbols/alphabets with different things entirely, written somewhere for your receivers to decrypt.
For example:
"C" key could be represented by "&" (C=&),
 "A" represented by "+" (A=+),
 "T' represented by "#" (T=#), etc

So you have the Word "&+#" as CAT, but you initially send you receiver "&+#"or all other complete words and their corresponding cryptic translations.
This will be more suitable for sending private keys and other short keys/words for your other harmless private stuff. For security reasons, the decryptors would need to be encrypted, saved somewhere immutably before you send to your receivers.

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.

This causes keyboard input latency to change from a few milliseconds to several hundred milliseconds. The delay will be noticeable as if the system was lagging. And this is without even considering decryption time yet.

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.

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.

---

Keyloggers live just after the device driver so an alternate solution could be to restrict programs from reading keyboard input regardless of focused window unless the binary has a good digital signature.

You need the a device to decrypt it. You would copy the text and the device would read it. You would read the unencrypted text on the device's screen

I would compare it to the price of a raspberry pi plus the cable and the screen.  

I think the most concern with this is that the confusion with utilizing it or something.

• Would this be installed or portable?
• Applicable on different OS?
• How does it activate?

These are just some questions that I initially thought of by reading it.

Without the need for a device to decrypt it?

It depends on a lot of things...
^{e.g. Open-source software, the whole process itself [for consumers], how that device is going to look, its price, and a few other things.}

Personally, I'm not going to use something like that on my main computer, unless I fully trust the provider/manufacturer, but I'd probably buy one to test for fun ^{[If the price is right]}.

How much you think that device is going to cost for potential buyers out there?