If the device is connected to the internet, and is getting keys from internet, that defeats purpose of it. Man in the middle attacks are much simpler to perform than breaking the encryption. I think your imagination got away from you, you need to be more realistic.

How do you plan to accomplish that without key exchange? One of the most important elements of secure communication is key exchange, there are even algorithms developed to do just that. If you are not going to do that, then you must set a pre shared key when you ship this so called device. Even if you don't do that, and want users to generate keys themselves, what are you going to do then? How are you going to input the public key of other party into the device securely? (Assuming you are talking about asymmetric encryption)

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)  

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.

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.

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.

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.

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?

I was in the same boat as yourself Borilla because I've registered using my (paid) VPN provider. Since this is a shared IP probably it ended up in a "evil list" as Royse777 rightfully said.

In my case I had to pay a small BTC fee to an address that I got whenever I logged in. You basically can't do anything until you pay your fee to the address provided. Upon paying if you wait a while the account will automatically be allowed to post/make threads.

Don't be like myself who waited almost 3 years to activate his account ... ((bells) Shame on me (bells)

Are you talking about a new account you created?

Possibly you have evil IP. There is a fee to pay for it to whitelist the IP.

There is a special link which will allow you to bypass the anoying captcha. You will find it once you visit this URL: https://bitcointalk.org/captcha_code.php

Dites moi,
Si je vais sur compound, que je mets X€ de btc en collateral pour pouvoir emprunter 75%*X€ d'usdt que je transforme ensuite en €, on est d'accord que je ne devrai déclarer aux impôts que les remboursements de ce prêt ? Sinon que leur déclarer??

Y en a t il qui ont essayé cette méthode? Avez vous des infos sur ce sujet car ça semble limite limite mais pouvant permettre de bonnes optimisations ...

Are you talking about signing a transaction?


- How bitcoin nodes communicate