Of course recoverin an email is an innocent disguise.
The same approach works for recovering any secret information that people used on a computer that an attacker can access. Of course there are plenty of possibilities. But it’s eye opening to see them in action.
Yes, encryption keys can persist in memory, too. That's why many law enforcement agencies use something like a HotPlug[1] + mouse jiggler to keep machines powered on when executing a search warrant.
It's why operating systems should implement a lockdown option to restrict users from performing arbitrary access to memory or kernel, even if the user is root. I mentioned before that, on one of my computer, I completely disabled dynamic kernel modules, hotpatching, /dev/mem, no ptrace() to arbitrary process, etc., making it difficult for root to do any low-level access to memory or kernel. I also enabled IOMMU, it isolates the address spaces of different hardware from each other, so no external hardware cannot have arbitrary RAM access via DMA, hardware-based memory capturer won't work. The only way to attack is either an 0day or a cold-boot attack, the 0day threat can be reduced by using a security-minded kernel, like PaX/grsec (not available to the public anymore), OpenBSD, or HardenedBSD. As for cold-boot attack, future hardware may support full memory encryption [0] at the hardware level and fix this vulnerability. Mouse jiggler is a problem, but USB firewalls already exist [1], if proper policies is enforced by the firewall, unauthorized hardware cannot register as an input device.
There may be still some exploits, especially when you consider that Linux kernel is not designed with security as its first priority, and over the last 20 years a lot of black magic has been developed to insert bad things into the kernel, but at least doing the countermeasures I mentioned will make it difficult. Hence, it's impossible to do any low-level changing or debugging on the system without rebooting it - which will immediately revert the system back to a "at rest" state, and triggers full-disk encryption. Other people may choose to do the opposite, it's a tradeoff between uptime and security.
Unfortunately, any attempt to introduce such a lockdown will be accused of being an evil technology that enables DRM. However, ultimately, the question is not whether a computer is locked down, but who is in control of the computer and it's locked down to protect whom.
[0] Don't confuse "memory scrambling" and "memory encryption". The vast majority of PCs today already use memory scrambling - the memory controller will "scramble" the data in RAM to a seemingly-random pattern using a Linear Feedback Shift Register, but it's done for electrical considerations - if there are too many 1s or 0s in a row, excessive current spike (di/dt) is produced, and it reduces signal integrity and creating excessive electromagnetic interference - LFSR-based scrambling is not for cryptography purposes and trivial to decode. On the other hand, memory encryption is a true solution that provides cryptographic protection to the RAM, and many hardware vendors have roadmap to implement it. Currently, it seems that there are two types, the first type is a "full memory encryption" - protecting RAM from physical access, the second type is "per-application memory encryption", which allows an application to request a segment of encrypted memory with an unique key - protect sensitive data of one application from accidental access by other programs. Both are helpful.
Just a note for you (and other readers), as I think it needs some elaboration.
> no ptrace() to arbitrary process
Traditionally, ptrace() restriction is a grsec feature. But in mainline kernels, the same feature is available in the Yama module, see [0]. Use Yama with "kernel.yama.ptrace_scope = 3" will permanently disable ptrace() for all users, including root, and it cannot be enabled again. Then, you should also compile your own kernel, so you can disable /dev/kmem (CONFIG_DEVKMEM), /dev/mem (CONFIG_DEVMEM) and /proc/kcore (CONFIG_PROC_KCORE) in the Linux kernel. Also, I forgot to mention kexec(), which allows the attacker to execute another kernel without rebooting, so CONFIG_KEXEC should be disabled as well. And the list goes on and on, I think it's necessary to download an old grsec kernel, and using the configuration section of grsec as a checklist (and try disabling them using mainline technique if possible) if your security is serious business.
If you do these things, it will block the technique described in the original article.
This reminded me I was still going to report this bug, but anyone else should feel free to do so before me: gpg-agent stores your password/-phrase in plain text in memory indefinitely. You can clear the cache with some command and they also expire after some time, and gpg-agent will pretend to have forgotten them and prompt you again for the password, but the memory that contains the password is not overwritten and you can still dump the process' memory and retrieve it. Email contents seem relatively benign by comparison...
Yes, eye opening. Non IT folks often believe they are safe because no one will find their secrets in a fast sea of information anyway. Nothing can be farther from truth. Most of the time key material and other secrets can be extracted automatically using widely and freely available tools.
The same approach works for recovering any secret information that people used on a computer that an attacker can access. Of course there are plenty of possibilities. But it’s eye opening to see them in action.