Using GPG to Encrypt Your Data
nas.nasa.gov
nas.nasa.gov
gpg --symmetric \
--cipher-algo aes256 \
--digest-algo sha256 \
--cert-digest-algo sha256 \
--compress-algo none -z 0 \
--quiet --no-greeting \
--no-use-agent "$@"
https://github.com/SixArm/gpg-encrypt
--s2k-mode 3
--s2k-digest-algo sha512
--s2k-count 1000000
(I'm asking seriously; I don't have a strong opinion about GPG command line arguments)
GPG 2 has better defaults, but it grew to include the kitchen sink and have a lot of moving parts, and I'd still prefer to have a good smaller program that does only a few things but do them good. My ideal would be a small executable with as little dependencies as possible.
https://gnupg.org/documentation/manuals/gnupg/gpgv.html#gpgv
https://gnupg.org/documentation/manuals/gnupg/symcryptrun.ht...
http://security.stackexchange.com/questions/15632/what-is-pu...
"In GnuPG 1.4.12 defaults are (found experimentally):
--s2k-mode = 3
--s2k-digest-algo = SHA1 (supports MD5, RIPEMD-160, SHA2s too)
--s2k-count = 65536 (supports from 1024 to 65011712)
--s2k-cipher-algo = CAST5 (supports 3DES, CAST5, Blofish, AES, Twofish, Camellia too)"
An additional 13 bits of safety margin basically gives you an extra Diceware word (log2(7776)), which, I agree, isn't a magical solution at all, but would to me cross the threshold of "it has some actual impact".
Of course, having much better usability for the average user, or just breaking OpenPGP compatibility so there are clean modern robust constructions like NaCl/libsodium running underneath are way better ways to get at good security margins, but here we are.
The default encryption is CAST5 which is a 64-bit block size cipher (even if it is confusingly called "CAST-128").
The default password derivation is using SHA1.
That's the reason people change the defaults. If you like them, you're of course free to use them or recommend them to your clients. Good luck. Of course I'd also like to read your explanation how you can consider 64-bits "secure enough" today (or for what you consider them secure enough). Also your estimate of how expensive would be to brute force shorter passwords for the traditionally small number of default rounds of SHA1. Thanks.
Which scenarios do you assume to be valid for offline encryption which don't make short block sizes problematic?
Why is poor password handling not a problem under these scenarios?
I'm not sure why an 8 byte block would materially impact file encryption. The kinds of attacks where short blocks come in handy are all online, CCA-style attacks. You might worry about things like CTR counter block sizes, but, again, not an issue for GPG1's defaults.
I'm not saying they're good settings. And: in particular, if you used them to encrypt something like session cookies, you could have serious vulnerabilities. But like I said: it's easy to encrypt files, and some things that are survivable for files aren't for other applications.
It can be requested directly via '--force-mdc', but, as long as you're tweaking the configuration, you might as well boost everything up to the full "Grovergeddon" settings.
It's a wrapper for gpg to edit encrypted files.
personal-cipher-preferences AES256 AES
personal-digest-preferences SHA256 SHA512
personal-compress-preferences Uncompressed
default-preference-list SHA256 SHA512 AES256 AES Uncompressed
cert-digest-algo SHA256
s2k-cipher-algo AES256
s2k-digest-algo SHA256
s2k-mode 3
s2k-count 65011712
disable-cipher-algo 3DES
weak-digest SHA1
force-mdc
These suggestions strike a different balance between protection and speed.
--no-use-agent
This is dummy option. gpg always requires the agent. gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect set -euf
onecmd --args "$@"
The set -e is not needed, as there is only one command, and the script will return the exit status of such command. Always. And will exit after that command. Always.
The set -f, will disable globbing, which I'm not sure it's what you want, when using a simple wrapper passing "$@" as filenames to gpg...
This is the classic braceless if-guard mistake; leave it out today because you don't need it, forget, add something tomorrow and it breaks.
#!/usr/bin/env bash
set -e
fail() { false ; echo hello; }
if ! fail; then :; fi
$ file /tmp/something.gpg
/tmp/something.gpg: GPG symmetrically encrypted data (AES cipher)
Not having a browser add-on to retrieve passwords was feeling like a step back in terms of convenience though. That's why I built & open sourced browserpass [1], a browser extension for Pass.
It uses Native Host Messaging to securely retrieve passwords, so no crazy port listening as some other open-sourced add-ons do (which is a terribly bad idea).
Features: http://keepass.info/features.html
I switched to pass / qtpass (cross-platform Qt frond-end for pass) after seeing it on hacker news (or somewhere else like Twitter) because it uses GnuPG + git (simple and I am capable of both in CLI). Last but not least, pass provides migration scripts from keepass/keepassx (and a lot more... - feel like I had to migrate ;-)
https://play.google.com/store/apps/details?id=com.zeapo.pwds...
$ xz -k elrond_minutes.txt
$ scrypt enc elrond_minutes.txt.xz elrond_minutes.txt.xz.enc
$ signify -S \
-s vilya.key \
-m elrond_minutes.txt.xz.enc \
-x elrond_minutes.txt.xz.enc.sig
$ rm elrond_minutes.txt{,.xz}
xz < file | scrypt enc - > file.xz.enc
>You need to be able to recall the passphrase that was used to encrypt the file.
Why bother writing security guidelines which are impossible for a human to follow?
edit: Try recalling any passphrases generated by the command below, and that's before the random sprinkling of punctuation.
grep -E "^[a-z]{5,10}$" /usr/share/dict/words | shuf -n5 | tr '\n' ' 'Imagine this, you take four word types/groups, say, substantive, verb, adverb, preposition/place.
You list 128 of each - all with identified uniqly by the first two letters. You let a machine pick a word from each column at random. The phrase is your mnemonic key, the password (to type in) is the first two letters of each word, concatenated.
If you want to appease password strength checks, capitalise the first letter, and end the input with a period.
So: "girl runs happily up", becomes "giruhaup" (or, with equivalent entropy, but satisfying "at least three symbol groups": "Giruhaup.").
Now, that's then 4 picks out of 128 words, or an encoding of 4 times 7 bits (2^7=128) - 28 bits. You'd need three such passwords concatenated to break past 64 bits of entropy. And you'd have to type in 24 letters. That's pretty hard to type in blind without a typo.
You might be able to use lists of 256 words - but it'd make it a bit more difficult to make the wordlists (because words should be identified by the first two characters) - and you'd still need two "phrases" and type in 16 characters.
Adding random numbers, symbols or capitalization is probably not worth the challenge they add in remembering where they go, for the single/few bits of entropy they add.
And I'm still not convinced 16 characters is short enough to be usable for "most people".
For the long tail of passwords that you shouldn't be memorizing in the first place, a password manager with a good configurable password generator is invaluable. I use Lastpass (I like the breadth of it's platform support: all major consumer OSes, all major mobile OSes, extensions for all major browsers). Alternatively, lot of people recommend 1password.
Diceware has better guarantees, but the password managers are usually much more convenient[1]. I weigh these costs and benefits when choosing which way to go for a particular use case.
[1] With the significant exception of passwords that will regularly have to be typed out on mobile, since diceware passwords are much more virtual keyboard friendly than random character generated passwords. This is partly because you can typically keep the entire thing in your head, not having to reference your password manager multiple times, and partly because they don't rely on special characters for their entropy, so can be typed out on the primary keyboard without switching to numeral or special character keyboards.
My main takeaway looking at the problem, is that 64 bits is a lot to encode in ~26 letters and maybe 10 digits - in a way that is easy to remember, easy to type, easy to read (if eg: given a printed initial password, read/hear (sharing over the phone/double as a way to read out a hash/shared key etc).
My main issue with diceware is the large number of words; almost touching on typical active vocabulary of even native speakers - never mind if your users speak little or no English. One benefit of the system above is that as long as you can come up with four/five sets of 128 words that don't collide among themselves in the groups of 128 - you can adapt the system to any alphabet and preserve any guarantees of entropy. Making a diceware wordlists is a huge undertaking by comparison. (But the benefit is that people have already done this for many languages).
And while it might feel good to pretend full words add entropy, if you assume the attacker knows your system - it really doesn't (hence "guaranteed" entropy).
As for diceware, I don't find those passwords easy to remember - especially past 60 bits of entropy. But use what works for you.
It does: munroe's proposed scheme operates on the assumption the attacker knows it. The 11 bits of entropy refer to a dictionary of 2K words to choose from. The reason to type full ones is you're not hamstrung by the "no common prefix" limitation, which allows larger (and easier to remember) dictionaries.
Also, we're talking theory. Typing them blindly is an artificial implementation limitation imposed on us by bad software. Just like "you need at least one digit", "maximum length 16", &c. If you're going to consider those, that's fine, but then you're not talking about actual password theory anymore--you're just discussing how to cope with bad platforms.
Case in point: many good PW forms (OS logins, &c) have no such limitations, and offer a "view password while typing" option.
This is indeed not about password "theory", because experience shows that actual system (in)security happens where computer systems and users interact.
Using a common subset of keyboard layouts for different languages (limiting the character set), being workable on touch screens, are important for security. And using passwords at all is working around "bad platforms".
> The 11 bits of entropy refer to a dictionary of 2K words to choose from. The reason to type full ones is you're not hamstrung by the "no common prefix" limitation, which allows larger (and easier to remember) dictionaries.
From playing with this, I'm not convinced the tradeoff of using a big dictionary whose that cannot be enumerated by a short unique prefix (to reduce length) really adds that much - just like increasing the character set beyond 26/36 helps all that much - because you only gain a bit for every doubling in size.
My idea is for the mnemonic to form an actual "story" (in a secure way) - in the hope that it's easier to remember : "boy flies angrily away" than "correct horse battery stapple".
A) that may be wrong
B) You still need too many words in order to encode a "high enough" entropy
Another note on this - assume an average word length of 5 - that's 11/5 or 2.5 bits per character typed (again, assuming the wordlist doesn't loose some bits for "double coding" like "at hat/a that").
At 7 bits per word - of which two characters are enough, we type 7/2 or 3.5 bits per character.
Conversely, we only memorize 7 bits per word vs 11 bits.
"Shiny C0rrect H0rse Battery Staple!"
In my experience, overly restrictive password policies force users to choose passwords that are less secure and easier to remember.
thanks for the link
This hunt for dates in titles on HN is bad and it's awitch hunt these days.
Disclaimer: I'm not an author nor submitter.
Asymmetric encryption solves the problem of transmitting the password safely ("solve" is a rather optimistic word, maybe "delegates" is more appropriate); if you can safely transfer passwords from point to point, then using symmetric encryption is far easier.
Which is just a different problem, not necessarily an easier one, like you say.
That's a very nice way to put it, I'm going to reuse that !
Unless you're doing it wrong.
====
Use GPG with the cipher AES256, without the --armour option, and with compression to encrypt your files during inter-host transfers. GPG
Encryption helps protect your files during inter-host file transfers (for example, when using the scp, bbftp, or ftp commands). We recommend GPG (Gnu Privacy Guard), an Open Source OpenPGP-compatible encryption system.
===
scp shouldn't be in that list.
But for bulk data encrypting good symmetric (AES, CAST5, etc.) is both more secure and significantly faster.
This is how the same document can be encrypted for multiple recipients efficiently, without duplication all the data. First the document is encrypted with a symmetric key, which is then encrypted with the public key of each recipient. This information will be prepended to the actual encrypted document.
For details see: https://tools.ietf.org/html/rfc4880#section-2.1