Encryption — The Content Is Locked, but the Record of Comings and Goings Remains

The Hands a Single Message Passes Through

On the subway ride to work, you send a message to a friend: "Let's meet at 7 PM tonight in front of the office." This text leaves your phone, passes through the subway Wi-Fi and a telecom company's network, stops by the messenger company's computers, and reaches your friend's phone. It feels instantaneous on the screen, but along the way, several entities get their hands on this text.

Who among them can actually read this text? Hearing that it is "protected by cryptography" sounds like nobody can see it. Cryptography hides a great deal in practice, and there are certainly things it fails to hide.

This article follows three questions. How does cryptography alter a text? Depending on where it is locked, who is it hidden from? And what remains even after it is locked? We will use no formulas.

Text That Can Only Be Read With a Key

"See you in front of the office at 7 PM tonight" is text that anyone can read. Plaintext is the original content before encryption, which anyone can read. The text appearing on my screen and the text appearing on my friend's screen are both plaintext.

Encryption is the process of scrambling information so that only someone with a key can restore it to the original content. When you apply encryption to plaintext, a jumble of characters whose meaning cannot be figured out comes out. Ciphertext is content that has gone through encryption and whose meaning cannot be figured out without a key.

Decryption is the process of turning ciphertext back into the original content using a key. The side with the key receives the ciphertext and decrypts it, and the plaintext appears on the screen again. One standard encryption method widely used today is one where the sender and receiver lock and open with the same key (DOI: 10.1109/ccict56684.2022.00039; DOI: 10.6028/nist.fips.197, standard document). Such ciphers where the locking key and the opening key are the same are called symmetric-key ciphers. As a counterpart, there is a method of locking with a public key, which is an open padlock put out for anyone to use, and both were covered in "Keys and Locks — Why a Public Key Is Safe to Publish". Quantum computers are cited as machines that can make the calculations this public key method relies on cheap. The threat of decrypting intercepted ciphertexts later is also discussed together (DOI: 10.55041/isjem08542). Exactly what becomes dangerous is covered in "Will Quantum Computers Really Break All Encryption? — Two Misconceptions: "All" and "Later"".

What encryption stops is reading. Encryption only protects the contents of data; it does not stop someone from intercepting that data in the middle or getting their hands on it itself (DOI: 10.1109/ccict56684.2022.00039). Ciphertext can fall into other people's hands. What encryption promises is only that even if someone else takes it away, they cannot read it without the key.

Publish the Method, Keep the Secret in the Key

The Caesar cipher, frequently introduced as an ancient encryption method, shifts letters by a fixed number of spaces in the alphabet. Simple by modern standards, such old methods are easily broken (DOI: 10.1016/s1353-4858(1070006-4). Because there are only twenty-five possible shift counts, anyone who knows the method can try all the shifts one by one and quickly find the original text.

Modern cryptography does not rely on hiding the method. Kerckhoffs's principle is the rule that the security of a cryptosystem must depend on keeping only the key secret, not on keeping the method secret. This principle is counted among the foundational rules of cryptography (DOI: 10.1109/netwks.2008.6231360). It means systems should be built so that even if the method leaks out, the lock remains secure as long as the key is safe.

The process of choosing a standard cipher demonstrates Kerckhoffs's principle directly. In 1997, the U.S. National Institute of Standards and Technology began a procedure to select a symmetric-key encryption method to protect sensitive (though non-classified) government information. The following year, after receiving fifteen candidates, it asked cryptography researchers to analyze them, and through a final five candidates, selected one as the standard (DOI: 10.6028/jres.106.023). It is a method approved through an international competition (DOI: 10.1080/0161-110291890876). This means researchers looked into the method openly and searched for flaws. Even now that it has become a standard, the method is public, and the only thing kept hidden is the key, which differs for each user.

What if we tried inserting the keys one by one? Brute-force attack is an attack that tries every possible key one by one. The reason the Caesar cipher is broken quickly is also because it has only twenty-five candidates against this attack. The keys of modern standard methods are strings of zeros and ones. A single position that can hold either a zero or a one is called a bit. The key length of the standard method is one of 128 bits, 192 bits, or 256 bits (DOI: 10.6028/nist.fips.197, standard document).

Every time a position is added, the number of key candidates to try doubles. For a 128-bit key, there are as many candidates as 2 multiplied by itself 128 times. In digital forensics as well, strong encryption is treated as a wall that cannot be bypassed without a key or passphrase (DOI: 10.1145/1368506.1368519). However, much like public-key systems, this lock is merely made expensive enough that no one can afford to open it yet, and it has not been proven impossible to open. If the cost of opening it head-on is this expensive, the remaining paths are to get the key into your hands or to look at the unencrypted contents. The subsequent sections follow that ground.

However, if a key is created from a human-memorized password, what needs to be guessed is not a 128-bit key, but that password.

Hiding, Checking, and Changing Format

Encoding is the task of rewriting information into a format that is easy for machines or programs to handle. If you copy a web address and paste it into a messenger, sometimes the Korean characters in the address turn into a string of symbols starting with %; this is encoding. Because the rule for changing it is public and there is no key, any program that knows the rule can turn it back to the original. A string of characters that looks unfamiliar to human eyes is not a secret on its own.

Hashing does another job. A hash is something that compresses any text, no matter how long, down to a single short value of a fixed length, and "What Is a Blockchain — Why a Ledger With No One in Charge Holds Up" covered this mechanism. There is no key to reverse a hash. Entering the same text always produces the same value, and changing even a single character in the text changes the value. Therefore, comparing it with a value received in advance makes it possible to know if the text has been altered. However, because someone who alters it on purpose can also newly calculate the hash value and swap it in, the value to compare it with must be received from a trustworthy source.

Therefore, the two have different roles. The hash used in cryptography is used to detect whether information has been altered, while encryption is used to allow only authorized people to see the information (DOI: 10.1109/sp40001.2021.00010). Even without a key to reverse it, short and common text can be guessed by trying candidates one by one to match the value. This problem, which arises when servers store passwords as hashes, is covered in another part of this series, "Passwords and Passkeys".

The question that separates the three is one. Is a key required to reverse it? Encryption requires a key to reverse, encoding can be reversed by anyone, and hashing leaves no path to reverse it at all.

Locks in Transit, Locks at Rest

Roughly 95% of data moving across the web already travels through encrypted connections. That figure is drawn from recent measurements cited in a 2026 systematic literature review. The same review summarizes that encryption has become the primary means of protecting data both in transit and at rest, and notes that these locks increasingly obscure data used in attacks as well (DOI: 10.55041/isjem08542). Data lives in these two states: while it is in transit, and while it is at rest.

Encryption in transit is the act of locking data along the road as it travels between my device and the other computer. The connection security indicated by the padlock icon in the address bar includes this lock. The padlock only guarantees the lock on the road, not that the site at the end of that road is honest. Once the road ends, the lock also comes off. The data that reaches the other computer is decrypted there, and that computer reads the contents.

Encryption at rest is the act of locking data stored on a disk or server while it is kept there. A feature that locks an entire laptop's storage drive is an example. With such strong encryption built into operating systems, investigators may find themselves unable to extract data from a turned-off computer. That is why investigators must decide whether to dump data from a running computer before turning it off (DOI: 10.1145/1368506.1368519). This means the lock does its job when the device is turned off, and also means the situation is different while it is turned on and the lock is released.

While powered on and in use, encryption keys sit in memory in plain text (DOI: 10.14722/ndss.2014.23125). Memory retains its contents for a few seconds after power is cut, and depending on conditions, much longer than that. There are experiments where someone who physically got hold of a machine found the keys in memory during that window and bypassed several disk encryption products, and researchers noted that to their knowledge there is no simple fix to eliminate this risk (DOI: 10.1145/1506409.1506429, published 2008, reprinted 2009). This attack requires physical possession of the device, and one independent reproduction experiment failed to reproduce it on newer memory chips of that time (DOI: 10.1109/ares.2013.52). Subsequent studies showed that this can bypass even mechanisms on newer chips that scramble memory contents (DOI: 10.1016/j.diin.2016.01.009; DOI: 10.1109/hpca.2017.10).

Data stored on a service company's servers can also be locked. However, cloud server administrators sit in a position where they can remotely inspect a server's memory and disk with root privileges. One research database attached specially designed hardware for that purpose, precisely to keep plain text invisible even to such administrators (DOI: 10.1145/2463676.2467797). If a server cannot read the contents, the work the server used to do also shrinks. Asking a mail server to find only emails containing a specific word among locked emails is one such example, and ways to bridge this trade-off have been studied separately (DOI: 10.1109/secpri.2000.848445).

Where you lock and where you open determines whom you hide from.

Conversations That Even Servers Cannot Read

The servers of a messenger company receive my message and pass it to my friend. If only transit encryption is applied, the message locked along the road is decrypted once it reaches the server. End-to-end encryption is a method where the sender's device locks the message and only the recipient's device opens it, preventing even the servers passing it in between from reading the contents. The servers merely pass the locked text while it remains locked.

One widely used messenger protocol has two devices first agree on a conversation key used only by the two of them, and changes that key anew every time a message is sent. This is a mechanism intended to ensure that even if a key is compromised once, the messages exchanged afterward become secure again. If a device continues to be compromised, this recovery does not happen either. As of 2017, this protocol had been adopted in various places, including two messengers with over 1 billion active users (DOI: 10.1109/eurosp.2017.27).

An analysis from 2017 that translated the core design of this protocol into a mathematical model and examined it stated that within the model they built, they proved the safety of that core and found no major flaws in the design. There had been almost no academic analyses covering this protocol until then, and the authors wrote that they hoped their analysis would serve as a starting point for other analyses (DOI: 10.1109/eurosp.2017.27). This analysis examined the design, not the code of each app or the state of the mobile phone.

A systematic literature review whose journal-level quality was not verified summarized that end-to-end encryption contributes significantly to keeping message secrets, while also noting challenges such as the performance overhead required for encryption and decryption (DOI: 10.69933/0j09nj29). For investigators, this lock acts as a wall. Because data stored on platforms is encrypted, analysis has become difficult, and investigators rely on traces left by messenger apps to find evidence (DOI: 10.1145/3727641). Whether investigative agencies should be granted a way into such conversations is a question where the access needed for investigations conflicts with concerns that such a back door could also be opened to others, and this article does not determine the answer to that.

There are also burdens that remain even with end-to-end encryption. The padlock I used to lock it must truly belong to my friend. Communication using public keys is generally effective against someone who merely eavesdrops on the line, but if the exchange procedure is poorly designed, it can be breached by an active attacker who impersonates others or modifies messages (DOI: 10.1109/tit.1983.1056650). A man-in-the-middle attack, where someone stuck in the middle pretends to be the counterpart to both sides, is such an attack.

The Record of Who Visited Stays

Words spoken inside a locked house cannot be heard from the outside. Still, access logs record who entered and left which house at what time, and how long they stayed. Metadata is the information surrounding the content, such as who sent what to whom and when, rather than the content itself.

A great deal is revealed by metadata alone. Many countries collect large quantities of telephone call metadata, and the principle that communication metadata receives much weaker protection than its content has been a subject of controversy (PMID 27185922). Telephone call metadata is densely interconnected, can be easily re-identified, and can be used to infer sensitive facts. This is the result shown by a 2016 study that gathered call logs directly from participants (PMID 27185922). This means that by simply looking at who called whom and when, a great deal can be guessed about a person.

Furthermore, even when content is encrypted, hiding metadata is not easy. This was pointed out by a 2012 study on peer-to-peer social networks without a central authority. In a structure where a central service company exists, that company mediates all contacts and shields users from seeing each other's metadata. Instead, everything gathers in that single company, and researchers designate such a gathering place as the most formidable attacker. Without a central authority, that attacker disappears, but the barrier between users vanishes with it (DOI: 10.1109/percomw.2012.6197506).

The same holds true along the road. Even over encrypted connections, attacks have been studied that analyze the metadata generated during communication to figure out which website a user visited. There are also studies targeting anonymous communication systems created to protect users (DOI: 10.1145/3576915.3623107). Without reading a single character of the content, the destination is guessed purely from the shape of the exchanged data.

There are also research systems that attempt to hide even metadata. One research prototype from 2016 initiated conversations while hiding who connected with whom; in an experiment handling 10 million users across three servers, it took an average of 150 seconds to ring the other party and initiate a connection (DOI: 10.5555/3026877.3026921). The systems on both the sending and receiving ends of the messages had to constantly mix in fake messages to avoid detection, which created a heavy burden. A system from 2018 reduced this burden to produce a 6.8-second delay at a scale of 2 million users, making it 5 to 10 times faster than the two previous systems compared (DOI: 10.5555/3291168.3291221). Both are results measured from prototypes of designs proposed by their respective research teams. The path to hiding metadata exists, and in these prototypes, time and overhead were paid as the price.

Just what can be guessed through metadata is covered in another part of this series, "Personal Data and Anonymization".

Leaks Outside the Lock

There are programs that secretly record the keys you press. These programs usually run without the user knowing (DOI: 10.1109/ccict56684.2022.00039). Messages are plain text while you type them, and the lock is applied afterward. On the receiving end as well, they only appear on the screen after the lock is removed. Therefore, in front of programs that spy on the device itself, even end-to-end encryption cannot protect the contents of that device. How programs created to cause harm without the user's knowledge get onto a device is covered in other parts of this series, "Security" and "Phishing and Social Engineering".

The second place is the code that handles encryption. When used properly, encryption can protect information from attackers. Yet news of major data leaks is frequent. A 2015 paper pointed out that a significant portion of them stem from misusing cryptographic devices, and that the problem lies in the fact that many developers building apps are not cryptography experts (DOI: 10.1145/2814228.2814229). Ways of misusing it include exposed secrets in the code or random values that others can guess (DOI: 10.1145/3319535.3345659).

Misuse was common. In a survey published in 2013, examining 11,748 apps on Google Play that used cryptographic features, 88% made at least one mistake (DOI: 10.1145/2508859.2516693). The weight of each mistake varies. A 2020 survey examining public Java projects noted that 85% of the examined cryptographic features were being misused, but not all of those mistakes led to severe consequences. The authors concluded that blindly blaming developers for such mistakes could lead to wrong conclusions (DOI: 10.1145/3382494.3422166). In a 2018 survey tracing the source, in 90% of problematic Android apps, the mistakes came from external code bundles the app had brought in (DOI: 10.1145/3196494.3196538).

The locking devices inside the device can also be flawed. When analyzing the self-encryption of storage devices made by three manufacturers between 2014 and 2018, many models allowed all data to be recovered without knowing secrets like passwords. Encryption software inside widely used operating systems simply left it to that hardware encryption if the storage device reported supporting this feature. The authors estimated that this situation spanned roughly 60% of the market. This does not mean that products accounting for 60% of the market were all cracked. And they concluded that one should not rely solely on the hardware encryption provided by the storage device, but take additional measures (DOI: 10.1109/sp.2019.00088).

The third place is the moment a key is born. A number where no one can predict what comes next in advance is called a random number. Encryption keys are made from random numbers. If there is a weakness in the process of creating those values, information can leak that allows even the strongest encryption to be cracked (DOI: 10.3390/s20071869). If others can guess the grooves of a key, the key itself is guessed. Even with a 128-bit key, if there are only a few values that can actually come out, a brute-force attack is finished by just plugging in those few. "Random values that others can guess" seen earlier is also a mistake of the same family.

Weak keys created by random number failures actually came out in droves. In 2012, two research teams calculated private keys—keys that only the owner holds and sends nowhere—from 0.5% of internet servers (HTTPS hosts) providing encrypted web connections. The two teams traced the cause to random number generation failures widespread across network devices. This issue was notified to dozens of manufacturers, some of which issued security advisories, and the operating system flaws that played a part in the failure were also fixed. However, a follow-up study four years later in 2016 reported, just as its title suggested, that weak keys still remained widespread in network devices (DOI: 10.1145/2987443.2987486).

Even if the encryption itself is robust, if the code handling keys and devices before locking and after opening, and the random numbers creating the keys, are flawed, the contents leak.

The Journey of a Single Message

Now let us send our initial message again through an end-to-end encrypted messenger. "See you in front of the office at 7 PM today."

While you type it on the keyboard, this text is plain text inside your phone. If a program on your device is peeking at this moment, the locks that come afterward cannot protect this text.

When you press send, the messenger locks the text inside your phone. The key is a conversation key matched with your friend's device. The foundation of this lock is that the key was created as a random number that others cannot guess, and that the code of the app handling that key is written correctly. Furthermore, the padlock you used to lock must genuinely belong to your friend.

What passes through the subway Wi-Fi and the carrier network is ciphertext. An extra layer of transit encryption may be applied here. Even so, when your phone exchanged how much data with the messenger server and at what times remains metadata visible along the way.

The server receives the locked text and passes it to your friend. If that padlock truly belongs to your friend, the server cannot read the contents. Who sent what to whom and when is metadata, not contents, so it is not what end-to-end encryption locks away.

When your friend's phone decrypts the text with the key, the plain text appears on the screen again. The conversations remaining on the phone can be locked again with at-rest encryption, but while the phone is turned on and in use, the decrypted contents move back and forth on the screen. Anyone who can unlock the phone can read that screen.

What the encryption hides along this path is the content of the text. What it fails to hide is the time it was sent, the counterpart, and the plain text on both screens. End-to-end encryption hides the contents from anyone without the key, but by itself, it does not hide who exchanged how much data with whom and when, nor the contents inside the device before locking or after opening. A robust encryption implemented properly is difficult to open head-on without the key using currently known methods, and all the leaky spots gathered in this piece existed outside that padlock. However, this list is a selection of cases and not the result of counting accidents.

Where to Read More

The public-key method that separates the locking tool from the opening tool, along with the story of name tags that verify whether the other party's lock is genuine, can be found in "Keys and Locks — Why a Public Key Is Safe to Publish". One way to protect the place that issues those name tags is covered in "What Does the Padlock in Your Address Bar Actually Guarantee? — Instead of Picking a Trustworthy Authority, the Web Decided to Write Every Issuance Down".

How hashes are used as seals for a ledger is in "What Is a Blockchain — Why a Ledger With No One in Charge Holds Up". The device that proves a statement is true without revealing its contents is found in "Zero-Knowledge Proofs: Proving the Truth Without Revealing the Data".

The day when the computational costs that cryptography relies on become cheap leads to "Will Quantum Computers Really Break All Encryption? — Two Misconceptions: "All" and "Later"".

Another piece in this series, "Personal Data and Anonymization", deals with what is revealed in metadata, while "Passwords and Passkeys" covers how servers store passwords.

Source Papers

• "A Systematic Review of Encryption and Keylogging for Computer System Security" (2022) — DOI: 10.1109/ccict56684.2022.00039 — Encryption allows access only to those with the password or key and protects the contents, but does not prevent interception or access itself. Symmetric key standards use the same key for both sender and receiver. Keyloggers typically record pressed keys without the user's knowledge.
• "Advanced Encryption Standard (AES)" (2001, standard document) — DOI: 10.6028/nist.fips.197 — A symmetric block cipher. Encryption turns data into unreadable ciphertext, and decryption turns it back into the original plaintext. Key lengths are 128, 192, and 256 bits.
• "Advanced Encryption Standard (AES)" (2009) — DOI: 10.1016/s1353-4858(1070006-4 — Older methods like the Caesar cipher look very simple today and are easily broken.
• "Kerckhoffs' principle for intrusion detection" (2008) — DOI: 10.1109/netwks.2008.6231360 — The fundamental principle of cryptography: The security of a system must depend only on keeping the key secret, not the algorithm (Kerckhoffs' principle). It proposes applying this to intrusion detection.
• "Report on the development of the Advanced Encryption Standard (AES)" (2001) — DOI: 10.6028/jres.106.023 — In 1997, NIST began the symmetric key cipher selection process; in 1998, it received 15 candidates, asked the research community to analyze them, narrowed them down to 5 finalists, and selected Rijndael as the standard.
• "THE ADVANCED ENCRYPTION STANDARD" (2002) — DOI: 10.1080/0161-110291890876 — AES was approved by NIST following an international competition.
• "The impact of full disk encryption on digital forensics" (2008) — DOI: 10.1145/1368506.1368519 — Strong encryption cannot be bypassed without a key or passphrase, and once turned off, data may be inaccessible, so investigators must decide whether to collect data while the system is powered on.
• "Encryption in Compute Networks: A Systematic Literature Review …" (2026) — DOI: 10.55041/isjem08542 — Encryption is the primary means of protecting data in transit and at rest. Recent measurements show that about 95% of web traffic uses HTTPS. Challenges include quantum threats such as harvesting now and decrypting later.
• "CRYLOGGER: Detecting Crypto Misuses Dynamically" (2021) — DOI: 10.1109/sp40001.2021.00010 — Cryptographic hashes can guarantee integrity, and encryption algorithms can guarantee confidentiality. Developers misuse them with hardcoded keys, weak passwords, and other flaws.
• "Copker: Computing with Private Keys without RAM" (2014) — DOI: 10.14722/ndss.2014.23125 — Cryptographic keys actually reside in memory as plaintext, making them vulnerable to physical memory attacks. It proposes a method that performs computations exclusively inside the CPU.
• "Lest we remember" (2009) — DOI: 10.1145/1506409.1506429 — Memory retains its contents for several seconds even after power is cut, limiting its ability to protect keys from physical access attackers. Several disk encryption products were breached. There is no simple known solution.
• "On the Practicability of Cold Boot Attacks" (2013) — DOI: 10.1109/ares.2013.52 — Independently reproducing the original research, it generally matched for DDR1 and DDR2, but could not be reproduced on the latest DDR3 chips (5 out of 17 systems used DDR3).
• "Lest we forget: Cold-boot attacks on scrambled DDR3 memory" (2016) — DOI: 10.1016/j.diin.2016.01.009 — By undoing Intel memory scrambling, this attack made cold boot attacks possible once again.
• "Cold Boot Attacks are Still Hot" (2017) — DOI: 10.1109/hpca.2017.10 — Enhanced scramblers in DDR4 also failed to fully prevent cold boot attacks, allowing disk encryption keys to be extracted. Strong full memory encryption is necessary.
• "Secure database-as-a-service with Cipherbase" (2013) — DOI: 10.1145/2463676.2467797 — Cloud administrators with root privileges can remotely view server memory and disk. Encryption is the foundational mechanism for confidentiality, and a trusted hardware-integrated database is demonstrated that prevents even administrators from seeing plaintext.
• "Practical techniques for searches on encrypted data" (2002) — DOI: 10.1109/secpri.2000.848445 — Encrypting data on a server usually sacrifices functionality (searching). It proposes a provable technique that allows servers to search without knowing the plaintext.
• "A Formal Security Analysis of the Signal Messaging Protocol" (2017) — DOI: 10.1109/eurosp.2017.27 — An end-to-end encrypted messaging protocol. It updates (ratchets) session keys for every message to aim for future secrecy and post-compromise security. It has been adopted by multiple services, including two with over 1 billion active users. As the first academic analysis, it proved its core properties and found no major flaws in the design.
• "Analysis of the Effectiveness of End-to-End Encryption in Chatting Applications on User Data Security: A Systematic Literature Review" (2025) — DOI: 10.69933/0j09nj29 — End-to-end encryption significantly contributes to message confidentiality, the prevention of data theft, and integrity, while facing technical challenges such as performance overhead.
• "A Systematic Literature Review of Secure Instant Messaging Applications from a Digital Forensics Perspective" (2025) — DOI: 10.1145/3727641 — The spread of end-to-end encryption has made forensic analysis difficult, leaving investigators to rely on artifacts generated by apps.
• "On the security of public key protocols" (1983) — DOI: 10.1109/tit.1983.1056650 — Public key systems are generally effective against passive eavesdroppers, but poorly designed protocols can be vulnerable to active attackers who impersonate or tamper.
• "The devil is in the metadata — New privacy challenges in Decentralised Online Social Networks" (2012) — DOI: 10.1109/percomw.2012.6197506 — Even when contents are encrypted, hiding metadata is not easy. In centralized systems, operators obscure metadata, but decentralization removes that protection. Metadata inference can infringe on privacy.
• "Transformer-based Model for Multi-tab Website Fingerprinting Attack" (2023) — DOI: 10.1145/3576915.3623107 — Even over anonymous communication systems, the websites visited can be identified by analyzing the metadata of encrypted connections. It proposes a multi-tab attack model.
• "Alpenhorn: bootstrapping secure communication without leaking metadata" (2016) — DOI: 10.5555/3026877.3026921 — A system that initiates encrypted connections while hiding metadata (who connected with whom). Prototype: 3 servers, 10 million users, and an average connection latency of 150 seconds.
• "Karaoke: distributed private messaging immune to passive traffic analysis" (2018) — DOI: 10.5555/3291168.3291221 — Private messaging with hidden metadata. Earlier systems imposed a heavy burden by continuously adding dummy messages; this reduced that burden to a 6.8-second latency for 2 million users.
• "Towards secure integration of cryptographic software" (2015) — DOI: 10.1145/2814228.2814229 — Cryptography can provably protect information, but a significant portion of major breaches stems from misuse. Many developers are not cryptography experts.
• "CryptoGuard" (2019) — DOI: 10.1145/3319535.3345659 — Cryptographic API misuses, such as exposed secrets, predictable random numbers, and vulnerable certificate checks, threaten software security. It is a detection tool with reduced false positives.
• "An empirical study of cryptographic misuse in android applications" (2013) — DOI: 10.1145/2508859.2516693 — Out of 11,748 Google Play apps using cryptographic APIs, 10,327 (88%) made at least one mistake.
• "Java Cryptography Uses in the Wild" (2020) — DOI: 10.1145/3382494.3422166 — While 85% of cryptographic APIs are misused, not all misuses lead to severe consequences. Blaming developers indiscriminately can lead to flawed conclusions.
• "Source Attribution of Cryptographic API Misuse in Android Applications" (2018) — DOI: 10.1145/3196494.3196538 — An analysis of 132,000 apps. In 90% of the violating apps, the misuse originated from third-party libraries.
• "Self-Encrypting Deception: Weaknesses in the Encryption of Solid State Drives" (2019) — DOI: 10.1109/sp.2019.00088 — Weaknesses in the hardware encryption of solid-state drives from three manufacturers between 2014 and 2018 allowed all data to be recovered without a secret. Operating systems delegated encryption solely to the hardware. Market share is roughly 60%. Additional measures should be taken rather than relying solely on hardware encryption.
• "Evaluating the privacy properties of telephone metadata." (2016) — PMID 27185922 — Crowdsourced telephone metadata is densely connected, easily re-identified, and can be used for sensitive inferences.
• "Weak Keys Remain Widespread in Network Devices" (2016) — DOI: 10.1145/2987443.2987486 — In 2012, two research teams computed RSA private keys from 0.5% of Internet HTTPS hosts, tracing the cause to widespread random number generation failures in network devices. Dozens of manufacturers were notified, some security advisories were issued, and entropy flaws during Linux kernel boot were patched. The conclusion is just as the title states: "Weak Keys Remain Widespread in Network Devices" (the abstract consists of only three background sentences).
• "Cryptographically Secure Pseudo-Random Number Generator IP-Core Based on SHA2 Algorithm" (2020) — DOI: 10.3390/s20071869 — Random numbers are used to generate cryptographic keys, and weaknesses in the key generation process can leak information that breaks even the strongest cryptography. It designs a hardware generator.