Does this project spark your interest?

Become a member to follow this project and don't miss any updates

NSA Away

Increase your privacy and security by exchanging short messages securely. Created by members of hackerspace Sector67.

41 110 108
Enjoy this project?
Share on twitter   Share on Facebook

This project was created on 06/23/2014 and last updated 19 hours ago.

Recent and ongoing disclosures show that our individual privacy has been severely eroded and that we should only expect that trend to continue into the future. While sitting around the common table at Sector67, a group of us recently discussed the idea of this project to protect privacy. The Hackaday Prize provides us a great incentive for us to get working on it now. Any prize proceeds would be donated to Sector67, a 501(c)(3) not for profit corporation in Madison, WI.

Our goal is to create an open source solution that facilitates private communication while being simple and verifiable to the end users. Our initial implementation may not achieve all those goals completely, but will provide practical and useful devices that will facilitate more secure communication and provide a platform for future investigations.

System Design

The implementation consists of two devices:

1) A simple, standalone key generator that generates random key data and writes it to two SD cards simultaneously, thus creating two identical one-time use pads for encrypting future messages. This hardware random number generator can generate random data for other purposes and send it via a USB port.  

Schematics for this device and a bill of materials are provided in the project links.

2) An Android-based encryption device with a camera, display, software keyboard, SD card reader and USB port. All other methods of communication to the device (WiFi, Bluetooth, IR, etc..) are disabled at the hardware level.  This standalone device encrypts and decrypts messages. Incoming encrypted data is read from your PC’s screen via the device’s camera, and with on-device software optical character recognition (OCR) is converted and decrypted using an SD card-stored key. The decrypted message is displayed on the encryption device display. Using a camera to capture the encrypted text from the PC display prevents the PC from retransmitting anything but the encrypted message which is not decryptable by anyone not holding the one-time pad key.  The used portions of the keys are erased on both the sending and receiving ends after use to provide forward secrecy (your message cannot be read by someone later even if they obtain your device).

Our prototype encryption device is implemented using an Android tablet or phone.  Requires specs for the Android device are listed in the components section.  The source code repositories for the Android application are referenced in the links for this project and are hosted on github (see project links).  They are licensed using GPL 3+.  We use several additional open source libraries to provide the complete solution, including Apache Commons Codec and Commons Core (Apache License 2.0) and Tesseract OCR (Apache License 2.0).


Messages to be encrypted are entered by typing on the encryption device's software keyboard and then encrypted using a one-time pad cipher with keys stored on SD cards. The encrypted data is sent off-device by having the encryption device act as a USB HID keyboard on a regular PC and sending simulated keystrokes. The encrypted data is encoded in a simple text format that is human-verifiable. This interface style prevents the encryption device from transmitting any data off the device outside of the HID compliant driver.  The video below introduces the team and describes the usage in more detail:

Example workflow

Before needing to send a private message:

  • Use the dedicated hardware key generator to populate two SD cards with identical one-time pad keys

  • Keep one copy of the key for your self and give the other copy to the message recipient

To send a message:

  • Type a message on the encryption device using the software keyboard

  • Choose the appropriate encryption key from an SD card to encrypt the message.  You would choose a key that you pre-exchanged with the message recipient.
  • The encryption device encrypts the message using that key
  • Start composing an email to the message recipient on your PC and have the cursor active in the message compose window
  • Plug in the encryption device via USB and click send to have the encrypted message typed into your email.  Your encrypted message will be typed into your email message by the encryption device sending keystrokes.

  • Send the email on the PC

To receive a message:

  • Open the email containing the encrypted message on your PC
  • Point the encryption device’s camera at the encrypted message and take a picture of the encrypted message

  • The encryption device performs optical character recognition (OCR) and interprets the data
  • Choose an appropriate key from an SD card to decrypt the message.  You would choose a key that you pre-exchanged with the message sender.
  • The encryption device decrypts the message using that key
  • You read the message displayed on the encryption...
Read more »

  • 1 × 16x2 LCD 3.3V Display for the hardware device
  • 1 × Atmel ATMEGA32U4 Microcontroller that runs the hardware device. Should have Arduino bootloader on it.
  • 2 × SD Card Holder 2 SD card holders allow for making 2 sets of identical SD cards at once.
  • 1 × MicroUSB connector Plugs in to a computer to charge, or to act as a HID keyboard, putting random numbers out .
  • 1 × Android v4 capable device For the prototype, we are running the message entry, message reading, encryption, decryption, OCR and keystroke sending using an Android device. This device should be capable of running Android v4.x and ideally have a camera, USB port and external SD card reader

Project logs
  • Video/code Jam #7

    19 hours ago • 0 comments

    Video code jam #7 wrapped up last night with a flurry of productive activity.  We shot the raw footage we need to edit into the five minute video and worked through a few last-minute integration issues with the USB OTG support and OCR.  There are still plenty of small development tasks, but we are sending messages device-to-device using keys from the hardware generator.  Expect some code cleanup over the next week as well as some additional documentation!

  • Hardware update - practically everything works!

    2 days ago • 0 comments

    Random Number Generator

    I know it's not funny, but the only thing that's NOT working is the hardware random number generator. It turns out my analog-fu and ability to read documentation is lacking. While the current circuit does generate random noise, it's in a very narrow range (20mV peak to peak), and at a random voltage about 1V. I can't do much with it without some amplification and craziness. At least, it'll require a new PCB or some breadboarding with parts I don't have yet. The good news is that I can use the Arduino pseudo RNG TEMPORARILY as a stub until I get real random number generation working. I believe this is completely fair, as I can't have this holding up the rest of the development, and I do have prototypes that show some randomness coming out of my RNG circuit, just not good enough for digital conversion.

    New Part

    We had a discussion about how to get the data from the Android device to the computer. One option was having the Android device flash light, which a photodiode would detect. This turned out to be too slow for reasonable data transmission. We didn't want anything wireless, as that would cancel out the idea of the Android having all wireless completely disabled. We decided to go with USB OTG. But instead of the Android connecting to the computer directly, we wanted it to go through our trusted device. This way only one thing plugs in to the computer. To do this we added an FTDI chip; the FT231RS, which can do USB OTG to serial.

    The serial was then piped into the hardware, and a new firmware mode was added to allow data coming in from the serial to be sent out through the other USB port connected to the computer as a keyboard. This way we can guarantee that no drivers are needed on the computer, and that it will only ever interface as a keyboard to anything; ensuring that data can't flow backwards into our secure device.

    Implementing was a little challenging as I'm essentially out of available pins, and I think there is a conflict with one of the other libraries that prevented SoftwareSerial from working. I eventually rerouted some wires and got Serial1 working, but it was a tough half a day.

    Everything Else Hardware

    Everything else is working well. There was a small change necessary on the hardware to get the write protect detection working on the SD cards. Now the firmware can check on the card presence and the write protect tab to make sure that the cards are present and writable before doing anything.

    The enclosure has been updated as well. It's a little prettier, smoother, curvier, and now black!


    Using the newest version of the SDFatLib ( was a breakthrough. It has support for two cards at once, so I didn't need to rewrite the older SD library. Most of the features are now working completely, and the ones that aren't are not on the critical path for the minimum viable product. In other words, all the stuff that has to work does, and the rest is just nice to have.

    To expand on that, you can now

    • Create duplicate files on two SD cards of user-set size containing random data.
    • Output a given section of a given file from the SD card to the keyboard.
    • Receive data from the USB OTG Android device and print it out to the keyboard.
    • Generate random data and print it to the keyboard.

    Fun things you can do with this device

    Besides its original intention, this hardware will allow you to do all kinds of things. You could write additional code to get it to have more fun features, but consider these options:

    • USB Random Number Generator. These exist already as dongles (, but they're at least $30 for the cheapest I found. NSA-Away can do that and more!
    • USB<->Serial. Essentially two USB->Serial ports on this one device. So many options!
    • SD Card Management. You could copy any file from one to the other, or delete files, or wipe them. Go nuts!
    • Generic Dev Board. It's got a battery, 16x2 LCD,...
    Read more »

  • Code Jam #6

    8 days ago • 0 comments

    We are working furiously toward the final working prototype, with the goal being to get all the necessary footage next Sunday to edit into the 5 minute video.  Significant progress made includes getting each team member on a critical task: OCR integration, USB sending, HID bridge, hardware key generator and video sketch.  

    Kate also created a nice set of icons for the Android app. 

View all 17 project logs


Markus Ottela wrote 16 days ago null point

Interesting. I like how every project that addresses end-point security comes close to one another. I would argue unless you can remove the hardware for wireless connectivity, you can't have certainty it's not leaking the keys, disabling them won't be enough. The OCR+camera should be secure enough but makes real time conversation somewhat tedious. For email purposes this should be convenient.

The main issue is the direct connection of TCB to the network connected computer. You can't be sure exploitation of NSA Away device (=key exfiltration) can not occur during the time the USB port is connected to the computer. As the requirement for bandwith is very low, consider adding "legacy support" for system with RS232 data diode between two 'RS-232 to USB' converters and maybe write a simple program for network connected computer that either simulates a keyboard, or prints the encrypted message, that can then be copied to email/IM application directly. Data diode is patented in US until 2017, but international users could have higher assurance.

Second issue is, how would the project with pre-built HWRNG mitigate the NSA's practice of shipping interdiction? How can customer trust the hardware isn't actually outputting PRNG stream with predetermined seed? This is why Tinfoil Chat was DIY.

You are right about not implementing QR-codes: it's more difficult to verify that no covert channels exist, than it is with OCR.

I'd also reccommend you over-write keys directly after they're used and disable logging by default: that way users have more assurance that already had conversations remain private in case the device is seized.

Message authentication was already discussed but remember also to add padding for messages.


Are you sure? [yes] / [no]

Scott Hasse wrote 16 days ago null point

Thanks for a bunch of great advice. Some thoughts:

Our ultimate goal per this contest is an integrated key management and encryption/decryption device, which would not have wireless capability, so that would mitigate that risk. We are working on a USB serial solution that would basically provide similar assurances to the data diode approach while still remaining a HID device. You'd have to have some trust in that adapter or build it yourself.

Your shipping interdiction concern is also a valid one, and all the specs will be open to maintain a DIY option. In fact that will most likely be the primary way to obtain a device.

Our current implementation overwrites keys after the message has been read or sent, allowing a brief period of re-reading or re-sending in case there are problems. However, you can't leave the "view plaintext message" screen or "send encrypted message" screen without the keys getting overwritten. The key media is definitely a concern as well, even if overwriting is done.

I'll add a project tasks for message padding and disabling logging by default.

Thanks again!


Are you sure? [yes] / [no]

Scott Hasse wrote 16 days ago null point

Also thanks for your work on Tin Foil Chat. We did extensive searching before getting started and didn't come across your project, but you are right the overlap is significant. Your documentation on the concept and implementation are both fantastic and if you're interested in collaborating we are as well.


Are you sure? [yes] / [no]

Jon wrote 19 days ago null point

jpixton the one time pad is the only proven unbreakable cipher as long as the key material stays protected. Theres plenty of projects utilizing public key infrastructures which will work great until quantum computers or new vulnerabilities are available. One Time Pad does not have these issues.

Are you sure? [yes] / [no]

jpixton wrote 24 days ago null point

One time pad is really not suitable for this.

* It fails catastrophically. Under failure, it has no deniability or confidentiality. If you've lost confidentiality, then deniability is a good property to have.
* Your screenshot with a ciphertext and plaintext pair does not seem to have a enough ciphertext expansion to have any authenticity. Does it? If not, what stops $BOOGEYMAN changing your message "I will pay you $100" to "I will pay you $999" by flipping bits in your message in transit?

We have *much* better mainstream crypto than one time pad these days, and you can even entirely avoid NSA influence if you desire.

I like the overall arrangement of the system, though.

Are you sure? [yes] / [no]

Scott Hasse wrote 24 days ago null point

Thanks for the feedback. The screen shot was a mock up. Message authentication can easily be added, and we do plan do that (although not as a priority initially). Of course that can not stop someone from flipping bits in transit but it will detect that it has happened. What currently stops your scenario is them not knowing which bits to flip.

I'm interested to understand more details about your opinion that OTP fails catastrophically and what you would specifically recommend as much better. It seems to me that the main weakness of OTP is if key management is not done properly and all crypto systems suffer that same weakness, with the same catastrophic failure. Keep in mind with a deniable crypto system you would be intentionally giving a false key, but if the real keys are compromised (the same weakness I presume you are saying makes OTP fail catastrophically, but please correct me if I am wrong), then you do not have deniability.

One of our important goals is to have a human-verifiable system, and that is a significant advantage of OTP.

I'm also interested to understand specifically how you would avoid NSA influence but use a mainstream crypto system other than OTP. Given what we know about NSA involvement in crypto system development, those two goals seem mutually exclusive.

In the future it is likely, due to hardware, math and other advancements, that many if not all algorithm-based crypto systems will be readily breakable (see DES for example). Even if using currently deniable crypto systems your messages will be retrospectively vulnerable. To me that seems like a significant problem.

Thanks for clarifying,


Are you sure? [yes] / [no]

Danny wrote a month ago null point

I'm somewhat confused...
There is talk about a one time pad, but it seems that this is re-used?

Then in these comments it seems that a really long pad is generated, and stored on both cards, then thrown away as used.

So if the OTP is 1324534675689780 and a four letter word is sent then the OTP on the senders card becomes.


When the recipient reads that message their used OTP section is also part destroyed.

Cool so far...

What if the message is lost in transit, never delivered, and needs to be re-generated/resent?
or if one email is delayed in a resend queue whilst another is not. then messages are delivered out of order? -and can never be decrypted?

Now the OTP situation looks like this
sender :1324534675689780
send four letter message

recipient: 1324534675689780
never received message.

sender: 534675689780
sends 4 letters again.

recipient: 1324534675689780
Can't decode.

Are you sure? [yes] / [no]

bob baddeley wrote a month ago null point

In the encrypted text that is sent is also sent the offset to use. So you start with 1324534675689780, send a four letter message like "0,XXXX", and the sender's OTP now looks like 0000534675689780. The used OTP section is destroyed, so if the sender's pad was compromised old messages couldn't be decrypted. Now the sender sends another four letters, and the message would be 4,YYYY, indicating that the message should use the 4th character as the offset for the message. So the recipient gets the second message only, and they see 4,YYYY and their pad looks like 1324534675689780. Now not only can they decrypt the second message properly, but they also know that they didn't get a message. After decrypting, they end up with 1324000075689780 (or 0000000075689780 depending on implementation).

Your next question is what happens if they send messages at the same time? It screws with the offseting and the zeroing. But not if they use different directions. So person A starts at the beginning of the file and goes from 0 up, and person B starts at the end of the file and decrements. Eventually they collide somewhere in the middle of the file, and then it's time for a new OTP.

Are you sure? [yes] / [no]

Scott Hasse wrote a month ago null point

To add to what Bob says, the safest is to use two different pads, one for sending from Bob to Alice and one for sending from Alice to Bob. Then there is no possibility that the same pad would inadvertently be re-used, weakening the encryption and also (with re-writing of the used keys with new randomness or zeros) making the messages unreadable.

Are you sure? [yes] / [no]

Arcadia Labs wrote a month ago null point

Hey congratulations for accessing the semi finals ! I have a "similar" project that got to the semifinals also. I'm happy to see some strong interest in privacy, finally :)
Keep up the excellent work

Are you sure? [yes] / [no]

Big Dave wrote a month ago null point

Hey guys, nice project. Mine also uses a one time pad. Check it out here:

Are you sure? [yes] / [no]

Scott Hasse wrote a month ago 1 point

Interesting project, thanks for sharing.

Are you sure? [yes] / [no]

Jon wrote a month ago null point

Check out tin foil chat which is very similar to this project: and definitely read the paper lots of good info.

Are you sure? [yes] / [no]

bob baddeley wrote a month ago null point

Wow, you're right. Thanks for this. It has some great information.

Are you sure? [yes] / [no]

Jon wrote a month ago null point

Very cool idea. Please consider utilizing full disk encryption on the storage cards utilizing AES 256 in case the card was lost or stolen. The problem is since there is no way to securely delete non magnetic storage it will have to stay encrypted. Maybe add the possibility of connecting a keyboard directly to the device to type the password so the pc never gets it?

Are you sure? [yes] / [no]

Scott Hasse wrote a month ago null point

Excellent feedback, thanks! Data is always entered on the device directly (even for instance if we added key encryption), so the password would never be exposed to the PC. Perhaps I'm not understanding your concern?

Are you sure? [yes] / [no]

ArchimedesPi wrote a month ago null point

How'd you get your RNG working? I'd love to know what was wrong with it :) Last I heard ( it was broken ;(

Are you sure? [yes] / [no]

ArchimedesPi wrote a month ago null point

Oops, didn't see that you're (currently) using the pseudorandom generator ;)

Are you sure? [yes] / [no]

Jasmine wrote a month ago -1 point

Hello Scott and NSA Away team. It doesn't look like you've updated your project in the last couple of weeks. Now is the time to add a few more details to give it the best chance of going through to the next round of The Hackaday Prize.

By August 20th you must have the following info on your project page:
- A video. It should be less than 2 minutes long describing your project. Put it on YouTube (or Youku), and add a link to it on your project page. This is done by editing your project (edit link is at the top of your project page) and adding it as an "External Link"
- At least 4 Project Logs
- A system design document
- Links to code repositories, and remember to mention any licenses or permissions needed for your project. For example, if you are using software libraries you need to document that information.

You should also try to highlight how your project is 'Connected' and 'Open' in the details and video.

There are a couple of tutorial video's with more info here:

Good luck!

Are you sure? [yes] / [no]

surubarescu wrote a month ago null point

Nice project. In order to skip the OCR step (if the message length is not very long) you can use some form of 2D encoding [QR code] on the receiving end to allow the arduino device to read the message. Or, you can paste the text into an editor, change the font into "code 39" (there are several fonts that implement this 1D bar code) and read it with the arduino camera. I suppose that this could be done with a optical mouse sensor.

Are you sure? [yes] / [no]

Scott Hasse wrote a month ago null point

Interesting ideas. We've focused on the least common denominator for now with OCR, but the feasible message length with that will probably be less than even with a QR code (although we could get creative with panoramic mode or something like that). There are lots of great things about QR codes (error correcting, parsing libraries, etc.), but for our purposes it does suffer from the lack of being able to be easily verified by a human. I can easily see some sort of bar code encoding as a future extension though.

The mouse sensor is definitely an interesting idea.

Are you sure? [yes] / [no]

surubarescu wrote a month ago null point

It doesn't matter if you cannot read the qr code without a decoder. It's just another link in the path of the message between two devices. If the message is corrupted, not by human reading will see that but by checks done on the device (i suppose that you will encode a check sum). A phone with camera can show you the content of the qr code if you wanna read it, but the message is certified as genuine only when read from the device.
QR standard allows you to break a message into up to 16 sub messages each with his own qr code, and you'll need all of them to get the original info. This also could help by sending the message through several channels (email accounts, blogs, webpages, so on). This feature is called "structured append".

Are you sure? [yes] / [no]

Scott Hasse wrote a month ago null point

Not being able to human-verify the QR code does matter to a small degree in that (for our "ultra-paranoid" use cases) you want to make sure the device has sent your encrypted message and only your encrypted message, no additional metadata. Sending a QR code makes that much more difficult to verify. Watching simulated keystrokes allows you to do that.

Are you sure? [yes] / [no]

Boz wrote 2 months ago null point


Not really my speciality but you can also use any common shared digital for a one time pad, eg a CD, a picture on facebook or even a streaming radio station? Spies used to use pages from books I believe to encode messages which might be easier than taking something with you.

Still thumbs up.

Are you sure? [yes] / [no]

Scott Hasse wrote 2 months ago null point

You are right that things like books can be used as a shared key. However, for a secure one-time pad, the randomness of the key data is very important ( The types of data in books, music, images, etc. are not very random at all, and so would not make a good one-time pad key.

Thanks for the good question and thumbs up!

Are you sure? [yes] / [no]

ipaq3115 wrote 2 months ago null point

This is a cool idea, I'd really like to see done with one device though. Preferably skipping the android phone and using something like OpenMV ( for text recognition. Directly driving a touch screen from any number of Arduino compatible processors is a fairly straight forward task these days and could provide a great UI. It also opens modifying the interface/adding features to anyone familiar to the Arduino environment as opposed to needing to know how to build Android apps.

Maybe an idea for version #2?

Are you sure? [yes] / [no]

Scott Hasse wrote 2 months ago null point

For right now the Android platform makes a great prototyping platform. The team has talked through lots of possible "version 2" options, both in the direction of less things you need to trust (e.g. a simpler platform like what you describe), and in the direction of less paranoia (e.g. a phone app or using GPG keys). There are lots of options, but right now we're focusing on Android to prove the concept.

Thanks for the feedback.

Are you sure? [yes] / [no]

ArchimedesPi wrote 2 months ago null point

An OpenMV is powerful enough to do both encryption/decryption and recognition, as well as providing a UI. I definitely believe that the OpenMV design would be good to consider for v2.

Are you sure? [yes] / [no]

bob baddeley wrote 2 months ago null point

There is a hardware component that is separate from the Android component. We have an ultimate goal of a single device but are making a proof of concept using two separate platforms and splitting up the labor. The hardware component currently in development has an LCD, 4 buttons, 2 SD card slots, a USB HID Keyboard, and a RNG circuit, all built around an Arduino. Eventually it'll get the camera and ability to do it all on one device, but not yet.

Are you sure? [yes] / [no]

ArchimedesPi wrote 3 months ago null point

Currently, you're relying on the HID drivers to be secure and uncompromized. If you turn the paranoia dial to 12 :), there's no reason why the HID driver couldn't do something malicious, like rewriting code or corrupting messages. I can't think of a way to completely separate the computer and encryption device though, any thoughts?


Are you sure? [yes] / [no]

Scott Hasse wrote 3 months ago null point

@ArchimedesPi, very good thought. The threat model for the encryption device definitely includes malicious HID drivers on the target computer. People have gotten Android devices to work directly as a HID device with kernel modifications ( and, which leaves this channel of attack open. However (and to be fair we have not really documented this on the page, only discussed it in our group meetings), to really mitigate the threat of a malicious target computer HID driver a hardware adapter (USB on the Android side to simple USB HID on the PC side) would be needed that eliminates the possibility of any HID attack propagating to the encryption device. We do plan to make a prototype device like this as a part of this project, but it has not been at the top of the priority list yet.

In terms of the HID driver rewriting or corrupting messages, the goal is to keep everything human-verifiable, so that you could directly compare the encrypted message displayed on the device with the keystrokes displayed on the target computer's screen. In theory you could implement a feature re-OCR and verify it before clearing the key used, but we are not implementing that in the prototype.

The attack vector in the other direction is definitely feasible as well and has been demonstrated (compromised Android device attacking the PC). The goal of only attaching to send the keystrokes (and perhaps having the USB HID adapter not able to send any sort of characters outside of printable ASCII) does also mitigate that to some degree, but deserves further thought.

Very insightful comment, thanks. I hope I've captured your concern appropriately, please let me know if not.


Are you sure? [yes] / [no]


[this comment has been deleted]

Scott Hasse wrote 3 months ago null point

Done, thanks!

Are you sure? [yes] / [no]

Adam Fabio wrote 3 months ago null point

Great project Sector67! Thanks for entering The Hackaday Prize! This is a great idea for keeping short communications secure. How capable are android devices at doing OCR without the help of Google on the back end?

Are you sure? [yes] / [no]

Scott Hasse wrote 3 months ago null point

That question has been one of the major technical risks we've been working to iron out. We are using Tesseract, a native open source OCR framework that will run on Android, in a unit test environment to test various configurations. Indications are that it will be basically workable, providing we do several things, including encoding the encrypted message into hexadecimal, separating each byte into its own "word" and constraining Tesseract to only look for hexadecimal characters and those two-character words.

In our unit test environment, adding additional error correcting information allowed for 100% recognition, but the error correction information comes at a cost of not being readily human-verifiable. If you want to check out our Andriod unit test environment, instructions for getting started can be found here:


Are you sure? [yes] / [no]

daytonpid wrote 3 months ago null point

You say that your smartphone can be exploited. Which I completely agree with. Your computer is also easily exploitable. I don't see how this is secure... forgive me if I am wrong. Only in a perfect world trust is kept. What if someone steals one of the cards created and the person with the other card is unaware? Another cool addon would be to convert the message into a picture which has the last 2 bits of the color channel encrypted with the encrypted pad (stenography). Anyways I really like your project guys. Keep it up!

Are you sure? [yes] / [no]

pnovotnak wrote 3 months ago null point

The only time your communications are unencrypted is when they are displayed in the device. When you want to send an encrypted message, you type it with the device- and it acts as a keyboard, typing your encrypted message. Therefore, any time data is in your computer is when it's encrypted.

You're right, if someone stole the card, they'd be able to decrypt old messages. When the device has matured past the initial Android proof-of-concept, and on to a simpler, hand-built device, we will look at securely destroying old data.

You could encrypt the encryption with a key, but it would add complexity, and doesn't fully solve the problem. A key may be cracked, given enough time and resources. A properly implemented one-time pad may not.

Are you sure? [yes] / [no]

Scott Hasse wrote 3 months ago 1 point

Great question, I've updated the Frequently Asked Questions above to include some clarification.

Are you sure? [yes] / [no]

visualkev wrote 3 months ago 1 point

Physical access to the device by wrong doers means nearly all bets are off for security. One has to keep their encryption device locked up or in hand at all times.
The best feature of OTP is that you can and should change keys often.

Are you sure? [yes] / [no]

ArchimedesPi wrote 3 months ago null point

@visualkev: When you encrypt or decrypt a message, the part of the key used is deleted after it's done encrypting/decrypting the message. That means there's perfect forward secrecy too, so after you decrypt/encrypt a message, *no one* can *EVER* get it back - the key's gone on *both cards*.

The description doesn't make this clear.

Are you sure? [yes] / [no]

Scott Hasse wrote 3 months ago null point

@ArchimedesPi: Thanks for the clarification. I've updated the description to make this more clear.

Are you sure? [yes] / [no]

bob baddeley wrote 3 months ago null point

@visualkev: The data is stored on an SD card, so physical access to the device without the SD card isn't a problem. In addition, you can write as big or small an OTP as you want, so if you and the person with whom you are communicating can exchange OTPs often, then you could get away with smaller OTPs. If a long period, then a larger OTP can be generated.

Are you sure? [yes] / [no]