cancel the post

[Borilla]

 

[1714052990]

1714052990

[1714052990]

1714052990

[SFR10]

The recipient can read the  original message.

Without the need for a device to decrypt it?

I don't know if people would be it interested.

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]}.

I don't want to lose my time building something people won't buy.

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

[crwth]

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.

[Borilla]

The recipient can read the  original message.

Without the need for a device to decrypt it?

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 don't know if people would be it interested.

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]}.

I don't want to lose my time building something people won't buy.

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

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

[NotATether]

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.

[Ucy]

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.

[NotATether]

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.

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.

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.

[dkbit98]

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.

[BrewMaster]

i think it is an overkill and the device has to be really cheap for me to even consider buying it. there are already solutions to achieve better security and protect oneself against different attacks.
considering this is a bitcoin forum the example could be using a cold storage where you only interact with it on an airgap computer. and if people wanted to pay they would pay for a hardware wallet to gain security for their wallets.

[Kong Hey Pakboy]

It's pretty interesting but as long as the encrypted message can't be decrypted by other machines then probably that would be much better, kind of like a one way encryption where only the recipient can open the message. You might to develop a software instead of a device since most things these days are done online.

[anu1908]

You might to develop a software instead of a devuce since.most things these days are done online.

wouldn't that defeat the purpose of protecting the user from keylogger? well, maybe there's no need for a device or a software. the sender and receiver just need to agree with a set of rules for their communication via another channel.

[Borilla]

...

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.

the device is between the keyboard and the computer

you seem to assume how it works

you could just encrypt the whole message in the device and then send the encrypted message but it would not allow you to fill forms or to chat online

[Borilla]

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.

It's for those who don't feel secure about their computers (travelers, paranoiacs...) or need to be 100% sure nobody can read their messages. 

[Kong Hey Pakboy]

You might to develop a software instead of a devuce since.most things these days are done online.

wouldn't that defeat the purpose of protecting the user from keylogger? well, maybe there's no need for a device or a software. the sender and receiver just need to agree with a set of rules for their communication via another channel.

That could be another feature you know, it won't defeat the purpose if it can make your product much more unique than the othere similar products in the market right? A feature that detects keyloggers or a message scrambler so even if there is a keylogger, they wouldn't even have a clue what the user is saying because it is already encrypted.

[dkbit98]

It's for those who don't feel secure about their computers (travelers, paranoiacs...) or need to be 100% sure nobody can read their messages.  

So all of them would have to trust and buy your device that is ''100%'' safe?
It's much easier to use some open source software that would do the same thing than to buy some device that can have backdoors, hidden code and can be affected by supply chain attacks.

[dkbit98]

so you prefer using an open source  soft wallet over a hard wallet?

any memory in the device could be erased pushing a button, you could also erase all memories but your key

Are we now talking about crypto wallets or about your imaginary device used for encrypting keyboards?

I always prefer any open source wallets instead of closed source devices with buttons for erasing memory.

[Kakmakr]

You know what you can develop is something that Encrypt the Private Key when you have to "sweep" it from your Paper wallet to your desktop wallet.    It will be nice if someone will not be able to keylog your Private key, when you are in the process to sweep it from cold storage to your Paper Wallet.

So you can go offline when you "Copy" the Private Key, then this software encrypts it and then you go online again and it is in memory in a encrypted format and once you logged into your Online wallet and you Paste it.. it will decrypt it and insert it in the field to sweep the wallet. 

It is always stressful when you have to sweep a wallet and you do not know if it can be intercepted before you are able to sweep it. 

[Ucy]

You know what you can develop is something that Encrypt the Private Key when you have to "sweep" it from your Paper wallet to your desktop wallet.    It will be nice if someone will not be able to keylog your Private key, when you are in the process to sweep it from cold storage to your Paper Wallet.

So you can go offline when you "Copy" the Private Key, then this software encrypts it and then you go online again and it is in memory in a encrypted format and once you logged into your Online wallet and you Paste it.. it will decrypt it and insert it in the field to sweep the wallet.  

It is always stressful when you have to sweep a wallet and you do not know if it can be intercepted before you are able to sweep it.  

I guess it'd be safer to automatically/manually generate encrypted private keys which can be decrypted with keys you previously generated to use for safe decryption of all your future private keys that are encrypted.
You get the encrypted private keys and decrypt them automatically/manually on very secure devices or on secure physical environments.

This ^ is recommended on well decentralized system (on full node) so that no one ever knows your decryption keys

[Kakmakr]

You know what you can develop is something that Encrypt the Private Key when you have to "sweep" it from your Paper wallet to your desktop wallet.    It will be nice if someone will not be able to keylog your Private key, when you are in the process to sweep it from cold storage to your Paper Wallet.

So you can go offline when you "Copy" the Private Key, then this software encrypts it and then you go online again and it is in memory in a encrypted format and once you logged into your Online wallet and you Paste it.. it will decrypt it and insert it in the field to sweep the wallet.  

It is always stressful when you have to sweep a wallet and you do not know if it can be intercepted before you are able to sweep it.  

I guess it'd be safer to automatically/manually generate encrypted private keys which can be decrypted with keys you previously generated to use for safe decryption of all your future private keys that are encrypted.
You get the encrypted private keys and decrypt them automatically/manually on very secure devices or on secure physical environments.

This ^ is recommended on well decentralized system (on full node) so that no one ever knows your decryption keys

I think you missed the suggestion that I made...

What I would like to see ..is some kind of method that will enable you to transfer a "Private Key" in a encrypted state, from say a air-gapped computer or a Paper wallet to a online wallet. So you generate or scan the "Private Key" on another "offline" computer and then you encrypt that key ..before you transfer it to the online wallet.

So when you paste that information in the "Private Key" field, you press a combination of keys and it will automatically decrypt it and you can simply press enter to sweep the wallet to the online wallet. (Example : Electrum)  

[Borilla]

You know what you can develop is something that Encrypt the Private Key when you have to "sweep" it from your Paper wallet to your desktop wallet.    It will be nice if someone will not be able to keylog your Private key, when you are in the process to sweep it from cold storage to your Paper Wallet.

So you can go offline when you "Copy" the Private Key, then this software encrypts it and then you go online again and it is in memory in a encrypted format and once you logged into your Online wallet and you Paste it.. it will decrypt it and insert it in the field to sweep the wallet.  

It is always stressful when you have to sweep a wallet and you do not know if it can be intercepted before you are able to sweep it.  

I guess it'd be safer to automatically/manually generate encrypted private keys which can be decrypted with keys you previously generated to use for safe decryption of all your future private keys that are encrypted.
You get the encrypted private keys and decrypt them automatically/manually on very secure devices or on secure physical environments.

This ^ is recommended on well decentralized system (on full node) so that no one ever knows your decryption keys

I think you missed the suggestion that I made...

What I would like to see ..is some kind of method that will enable you to transfer a "Private Key" in a encrypted state, from say a air-gapped computer or a Paper wallet to a online wallet. So you generate or scan the "Private Key" on another "offline" computer and then you encrypt that key ..before you transfer it to the online wallet.

So when you paste that information in the "Private Key" field, you press a combination of keys and it will automatically decrypt it and you can simply press enter to sweep the wallet to the online wallet. (Example : Electrum)  

I thought that sweeping private keys meant you sign a transaction that sends all your coins to a new address. Which is safe.

Sending a private key, or even have it on my screen is way to risky for me. But if you had to send something secret , like a key, to an online wallet then this wallet should provide their public key so you can have a secure communication.