h a l f b a k e r yWe are investigating the problem and will update you shortly.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
Alice wants to get a message to Bob but she doesn't want to put it on the Internet. Too likely to be captured and, even if they can't decrypt the message, they have metadata about who sent to whom, from where and when. Most of that metadata goes out the window if something is dropped in a public mailbox;
after all, there doesn't need to be a return address, so long as the destination address is legit and there's enough postage.
Alice uses an app to write a secure message to Bob. Alice's message is encrypted, using something akin to PGP (create a random symmetric key, use that key to encrypt the message, encrypt the symmetric key with Bob's public key, create a checksum of the whole thing and encrypt it with Alice's private key, mash all of this together into one digital blob of information) and printed to page-size 2D barcodes. After that, Alice folds it up in an envelope (or rolls it and puts it in a tube) and mails it to Bob.
If it is intercepted and copied (appears to be significantly less common when sent via US Snail), decoding the 2D barcode is straightforward but breaking the encryption is CONSIDERABLY less so.
When Bob receives it, he decodes the barcode, uses his private key to decode the symmetric key, decrypts the message and the checksum, then decrypts the checksum with Alice's public key and checks to see if the sent-checksum matches the locally-calculated checksum. If they match, Alice has effectively signed the message: it could only have come from her (otherwise her public key couldn't decrypt it) and Bob can be reasonably certain it hasn't been tampered with (tampering with it would give a different checksum).
Paperback, a tool to "backup" data to page-sized 2D barcodes, talks about being able to put nearly 6 KB of data (uncompressed) into a square inch of space; that's more than a page of typewritten text. Add some compression to the whole thing and a sizable message could be printed on the back of a postcard. Sure, anyone could image the barcode and decode it but they'd get a bunch of gibberish. Just make sure the ink used to print it won't run if it gets wet (avoid Canon and HP inkjet printers). Most 2D barcode tech lets you add some error correction such that a few messed up pixels won't disrupt the message.
Alice and Bob would each need a smartphone / tablet with imager, or PC with scanner, and a printer for this to work. So long as their device rendered the images, just about any printer, even one at the local library, could likely handle the printing (data would already be encrypted before it went to the printer).
Not the fastest medium in the world but you could send stuff internationally for reasonable rates with minimal risk of surveillance. There was a time when I could get letters between Norway and the midwestern USA in 3 days.
[link]
|
|
Nice. Is there a vulnerability though at the sending/receiving ends? So, I understand the point about metadata revealing that Alice has sent a message of some kind to Bob, but in the model you propose there will be evidence on Alices computer that she downloaded Bobs public key and prepared (via Paperback) a message. |
|
|
There would be evidence on the personal devices on each end, sure. The vast majority of online surveillance is just recording / analysis of data passing through the Internet. Getting at the data on the personal devices would require some organization to access said devices, either remotely or physically. |
|
|
That's a fair point and it's easily fixed. |
|
|
Since the app which enables this can read 2D barcodes, it might be sufficient to have Alice and Bob download each other's public keys and print that information in 2D barcode form, then remove all evidence of same from the personal devices. This data would be sufficiently small that it could fit on a business card, maybe even the space of a postage stamp. When Alice wants to send Bob a message, she pulls out a piece of paper with Bob's public key on it and scans / decodes it, without retaining that info on the device. When Bob wants to decode Alice's sent-checksum, he pulls out a piece of paper with Alice's public key on it, etc. That would require an organization to get access to Alice's and Bob's personal effects, which is less likely than remotely-accessing their devices. |
|
|
I mentioned Paperback as an example of how it's currently do-able and what the likely performance could be. I expect the app would have its own code for encoding / decoding 2D barcodes and encryption / decryption. It should be relatively straightforward to have the app retain no data in storage, such that accessing the device would show the app in evidence but provide no history. |
|
| |