51–60 of 100 posts
If we're talking about GPG, please pay attention to https://www.passwordstore.org/ which is really cool, open source password manager built on GPG.
Earlier quoted context omitted.
That's not at all true. Simple symmetric offline encryption of files is one of the few crypto operations that is easy to get right. The GPG1 defaults aren't great, but they aren't going to get your files compromised. And with the command line options presented upthread, you have the passphrase problem either way.
> they aren't going to get your files compromised. 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 co…
If we're talking about GPG, please pay attention to https://www.passwordstore.org/ which is really cool, open source password manager built on GPG.
Is there anything like this that doesn't leak the folder structure in plaintext? Manually obfuscating site names would be very tedious.
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…
If we're talking about GPG, please pay attention to https://www.passwordstore.org/ which is really cool, open source password manager built on GPG.
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…
This illustrates what's wrong with GPG: it's too hard to use. Why so many arguments for a common task? Why aren't the defaults acceptable?
These suggestions strike a different balance between protection and speed.
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…
--no-use-agent
This is dummy option. gpg always requires the agent.Earlier quoted context omitted.
more importantly, they're more cpu intensive and slow to deal with large files
Asymmetric encryption adds constant overhead, independent of message size. Unless you're doing it wrong.
>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…
Is it really impossible for a human to follow? "Shiny C0rrect H0rse Battery Staple!"
Earlier quoted context omitted.
"Password2017" is a typical "secure" password. Capital and small letters, and number - longer than 8 characters. Passes most "checks" for passwords...
"Password2017!" is even better. It's got a special character!