password safety

Links :: devdungeon primer :: NASA page

This post assumes use of gpg for password protection at the 256 level. Geofencing is not covered here, and anyways has no current protections: too many 3rd parties sell to each other and governments.

gpg shortcomings

1. trivially overcome by government organizations
2. modifying defaults requires a configuration file
• default password timeout is several minutes
• default cypher (CAST5) easily bypassed
3. default encrypted file is a binary. May not therefore pass virus checks, etc.
4. the encrypted file exists without password attempt safeguards. It need only be copied, and then a second program to run a brute force password attack millions of times per second until it is cracked
5. often used without a hash, degrading its security

In short, as provided, this program is little more than window dressing providing a (dangerously) false sense of security. Let's look at solutions by number.

TLDR

GPG non-destructively encrypts: an encrypted output file is created and the unencrypted input file still exists. If no output file is specified (-o flag) during encryption, an output file will still be created. It will have the input filename with a "GPG" extension added. An output file should also be specified (-o flag) for decryption, or the decrypted file will simply read to the screen, with no file creation. 1) accomplish the configuration changes in section 2 "configuration file" below and restart, then 2) encrypt and decrypt as follows.

encrypt

$ gpg -c inputfiletoencrypt.txt
[password]
inputfiletoencypt.txt.gpg

In lieu of providing an output name, rename the file with the GPG extension whatever you wish. It makes no difference to decoding what the file's name is.

decrypt

$ gpg -o decryptedoutputname.txt -d encrypted.txt
[password]
decryptedoutputname.txt

The encrypted file is a binary, and may not pass all virus tests, eg required for uploading into GDrive. If this is a problem, add the flag --armor into the encryption command. This encodes the file into a scrambled block of ASCII text, instead of a binary.

1. transparency to gov't

No reasonable solution. Securing files against gov't intrusion requires a CS degree or steps more problematic for the user than the privacy is worth. If a citizen's files are stored on the Web, it's easiest for a government, but any device connected to the Web for even a few seconds likely has been indexed or otherwise compromised. Citizens' thoughts, patterns, networks, and locations are trivially determinable with AI. If deemed interesting, their information is forwarded for human review. Accept the gov't panopticon.

2. configuration file

Average users want the convenience of symmetry. If so, a person wants the strongest symmetric setup.

$ touch [or nano] ./gnupg/gpg-agent.conf
# Comment line indicator
# Seconds until password required for decrypt
default-cache-ttl 20
# Seconds until all passwords dropped
max-cache-ttl 25
# AES256 encryption
cipher-algo AES256

2a encrypt/decrypt

With the changes above, standard encryption syntax is OK

$ gpg -c toencrypt.txt
[password]
toencrypt.txt.gpg

Idiots leave files on their system with "GPG" extensions, so specify the file name. Give all your encrypted files the same preface, say "t", so you'll know:

$ gpg -o t20211101.docx -c toencrypt.txt
[password]
t20211101.docx

To decrypt, give an output filename or it just reports to the screen.

$ gpg -o output.txt -d t20211101.docx
[password]
output.txt

3. binary file

By default, a binary file is created, and that's space efficient. But binaries look bad to some virus checkers and sometimes are flagged as viruses, preventing uploads or storage. When this occurs, the solution is to create an encrypted file with ASCII text. For this we simply add the "armor" flag.

$ gpg -o t20211101.docx --armor -c toencrypt.txt
[password]
t20211101.docx

To verify, cat the encrypted file. It should be a block of text.