6 ms·

So, according to this paper, "GnuPG in its current form is not safe for a multi-user system or for any system that may run untrusted code." The attack is again

So, according to this paper, "GnuPG in its current form is not safe for a multi-user system or for any system that may run untrusted code." The attack is against the RSA implementation specifically. Is there a gpg asymmetric encryption that would be considered safe? If not, is there a reasonable gpg alternative?

lelf 13y ago
http://lists.gnupg.org/pipermail/gnupg-announce/2013q3/000330.html http://lists.gnupg.org/pipermail/gnupg-announce/2013q3/00033... GnuPG 1.4.14 released What's New =========== * Mitigate the Yarom/Falkner flush+reload side-channel attack on RSA secret keys. See http://eprint.iacr.org/2013/448 Edit: and Libgcrypt 1.5.3 contains fix for GnuPG 2.x
alcari 13y ago
With their same logic, your software based CSPRNG isn't safe, and your browser isn't safe, and your full disk encryption isn't safe and all it requires is the trivial feat of being able to run arbitrary code as arbitrary users on your system without your knowledge.
- tlb 13y ago
  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.
- bigiain 13y ago
  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).
  - bcoates 13y ago
    The only reason for these operators to do memory sharing would be if it allowed them to oversubscribe RAM--is there any reason to believe any of them are doing that? It seems like it would lead to extremely noticeable and severe performance or stability issues in edge cases unless the provider required you to run a specific image on your instance.
- earthrise 13y ago
  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 https://defuse.ca/flush-reload-side-channel.htm
hosay123 13y ago
This is probably a naive solution.. What is to stop creating a statically linked build of GPG, create a new user account, chmod 0700 the new uid's homedir, copy the new binary into the private user account, and perform all your encryption work in there. So long as you're not running on a VM using tech like kernel samepage merging, pages from the binary should never be shared
- mh- 13y ago
  for those unfamiliar with kernel samepage merging (KSM): http://lwn.net/Articles/330589/ http://lwn.net/Articles/330589/

lelf 13y ago

http://lists.gnupg.org/pipermail/gnupg-announce/2013q3/000330.html http://lists.gnupg.org/pipermail/gnupg-announce/2013q3/00033... GnuPG 1.4.14 released What's New =========== * Mitigate the Yarom/Falkner flush+reload side-channel attack on RSA secret keys. See http://eprint.iacr.org/2013/448 Edit: and Libgcrypt 1.5.3 contains fix for GnuPG 2.x

alcari 13y ago

With their same logic, your software based CSPRNG isn't safe, and your browser isn't safe, and your full disk encryption isn't safe and all it requires is the trivial feat of being able to run arbitrary code as arbitrary users on your system without your knowledge.

tlb 13y ago
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.
bigiain 13y ago
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).
- bcoates 13y ago
  The only reason for these operators to do memory sharing would be if it allowed them to oversubscribe RAM--is there any reason to believe any of them are doing that? It seems like it would lead to extremely noticeable and severe performance or stability issues in edge cases unless the provider required you to run a specific image on your instance.
earthrise 13y ago
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 https://defuse.ca/flush-reload-side-channel.htm

hosay123 13y ago

This is probably a naive solution.. What is to stop creating a statically linked build of GPG, create a new user account, chmod 0700 the new uid's homedir, copy the new binary into the private user account, and perform all your encryption work in there. So long as you're not running on a VM using tech like kernel samepage merging, pages from the binary should never be shared

mh- 13y ago
for those unfamiliar with kernel samepage merging (KSM): http://lwn.net/Articles/330589/ http://lwn.net/Articles/330589/