sorry I was contacted by people interested to produce this device and for now they want me to erase all my answers
Why? bitcointalk.org posts (particularly threads topics with ideas in them such as yours) are NOT eligible for patent protection.
Topic: cancel the post (Read 306 times)
Why? bitcointalk.org posts (particularly threads topics with ideas in them such as yours) are NOT eligible for patent protection.
you guys are funny I come with a specific question but you can't help to assume and judge not even answering
I feel sorry for you eckmar, I answered all your questions and you still can't get a clue or pass your own mental restrictions
You legendary badge won't protect from ridicule lol
I erased some answers because otherwise the idea isn't patentable and I just want someone to build it
I feel sorry for you eckmar, I answered all your questions and you still can't get a clue or pass your own mental restrictions
You legendary badge won't protect from ridicule lol
I erased some answers because otherwise the idea isn't patentable and I just want someone to build it
a device that can encrypt what you type character after character
Um, I fear that such a device's "encryption" will only create permutations (mix up) of the actual printable characters. And I am not convinced it will work properly with unexpectedly large character sets.
Also, if the hacker expects an user types mostly in a certain language, it won't be too difficult to find the key based on what characters come out most often.
a few different people tried to explained why it won't work for different reasons but OP doesn't understand any of the answers. He is obviously not a developer, and doesn't have a technical background. This is just a wild imagination.
I hope that my explanation is simpler
And yeah, it won't work, not like that.
sorry I was contacted by people interested to produce this device and for now they want me to erase all my answers
yeah right...
I thought about a device that can encrypt what you type character after character! You type a character it is encrypted directly between your keyboard and your computer. What you see on your screen is another character.
<>
So even if you have a keylogger malware you can send secure messages.
Are you saying that if I typed "x" that something other than "x" would be displayed? Or would the screen display "x"? <>
So even if you have a keylogger malware you can send secure messages.
If it is the former, you may as well not display anything. And the arguments about the time to decrypt would be moot. If it is the latter, it would not actually prevent keyloggers. Someone with access to your computer would be able to know that you pressed "x". The decryption key would also need to be stored in RAM, so an attacker would be able to obtain the decryption key and decrypt messages. The only thing this setup would protect against would be a device that a keyboard is plugged into that plugs into your computer.
I don't think its any use of explaining that to the OP. If you take a look at the thread, a few different people tried to explained why it won't work for different reasons but OP doesn't understand any of the answers. He is obviously not a developer, and doesn't have a technical background. This is just a wild imagination.
I thought about a device that can encrypt what you type character after character! You type a character it is encrypted directly between your keyboard and your computer. What you see on your screen is another character.
<>
So even if you have a keylogger malware you can send secure messages.
Are you saying that if I typed "x" that something other than "x" would be displayed? Or would the screen display "x"? <>
So even if you have a keylogger malware you can send secure messages.
If it is the former, you may as well not display anything. And the arguments about the time to decrypt would be moot. If it is the latter, it would not actually prevent keyloggers. Someone with access to your computer would be able to know that you pressed "x". The decryption key would also need to be stored in RAM, so an attacker would be able to obtain the decryption key and decrypt messages. The only thing this setup would protect against would be a device that a keyboard is plugged into that plugs into your computer.
sorry I was contacted by people interested to produce this device and for now they want me to erase all my answers
I had an idea about my device: offer plans to build it yourself. Buy your components, and build it. Reading about Anom today makes me upset that simple multiplication on a device could have prevented all this. Seeing also that so much money is put into security... I don't understand why nobody has built such thing yet.
My device has the convenience to work immediately with no previous data/key shared between the protagonists, with an en/decryption key by key (you can chat live and decrypt any word real time). But a scheme with shared data/key and the whole message encrypted and then decrypted is much simpler to realize and as safe (just less cool)
My device has the convenience to work immediately with no previous data/key shared between the protagonists, with an en/decryption key by key (you can chat live and decrypt any word real time). But a scheme with shared data/key and the whole message encrypted and then decrypted is much simpler to realize and as safe (just less cool)
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)
Both generate their own secret and public keys. Then the devices can listen and extract a number from the same source on the internet: like NIST beacon or any blockchain. This is how you can start chatting right away with any one owning the same device.
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.
I had an idea about my device: offer plans to build it yourself. Buy your components, and build it. Reading about Anom today makes me upset that simple multiplication on a device could have prevented all this. Seeing also that so much money is put into security... I don't understand why nobody has built such thing yet.
My device has the convenience to work immediately with no previous data/key shared between the protagonists, with an en/decryption key by key (you can chat live and decrypt any word real time). But a scheme with shared data/key and the whole message encrypted and then decrypted is much simpler to realize and as safe (just less cool)
My device has the convenience to work immediately with no previous data/key shared between the protagonists, with an en/decryption key by key (you can chat live and decrypt any word real time). But a scheme with shared data/key and the whole message encrypted and then decrypted is much simpler to realize and as safe (just less cool)
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)
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.
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.
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.
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)
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.
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
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.
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.
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?any memory in the device could be erased pushing a button, you could also erase all memories but your key
I always prefer any open source wallets instead of closed source devices with buttons for erasing memory.
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.
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.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.
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.
...
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.
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
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.
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.
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.
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.
Jump to: