Vulnerabilities in private networks are difficult to detect for attackers outside of the network. While there are known methods for port scanning internal hosts that work by luring unwitting internal users to an external web page that hosts malicious JavaScript code, no such method for detailed and precise service identification is known. The reason is that the Same Origin Policy (SOP) prevents access to HTTP responses of other origins by default.

OpenPGP and S/MIME are two major standards for securing email communication introduced in the early 1990s. Three recent classes of attacks exploit weak cipher modes (EFAIL Malleability Gadgets, or EFAIL-MG), the flexibility of the MIME email structure (EFAIL Direct Exfiltration, or EFAIL-DE), and the Reply action of the email client (REPLY attacks). Although all three break message confidentiality by using standardized email features, only EFAIL-MG has been mitigated in IETF standards with the introduction of AEAD algorithms. So far, no uniform and reliable countermeasures have been adopted by email clients to prevent EFAIL-DE and REPLY attacks. Instead, email clients implement a variety of different ad-hoc countermeasures which are only partially effective, cause interoperability problems, and fragment the secure email ecosystem.

Many digital signature schemes rely on random numbers that are unique and non-predictable per signature. Failures of random number generators may have catastrophic effects such as compromising private signature keys. In recent years, many widely-used cryptographic technologies adopted deterministic signature schemes because they are presumed to be safer to implement. In this paper, we analyze the security of deterministic ECDSA and EdDSA signature schemes and show that the elimination of random number generators in these schemes enables new kinds of fault attacks. We formalize these attacks and introduce practical attack scenarios against EdDSA using the Rowhammer fault attack. EdDSA is used in many widely used protocols such as TLS, SSH, and IPSec, and we show that these protocols are not vulnerable to our attack. We formalize the necessary requirements of protocols using these deterministic signature schemes to be vulnerable, and discuss mitigation strategies and their effect on fault attacks against deterministic signature schemes.