Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using GPG to Encrypt Your Data

nas.nasa.gov

Post reply on HN
Print view View original

21–30 of 100 posts

Re: Using GPG to Encrypt Your Data

#21

Post by throwawayish »

tptacek wrote: post #20
jph wrote: post #8

For GPG symmetric encryption, the kind the article describes, here are the best options I've found for my typical case: gpg --symmetric \ --cipher-algo aes256 \ --digest-algo sha256 \ --cert-digest-algo sha256 \ --compress-algo none -z 0 \ --quiet --no-greeting \ --no-use-agent "$@" I keep this command here: https://github.com/SixArm/gpg-encrypt The options are chosen to balance tradeoffs of convenience, strength, an…

What is this getting you that a simple 'gpg -c' isn't? (I'm asking seriously; I don't have a strong opinion about GPG command line arguments)

The defaults he has chosen hints at a distro that ships GPG v1 / classic, which has stranger defaults than GPG v2. IIRC the default ciphers are CAST5, (very slow) compression is on by default, hashes are RIPEMD I believe and so on

Re: Using GPG to Encrypt Your Data

#22

Post by vesinisa »

jph wrote: post #8

For GPG symmetric encryption, the kind the article describes, here are the best options I've found for my typical case: gpg --symmetric \ --cipher-algo aes256 \ --digest-algo sha256 \ --cert-digest-algo sha256 \ --compress-algo none -z 0 \ --quiet --no-greeting \ --no-use-agent "$@" I keep this command here: https://github.com/SixArm/gpg-encrypt The options are chosen to balance tradeoffs of convenience, strength, an…

You can also explore the --s2k-* options to add a level of difficulty to hashing the password to protect against brute-forcing. E.g.

  --s2k-mode 3 
  --s2k-digest-algo sha512 
  --s2k-count 1000000
Default is to use salt + one round of SHA1, which is relatively weak.

Re: Using GPG to Encrypt Your Data

#23

Post by falcolas »

gcp wrote: post #9
45h34jh53k4j wrote: post #7

Earlier quoted context omitted.

because encryption in transit != encryption at rest. Maybe you don't trust the server you are scp'ing the data to, with encryption at rest you dont' need to.

That's not what the documentation is about, though: ==== 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…

If your goal is to transfer securely from person to person, 'scp' generally means there's a common server you're accessing - not that you're 'scp'ing directly to the other user's machine. Keeping it secure when "at rest" on the remote server would ensure it's securely transferred between the two end points.

Re: Using GPG to Encrypt Your Data

#24

Post by throwawayish »

rakoo wrote: post #17
discreditable wrote: post #3

Why would they not use asymmetric encryption?

Because the paragraph on key generation and management would be 3 times as long as the entire article in its current form ? 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.

Asymmetric cryptography transforms key distribution problems into key management problems.

Which is just a different problem, not necessarily an easier one, like you say.

Re: Using GPG to Encrypt Your Data

#25

Post by txutxu »

jph wrote: post #8

For GPG symmetric encryption, the kind the article describes, here are the best options I've found for my typical case: gpg --symmetric \ --cipher-algo aes256 \ --digest-algo sha256 \ --cert-digest-algo sha256 \ --compress-algo none -z 0 \ --quiet --no-greeting \ --no-use-agent "$@" I keep this command here: https://github.com/SixArm/gpg-encrypt The options are chosen to balance tradeoffs of convenience, strength, an…

Regarding the code...

    set -euf
    onecmd --args "$@"
The set -u is unneeded, as there are no code variables involved.

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...

Re: Using GPG to Encrypt Your Data

#26

Post by e12e »

parfe wrote: post #2

>We suggest that you include five words of 5-10 letters in size, chosen at random, with spaces, special characters, and/or numbers embedded into words. >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 sprinkl…

I've been thinking about this for a while, and the early conclusion I've come to, is that 64bits of provable random entropy in a password that's also memorable is a very high bar to clear.

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".

Re: Using GPG to Encrypt Your Data

#27

Post by raimue »

brockers wrote: post #6
discreditable wrote: post #3

Why would they not use asymmetric encryption?

GPG, of course, allows you to use asymmetric crypto and currently supports RSA, RSA-E, RSA-S, ELG-E, and DSA algorithms for that purpose. But for bulk data encrypting good symmetric (AES, CAST5, etc.) is both more secure and significantly faster.

You should be aware that even for asymmetric encryption, only a one-time document-specific key will be encrypted with the asymmetric algorithm. The document itself will always be encrypted using a symmetric cipher.

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

Re: Using GPG to Encrypt Your Data

#28

Post by e12e »

COil wrote: post #18
LordKano wrote: post #14

Earlier quoted context omitted.

That's a good long term solution but when policies force you to change your password every 45 days, it falls apart. In my experience, overly restrictive password policies force users to choose passwords that are less secure and easier to remember.

Yes indeed. For example they add the current year and month and keep the same "base password" which is unsafe.

"Password2017" is a typical "secure" password. Capital and small letters, and number - longer than 8 characters. Passes most "checks" for passwords...

Re: Using GPG to Encrypt Your Data

#29

Post by Xophmeister »

brockers wrote: post #6
discreditable wrote: post #3

Why would they not use asymmetric encryption?

GPG, of course, allows you to use asymmetric crypto and currently supports RSA, RSA-E, RSA-S, ELG-E, and DSA algorithms for that purpose. But for bulk data encrypting good symmetric (AES, CAST5, etc.) is both more secure and significantly faster.

GPG 2.1 (via libgcrypt) also supports various elliptic curve algorithms for asymmetric crypto, depending on what version of libgcrypt you have.

Re: Using GPG to Encrypt Your Data

#30

Post by 0xffff2 »

parfe wrote: post #2

>We suggest that you include five words of 5-10 letters in size, chosen at random, with spaces, special characters, and/or numbers embedded into words. >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 sprinkl…

I do this... I have 3-4 randomly generated passwords memorized. One for each "important" account (e.g. email, banking).
Post reply on HN