41–50 of 100 posts
There's the [2015] which should be included.
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.
Earlier quoted context omitted.
Exactly. The defaults of GPG 1, the one which can be used as a single not-too-big binary, seem to be poor. 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.
The GPG1 defaults are definitely not great, but I'm not sure they have much practical impact for this use case.
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)"
Earlier quoted context omitted.
The GPG1 defaults are definitely not great, but I'm not sure they have much practical impact for this use case.
What is "this use case" for you? The topic of the article is symmetric encryption, and whoever uses the defaults has much more chance to produce the files which could be compromised. it is a huge practical impact for me. Even when not using the defaults, the passphrases have to be really, really long to keep the content safe. http://security.stackexchange.com/questions/15632/what-is-pu... "In GnuPG 1.4.12 defaults ar…
Earlier quoted context omitted.
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...
>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.…
Earlier quoted context omitted.
What is "this use case" for you? The topic of the article is symmetric encryption, and whoever uses the defaults has much more chance to produce the files which could be compromised. it is a huge practical impact for me. Even when not using the defaults, the passphrases have to be really, really long to keep the content safe. http://security.stackexchange.com/questions/15632/what-is-pu... "In GnuPG 1.4.12 defaults ar…
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.
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.
Earlier quoted context omitted.
Exactly. The defaults of GPG 1, the one which can be used as a single not-too-big binary, seem to be poor. 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.
The GPG1 defaults are definitely not great, but I'm not sure they have much practical impact for this use case.
Earlier quoted context omitted.
Asymmetric cryptography transforms key distribution problems into key management problems. Which is just a different problem, not necessarily an easier one, like you say.
more importantly, they're more cpu intensive and slow to deal with large files
Unless you're doing it wrong.
Earlier quoted context omitted.
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...
I disagree. set -eu should be at the top of every bash script. 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