Comment by disambiguation
Comment by disambiguation a day ago
# Encrypt a file openssl enc -aes-256-cbc -salt -in secret.txt -out secret.enc
# Decrypt openssl enc -d -aes-256-cbc -in secret.enc -out secret.txt
Wow that was hard.
Comment by disambiguation a day ago
# Encrypt a file openssl enc -aes-256-cbc -salt -in secret.txt -out secret.enc
# Decrypt openssl enc -d -aes-256-cbc -in secret.enc -out secret.txt
Wow that was hard.
> where do you keep secret.txt
Reminds me of using Ansible Vault and preciously encrypting every secret (so we can say that repos doesn't contain any secrets), then just putting ~/.vault_pass in plaintext on every Ansible controller to be taken by anyone with access to the servers.
The author of AGE has a great point in the below blog post [0]:
If you use something like SOPS or just check age secrets into a git repository next to source code, you need an authentication story for the whole repository. Having authentication for the secrets will do nothing if the attacker can change the source code that decrypts and uses them.
That story can simply be “we trust GitHub” like most projects. Encrypting secrets with age will keep them confidential even if the project is Open Source, and anyone wanting to replace them will have to make a PR even if they can generate a new valid age file.
>where do you keep secret.txt exactly?
Hidden. Encrypted. And the passphrase is: at 5,21 which is the 5th line on page 21 of your favorite book. Which you have more than one copy of, because you like it that much. And you need copies to lend. Or you have the PDF from Gutenberg.org?
And 5/21 might be the birthday of your first child, or your wedding day, or whatever?
It might be a favorite quote, like "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." Augmented by the above date if needed?
Hidden where? Are you writing it on a post-it and putting it on top of your screen? Are you keeping it in your wallet? In a safe? What if you lose it or your house is flooded?
> And 5/21 might be the birthday of your first child, or your wedding day, or whatever?
How sure are you that you'd remember all that scheme for 20 years? How about 50 years? Some documents may be relevant for a very long time. What about if you need more than one key? What about if you need to give access to one document to specific set of persons?
Once you consider all the scenarios that can happen through a lifetime, you start to understand why managing all those complexities correctly is not trivial. And that's why people pay third parties to do it for them. It's not because encrypting a bag of bytes is hard. It's because of all the things that surround it.
Some people are lucky with memory that works extremely well with numbers. My memory is average but when it comes to numbers, I remember serial numbers of certain products, enrollment numbers etc from more than a decade ago.
HP-L170 (A monitor I bought) QW4HD-DQCRG-HM64M-6GJRK-8K83T (Windows XP key) 10396-9 (My enrollment number for board exam)
I remember a bunch of long-ago-abandoned phone numbers as well.
>>My memory is average but when it comes to numbers...
Where I live, memorizing a 25 char alphanumeric is not average. It's not more, either.
As of now I have to care for my (digital) backups, that is, I cannot ignore them for N years. I had to copy things from discettes to magnetic tape, from tape to hard drives, etc. I have to periodically check my backups if they are restorable. That's life.
It's the same for documents, as for secrets, which I have to transfer from one medium to another, I have to check that I remember secrets and passphrases. And places. As I already said, that's life.
> it's something they'd never ever know how to do
There are hundreds of millions of people who have memorized megabytes of baseball statistics, pop song lyrics, celebrity relationship trivia, vehicle model data, sitcom character biographies, comic book plots, makeup shades, travel routes, mixed drink recipes, MtG card modifiers, etc.
At a certain point, one has to realize that pulling the "normie card" is not a viable excuse, given the wide array of knowledge that humans routinely pack into their brains.
The double entendre occurred to me, I don't disagree.
But the relative ease does not merely apply to users, but to the barrier of entry for alt products as well.
Consider that the current paradigm is contingent on the "blind trust" users have held in tech for a long time. It's possible that a new kind of app will thrive in a different paradigm.
For example, is there any reason we couldn't have a simple "message wrapper" which only sends encrypted payloads via SMS or Email and decrypts on the fly in a secure sandbox? Easy for the user and hard to regulate.
I think that's what Silence was (for SMS): https://f-droid.org/packages/org.smssecure.smssecure/
Yeesh, this seems like a good example of the fact that a feature (encrypting a file) is not a product (an E2E encrypted storage solution.)
Nice.
Now explain how my mum can select that in settings of her phone, thx.
Threat modeling is important of course. The UK government does have tools with which to punish people who don't turn over the cleartext of targeted documents once it's directly investigating them, but that's not scalable. The method the grandparent comment proposes greatly reduces one's exposure to mass surveillance, criminals, and abusive service providers.
You may think you're being sarcastic, but you are just stating a true fact here. For about 99.9% of this planet's population, it's not just hard, it's something they'd never ever know how to do and have no intention to ever learn. Like it or hate it, but that's what it is.
And, for 99.9% of people who know how to do that, they'd still be too lazy to do it properly (hint: where do you keep secret.txt exactly? What happens if your dog eats it?) and will use some third-party solution instead.