Q2: Cleanest would be to uninstall GnuPG and install latest from source. Make sure to backup relevant directories containing GnuPG related data (probably in your home - sorry I'm not familiar with Ubuntu)
BIG WARNING - THIS IS NOT THE BEST WAY TO INSTALL GNUPG! IT DOES NOT
VERIFY ANY (REAL) SIGNATURES!!
FYI - Debian unstable (aka sid) has a pacakge, and there is a backport to Ubuntu Saucy. I'm not sure what the best/easiest way to automatically pull down sources for a newer release than the release you're running in Ubuntu (there might be some apt-add magick for source mirrors?) -- but since it is up at launchpad[1], you can:
a) try the binaries
b) build the debs yourself (aka manually "backport"):
mkdir tmp/gnupg -p
cd tmp/gnupg
sudo apt-get build-dep gnupg
sudo aptitude install dpkg-dev #This might get pulled
#in by the line above
wget https://launchpad.net/ubuntu/saucy/+source/gnupg/1.4.14-1ubuntu1/+files/gnupg_1.4.14.orig.tar.gz \
https://launchpad.net/ubuntu/saucy/+source/gnupg/1.4.14-1ubuntu1/+files/gnupg_1.4.14-1ubuntu1.debian.tar.gz \
https://launchpad.net/ubuntu/saucy/+source/gnupg/1.4.14-1ubuntu1/+files/gnupg_1.4.14-1ubuntu1.dsc
tar xzf gnupg_1.4.14.orig.tar.gz
cd gnupg-1.4.14
tar xzf gnupg_1.4.14-1ubuntu1.debian.tar.gz
cd debian
dpkg-buildpackage
cd ..
sudo dpkg -i gpgv_1.4.14-1ubuntu1_amd64.deb \
gnupg_1.4.14-1ubuntu1_amd64.deb \
gnupg-curl_1.4.14-1ubuntu1_amd64.deb
Note: This might not be a good idea with a package that is as imprtant
as gnupg (among other things apt package lists are signed with gnupg!).
And as you can also see above, the packages are not signed (explicitly,
even if they do come in via https...).
At least this built fine under wheezy -- but I haven't tried installing them (I'm not that worried that someone will snoop my workstation cache..).
So not really meant for advice on how to get an upstream gnupg -- but
useful with a few other well-behaved programs. So big warning,
practice safe hex and all that!
Some nitpicking: the passphrase is not as good as it seems. It consists of two parts ("horse in a box" and "riding a fish") both of which can be found in e.g. Google's n-gram corpus [1]. The Google's corpus has on the order of 2^32 n-grams so even assuming you chose these two at random, you get only 64 bits of entropy. There is also some punctuation (let's be generous and say it gives 10 bits), so the entire passphrase is about 74 bits of entropy. While very good, this is probably not enough to protect your bitcoin life savings or a truecrypt container that can implicate you in a serious crime (the reason being that Moore's law may well make 74-bit passwords easily crackable in 10 years or so)
For comparison, the first password you provided (16 random alphanumeric characters) has 95 bits of entropy.
still won't help. This is security trough obscurity. It works only if the attacker don't suppose you use passphrase.
4000^4 gives 256000000000000 giving 3.3 bits of entropy per decimal digit it comes to 50 bits of entropy. Not too shabby but not that secure either. Your PCs rng may play you dirty tricks.
And of course there are all kind of legacy systems with password limitations to 32 or 16 character, but above 8 etc etc which would further reduce the pool.
Of course you could try your own password deriving mechanism. Take the first 16 characters of bcrypt(username,site domain) it will produce awesome passwords for any site that you will have easy time producing when needed. Until the hackers begin to suspect what you use if it becomes widespread.
(Disclaimer - not a cryptographer or security expert or particularly competent in anything)
> Take the first 16 characters of bcrypt(username,site domain)
Hey, that's the very definition of security through obscurity ;)
Here's a thought experiment I use when estimating security of similar password schemes: imagine you asked someone to come up with 1000 different mechanisms of generating passwords based on username and domain. Is your scheme is likely to be among them? If yes, this means it provides less than 10 bits of security.
What do you mean "not that secure either"? 8 random upper-lower-numeric characters are 47.6 bits of entropy, that is 47.8. I'd say that's decently secure, and the suggestion that you bcrypt your username with the site's domain for a salt is pretty much the definition of security through obscurity, like the other commenter said.
Please don't discourage good practices. Four random words is a lot better than "password123", though it would still take 1.5 day to crack it if it were stored as an MD5 hash. Six words would take 65 years at 1ghash/sec, which is pretty damn good, and better than a 12-char random password. 5 words would take 16 years, which seems like a pretty good compromise.
EDIT: Although, I don't like straight-up Shannon entropy as a measure of password strength.
I gave the bcrypt example as a anti-pattern if I didn't make myself clear.
Any password derivation scheme works brilliantly until you are the only one using it. The moment it becomes widespread and people begin to target it - it goes anywhere from significantly weaker to trivial to crack.
The problem with that is that password derivation is entirely reasonable and encouraged. It's what PBKDF2 does (the "KD" stands for "Key Derivation"). Securing your passphrase with a few thousand rounds of bcrypt and salting with the domain is a great way to strengthen it, since you don't have to trust any shitty MD5 password storage mechanism the site has, the attacker has to brute-force bcrypt to be able to get your master passphrase.
It is not security through obscurity. It works even when the attacker knows I use a passphrase and has a copy of my dictionary. It's about the same security as a random 8 character password with lower and upper case, numbers and choice of 10 symbols.
Maybe that's no longer secure enough; I don't know how fast password crackers are now. So use "shuf -n 5" instead.
It doesn't work when the attacker knows you use this scheme, your username and the site's domain. There's no secret in that scheme, therefore it's pretty much the exact definition of security through obscurity. Add a password to it, though, and you pretty much have SuperGenPass.
I think you replied to the wrong person here. I'm saying that the passphrase does not rely on security through obscurity. venomsnake's scheme does, though it appears he meant it to be exactly that (ie. an example).
Yeah, that was weird. You are correct in that comment, I posted the entropy equivalents in another comment in this thread (using 5 words is pretty secure).
Can you please elaborate on why & how the withholding taxes in other countries are affecting you? I assume that you sell software or services from your company's web site.
Somehow this does not click with my CFO experience.
You can have multiple remotes for your Git repositories, one of them (Github) being down should not affect your work since you can coordinate a new one with your team in the manner described above.
Yep! I usually setup a mirror at bitbucket and set my local to push to both github and bitbucket and only pull from github. It worked well when github was down and I needed a branch from a remote developer.
I am on Ubuntu LTS 12.04 with GnuPG 1.4.11 (Linux version 3.2.0-32-virtual (buildd@batsu) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)).
Q1. Do I need to fix this potential attack?
Q2. Assuming this fix is not backported [now] - if I compile fresh gpg and swap the binary with the old gpg - will this fix it?