This website does readability filtering of other pages. All styles, scripts, forms and ads are stripped. If you want your website excluded or have other feedback, use this form.

Schneier on Security: Blog Entries Tagged cryptography

Schneier on Security

Blog > Entries by Tag >

Entries Tagged “cryptography”

Page 9 of 44

Amateurs Produce Amateur Cryptography

Anyone can design a cipher that he himself cannot break. This is why you should uniformly distrust amateur cryptography, and why you should only use published algorithms that have withstood broad cryptanalysis. All cryptographers know this, but non-cryptographers do not. And this is why we repeatedly see bad amateur cryptography in fielded systems.

The latest is the cryptography in the Open Smart Grid Protocol, which is so bad as to be laughable. From the paper:

Dumb Crypto in Smart Grids: Practical Cryptanalysis of the Open Smart Grid Protocol

Philipp Jovanovic and Samuel Neves

Abstract: This paper analyses the cryptography used in the Open Smart Grid Protocol (OSGP). The authenticated encryption (AE) scheme deployed by OSGP is a non-standard composition of RC4 and a home-brewed MAC, the "OMA digest'."

We present several practical key-recovery attacks against the OMA digest. The first and basic variant can achieve this with a mere 13 queries to an OMA digest oracle and negligible time complexity. A more sophisticated version breaks the OMA digest with only 4 queries and a time complexity of about 2^25 simple operations. A different approach only requires one arbitrary valid plaintext-tag pair, and recovers the key in an average of 144 message verification queries, or one ciphertext-tag pair and 168 ciphertext verification queries.

Since the encryption key is derived from the key used by the OMA digest, our attacks break both confidentiality and authenticity of OSGP.

My still-relevant 1998 essay: "Memo to the Amateur Cipher Designer." And my 1999 essay on cryptographic snake oil.

ThreatPost article. BoingBoing post.

Note: That first sentence has been called "Schneier's Law," although the sentiment is much older.

Posted on May 12, 2015 at 5:41 AMView Comments

More on the NSA's Capabilities

Ross Anderson summarizes a meeting in Princeton where Edward Snowden was "present."

Third, the leaks give us a clear view of an intelligence analyst's workflow. She will mainly look in Xkeyscore which is the Google of 5eyes comint; it's a federated system hoovering up masses of stuff not just from 5eyes own assets but from other countries where the NSA cooperates or pays for access. Data are "ingested" into a vast rolling buffer; an analyst can run a federated search, using a selector (such as an IP address) or fingerprint (something that can be matched against the traffic). There are other such systems: "Dancing oasis" is the middle eastern version. Some xkeyscore assets are actually compromised third-party systems; there are multiple cases of rooted SMS servers that are queried in place and the results exfiltrated. Others involve vast infrastructure, like Tempora. If data in Xkeyscore are marked as of interest, they're moved to Pinwale to be memorialised for 5+ years. This is one function of the MDRs (massive data repositories, now more tactfully renamed mission data repositories) like Utah. At present storage is behind ingestion. Xkeyscore buffer times just depend on volumes and what storage they managed to install, plus what they manage to filter out.

As for crypto capabilities, a lot of stuff is decrypted automatically on ingest (e.g. using a "stolen cert," presumably a private key obtained through hacking). Else the analyst sends the ciphertext to CES and they either decrypt it or say they can't. There's no evidence of a "wow" cryptanalysis; it was key theft, or an implant, or a predicted RNG or supply-chain interference. Cryptanalysis has been seen of RC4, but not of elliptic curve crypto, and there's no sign of exploits against other commonly used algorithms. Of course, the vendors of some products have been coopted, notably skype. Homegrown crypto is routinely problematic, but properly implemented crypto keeps the agency out; gpg ciphertexts with RSA 1024 were returned as fails.

[...]

What else might we learn from the disclosures when designing and implementing crypto? Well, read the disclosures and use your brain. Why did GCHQ bother stealing all the SIM card keys for Iceland from Gemalto, unless they have access to the local GSM radio links? Just look at the roof panels on US or UK embassies, that look like concrete but are actually transparent to RF. So when designing a protocol ask yourself whether a local listener is a serious consideration.

[...]

On the policy front, one of the eye-openers was the scale of intelligence sharing -- it's not just 5 eyes, but 15 or 35 or even 65 once you count all the countries sharing stuff with the NSA. So how does governance work? Quite simply, the NSA doesn't care about policy. Their OGC has 100 lawyers whose job is to "enable the mission"; to figure out loopholes or new interpretations of the law that let stuff get done. How do you restrain this? Could you use courts in other countries, that have stronger human-rights law? The precedents are not encouraging. New Zealand's GCSB was sharing intel with Bangladesh agencies while the NZ government was investigating them for human-rights abuses. Ramstein in Germany is involved in all the drone killings, as fibre is needed to keep latency down low enough for remote vehicle pilots. The problem is that the intelligence agencies figure out ways to shield the authorities from culpability, and this should not happen.

[...]

The spooks' lawyers play games saying for example that they dumped content, but if you know IP address and file size you often have it; and IP address is a good enough pseudonym for most intel / LE use. They deny that they outsource to do legal arbitrage (e.g. NSA spies on Brits and GCHQ returns the favour by spying on Americans). Are they telling the truth? In theory there will be an MOU between NSA and the partner agency stipulating respect for each others' laws, but there can be caveats, such as a classified version which says "this is not a binding legal document." The sad fact is that law and legislators are losing the capability to hold people in the intelligence world to account, and also losing the appetite for it.

Worth reading in full.

Posted on May 11, 2015 at 6:26 AMView Comments

The Eighth Movie-Plot Threat Contest

It's April 1, and time for another Movie-Plot Threat Contest. This year, the theme is Crypto Wars II. Strong encryption is evil, because it prevents the police from solving crimes. (No, really -- that's the argument.) FBI Director James Comey is going to be hard to beat with his heartfelt litany of movie-plot threats:

"We're drifting toward a place where a whole lot of people are going to be looking at us with tears in their eyes," Comey argued, "and say 'What do you mean you can't? My daughter is missing. You have her phone. What do you mean you can't tell me who she was texting with before she disappeared?"

[...]

"I've heard tech executives say privacy should be the paramount virtue," Comey said. "When I hear that, I close my eyes and say, 'Try to imagine what that world looks like where pedophiles can't be seen, kidnappers can't be seen, drug dealers can't be seen.'"

(More Comey here.)

Come on, Comey. You might be able to scare noobs like Rep. John Carter with that talk, but you're going to have to do better if you want to win this contest. We heard this same sort of stuff out of then-FBI director Louis Freeh in 1996 and 1997.

This is the contest: I want a movie-plot threat that shows the evils of encryption. (For those who don't know, a movie-plot threat is a scary-threat story that would make a great movie, but is much too specific to build security policies around. Contest history here.) We've long heard about the evils of the Four Horsemen of the Internet Apocalypse -- terrorists, drug dealers, kidnappers, and child pornographers. (Or maybe they're terrorists, pedophiles, drug dealers, and money launderers; I can never remember.) Try to be more original than that. And nothing too science fictional; today's technology or presumed technology only.

Entries are limited to 500 words -- I check -- and should be posted in the comments. At the end of the month, I'll choose five or so semifinalists, and we can all vote and pick the winner.

The prize will be signed copies of the 20th Anniversary Edition of the 2nd Edition of Applied Cryptography, and the 15th Anniversary Edition of Secrets and Lies, both being published by Wiley this year in an attempt to ride the Data and Goliath bandwagon.

Good luck.

Posted on April 1, 2015 at 6:33 AMView Comments

Threats to Information Integrity

Every year, the Director of National Intelligence publishes an unclassified "Worldwide Threat Assessment." This year's report was published two weeks ago. "Cyber" is the first threat listed, and includes most of what you'd expect from a report like this.

More interesting is this comment about information integrity:

Most of the public discussion regarding cyber threats has focused on the confidentiality and availability of information; cyber espionage undermines confidentiality, whereas denial-of-service operations and data-deletion attacks undermine availability. In the future, however, we might also see more cyber operations that will change or manipulate electronic information in order to compromise its integrity (i.e. accuracy and reliability) instead of deleting it or disrupting access to it. Decisionmaking by senior government officials (civilian and military), corporate executives, investors, or others will be impaired if they cannot trust the information they are receiving.

This speaks directly to the need for strong cryptography to protect the integrity of information.

Posted on March 13, 2015 at 6:05 AMView Comments

FREAK: Security Rollback Attack Against SSL

This week, we learned about an attack called "FREAK" -- "Factoring Attack on RSA-EXPORT Keys" -- that can break the encryption of many websites. Basically, some sites' implementations of secure sockets layer technology, or SSL, contain both strong encryption algorithms and weak encryption algorithms. Connections are supposed to use the strong algorithms, but in many cases an attacker can force the website to use the weaker encryption algorithms and then decrypt the traffic. From Ars Technica:

In recent days, a scan of more than 14 million websites that support the secure sockets layer or transport layer security protocols found that more than 36 percent of them were vulnerable to the decryption attacks. The exploit takes about seven hours to carry out and costs as little as $100 per site.

This is a general class of attack I call "security rollback" attacks. Basically, the attacker forces the system users to revert to a less secure version of their protocol. Think about the last time you used your credit card. The verification procedure involved the retailer's computer connecting with the credit card company. What if you snuck around to the back of the building and severed the retailer's phone lines? Most likely, the retailer would have still accepted your card, but defaulted to making a manual impression of it and maybe looking at your signature. The result: you'll have a much easier time using a stolen card.

In this case, the security flaw was designed in deliberately. Matthew Green writes:

Back in the early 1990s when SSL was first invented at Netscape Corporation, the United States maintained a rigorous regime of export controls for encryption systems. In order to distribute crypto outside of the U.S., companies were required to deliberately "weaken" the strength of encryption keys. For RSA encryption, this implied a maximum allowed key length of 512 bits.

The 512-bit export grade encryption was a compromise between dumb and dumber. In theory it was designed to ensure that the NSA would have the ability to "access" communications, while allegedly providing crypto that was still "good enough" for commercial use. Or if you prefer modern terms, think of it as the original "golden master key."

The need to support export-grade ciphers led to some technical challenges. Since U.S. servers needed to support both strong and weak crypto, the SSL designers used a "cipher suite" negotiation mechanism to identify the best cipher both parties could support. In theory this would allow "strong" clients to negotiate "strong" ciphersuites with servers that supported them, while still providing compatibility to the broken foreign clients.

And that's the problem. The weak algorithms are still there, and can be exploited by attackers.

Fixes are coming. Companies like Apple are quickly rolling out patches. But the vulnerability has been around for over a decade, and almost has certainly used by national intelligence agencies and criminals alike.

This is the generic problem with government-mandated backdoors, key escrow, "golden keys," or whatever you want to call them. We don't know how to design a third-party access system that checks for morality; once we build in such access, we then have to ensure that only the good guys can do it. And we can't. Or, to quote the Economist: "...mathematics applies to just and unjust alike; a flaw that can be exploited by Western governments is vulnerable to anyone who finds it."

This essay previously appeared on the Lawfare blog.

EDITED TO ADD: Microsoft Windows is vulnerable.

Posted on March 6, 2015 at 10:46 AMView Comments

"Surreptitiously Weakening Cryptographic Systems"

New paper: "Surreptitiously Weakening Cryptographic Systems," by Bruce Schneier, Matthew Fredrikson, Tadayoshi Kohno, and Thomas Ristenpart.

Abstract: Revelations over the past couple of years highlight the importance of understanding malicious and surreptitious weakening of cryptographic systems. We provide an overview of this domain, using a number of historical examples to drive development of a weaknesses taxonomy. This allows comparing different approaches to sabotage. We categorize a broader set of potential avenues for weakening systems using this taxonomy, and discuss what future research is needed to provide sabotage-resilient cryptography.

EDITED TO ADD (3/3): News article.

Posted on February 25, 2015 at 6:09 AMView Comments

IRS Encourages Poor Cryptography

I'm not sure what to make of this, or even what it means. The IRS has a standard called IDES: International Data Exchange Service: "The International Data Exchange Service (IDES) is an electronic delivery point where Financial Institutions (FI) and Host Country Tax Authorities (HCTA) can transmit and exchange FATCA data with the United States." It's like IRS data submission, but for other governments and foreign banks.

Buried in one of the documents are the rules for encryption:

While performing AES encryption, there are several settings and options depending on the tool used to perform encryption. IRS recommended settings should be used to maintain compatibility:

  • Cipher Mode: ECB (Electronic Code Book).
  • Salt: No salt value
  • Initialization Vector: No Initialization Vector (IV). If an IV is present, set to all zeros to avoid affecting the encryption.
  • Key Size: 256 bits / 32 bytes ­ Key size should be verified and moving the key across operating systems can affect the key size.
  • Encoding: There can be no special encoding. The file will contain only the raw encrypted bytes.
  • Padding: PKCS#7 or PKCS#5.

ECB? Are they serious?

Posted on February 18, 2015 at 6:42 AMView Comments

Cryptography for Kids

Interesting National Science Foundation award:

In the proposed "CryptoClub" afterschool program, middle-grade students will explore cryptography while applying mathematics to make and break secret codes. The playfulness and mystery of the subject will be engaging to students, and the afterschool environment will allow them to learn at their own pace. Some activities will involve moving around, for example following a trail of encrypted clues to find a hidden treasure, or running back and forth in a relay race, competing to be the first to gather and decrypt the parts of a secret message. Other activities will involve sitting more quietly and thinking deeply about patterns that might help break a code. On the other hand, in the proposed CryptoClub Online approach, the CryptoClub Website will provide additional opportunities for applying and learning cryptography in a playful way. It currently includes cipher tools for encrypting and decrypting, message and joke boards where users decrypt messages or submit their own encrypted messages, historical comics about cryptography, and adventure games that involve secret messages.

Posted on February 13, 2015 at 1:13 PMView Comments

Hiding a Morse Code Message in a Pop Song

In Colombia:

The team began experimenting with Morse code using various percussion instruments and a keyboard. They learned that operators skilled in Morse code can often read the signals at a rate of 40 words per minute ­ but played that fast, the beat would sound like a European Dance track. "We discovered the magic number was 20," says Portela. "You can fit approximately 20 Morse code words into a piece of music the length of a chorus, and it sounds okay."

[...]

Portela says they played with the Morse code using Reason software, which gives each audio channel or instrument its own dedicated track. With a separate visual lane for certain elements, it was possible to match the code to the beat of the song -- and, crucially, blend it in.

Hiding the Morse code took weeks, with constant back-and-forth with Col. Espejo and the military to make sure their men could understand the message. "It was difficult because Morse code is not a musical beat. Sometimes it was too obvious," says Portela. "Other times the code was not understood. And we had to hide it three times in the song to make sure the message was received."

Posted on February 2, 2015 at 7:01 AMView Comments

←Previous 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 Next→

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.