| Author |
Message |
|
|
 Posted: Sep 02, 2009 - 10:23 PM |
|
Joined: May 28, 2009
Posts: 82
|
|
I was thinking of making a device for sending text from an unsecured computer back to home.
The idea is it would be a USB device (about the size of a flash drive) that a USB keyboard can plug into, with a digital one time pad saved in the devices memory (reprogrammable from home). You would plug the device into a public PC, then plug their keyboard into that, type out your message into any email system you want and then send it home. A disadvantage is the only feedback you get while typing the message is seeing the encrypted text appearing on the keystrokes.
Then at home after the email is received, the text transferred to a PC that generated the one time pad (which wouldn't be on the net) and decoded.
So the point is to encrypt the text at a hardware level and then sent through the web, over computers that may be key logged.
Is there a product that already does this?
Is there a way of protecting the devices memory so it can only be read in a certain way (once, character by character and then forgotten)?
(This is just tinkering, if i had something like this half the messages would be "remember to buy x" or "feed the cat") |
|
|
| |
|
|
|
|
|
|
Posted: Sep 03, 2009 - 10:11 AM |
|
Joined: Jul 18, 2005
Posts: 62899
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
How do I tell if I've made speelong errors or correct the text I'm typing if my keystrokes are immediately being converted into obscure characters in the email editor?
You have to have some way of typing "in the clear" and then encrypting the text when you are happy. Just as PGP does. However I take your point that a "key grabber" on the PC can then copy the secure text you just typed. So maybe your device needs some kind fo screen. You type/edit on it's "litte screen" then when ready the encrypted text is injected into the PC's keyboard port and off into the body of the email? (I'd also UUencode it or something similar to ensure it will pass through email without character conversion - you cannot guarantee to transport anything outside the ASCII range successfully)
Cliff |
_________________
|
| |
|
|
|
|
|
|
Posted: Sep 03, 2009 - 06:12 PM |
|
Joined: May 28, 2009
Posts: 82
|
|
Thanks for the reply.
Poor feedback is a disadvantage i could live with for the sake of keeping the device small. A small screen would improve the ui, but the device would be more noticeable, and more expensive. If it had the size and functionality of an old USB flash drive it would be more clandestine (i could have a switch to change its mode and the USB input hidden by a cap).
Most people have fairly reasonable typing accuracy (but this is probably degrading as we move from typewriters to keyboards to speech-to-text or whatever comes next). If i kept it small and innocent looking the delete key would have to be replaced by a visible character, making the feedback even worse. You hit delete and another character appears.
To stop character conversion, function keys (escape, tab, F1) could be passed straight through and I would also have to change the one time pads range so they don't appear in the encrypted text. I am pretty sure gmail or other web based text boxes (like what i am typing in now) wouldn't complain if my encrypted text comes out as something like "/n" or "=yend" and if there are some offending character combinations i could not include required characters in the possible encrypted text range.
Example (trying to use 7 bit ascii):
"7" + "H" = "delete"
so then i can't include H in the one time pad, i can replace "H" with "backspace" in the one time pad so the encrypted text comes out as "A" instead of "delete".
...and if it's too hard for me to get my head around then i could send the encrypted text as an attachment, which has its own set of problems and makes the whole thing more clunky. |
|
|
| |
|
|
|
|
|
|
Posted: Sep 03, 2009 - 07:17 PM |
|
Joined: May 28, 2009
Posts: 82
|
|
I guess the question about protecting the devices memory if its stolen is easier than i was thinking, just have a chip read the character, then write an "H" to it. If i encased the whole thing in some resin it should be noticeable if its tampered with.
I still would like to know if there is memory out there that becomes unreadable at a hardware level when it is read. Is there write once read once memory out there? |
|
|
| |
|
|
|
|
|
|
Posted: Sep 03, 2009 - 07:48 PM |
|
Joined: Jul 18, 2005
Posts: 62899
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
Is there write once read once memory out there?
Funny you should mention it - I just had a 4GB CF card suddenly decide it was only going to let 3GB of it be read - I don't think this was by design though  |
_________________
|
| |
|
|
|
|
|
|
Posted: Sep 03, 2009 - 08:17 PM |
|
Joined: Jan 12, 2002
Posts: 7832
Location: Canada
|
|
You won't defeat the key-logger if it is placed before the device, say for example in the keyboards firmware itself.
Ref: http://www.osnews.com/story/21933/Apple ... mware_Hack
To be useable your one time pad will need to work entirely in the printable character domain. [not too hard to do]
Also realize that what the keyboard sends is not an ASCII letter itself, but rather a set of make and break codes that the PC then converts into ASCII. If a key is held, many make codes are sent at the "typematic rate", with only a single break code sent when the key is released. |
|
|
| |
|
|
|
|
|
|
Posted: Sep 03, 2009 - 08:42 PM |
|
Joined: Jun 15, 2008
Posts: 1779
Location: North Carolina USA
|
|
| Save the text on the stick and issue printable characters from a long innocuous message, e.g. "Honey, I'll be late home tonight, got to spend some time in the library." Pass the delete and formatting characters unchanged. When you are done, exclusive or with your pad, insert it into the data area of a large jpeg, and add it as an attachment. You can erase each byte from the pad after reading it. Jpeg images from holiday snaps make great one time pads if you use the just the higher order AC coefficients. Or so it would seem. |
|
|
| |
|
|
|
|
|
|
Posted: Sep 03, 2009 - 09:07 PM |
|
Joined: May 28, 2009
Posts: 82
|
|
|
glitch wrote:
You won't defeat the key-logger if it is placed before the device, say for example in the keyboards firmware itself.
That I didn't think about, and changing the design from a USB keyboard to an older type doesn't fix the problem, there could be a microcontroller keylogging inside any keyboard. I can't think of a solution that doesn't involve carrying a tamper proof keyboard, or smashing every public keyboard you use just in case.
The key being held problem can be solved, have the micro in the device convert the make and break codes to ASCII, encrypt, then convert back to the make and break codes. If the arrow keys go straight through just like tab and function keys the only real use for holding a key would be to purposely "burn" the one time pad, which should be done some other way, another hardware switch on the device. |
|
|
| |
|
|
|
|
|
|
Posted: Sep 03, 2009 - 09:43 PM |
|
Joined: May 28, 2009
Posts: 82
|
|
|
dak664 wrote:
insert it into the data area of a large jpeg, and add it as an attachment. You can erase each byte from the pad after reading it. Jpeg images from holiday snaps make great one time pads if you use the just the higher order AC coefficients. Or so it would seem.
Obfuscation of the encrypted message isn't really what i am going for, and I would guess jpegs that don't look right are flagged just as fast as encrypted looking text in the body of an email - message board.
And public or semi public sources for the one time pad is another idea, maybe have a shared source of large guarantied identical files (the pirate bay for example) that you could run through some program could make a good key out of on both ends. But that's not really what i am looking at either. The pad should be made with hardware generated random numbers and destroyable at the unsecured end. |
|
|
| |
|
|
|
|
|
|
Posted: Sep 03, 2009 - 09:48 PM |
|
Joined: Jun 15, 2008
Posts: 1779
Location: North Carolina USA
|
|
You can use any pad you want, the jpeg is to pass the binary data. You are probably right about any jpeg not looking right being flagged, but a suitable subject for the image might sufficiently randomize the high order AC coefficients.
Of course, by this time all of your emails are going to be scanned anyway  |
|
|
| |
|
|
|
|
|
|
Posted: Sep 03, 2009 - 10:08 PM |
|
Joined: May 28, 2009
Posts: 82
|
|
As much as i love both photography and the whole semester i did on DSP, this sounds like a totally unrelated train of thought. You can't use any pad you want, if i used a pad of all "0"s it wouldn't do anything, but i can see how a camera with the right setup might be used as a random number generator, but there are easier setups.
XORing the data bit by bit might be how modern electric one time pad encryption should work, but not for this application. |
|
|
| |
|
|
|
|
|
|
Posted: Sep 03, 2009 - 11:52 PM |
|
Joined: Jun 15, 2008
Posts: 1779
Location: North Carolina USA
|
|
The jpeg is just one method to pass a binary attachment through MIME so you can send 8 bit data, it is easy to change AC coefficients without invalidating the image. You could pass it as encrypted/binary if such a MIME type existed, and it would not detract from the security. The one-time pad is the security, which you can independently generate with mouse movements and white noise, or using websites based on atomic decay if you are not paranoid. If the pad is random, then even if a large chunk of it is all zeroes, the rest of the message can not be decoded, and hashing it would not change the probable number of consecutive zeroes.
But as is well known, once another message uses the same pad both are easily decoded. |
|
|
| |
|
|
|
|
|
|
Posted: Sep 04, 2009 - 12:41 AM |
|
Joined: May 28, 2009
Posts: 82
|
|
I liked the sound of keeping the encrypted text in the printable character domain (the pad its just saved as a number on the device so it can include the non printables). You wouldn't really need more than 7 bits for text, you could send the message over the net easier (message boards, im, whatever) Like i said sending an attachment is more clunky.
The funny thing is that the parts needed to make something like this are nearly the same as a hardware keylogger would need. 2 USB interfaces, a micro and probably some flash memory.
And I think I am wrong about converting from the lower level keyboard signals to ASCII on the device, that sounds like the silly way of doing it.
I could just have the device handle everything in that form, store the make and break hex codes needed to form one character, combine that with the one time pad (which would have been converted from ASCII to hex before being put on the device), send it off to the PC. Feedback would suffer another blow as a letter wouldn't appear until the keys were released. It looks a little tricky for capital letters but not impossible. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
