Home Tags Hash Functions

Tag: Hash Functions

Google kills SHA-1 with successful collision attack

It's official: The SHA-1 cryptographic algorithm has been "SHAttered." Google successfully broke SHA-1. Now what?After years of warning that advances in modern computing meant a successful collision attack against SHA-1 was imminent, a team of researchers from Google and Centrum Wiskunde & Informatica (CWI) in the Netherlands have successfully developed the first successful SHA-1 collision.
In practical terms, SHA-1 should not be relied upon for practical security.[ 18 surprising tips for security pros. | Discover how to secure your systems with InfoWorld's Security Report newsletter. ]Modern cryptographic hash functions depend on the fact that the algorithm generates a different cryptographic hash for every file.

A hash collision refers to having two separate files with the same hash.

The fact that cryptographic weaknesses in SHA-1 make certificates using the SHA-1 algorithm potentially vulnerable to collision attacks is well-known.

The National Institute of Standards and Technology deprecated SHA-1 more than five years ago, and experts have been long urging organizations to switch to stronger hash algorithms. Up until now, the only thing going for SHA-1 was the fact that collision attacks were still expensive and theoretical.To read this article in full or to leave a comment, please click here

Encryption in 2016: Small victories add up

Technology development seems to gallop a little faster each year.

But there's always one laggard: encryption. Why the deliberate pace? Because a single, small mistake can cut off communications or shut down businesses. Yet there are times when you take stock—only to discover the encryption landscape seems to have transformed overnight. Now is that time.

Although the changes have been incremental over several years, the net effect is dramatic. Some of those changes began shortly after Edward Snowden's disclosures of the U.S. government’s extensive surveillance apparatus. Others are the natural result of cryptographic ideas reaching the marketplace, says Brent Waters, an associate professor at the University of Texas at Austin and the recipient of the Association for Computing Machinery’s 2015 Grace Murray Hopper Award. “Many of the new tools and applications available are based on research innovations from 2005 and 2006,” Waters says. “We are just realizing what type of crypto functionality is possible.” A step closer to an encrypted world Encrypted web traffic is the first step toward a more secure online world where attackers cannot intercept private communications, financial transactions, or general online activity. Many sites, including Google and Facebook, have turned HTTPS on by default for all users. But for most domain owners, buying and deploying SSL/TLS certificates in order to secure traffic to their sites has been a costly and complicated endeavor. Fortunately, Let’s Encrypt and its free SSL/TLS certificates have transformed the landscape, giving domain owners the tools to turn on HTTPS for their websites easily.

A nonprofit certificate authority run by the Internet Security Research Group, Let’s Encrypt is backed by such internet heavyweights as Mozilla, the Electronic Frontier Foundation, Cisco, and Akamai. How ubiquitous has HTTPS become? In October, Josh Aas, head of Let’s Encrypt and former Mozilla employee, posted a graph from Mozilla Telemetry showing that 50 percent of pages loaded that day used HTTPS, not HTTP. While the graph showed only Firefox users, the figure is still significant, because for the first time, the number of encrypted pages outnumbered unencrypted pages. NSS Labs expects the trend to continue, predicting that 75 percent of all Web traffic will be encrypted by 2019. Free certificate offerings will further accelerate adoption. By next year, the number of publicly trusted free certificates issued will likely outnumber those that are paid for, says Kevin Bocek, vice president of security strategy and threat intelligence at key-management company Venafi. Many enterprises will also start using free services. With certificate cost no longer a consideration, certificate authorities will focus on better tools to securely manage certificates and protect their keys. Speaking of certificate management, after years of warnings that SHA-1 certificates were weak and vulnerable to attack, enterprises are making steady progress toward upgrading to certificates that use SHA-2, the set of cryptographic hash functions succeeding the obsolete SHA-1 algorithm. Major browser makers, including Google, Mozilla, and Microsoft, have pledged to deprecate SHA-1 by the beginning of the year and to start blocking sites still using the older certificates.

Facebook stopped serving SHA-1 connections and saw “no measurable impact,” wrote Facebook production engineer Wojciech Wojtyniak. From May to October 2016, the use of SHA-1 on the web fell from 3.5 percent to less than 1 percent, as measured by Firefox Telemetry.

Enterprises can’t be complacent, though, since recent estimates from Venafi suggest approximately 60 million websites still rely on the insecure encryption algorithm. “We look forward to the industry's movement toward greater use of stronger certificates like SHA-256,” Wojtyniak said. Crypto is still king Cryptography has taken quite a beating over the past few months, with researchers developing cryptographic attacks such as Drown, which can be used to decrypt TLS connections between a user and a server if the server supports SSLv2, and Sweet32, a way to attack encrypted web connections by generating huge amounts of web traffic. Nation-state actors also have encryption in their crosshairs. Late last year, Juniper Networks uncovered spying code implanted in specific models of its firewall and Virtual Private Network appliances. Many experts believe the NSA was involved. Shortly after the cache of hacking tools allegedly belonging to the NSA made its way to underground markets this summer, Cisco discovered a vulnerability in its IOS, IOS XE, and IOS XR software that powers many of its networking devices.

The flaw, which could be used to extract sensitive information from device memory, was similar to the vulnerability exploited by the tools and was related to how the operating system processed the key exchange protocol for VPNs, Cisco said. Even Apple’s iMessage app, the poster child for how companies can bring end-to-end encryption to the masses, had its share of issues.

Cryptography professor Matthew Green and his team of students at Johns Hopkins University were able to develop a practical adaptive chosen ciphertext attack that could decrypt iMessage payloads and attachments under specific circumstances.

The team also found that iMessage lacked the forward secrecy mechanism, meaning attackers could decrypt previously encrypted messages, such as those stored in iCloud.

Forward secrecy works by generating a new key after a set period of time so that even if the attackers obtained the original key, the previously encrypted messages can’t be cracked. One thing remains clear despite all the bad news: Cryptography is not broken.

The mathematics behind cryptographic calculations remain strong, and encryption is still the best way to protect information. “The latest attacks have not been on the math, but on the implementation,” Waters says. In fact, encryption works so well that attackers rely on it, too.

Criminals are equally as capable of obtaining keys and certificates to hide their activities inside encrypted traffic.

The fact that this attack vector is fast becoming default behavior for cybercriminals “almost counteracts the whole purpose of adding more encryption,” Bocek says. Cybercriminals are using encryption to great effect in ransomware. Once the files are encrypted, victims have to either pay up to obtain a key or wipe their systems and start over. Just as attackers target flawed implementations, security researchers have successfully developed decryption tools for ransomware variants that contained mistakes in their encryption code. Government backs down on backdoors Technology firms have always had to balance security and privacy concerns with law enforcement requests for user information.

FBI Director James Comey had been pushing hard for backdoors in technology products using encryption, claiming that increased use of encryption was hindering criminal investigations. While companies frequently quietly cooperate with law enforcement and intelligence requests, the unprecedented public showdown between the FBI and Apple showed that in recent years, enterprises are beginning to push back. The FBI backed down in that fight, and a bipartisan Congressional working group—with members of both House Judiciary and Energy & Commerce Committees—was formed to study the encryption problem.

The House Judiciary Committee’s Encryption Working Group unequivocally rejected Comey's calls for backdoors and advised the United States to explore other solutions. “Any measure that weakens encryption works against the national interest,” the working group wrote in its report. “Congress cannot stop bad actors—at home or overseas—from adopting encryption.

Therefore, the Committees should explore other strategies to address the needs of the law enforcement community.” Weakening encryption so that police can break into encrypted devices would speed up criminal investigations, but it would be a short-term win "against the long-term impacts to the national interest," the working group warned.

Alternative strategies include giving law enforcement legal methods to compel suspects to unlock their devices and improving metadata collection and analysis. While the working group report indicates Congress will not pursue legal backdoors, other encryption-related battles are looming on the horizon.

The report seemed to support letting police use "legal hacking" to break into products using software vulnerabilities that only law enforcement and intelligence authorities know about, which poses its own security implications.

The technology industry has an interest in learning about vulnerabilities as soon as they are found, and not letting the government stockpile them with no oversight. As for Comey's "going dark" claim, the working group said “the challenge appears to be more akin to ‘going spotty.’” Adding to the enterprise tech stack Governments have been trotting out the terrorists “going dark” argument for years and will always play on those fears, says Mike Janke, co-founder and chairman of encrypted communications company Silent Circle. What's changing is that the enterprises are becoming more serious about securing their communications stack and are less willing to compromise on those features. Many organizations were shocked at the extent of government surveillance exposed by former NSA contractor Edward Snowden.

They reacted by integrating secure video and text messaging tools along with encrypted voice calls into the enterprise communications stack, Janke says.

Encryption is now a bigger part of the technology conversation, as enterprises ask about what features and capabilities are available.
IT no longer treats encryption as an added feature to pay extra for, but as a must-have for every product and platform they work with. Consumers were outraged by the surveillance programs, and anecdotal evidence indicates many have signed up for encrypted messaging apps such as WhatsApp and Signal.

But for the most part, they aren't paying for secure products or changing their behaviors to make privacy a bigger part of their daily lives. The change is coming from CSOs, vice presidents of engineering, and other technical enterprise leaders, because they're at the forefront of making security and privacy decisions for their products and services. With Tesla now digitally signing firmware for every single one of its internal components with a cryptographic key, it's easier to ask TV manufacturers or toymakers, "Why aren't you doing that?" says Janke. Consumers are the ones who will benefit from encryption built in by default as enterprises change their mindset about the importance of encryption.  Riding the innovation wave Cryptography tends to go in waves, with important innovations and research from 2005 to 2006 finally coming out as practical applications. Researchers are currently looking at improving the "precision of encrpytion," instead of the current model of all or nothing, where if something is exposed, everything gets leaked. "Encrpytion can be precise like a scalpel, giving fine-grained control over the information," Waters says. Google has looked at cryptography in its experiments with neural networks. Recently, its Google Brain team created two artificial intelligence systems that was able to create their own cryptographic algorithm in order to keep their messages a secret from a third AI instance that was trying to actively decrypt the algorithms. The dawn of quantum computing will also spur new avenues of research. “If large-scale quantum computers are ever built, they will be able to break many of the public-key cryptosystems currently in use,” wrote the National Institute of Standards and Technology in a public notice. Once such machines become widely available, “this would seriously compromise the confidentiality and integrity of digital communications on the Internet and elsewhere." To prepare for that eventuality, NIST is soliciting work on "new public-key cryptography standards," which will "specify one or more additional unclassified, publicly disclosed digital signature, public-key encryption, and key-establishment algorithms that are capable of protecting sensitive government information well into the foreseeable future, including after the advent of quantum computers.” The submission deadline is Nov. 30, 2017, but NIST acknowledges the work will take years to be tested and available, noting that "historically, it has taken almost two decades to deploy our modern public key cryptography infrastructure." “Regardless of whether we can estimate the exact time of the arrival of the quantum computing era, we must begin now to prepare our information security systems to be able to resist quantum computing,” NIST said. There have been a number of intriguing advances in cryptography, but it will likely be years before they become available to enterprise IT departments, and who knows what form they will take.

The future of cryptography promises even more security.

The good news is we are already experiencing some of the benefits now.

Stupid encryption mistakes criminals make

Writing secure code can be challenging, and implementing cryptography correctly in software is just plain hard.

Even experienced developers can get tripped up.

And if your goal is to swindle people quickly, not to wow them with the quality of your software, there are sure to be serious crypto mistakes in your code. Malware authors may provide significant lessons in how not to implement cryptography.
Such was the upshot of research by Check Point’s Yaniv Balmas and Ben Herzog at the recent Virus Bulletin conference in Denver. Malware authors may be more likely to insert crypto doozies in their code than developers working on legitimate software because they may not care as much about code quality or design, said Balmas and Herzog.

These criminals are focused on getting a product that does enough to satisfy their immediate requirements -- and no more. Here’s a look at the crypto mistakes of recent malware headliners -- and how to identify similar missteps in future malware scripts in hopes of cracking their malicious code. Fuzzy-headed thinking on crypto Mistakes are inevitable when you have only a “fuzzy understanding of the details” and a very tight time frame.

Analyzing the work of malware authors, Balmas and Herzog identified four “anti-patterns,” when it came to implementing encryption, including voodoo programming, cargo cult technique, reinventing the square wheel, and bluffing.

Defenders who uncover hints of these categories of mistakes can break the encryption and hinder malware execution, or they can uncover its secrets via reverse-engineering. “These are basic misunderstandings of how to use cryptographic tools properly, which at best broadcast, ‘I have no idea what I am doing,’ and at worst, catastrophically cripple the malware such that it does not actually do what it set out to do,” Balmas and Herzog wrote. Professional or amateurish, these malware authors recognize that cryptography is increasingly essential to malware development -- in ransomware, to extort money from victims; in hiding communications from the infected device to the command-and-control server; in stealthily evading detection by security tools; and in signing malware as a trusted application.

But analysis shows that many appear to have trouble using encryption effectively, to their detriment.
Security analysts and network administrators who recognize the main classes of cryptographic errors have a big advantage in foiling ransom demands and thwarting infections. “Malware authors compose primitives based on gut feeling and superstition; jump with eagerness at opportunities to poorly reinvent the wheel; with equal eagerness, at opportunities to use ready-made code that perfectly solves the wrong problem,” Balmas and Herzog wrote in the conference whitepaper. No idea what this does, but it looks cool The authors behind the Zeus banking Trojan and Linux-based ransomware Linux.Encoder fell into the “voodoo programming” trap.

Their cryptographic implementation “betrays a deep confusion about the functionality being invoked -- what it is, what it does, and why it might fail,” the researchers said. In the case of Zeus, the authors chose popular stream cipher RC4 to encrypt all Zeus C&C traffic, but added another tweak.

They took the already encrypted stream and modified every byte by XORing it with the next byte. While RC4 has its own security weaknesses, the cipher is secure enough to do what Zeus needed, and the tweaked variant was “exactly as secure as plain, vanilla RC4,” the researchers noted. With Linux.Encoder, the authors seeded the rand() function with the current time stamp to generate its encryption key. When security researchers pointed out that it was really easy to break the ransomware keys, the authors tried generating an AES key by hashing the time stamp eight times. “Using a hash function eight consecutive times on an input shows a deep misunderstanding of what hash functions are,” the researchers wrote, noting that repeating the function does not yield a better hash.
In fact, it could result in “an odd creation that has weaker security properties.” Copy and paste this code I found The second class, “cargo cult programming,” refers to copying what looks like a working solution to the problem and pasting that block of code into the program without understanding why or how the code works.

Copying code isn’t a big deal -- if it was, Stack Overflow wouldn’t exist -- but if the programmer doesn’t know what is actually happening in that block, then the programmer doesn’t know whether the code is actually the correct solution. “[They] might end up using code that performs almost what they had in mind, but not quite,” the researchers wrote, noting that the authors behind the CryptoDefense ransomware fell in this trap. While most of CryptoDefense’s features -- RSA-2048 encryption, payment via bitcoin, communication with C&C servers via Tor -- were copied from the original CryptoLocker ransomware, the actual RSA implementation relied on a low-level cryptographic Windows API.

The actual code can be found in Microsoft Developer Network documentation, along with the explanation that when a flag is not set correctly, the application saves the private key in local key storage.

The CryptoDefense authors didn’t set that flag, so security researchers worked with victims to find the private key on their computers to decrypt the files. Because the malware authors didn’t thoroughly read the documentation, the defenders were able to save the day. Cobble together the code The typical software developer would gladly link to an open source project that handles a necessary task and save the time and effort to write it from scratch. Unfortunately for malware authors, compiling with statically linked third-party code is not always an option, as the extra code can enlarge the resulting executable or make it easier for security tools to detect the malware.
Instead of linking, authors tend to improvise and cobble together something that works.

The groups behind the Nuclear exploit kit and the ransomware families Petya and DirCrypt attempted to “reinvent the square wheel,” and to everyone else’s benefit, they did so poorly. “If you believe anything in cryptography is completely straightforward to implement, either you don’t understand cryptography, or it doesn’t understand you,” the researchers wrote. The widely distributed Nuclear exploit kit obfuscates exploit delivery by using the Diffie-Hellman Key Exchange to encrypt the information passed to the payloads.

The variables needed for the key exchange are sent to the server as a JSON file containing strings of hex digits, and the values are parsed and decoded using Base64. However, the researchers noted the implementation was “absurd” as it set the secret key to 0, rendering the whole process useless. Petra’s authors implemented Salsa20, a lesser-known stream cipher that is considered to be more resistant to attacks than RC4, from scratch. However, three major flaws in Petya’s implementation means the ransomware generates a 512-bit key containing 256 bits of constant and predictable values. “When your implementation of a cipher cuts its effective key size by half, and the required time for a break by 25 orders of magnitude, it’s time to go sit in the corner and think about what you’ve done,” the researchers said. DirCrypt didn’t fare much better, as the authors made the common mistake of reusing the same key when encrypting each file with RC4. Key-reuse is an understandable mistake, especially if the person doesn’t have elementary knowledge of how stream ciphers work and how they can fail. However, the group made a bigger mistake by appending the key to the encrypted file.
Victims could directly access the key and use it recover portions of locked files and, in some case, recover entire files. Fake it The last category isn’t actually a coding mistake, but rather the malware author’s intentional social engineering shortcut. Ransomware authors, for example, don’t need to create the “impeccable cryptographic design and implementation” when it’s far easier to lie, Check Point’s Balmas and Herzog said.

Few victims are going to question the malware’s encryption claims when it comes to retrieving their data. This was the case with Nemucod, a JavaScript Trojan that recently transformed into ransomware, which claimed to encrypt files with RSA-1024 encryption when it was actually using a simple rotating XOR cipher. Nemucod also displays the ransom note before the files are actually encrypted, so if the victim’s antivirus or security tools were vigilant enough to prevent the malware from downloading the encryption components, the files remain intact. Similarly, the ransomware Poshcoder originally used AES, instead of either RSA-2048 or RSA-4096 encryption listed on the ransom note. Poshcoder also claims to use strong asymmetric encryption, except AES is a symmetric cipher and is vulnerable to a number of attacks. The group behind Nemucod believes “would-be adversaries will become light-headed and weak in the knees the moment they hear the phrase ‘RSA-1024,’” the researchers wrote, noting that Nemucod “sets the gold standard for minimal effort.” If the victims are scared enough, they may be less likely to take a closer look at the malware’s capabilities. Take advantage of the mistakes Cryptography is hard, and many software developers screw up when trying to implement encryption.

Consider that the Open Web Application Security Project’s Top 10 list of web application vulnerabilities identifies only two common cryptographic mistakes that developers can make.
It’s no surprise the bad guys are struggling, too. “Evidence heavily suggests that most malware authors view those tools as wondrous black boxes of black magic, and figure they should be content if they can get the encryption code to run at all,” the researchers wrote. It’s tempting to pay the ransom or begin restoring from backup right away when files have been locked by ransomware or to assume that there is no way to break open the communications between an infected endpoint and the malware’s C&C servers.
Security analysts and IT administrators willing to take the time to look for these common mistakes in the offending malware may be able to change the outcome.
Someday, the bad guys will learn how to use encryption properly; until then, the defenders have the edge as they can get around broken implementations and coding errors. Related articles

SHA3-256 cipher is quantum-proof, should last BEELLIONS of years, say boffins

Ye Olde asymmetric encryption looks like it can beat the coming of the quantum cats While it's reasonable to assume that a world with real quantum computers will ruin traditional asymmetric encryption, perhaps surprisingly hash functions might survive. That's the conclusion of a group of boffins led by Matthew Amy of Canada's University of Waterloo, in a paper at the International Association of Cryptologic Research. The researchers – which included contributions from the Perimeter Institute for Theoretical Physics and the Canadian Institute for Advanced Research – looked at attacks on SHA-2 and SHA-3 using Grover's algorithm (a quantum algorithm to search "black boxes" - Wikipedia). They reckon both SHA-256 and SHA3-256 need around 2166 “logical qubit cycles” to crack. Perhaps counter-intuitively, the paper says the problem isn't in the quantum computers, but the classical processors needed to manage them. The paper notes: “The main difficulty is that the coherence time of physical qubits is finite. Noise in the physical system will eventually corrupt the state of any long computation.” “Preserving the state of a logical qubit is an active process that requires periodic evaluation of an error detection and correction routine.” If the quantum correction is handled by ASICs running at a few million hashes per second (and if Vulture South's spreadsheet is right), Grover's algorithm would need about 1032 years to crack SHA-256 or SHA3-256. That's considerably longer than the mere 14 billion years the universe has existed, although less than the estimated 10100 years until the heat death of the universe.

Even if you didn't care about the circuit footprint and used a billion-hash-per-second Bitcoin-mining ASIC, the calculation still seems to be in the order of 1029 years. ®

Pass the hash for peace, love and security in the quantum...

Boffins smokin' idea to share parts of keys to cook quantum-proof crypto Digital signatures, one of the fundamental parts of cryptography, may one day be threatened by quantum computers – so crypto-boffins are busy devising schemes that can survive a post-quantum world. In a paper that's just landed at the International Association for Cryptologic Research, a group of UK and Belgian researchers are offering up a dig-sig scheme they reckon is a feasible offering for a post-quantum world. As the paper notes, there are currently two research streams examining what to do if Shor's algorithm* ever arrives to render today's signatures crackable. On one hand, there's research into “quantum-safe” systems, which extend the historical “hard problems” approach to the future.

Today's hard problem, factoring very large prime numbers, is exactly what a quantum computer might achieve, so the quantum-safe system propose new, harder problems. The second, which this paper explores, is a universal approach: an “unconditionally secure signature” (USS) scheme, uncrackable according to mathematical proofs. There's a downside, however: USS systems are symmetrical, depending on secret key distribution; that means key distribution becomes a problem and a vulnerability, and most proposals to handle it depend on a trusted third party. The need to pre-distribute keys disqualifies USS from everyday applications, but the authors argue its high security means it's worth the effort for high-value applications (for example, inter-bank channels). The proposal from Ryan Amiri and Erika Andersson of Heriot-Watt University in Edinburgh, Aysajan Abidin of Belgium's KU Leuven and iMinds, and Petros Wallden of the University of Edinburgh, is to create a USS that does away with third party for key distribution – and doesn't need anonymous communication channels. The neat idea in the impenetrable academic maths of the typical crypto-paper seems to be this one: to make the scheme work, Amiri et al propose that in a group of participants, the sender starts by sharing a set of hashes with everybody else. Recipients then pass around “a random portion of the keys that they received from the sender”.

The recipients can, therefore, share enough of the keys to assure each other the message is authentic, without revealing enough information to compromise the signature. “A signature for a message is a vector of tags generated by applying the hash functions to the message”, the paper continues. For questions of forging, transferability, and non-repudiation, we'll have to defer to those with sufficient mathematics to decipher the rest of the paper. The authors claim that with respect to other USS schemes: ”We require fewer trust assumptions – the protocol does not require a trusted authority. ”Security in our scheme can be tuned independently of message size, resulting in shorter signature lengths. Our scheme scales more efficiently (with respect to message size) in terms of the number of secret shared bits required.” Nice to know the post-quantum world could still be protected, at least. ® *Bootnote: Shor's algorithm is one of the seminal ideas of quantum computing. Published in 1994, it proposed how to use a quantum computer to find the prime factors of any number, faster than a classical computer. ® Sponsored: Global DDoS threat landscape report