Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel Attack [pdf]

GPG RSA is much leakier than the other things you mention, because it iterates through the bits of the plaintext doing either a lot of work or a little work at each bit if it's 1 or 0. Smarter implementations of RSA do the same amount of work every time, discarding it when the bit is 0.

From the article:

"Furthermore, as virtual machine hypervisors transparently share memory pages between VMs [5,19], the attack is applicable across the isolation layer between VMs"

It's saying your VMs aren't safe - your Amazon/Linode/Rackspace/DigitalOcean/NineFold/Hertzner cloud instances _do_ have arbitrary users running arbitrary code on them – and the hypervisor can't protect you against what they do (in terms of manipulating the shared cache).

CSPRNGs and full disk encryption are probably safe, at least from this attack. Symmetric crypto usually doesn't use code whose execution depends on the secrets.

There have been cache side-channels demonstrated against some AES implementations, but this attack requires some bit of code whose "execution-or-not" (for lack of a better term) reveals some information the user would like to keep secret.

It is actually very worrying, since it might affect compression software (leak info about the file being compressed), text editors and other software that executes code based on key presses (cross-user keylogger), code whose execution depends on mouse actions e.g. button hover/click events (track another user's mouse), and so on.

Essentially, it turns all "if", "while", and "for" statements into information leaks.

I've written more about it here:

https://defuse.ca/flush-reload-side-channel.htm

for those unfamiliar with kernel samepage merging (KSM):

http://lwn.net/Articles/330589/

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!

The paper describes flushing the data pages. I don't see anything about the code pages in their algorithm.

Still, the abstract completely failing to mention that a RAM deduplicator in the hypervisor or guest is necessary to make the attack work is a big omission.