Simplest effective encryption
May 26, 2020 8:00 AM   Subscribe

I need to create an unbreakable code to protect a document.

Assume:
-- Nothing illegal or violent
-- Must withstand targeted attack
-- One code shared by 2 people
-- No cloud

I would love to DIY a code. I recall reading that one or two of the simplest are virtually unbreakable.

Should that prove too difficult, how secure is a SanDisk encrypted drive?

Solutions appreciated.
posted by LonnieK to Technology (31 answers total) 4 users marked this as a favorite
 
How large is the document, and how cumbersome do you want it to be to decrypt? The simplest answer is an implementation of a one-time pad.
posted by zamboni at 8:07 AM on May 26, 2020 [8 favorites]


More things to consider: How is the document being transferred? Are you sending it once, or will there be multiple documents? How are you exchanging keys?
posted by zamboni at 8:12 AM on May 26, 2020 [2 favorites]


A one time pad with random data is genuinely unbreakable, if your partner is willing to open a terminal and type a few lines and nobody at the post office has intercepted your mail or the message about which cereal box text to use. (On preview, what Zamboni said.)

GPG is pretty good, until quantum computing matures and an entity with big resources focuses on you. Which I'd guess is 15 years off if you're a known human rights advocate and never if you're just an ordinary erson.

I suspect I'm at least 100 million down on the list of people who need to worry, but a SanDisk backdoor isn't terribly unlikely and would make me uncomfortable. A LUKS format encrypted file on reformatted drive, with a pass phrase shared half by phone and half by mail would be my paranoid choice. Still no guarantee. But, pretty good if you're not actually a spy with enemies

But, a physical letter in plain text is worth considering. Most national postal systems have pretty strict regulations. A physical letter and a pad one can buy at the store communicated by phone is better.
posted by eotvos at 8:28 AM on May 26, 2020


one time pad is very simple and genuinely unbreakable but also completely impractical.

Step 1. Generate truly random key data using a real random number generator (note: most software random generators are only psuedo random number generators). You are going to need a lot of key data.

Step 2. Transmit this key data to your confederate in a secure fashion. Like I said, this is going to be a lot of key data.

Step 3. To encrypt your document, take the length of your document and gather the same amount of key data. You then Exclusive OR the contents of your document i.e. the plaintext with the key to produce the ciphertext. You are free now to transmit/store the document.

Step 4. To decrypt your document, perform the same XOR operation with the ciphertext and the key and then you throw away the key and never use it again.

For any non-trivial document (either in size or in frequency of changes) this is cumbersome/impractical.

If you are really serious about repelling a persistent attack, you need to read this report on a journalist who was in contact with Edward Snowden.
posted by mmascolino at 8:56 AM on May 26, 2020 [2 favorites]


Rolling your own encryption will put you about 80 years behind your expert adversaries. It’s way better to use something off the shelf.
posted by sjswitzer at 9:00 AM on May 26, 2020 [30 favorites]


also what sjswitzer said...writing your own encryption routine is the wrong answer 999,999 times out of a 1,000,000.
posted by mmascolino at 9:06 AM on May 26, 2020 [3 favorites]


Without knowing your adversary & threat model, this is impossible to answer.

Some questions:

Who are you protecting this document from? An individual? A company? A nation state?
How long do you want this document to remain secure? A year? Five years? Twenty-five years?
How much key material can you securely exchange with your partner-in-whatever-it-is?
How much key material can you both store securely?
Must the existence of the encrypted document also be secret?

I’m sure I could come up with a few more.
posted by pharm at 9:12 AM on May 26, 2020 [3 favorites]


Oh wait: another one. Do you only care about securing the document in transit, or must it be encrypted whilst at rest at the endpoints?

If the latter, then you need some kind of trusted hardware & that’s a whole other rabbit hole to go down.

Again, without knowing your threat model, it’s impossible to give useful advice.
posted by pharm at 9:14 AM on May 26, 2020 [1 favorite]


One-Time Pad is a good cipher that resists computer attack.

Substituting words or phrases in a private dictionary that only you have is a good code. For example, no computer software can figure out that "suitcase" means beer or that "Aunt Clara" means your puppy dog -- it would take a smart human doing text analysis to figure it out. (Think of all the private jokes you have ever had with friends, and how impenetrable they are to outsiders Who Weren't There.)

You can lose the key to a cipher (or share it!), but private jokes are pretty resistant to that attack.
posted by wenestvedt at 9:39 AM on May 26, 2020


If your adversary is script kiddies, people trying to get the document for business reasons, some random person who dislikes you for some reason, or anyone else with less than state-level crypto, bitlocker with a 256-bit key would be fine. Without several of the world's most powerful publicly-acknowledged computers, it would take someone millions to quadrillions of years to stumble across the correct key.

If your adversary is a state or similarly-equipped criminal enterprise, don't worry about it. They won't try to decrypt it with cryptographic attacks; they'll just beat the shit out of you or your conspirator or otherwise do Bad Stuff to you and/or anyone you care about until you give it up.
posted by GCU Sweet and Full of Grace at 10:37 AM on May 26, 2020 [3 favorites]


Unclear if you are looking for a practical solution, or to experiment with cryptography.

If you want a practical solution that will stand up to reasonably well-resourced adversaries, do not roll your own crypto.

My initial recommendation was going to be OpenSSL in symmetric mode, or GPG for asymmetric encryption, but both of those tools have a fairly steep learning curve and can be insecure if used improperly. They are both still the state of the art in terms of actual cryptography, but neither is close to it for usability.

What I would actually recommend if you need to send a document securely in 2020 is for both you and the recipient to install Signal, and send the document as a file transfer that way. (IIRC there is a 100MB limit for file transfers, but as long as your document is smaller than that, you are good.) Signal uses asymmetric cryptography in a way that's not too dissimilar to GPG, but there's no opportunity to screw it up by forgetting a particular command-line option.
posted by Kadin2048 at 11:06 AM on May 26, 2020 [2 favorites]


You sound like you're more interested in archiving than protection of a document being transmitted.

With this in mind, I suggest using GPG. You can exchange keys openly, and encrypt the document so that it can be opened by either party but no-one else. It's not tied to any particular type of operating system so if you are on windows and your co-conspirator is on mac it's not a problem.

If you go with gpg, practice until you understand how to use it. Be aware that decryption involves both a pass phrase which you need to memorize and a private key which is a file that you need to keep secure. Without both, your original document can't be retrieved.

Going back to your requirements:
-- Nothing illegal or violent check
-- Must withstand targeted attack check
-- One code shared by 2 people can be done but probably makes more sense to encrypt for multiple recipients as I mentioned earlier
-- No cloud check
posted by metadave at 11:21 AM on May 26, 2020


A one time pad is about the only encryption you should be rolling your own of. With time, a birdcage and 10 colour coded ten sided Game Science dice you could generate a pretty lengthy, essentially random (even good like those made by Game Science aren't 100% random) by hand.

Or you could pull scrabble tiles (from a specially prepared set of equal numbers of A-Z) from a bag. You can then ROT13 your pad with the plain text. There is probably some sort of mechanical bias to this process that exposes a weakness to analysis but good luck figuring that out with an attack against the encryption with a moderately short encrypted text.

Obviously you don't want to perform this to encrypt War and Peace or something but a few pages of a letter are very doable.
posted by Mitheral at 11:23 AM on May 26, 2020


If you're looking for unbreakable-by-almost-everyone encryption, and you either need to or would enjoy doing it by hand, then you want Solitaire, created by Bruce Schneier, and publicised in Neal Stephenson's Cryptonomicon. It requires a deck of cards, and you'll need to agree an ordering for the cards via a secure means beforehand. A few weaknesses have been found in it, and it might not be safe any more against a government-level attacker, but it's secure against any normal attacker.

For practical purposes for most people, WhatsApp is the best choice. It's end-to-end encrypted with encryption that's as unbreakable as anything else we know. It has the significant advantage that many, many people are using it so it doesn't stand out as a "weird crypto thing" worthy of further investigation like GPG is. If you don't trust Facebook, then Signal is essentially the same encryption, but it is Open Source and perhaps more trustworthy.
posted by siskin at 11:34 AM on May 26, 2020


People here are not wrong that one time pads are fully secure. As long as you can generate a pad that’s sufficiently random, at least as long as your message text, can transmit and store the pad securely, and no matter what only use it once.

There are so many practical difficulties with all that that true one time pads are used only in very specialized cases.
posted by sjswitzer at 12:32 PM on May 26, 2020 [1 favorite]


Weaknesses have been found in solitaire. I would not regard it as secure against a well resourced attacker.
posted by pharm at 2:18 PM on May 26, 2020


(These days, "a well-resourced attacker" might simply be a CS post-grad with access to AWS & a budget of a few $100. Breaks in cryptography only get better over time, they never get worse.)
posted by pharm at 2:25 PM on May 26, 2020 [1 favorite]


Perhaps you can be a little more specific about what you want to accomplish. Do you want to protect a document being transmitted over an insecure line or protect a document that is on insecure storage (or maybe both or something else altogether)?

Because you ask about a "SanDisk encrypted drive" It sounds to me like you're interested in the insecure storage scenario but some of the answers here are addressing the insecure transmission case.

Please clarify.
posted by metadave at 3:16 PM on May 26, 2020 [1 favorite]


Would be rather useful if you responded to the numerous questions to clarify your inquiry.
posted by Ahmad Khani at 7:06 PM on May 26, 2020


Step 2. Transmit this key data to your confederate in a secure fashion.

Designing a security system by presupposing they existence of another, known-effective security system is cheating.
posted by mhoye at 5:41 AM on May 27, 2020 [1 favorite]


I would love to DIY a code. I recall reading that one or two of the simplest are virtually unbreakable.

Common wisdom in the crypto community is that anyone can design encryption that they don't know how to break themselves.

If what you want is encryption that nobody knows how to break, use any of the standard methods. They're standard because they work.

Lowest-friction practical standard encryption I'm aware of for files at rest involves wrapping them in a password protected 7Z archive, using a long, random, unique-per-file password generated by KeePass and stored inside a KeePass database which is itself protected by a shared, memorized and never written down master passphrase of at least eight words that's only ever communicated face to face and verbally, with adequate attention paid to avoiding eavesdroppers.

The only way even a state-level actor will ever break the encryption on a file stored that way on a USB stick or SD card or similar is via rubber hose cryptanalysis or by compromising the devices the owners use to decrypt it and/or the environment in which they do so while they're doing so.
posted by flabdablet at 6:32 AM on May 27, 2020


Response by poster: OP here -- thanks all for the info.

Here's further detail in answers and a question:

How large is it? How cumbersome can it be?
-- 4k characters. Preference to dencrypt in less than 2 hours.

Who are you protecting this document from?
-- Nation state or business competitor.

How long do you want this document to remain secure?
-- 25 years.

How much key material can you securely exchange with your partner-in-whatever-it-is?
-- I'll remove my partner from the equation. I'll be the only user, no exchange or transmission.

How much key material can you both store securely?
-- Moot for partner. I have plenty of storage, but only ordinary security. Isn't the key meaningless for anyone else?

Must the existence of the encrypted document also be secret?
-- Yes
posted by LonnieK at 5:13 PM on May 27, 2020


Response by poster: OP here.
NOTE CHANGE IN ASSUMPTIONS shown in previous comment:
Not one code shared by 2 people. My eyes only.
posted by LonnieK at 5:17 PM on May 27, 2020


Do you have a reasonable belief that a nation state might be targetting you right now?

If so, you’re going to have to take fairly extreme measures.
posted by pharm at 6:53 AM on May 28, 2020 [2 favorites]


If I had a reasonable belief that a nation state might be targeting me right now, the last thing I would be doing is asking for advice about encryption on a public forum. So I think we can reasonably assume that that's not happening. At least, not yet.

4k characters. Preference to decrypt in less than 2 hours.

2 hours is enough to decrypt hundreds of gigabytes with today's technology, let alone whatever will exist in 25 years, so the time constraint can basically be ignored.

25 years.

This poses problems, not because encryption strength will be inadequate because it won't be, but because keeping any digital information securely stored for 25 years is iffy unless you're making and testing regular copies. So your best bet would be to store your 4k of encrypted stuff in amongst a bunch of something else that you'd be keeping good backups of as a matter of course.

For a document that small, I'd just keep it in my KeePass database as an attachment. This wouldn't make a noticeable difference to the existing size of that database, which is also something I am strongly motivated to keep highly available because it's got secrets in it that I need to use literally every single day; that need also makes my long, randomly machine-generated KeePass master passphrase (which has 280 bits of entropy even before key stretching) stick in my memory.
posted by flabdablet at 8:08 AM on May 28, 2020 [2 favorites]


OP are you looking to keep this digitally or can you dead tree it? Dead trees aren't accidentally available online no matter how compromised your computer might get and storage if printed with a laser printer (ink can fade, laser toner is essentially carbon) is straight forward for your time period.

Given your addendums you need something other than a one time pad because a OTP just moves the problem from keeping a document secure to keeping a pad secure. You need something with a key you can memorize.

This also means you can't guarantee it'll be safe unattended for 25 years. EG: though unlikely a break through in factoring prime numbers could mean RSA becomes useless. There could also be hidden weakness in any encryption scheme that even now might be known to state actors but only come to light to the general public latter. See the NSAs involvement with DES which makes plain that the NSA and IBM knew about differential cryptanalysis 20 years before public researchers. This is also one of the reasons you shouldn't roll you own encryption, it is ridiculously easy to make a non-obvious error (weak S-Boxes in this case) that makes your encrypted text easy to decipher.

If it was me I'd:
  1. Buy a used laptop with cash from a private previously unknown to you party. Remove the hard drive.
  2. Do the same with a printer from someone else. Remove any storage it may contain.
  3. Download a live CD using a public machine, preferably a significant distance from work/home/hangouts. You'll want a version that includes GPG.
  4. Verify the hash using a different machine/location.
  5. Use the above hardware to encryt the text. It would be best if you just typed the info in but using a non-rewritable CD to transfer the information might be safe. The closer you can get the documents to plain text the better. If you are already under suspicion you want to do this someplace you've never been, will never return to, and having nothing close you have owned before or plan to keep afterwards far away from other people. If you can arrange to be dropped off naked in a random field miles from a power line or something that might be good. Memorize the pass phrase. Pass phrase should be generated with something like Diceware at your secure location. Obviously use the physical dice and printed paper method to generate the pass phrase.
  6. Print off the encrypted text. There are trade offs between accessibility and security. Lots of copies will be easier to make accessible and guard against loss but every copy increases the chance the adversary knows an encrypted document exists and that can lead to rubber hose cryptanalysis.
  7. Burn and destroy everything vaguely related to the generation of the encrypted text including the CDs and printer and any machine that might have had the plain text in the past. A blow torch will be helpful to reduce the electronic device to slag. It goes without saying to never even think about writing down the pass phrase.
  8. Wait naked with your stack of encrypted text for your ride.
  9. If you've decided to keep the encrypted text nearby maybe disguise it somehow (paint a picture over it or paste it into the end covers of a book?) otherwise spread the copies around (buried in the forest? (Transcribed to the back of the US declaration of independence not recommended) IDK)
  10. Never return to the hidden locations until you are ready to decypher.
This seems crazy yet probably isn't enough to keep a secret from a determined state actor; especially if you are already being monitored. To give you an idea British intelligence once bugged every single rental car in Ireland to surveil one IRA agent. His operating method was to hold meetings in rental cars (correctly assessing that British intelligence hd/would likely bug any physical location they thought he might go) and so because they couldn't tell when/which ahead of time they took a shotgun approach.

Or I'd use something like VeraCrypt to encrypt my document. Keep a copy of the encrypted text on my local hard drive (destroy the hard drive with the plain text version if extra paranoid) and a couple of online repositories. And have some juicy pictures of myself banging an automobile or something in the plausible deniability section of the encrypted file. That is just as likely to keep your data safe as neither of the outlined options will prevent a state actor from kidnapping you to their local Gitmo where they hold/torture you for either the pass phrase or the encrypted information until you acquiesce or die.
posted by Mitheral at 2:06 PM on May 28, 2020


though unlikely a break through in factoring prime numbers could mean RSA becomes useless

AES256 is symmetric-key encryption (same key is used to encrypt and decrypt) whose security relies totally on tight control over access to the key, not public-key encryption that also relies on the computational difficulty of associating public encryption keys with their private counterparts.

And it's really really good symmetric-key encryption. The only way I can see an AES256-encrypted document being decrypted within the next half century is by using the key. Even if quantum computing makes factoring huge numbers super easy and breaks everybody's RSA-based digital signatures, that will have no effect at all on the strength of AES256.

That said, the methods Mitheral recommends would all make worthwhile contributions toward avoiding leakage of either the passphrase you used to generate your encryption key, or the key itself.

Another approach to keeping the existence of your encrypted document secret, assuming the encryption is going to be done well before you become a person of interest to state actors, would be to memorize its key generation passphrase, then use burner phones to upload the encrypted document anonymously to a bunch of publicly accessible file sharing platforms and leave messages on Reddit asking if anybody knows what the hell it is. If you do this while nobody is looking and you never tell anybody you've done it, multiple copies will end up downloaded and forgotten about and generally understood to be unimportant on any number of puzzle-junkie private computers all over the world, and there will be no way to find out that the secret it's keeping has anything whatsoever to do with you until such time as you actually go ahead and decrypt it.

Variants on this principle include ideas like breaking your encrypted 4K into multiple QR codes and stencilling them on walls and paths and underpasses Banksy style. Operational security will be harder to maintain that way but you could apply some of the ingenuity you'd otherwise be wasting on designing inferior encryption to working out methods to get other people to do it for you. If Satoshi Nakamoto can remain hidden in plain sight after inventing much more interesting crypto, so can you.
posted by flabdablet at 3:02 PM on May 28, 2020


Rather than depend on the longevity of a website, you could also just encrypt the file and post it with ASCII armoring to alt.anonymous.messages, it's basically designed for that purpose. Lots of places have infinite retention of text Usenet, including IIRC the Internet Archive via Giganews.

You'd want to take proper privacy-protecting precautions before posting, of course, because your IP address will be logged, but you should assume that's happening no matter where you're posting something. (Running an OS like Tails which routes through Tor, using public WiFi, etc.)

The further out in time you can do this from when you think you will come under observation, the better.
posted by Kadin2048 at 8:21 PM on May 28, 2020 [1 favorite]


Even if quantum computing makes factoring huge numbers super easy and breaks everybody's RSA-based digital signatures, that will have no effect at all on the strength of AES256.

This is unfortunately not true I believe.

Grover’s algorithm vastly reduces the search space for decrypting symmetric encryption algorithms (amongst other things). It reduces an O(N) search space to an O(√N) one, which is equivalent to halving the number of bits in the keyspace.

So 128-bit AES is reduced to 64-bits of work. 256-bit AES is reduced to 128 bits of work. The latter /should/ be safe for a long time, but I wouldn’t like to guarantee it.

(Apparently, it’s been demonstrated that if reality is represented by a non-local hidden variable form of QM, then the reduction is by the cube root ∛N i.e. 256 bits ends up with about 85 bits of security. That’s not a lot of headroom if QC follows the same exponential path that current computing architectures did. Is reality a non-local hidden variable universe? Who knows :) )
posted by pharm at 11:24 AM on May 30, 2020


85 bits of security. That’s not a lot of headroom

Let's take a billion searches per second as a rough estimate of what's feasible today.

The number of nanoseconds in a year is about 255, and a search will complete after searching 2-1 of the search space on average, so a search space of 285 would take an average of 229 (half a billion) years to search at today's rates; a space of 2128 requires 272 years, or about a trillion times the present age of the Universe.

Doubling the expected search performance every year would appear to yield a reduction in the expected search time to a single year by 2050 if reality is represented by a non-local hidden form of QM, or by the next century if not. But as it turns out, Moore's Law isn't sustainable and we won't actually be able to do that because thermodynamics.

AES256 is really good encryption.
posted by flabdablet at 9:12 PM on May 30, 2020


AES256 is really good encryption.

It is & it’s what I’d choose. I was mostly just pointing out that the implied assertions about QC not affecting symmetric encryption were incorrect. AES-256 should be good enough. Just don’t use AES-128, it’s not secure against QC attacks.

(Also, the claim about non-local QM leading to cube root reduction in work is theoretical & I think needs some kind of oracle that has access to the internal non-local state, although I only read a part of the paper in question. That seems extremely unlikely to be achievable at the current time, we’re definitely more in the realm of SF-nal speculation!)
posted by pharm at 2:22 AM on May 31, 2020 [1 favorite]


« Older I think I have depression   |   Sound from two laptops, but with one pair of... Newer »
This thread is closed to new comments.