In an extraordinary essay, the former FBI general counsel Jim Baker makes the case for strong encryption over government-mandated backdoors:

All public safety officials should think of protecting the cybersecurity of the United States as an essential part of their core mission to protect the American people and uphold the Constitution. And they should be doing so even if there will be real and painful costs associated with such a cybersecurity-forward orientation. The stakes are too high and our current cybersecurity situation too grave to adopt a different approach.

Basically, he argues that the security value of strong encryption greatly outweighs the security value of encryption that can be bypassed. He endorses a "defense dominant" strategy for Internet security.

Baker joins the growing list of former law enforcement and national security senior officials who have come out in favor of strong encryption over backdoors: Michael Hayden, Michael Chertoff, Richard Clarke, Ash Carter, William Lynn, and Mike McConnell.

Edward Snowden also agrees.

EDITED TO ADD: Good commentary from Cory Doctorow.

There's a lot to argue with about the methodology and the assumptions. I don't know if I buy that the benefits of AES to the economy are in the billions of dollars, mostly because we in the cryptographic community would have come up with alternative algorithms to triple-DES that would have been accepted and used. Still, I like seeing this kind of analysis about security infrastructure. Security is an enabling technology; it doesn't do anything by itself, but instead allows all sorts of things to be done. And I certainly agree that the benefits of a standardized encryption algorithm that we all trust and use outweigh the cost by orders of magnitude.

ctmg is an encrypted container manager for Linux using cryptsetup and various standard file system utilities. Containers have the extension .ct and are mounted at a directory of the same name, but without the extension. Very simple to understand, and very simple to implement; ctmg is a simple bash script.

In Neal Stephenson's novel Cryptonomicon, the character Enoch Root describes a cryptosystem code-named "Pontifex" to another character named Randy Waterhouse, and later reveals that the steps of the algorithm are intended to be carried out using a deck of playing cards. These two characters go on to exchange several encrypted messages using this system. The system is called "Solitaire" (in the novel, "Pontifex" is a code name intended to temporarily conceal the fact that it employs a deck of cards) and I designed it to allow field agents to communicate securely without having to rely on electronics or having to carry incriminating tools. An agent might be in a situation where he just does not have access to a computer, or may be prosecuted if he has tools for secret communication. But a deck of cards...what harm is that?

Solitaire gets its security from the inherent randomness in a shuffled deck of cards. By manipulating this deck, a communicant can create a string of "random" letters that he then combines with his message. Of course Solitaire can be simulated on a computer, but it is designed to be implemented by hand.

Solitaire may be low-tech, but its security is intended to be high-tech. I designed Solitaire to be secure even against the most well-funded military adversaries with the biggest computers and the smartest cryptanalysts. Of course, there is no guarantee that someone won't find a clever attack against Solitaire (watch this space for updates), but the algorithm is certainly better than any other pencil-and-paper cipher I've ever seen.

It's not fast, though. It can take an evening to encrypt or decrypt a reasonably long message. In David Kahn's book Kahn on Codes, he describes a real pencil-and-paper cipher used by a Soviet spy. Both the Soviet algorithm and Solitaire take about the same amount of time to encrypt a message: most of an evening.

In 1999, I invented the Solitaire encryption algorithm, designed to manually encrypt data using a deck of cards. It was written into the plot of Neal Stephenson's novel Cryptonomicon, and I even wrote an afterward to the book describing the cipher.

I don't talk about it much, mostly because I made a dumb mistake that resulted in the algorithm not being reversible. Still, for the short message lengths you're likely to use a manual cipher for, it's still secure and will likely remain secure.

Readers of Neal Stephenson's "Cryptonomicon" will be familiar with the cipher "Solitaire" (called "Pontifex" in the book), which was designed by cryptologist Bruce Schneier specifically for the purposes of the book. It is intended to be the first truly secure hand cipher, and requires only a pack of cards for encryption and decryption.

As yet, the technical information about the design of the cipher has not been made available, but I decided to go investigating, and I've now written a fast "C" implementation of the cipher suitable for collecting statistics about the CPRNG at its heart. I have found two interesting facts:

• The CPRNG state machine is not reversible, contrary to what the operational notes claim: the initial step in which a joker is moved to the top if it is on the bottom cannot be reversed. This is surprising since non-reversible CPRNGs tend to have shorter periods and can more easily exhibit bias.
• And indeed, the output of the CPRNG is very biased. The output of each step of the CPRNG is a number from 0 to 25; you would expect successive outputs to be the same around one time in 26, but my experiments show that the frequency is closer to 1/22.5.

I'm making the source code for the tests I ran available to the public domain.

Critically, these systems must be as secure as we can make them. As former FCC Commissioner Tom Wheeler has explained, there's a lot more to securing 5G than keeping Chinese equipment out of the network. This means we have to give up the fantasy that law enforcement can have back doors to aid criminal investigations without also weakening these systems. The world uses one network, and there can only be one answer: Either everyone gets to spy, or no one gets to spy. And as these systems become more critical to national security, a network secure from all eavesdroppers becomes more important.

[Ryan Flowers] writes in with a clever little hack that can allow you to hide data where nobody is going to go looking for it. By exploiting the fact that a web server will generally log all HTTP r…//

As [Ryan] demonstrates, you can compress a text file, encode it with uuencode, and then send it line by line to the destination server with curl. He shows how the process, which he calls “CurlyTP” can be done manually on the command line, but it would be a simple matter of wrapping it up in a Bash script.

To get the message back, you just do the opposite. Use grep to find the lines in the log file that contain the encoded data, and then put them through uudecode to get the original text back. Finding the appropriate lines in the log file is made easier by prepending a prearranged keyword to the beginning of the URL requests. The keyword can be changed for each message to make things easier to keep track of.

If you’re still wondering why anyone would go through the trouble to do this, [Ryan] provides an excellent example: a covert “dead drop” where people could leave messages they’d rather not send through the usual channels.

But after all this talk of GPUs and algorithms and hash speeds there’s one really, really simple solution that will take you 60 seconds to implement and will make your passwords near uncrackable. It’s this:

<add name="AspNetSqlMembershipProvider" minRequiredPasswordLength="30" 

minRequiredNonalphanumericCharacters="5" />

That’s it – increase the length and complexity requirements to the point that it’s highly likely any chosen passwords will be unique, not to mention outside the range of most default cracking patterns. Of course unfortunately, nobody in their right mind is going to demand this degree of complexity because most users don’t have a means of tracking unmemorable passwords. It’s a shame though because that’s pretty much all our cracking problems solved right there.

But let me wrap this up with the following quote from the preface of Bruce Schneier’s Applied Cryptography:

There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files.

This does indeed appear to be the case and unfortunately SHA is now firmly in the former category.

fast hashes are killing our security.

But let’s get a bit of context here – do we really need to be able to generate 4.7 billion password hashes per second? That’s like taking the entire Facebook population of over 900 million and sequentially hashing every single password 5 times every second. And that’s on consumer hardware. No, we don’t need to get anywhere even close to that.

The problem is that algorithms like MD5 and SHA were designed to demonstrate data integrity at high computational speed rather than to provide a password storage mechanism; cryptographic hash functions are not password hash functions. Even if they were “safe” for password storage when designed, MD5 goes back 20 years now so by Moore’s Law we now have processors that are now eight thousand times faster.

There are various approaches for breathing life back into old algorithms; key stretching, for example, where an algorithm which is too fast is “slowed” by repeating it over and over again, perhaps thousands of times. But the guidance around the likes of MD5 and SHA is clear and OWASP summarises it quite succinctly:

General hashing algorithms (eg, MD5, SHA-1/256/512) are not recommended for password storage. Instead an algorithm specifically designed for the purpose should be used.

What we need is a hashing algorithm which was designed from the ground up with speed in mind, not fast speed, but slow speed.
The concept of increasing the effort required to execute the hash function is one that is frequently implemented by key stretching and indeed this is modus operandi of PBKDF2. In fact PBKDF2 may then be applied to an algorithm such as SHA so strictly speaking, SHA is still being used, just not as we know it in its single iteration form. //

the thing about algorithms like these is that they’re adaptive:

Over time it can be made slower and slower so it remains resistant to specific brute-force search attacks against the hash and the salt.

Clearly the ability to increase the workload is important if we don’t want to be caught by Moore’s law again in the near future. All we need is a way to integrate this into our existing work.

There are 195 countries in the world. If we assume that each country would want its own backdoor that means there will be 195 backdoors or master keys for every encrypted application.

If we also assume that on average only 100 people per country have access to the back door (a ludicrously low number) that means that around the world encryption relies on almost 20,000 people being completely honest, not willing to be bribed and not capable of being coerced. The likely reality is that the number of people with access to the back door would be a lot higher.

Basically that means no security whatsoever...apart from those really bad people who create their own, after all it is just math.

"The FBI says they're 'going dark.' Well yeah, because they've been staring at the sun." //

So, is surveillance really "going dark"? Or is this, as Graham suggested, "a Golden Age of Surveillance," where even more privacy is required? Joseph Lorenzo Hall, Chief Technologist at the Center for Democracy and Technology (CDT), leans toward the latter.

"The FBI says they're 'going dark'," Hall told Ars. "Well yeah, because they've been staring at the sun." //

HTTPS has had the biggest effect so far, and the changes in TLS will further close the door on surveillance. In 2013, less than 30% of Web traffic was encrypted, and less than 10% of websites supported secure connections. By 2017, more than half of the Web supported HTTPS, and today over 70% of Web traffic is encrypted, based on data from Google and Let's Encrypt. As of April 2019, 91% of webpages visited by US users were secured. Internationally, about 85% of webpages visited were encrypted.

Adoption of encryption for email traffic—both between client and server and from provider to provider—also grew dramatically as a direct result of the Snowden revelations. In early 2014, only about a quarter of the email traffic between Google and other providers was encrypted. Now, it's over 75%.

Some SSDs advertise support for “hardware encryption.” If you enable BitLocker on Windows, Microsoft trusts your SSD and doesn’t do anything. But researchers have found that many SSDs are doing a terrible job, which means BitLocker isn’t providing secure encryption.

Update: Microsoft has issued a security advisory about this problem. It includes a command you can use to check whether you’re using hardware or software encryption. //

Some SSDs advertise support for “hardware encryption.” If you enable BitLocker on Windows, Microsoft trusts your SSD and doesn’t do anything. But researchers have found that many SSDs are doing a terrible job, which means BitLocker isn’t providing secure encryption.

Update: Microsoft has issued a security advisory about this problem. It includes a command you can use to check whether you’re using hardware or software encryption.

Description: In this lecture, Professor Devadas continues with cryptography, introducing encryption methods.

Cryptography is an indispensable tool for protecting information in computer systems. This course explains the inner workings of cryptographic primitives and how to correctly use them. Students will learn how to reason about the security of cryptographic constructions and how to apply this knowledge to real-world applications. The course begins with a detailed discussion of how two parties who have a shared secret key can communicate securely when a powerful adversary eavesdrops and tampers with traffic. We will examine many deployed protocols and analyze mistakes in existing systems. The second half of the course discusses public-key techniques that let two or more parties generate a shared secret key. We will cover the relevant number theory and discuss public-key encryption and basic key-exchange.

Our mission is to directly connect the world’s devices and enable a new era of decentralized computing.

Our software automatically handles the complexities of networking across physical network boundaries, dealing with mobility, and unifying cloud and edge to free you to spend your time building your projects and running your business. //

After installing and starting the service (which happens automatically on most platforms) your device will generate a ZeroTier address. This is a ten-digit address that looks like 89e92ceee5.

To actually connect to anything you will need to join a network. These have 16-digit network IDs that look like 8056c2e21c000001. You can get a network ID from someone else or you can create your own network at my.zerotier.com.

Free service prevents BGP hijackers from fraudulently obtaining browser-trusted certs. //

Cloudflare will be making a programming interface available for free to all certificate authorities. The multipath check for domain control validation consists of two services: agents that perform domain validation out of a specific datacenter, and a domain validation “orchestrator” that handles multipath requests from CAs and dispatches them to a subset of agents.

When a CA wants to ensure a domain validation hasn’t been intercepted, it can send a request to the Cloudflare API that specifies the type of check it wants. The orchestrator then forwards a request to more than 20 randomly selected agents in different datacenters. Each agent performs the domain validation request and forwards the result to the orchestrator, which aggregates what each agent observed and returns the results to the CA. //

Sullivan said Cloudflare is offering the service for free because the company believes that attacks on the certificate authority system harms the security of the entire Internet. He said he expects the use of multipath domain validation to become standard practice, particularly if it’s offered by other large networks.

Banksy's anonymity makes it hard to authenticate his pieces and prints, so Banksy has created a nonprofit called "Pest Control" that issues certificates of authenticity: you send them an alleged Banksy print and £65 and if they agree that it's authentic, they'll return it with a certificate that has a torn-in-half "Di-faced" fake banknote with Lady Diana's face on it, with a handwritten ID number across the bill.

As Clinton Freeman points out, this is a great piece of cryptographic engineering: faking a Banksy cert involves matching the tear precisely, and also requires that a would-be counterfeiter know what was written on the other half of the note, which is stored at Pest Control and is not made available. //

Can an information system be art? Because, like I said, it’s flipping sweet, and all executed in Banksy’s trademark tongue in cheek style. This whole authentication process would easily be my favourite artwork by Banksy.

Everest is a recursive acronym: It stands for the “Everest VERified End-to-end Secure Transport”. //

Project Everest addresses this problem by constructing a high-performance, standards-compliant, formally verified implementation of components in HTTPS ecosystem, including TLS, the main protocol at the heart of HTTPS, as well as the main underlying cryptographic algorithms such as AES, SHA2 or X25519. //

We aim for our verified components to be drop-in replacements suitable for use in mainstream web browsers, servers, and other popular tools and are actively working with the community at large to improve the ecosystem.

Project Everest is the combination of the following projects. Read below for an easy way to install all these projects together.

• F*, a verification language for effectful programs
• miTLS, reference implementation of the TLS protocol in F*
• KreMLin, a compiler from a subset of F* to C
• HACL, a verified library of cryptographic primitives written in F
• Vale, a domain-specific language for verified cryptographic primitives in assembly
• EverCrypt, a verified crypto provider that combines HACL* and Vale via an agile, multi-platform, self-configuring cryptographic API.

EverCrypt is a formally verified modern cryptographic provider that provides cross-platform support as well as platform-specific optimizations that are automatically enabled if processor support is detected (multiplexing). Furthermore, EverCrypt offers an (agile) API that makes it simple to switch between algorithms (e.g., from SHA2 to SHA3).

EverCrypt is written and verified using the F* programming language, then compiled to a mixture of C (using a dedicated compiler, KreMLin) and assembly.

EverCrypt's formal verification involves using software tools to analyze all possible behaviors of a program and prove mathematically that they comply with the code's specification (i.e., a machine-readable description of the developer's intentions). Unlike software testing, formal verification provides strong guarantees that a program behaves as expected and is free from entire classes of errors.
Portions of EverCrypt are being used in Firefox, the Windows kernel, the Tezos blockchain, and the Wireguard VPN.