Home Tags Ciphertext

Tag: Ciphertext

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.

In the three years since IETF said pervasive monitoring is an...

IETF Security director Stephen Farrell offers a report card on evolving defences FEATURE After three years of work on making the Internet more secure, the Internet Engineering Task Force (IETF) still faces bottlenecks: ordinary peoples' perception of risk, sysadmins worried about how to manage encrypted networks, and – more even than state snooping – an advertising-heavy 'net business model that relies on collecting as much information as possible. In a wide-ranging 45-minute, 4,000-word interview (full transcript in this PDF), IETF Security Area Director Stephen Farrell gave a report card of what's happened since the Internet Architecture Board declared that “pervasive monitoring is an attack”, in RFC 7258. Much of the discussion used Farrell's presentation to the NORDUnet conference in September, and the slides are here. Let's boil the ocean, so we can cook an elephant.

And eat it. Given the sheer scale of the effort involved – the IETF's list of RFCs passed the 8,000 mark in November – nobody expected the world to get a private Internet quickly, but Farrell told The Register some of the key in-IETF efforts have progressed well: its UTA (Using TLS in Applications), DPRIVE (DNS Privacy), and TCPINC (TCP INCreased security, which among other things is working to revive the tcpcrypt proposal rejected earlier in the decade). UTA: The idea is to get rid of the nasty surprises that happen when someone realises a standard (and therefore code written to that standard) still references a “laggard” protocol – so, for example, nobody gets burned complying with a standard that happens to reference a deprecated SSL or TLS standard. “The UTA working group produced RFC 7525 (Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), https://tools.ietf.org/html/rfc7525 here).

The last time I looked, there were something like 50 RFCs that are referencing that [The Register checked this list, provided by Farrell – it seems to be close to 70 already].” The idea of UTA is that a protocol written 10 or 15 years ago should be updated so it no longer references the then-current version of TLS, he said. “That's being used in order to provide a common reference: as people update their implementations, they'll reference a more modern version of TLS, currently TLS 1.2, and as TLS 1.3 is finished, we have an automated-ish way of getting those updates percolating through to the documentation sets. “That's quite successful, I think, because it normalises and updates and modernises a bunch of recommendations.” DNSPRIV: Readers will recall that IETF 97 was the venue for the launch of Stubby, a demonstrator for securing DNS queries from the user to their DNS responder. Stubby, a demonstrator of DNS privacy work That, Farrell said, is a good example of where DNSPRIV is at – on the user side, it's ready for experimental code to go into service. “DNS privacy is something that is ready to experiment with.

The current work in DPRIVE was how to [secure] the hop between and the next DNS provider you talk to. “That's an easy problem to tackle – you talk to that DNS resolver a lot, and you have some shared space, so the overhead of doing the crypto stuff is nowhere.” Getting upstream to where DNS queries become recursive – your ISP can't answer, so they pass the query upwards – is much harder, he said. “Assuming that [the ISP] needs to find “where is theregister.co.uk?”, he'll eventually talk to the UK ccTLD, and then he'll go talk to .co.uk and then he'll go talk to theregister.co.uk – it's forking the communications a lot more, and it's a little harder to see how to efficiently amortise the crypto. “The DPRIVE working group are now examining whether they think they can produce some technology that will work for that part of the problem.” TCPINC: Some of the questions in this working group may never be seen by ordinary Internet users, but they're still important, Farrell said. “I think we're close to having some TCP-crypt-based RFCs issued, there's been code for that all along. Whether or not we'll get much deployment of that, we'll see.” “I think there are a bunch of applications that maybe wouldn't be visible to the general public. Let's say you have an application server that has to run over a socket – an application that runs on top of the Linux kernel, say, where you have to use the kernel because of the interfaces involved, and you can't provide the security above the kernel because you need it inside. “That's where TCPINC fits in.
Storage – they have really complex interfaces between the network-available storage server and the kernel, and there's lots of complex distributed processing going on.” That's important to “the likes of NetApp and EMC and so on”, he said: “For some of those folks, being able to slot in security inside the kernel, with TCPINC, is attractive.
Some, I might expect, will adopt that sort of thing – but it may never be seen on the public Internet.” Security and the end-to-end model Farrell said more encryption is changing the Internet in ways the general public probably doesn't think about – but which they'll appreciate. The old end-to-end model – the “neutral Internet” – has been under both overt and covert attack for years: carriers want to be more than passive bit-pipes, so they look for ways that traffic management can become a revenue stream; while advertisers want access to traffic in transit so they can capture information and inject advertisements. Ubiquitous encryption changes both of these models, by re-empowering the endpoints.

Along the way, perhaps surprisingly, Farrell sees this as something that can make innovation on the Internet more democratic. He cited HTML2 and QUIC as important non-IETF examples: “there's a whole bunch of people motivated to use TLS almost ubiquitously, not only because they care about privacy, but because of performance: it moves the point of control back towards the endpoint, not the middle of the network. “One of the interesting and fun things of trying to improve the security properties and privacy properties of the network is that it changes who controls what. “If you encrypt a session, nobody in the middle can do something like inject advertising. “It reasserts the end-to-end argument in a pretty strong way.
If you do the crypto right, then the middlebox can't jump in and modify things – at least not without being detectable.” He argues that the carrier's / network operators' “middleboxes” became an innovation roadblock. “The real downside of having middleboxes doing things is that they kind of freeze what you're doing, and prevent you innovating. “One of the reasons people did HTTP2 implementations, that only ever talk ciphertext, is because they found a lot of middleboxes would break the connection if they saw anything that wasn't HTTP 1.1. “In other words, the cleartext had the effect that the middleboxes, that were frozen in time, would prevent the edges from innovating. Once they encrypted the HTTP2 traffic, the middleboxes were willing to say 'it's TLS so I won't go near it', and the innovation can kick off again at the edges.” Won't somebody think of the sysadmin? Systems administrators – in enterprises as well as in carriers – are less in love with crypto. “Network management people have been used to managing cleartext networks,” he said. For more than 20 years, for perfectly legitimate reasons – and without betraying their users – sysadmins would look into packets, see what they contained, and when sensible do something about them. “Not for nefarious reasons – in order to detect attacks, in order to optimise traffic, and so on. We're changing that, and that also means the technology they're using will be undergoing change, to deal with much more ciphertext than plaintext. “We need to learn better ways of how to fulfil those same functions on the network,” he said. “If you had some security mechanism in your network for detecting some malware attack traffic, instead of being able to operate that from the middle of the network, it pushes a requirement on you to move that to the edge.” Commercial services are starting to understand how this can work, he said: “If you look at some of the commercial instant messaging providers, that have introduced end-to-end encryption of their messaging – they have found they can move those functions in their networks to new places to do what they need to do. “It means change, but it doesn't make network management impossible.” Advertising models will change Companies collaborating to collect advertising data remains a big challenge, he said.

That's likely to change – “there's no reason why a particular business model has to last forever”, but in the meantime, “it's hard to see how we make a dramatic improvement in privacy. “We can make some improvements, but how we make it dramatically better – it's hard.

The incentives are aligned to make all the service providers want to be privacy-unfriendly, from the point of “me”, but not perhaps the point of view of 99 per cent of people who use the Internet, and seem happy enough with it.” Breaches and leaks are frightening the service providers, which helps, because providers “realise that storing everything, forever, is toxic, and in the end they'll get caught by it.” About the cough NSA coughThe Register also asked: what protects future standards against security organisations polluting standards, as they did with DUAL-EC? “As an open organisation, we need to be open to technical contributions from anywhere,” Farrell said, “be that an employee of the NSA, or be that – as we've had in one case – a teenager from the Ukraine who was commenting on RFCs five or six years ago.” It has to be handled socially, rather than by process, he argued, citing the IETF's creation of the Crypto Forum Research Group, chaired by Alexey Melnikov and Kenny Paterson and designed to bring together IETF standards authors and the academic crypto community. He described it as a “lightweight process” designed to assess crypto proposals – have they been reviewed? Is the proposal novel and maybe not ready for prime time? “The number of NSA employees that attend IETF [meetings] – I don't think it's a useful metric at all.
I think how well peoples' contributions are examined is a much more useful metric, and there, things like having the CFRG, having academic cryptographers interacting much more with the standards community – those are more effective ways of doing that. “We've set up a thing called the Advanced Networking Research Prize, which is a prize for already-published academic work.
It pays for the academic come to an IETF meeting, give us a talk, get them involved” (Paterson first became involved in the CRFG as an invited academic who won the prize). Spooks want to monitor everyone because they believe everyone might be guilty, he added, and that's a mistake. “We should not think people are guilty by association.

That's a fallacy – if you believe that NSA employees are not allowed to contribute, you're making the same mistake they're making.” ®

Google teaches “AIs” to invent their own crypto and avoid eavesdropping

reader comments 18 Share this story Google Brain has created two artificial intelligences that evolved their own cryptographic algorithm to protect their messages from a third AI, which was trying to evolve its own method to crack the AI-generated crypto. The study was a success: the first two AIs learnt how to communicate securely from scratch. Enlarge / The setup of the crypto system. P = input plaintext, K = shared key, C = encrypted text, and PEve and PBob are the computed plaintext outputs. The Google Brain team (which is based out in Mountain View and is separate from Deep Mind in London) started with three fairly vanilla neural networks called Alice, Bob, and Eve. Each neural network was given a very specific goal: Alice had to send a secure message to Bob; Bob had to try and decrypt the message; and Eve had to try and eavesdrop on the message and try to decrypt it. Alice and Bob have one advantage over Eve: they start with a shared secret key (i.e. this is symmetric encryption). Importantly, the AIs were not told how to encrypt stuff, or what crypto techniques to use: they were just given a loss function (a failure condition), and then they got on with it. In Eve's case, the loss function was very simple: the distance, measured in correct and incorrect bits, between Alice's original input plaintext and its guess. For Alice and Bob the loss function was a bit more complex: if Bob's guess (again measured in bits) was too far from the original input plaintext, it was a loss; for Alice, if Eve's guesses are better than random guessing, it's a loss. And thus an adversarial generative network (GAN) was created. Alice, Bob, and Eve all shared the same "mix and transform" neural network architecture, but they were initialised independently and had no connection other Alice and Bob's shared key. For Alice the key and plaintext are input into the first layer of the neural network; for Bob the key and the ciphertext were input; and for Eve, she got just the ciphertext. The first layer is fully-connected, so the text and key can mix about. Following the first layer there are a number of convolutional layers, which learn to apply a function to the bits that were handed to it by the previous layer. They don't know what that function might be; they just learn as they go along. For Alice, the final layer spits out some ciphertext; Bob and Eve output what they hope is the plaintext. Enlarge / Bob and Eve's reconstruction errors during training. You can see that Eve starts to improve, but then a change in the Alice-Bob crypto method shuts her out again. The results were... a mixed bag. Some runs were a complete flop, with Bob never able to reconstruct Alice's messages. Most of the time, Alice and Bob did manage to evolve a system where they could communicate with very few errors. In some tests, Eve showed an improvement over random guessing, but Alice and Bob then usually responded by improving their cryptography technique until Eve had no chance (see graph). The researchers didn't perform an exhaustive analysis of the encryption methods devised by Alice and Bob, but for one specific training run they observed that it was both key- and plaintext-dependent. "However, it is not simply XOR. In particular, the output values are often floating-point values other than 0 and 1," they said. In conclusion, the researchers—Martín Abadi and David G. Andersen—said that neural networks can indeed learn to protect their communications, just by telling Alice to value secrecy above all else—and importantly, that secrecy can be obtained without prescribing a certain set of cryptographic algorithms. There is more to cryptography than just symmetric encryption of data, though, and the researchers said that future work might look at steganography (concealing data within other media) and asymmetric (public-key) encryption. On whether Eve might ever become a decent adversary, the researchers said: "While it seems improbable that neural networks would become great at cryptanalysis, they may be quite effective in making sense of metadata and in traffic analysis." You can read the researchers' preprint paper on arXiv. This post originated on Ars Technica UK

JSA10759 – 2016-10 Security Bulletin: OpenSSL security updates

The ​OpenSSL project has published a set of security advisories for vulnerabilities resolved in the OpenSSL library in December 2015, March, May, June, August and September 2016.

The following is a summary of these vulnerabilities and their status with respect to Juniper products: CVE OpenSSL Severity Rating Summary CVE-2016-6309 Critical statem/statem.c in OpenSSL 1.1.0a does not consider memory-block movement after a realloc call, which allows remote attackers to cause a denial of service (use-after-free) or possibly execute arbitrary code via a crafted TLS session. CVE-2016-0701 High The DH_check_pub_key function in crypto/dh/dh_check.c in OpenSSL 1.0.2 before 1.0.2f does not ensure that prime numbers are appropriate for Diffie-Hellman (DH) key exchange, which makes it easier for remote attackers to discover a private DH exponent by making multiple handshakes with a peer that chose an inappropriate number, as demonstrated by a number in an X9.42 file. CVE-2016-0703 High The get_client_master_key function in s2_srvr.c in the SSLv2 implementation in OpenSSL before 0.9.8zf, 1.0.0 before 1.0.0r, 1.0.1 before 1.0.1m, and 1.0.2 before 1.0.2a accepts a nonzero CLIENT-MASTER-KEY CLEAR-KEY-LENGTH value for an arbitrary cipher, which allows man-in-the-middle attackers to determine the MASTER-KEY value and decrypt TLS ciphertext data by leveraging a Bleichenbacher RSA padding oracle, a related issue to CVE-2016-0800. CVE-2016-0800 High The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to send a ServerVerify message before establishing that a client possesses certain plaintext RSA data, which makes it easier for remote attackers to decrypt TLS ciphertext data by leveraging a Bleichenbacher RSA padding oracle, aka a "DROWN" attack. CVE-2016-2107 High The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a certain padding check, which allows remote attackers to obtain sensitive cleartext information via a padding-oracle attack against an AES CBC session, NOTE: this vulnerability exists because of an incorrect fix for CVE-2013-0169. CVE-2016-2108 High The ASN.1 implementation in OpenSSL before 1.0.1o and 1.0.2 before 1.0.2c allows remote attackers to execute arbitrary code or cause a denial of service (buffer underflow and memory corruption) via an ANY field in crafted serialized data, aka the "negative zero" issue. CVE-2016-6304 High Multiple memory leaks in t1_lib.c in OpenSSL before 1.0.1u, 1.0.2 before 1.0.2i, and 1.1.0 before 1.1.0a allow remote attackers to cause a denial of service (memory consumption) via large OCSP Status Request extensions. CVE-2015-3193 Moderate The Montgomery squaring implementation in crypto/bn/asm/x86_64-mont5.pl in OpenSSL 1.0.2 before 1.0.2e on the x86_64 platform, as used by the BN_mod_exp function, mishandles carry propagation and produces incorrect output, which makes it easier for remote attackers to obtain sensitive private-key information via an attack against use of a (1) Diffie-Hellman (DH) or (2) Diffie-Hellman Ephemeral (DHE) ciphersuite. CVE-2015-3194 Moderate crypto/rsa/rsa_ameth.c in OpenSSL 1.0.1 before 1.0.1q and 1.0.2 before 1.0.2e allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via an RSA PSS ASN.1 signature that lacks a mask generation function parameter. CVE-2015-3195 Moderate The ASN1_TFLG_COMBINE implementation in crypto/asn1/tasn_dec.c in OpenSSL before 0.9.8zh, 1.0.0 before 1.0.0t, 1.0.1 before 1.0.1q, and 1.0.2 before 1.0.2e mishandles errors caused by malformed X509_ATTRIBUTE data, which allows remote attackers to obtain sensitive information from process memory by triggering a decoding failure in a PKCS#7 or CMS application. CVE-2016-0704 Moderate An oracle protection mechanism in the get_client_master_key function in s2_srvr.c in the SSLv2 implementation in OpenSSL before 0.9.8zf, 1.0.0 before 1.0.0r, 1.0.1 before 1.0.1m, and 1.0.2 before 1.0.2a overwrites incorrect MASTER-KEY bytes during use of export cipher suites, which makes it easier for remote attackers to decrypt TLS ciphertext data by leveraging a Bleichenbacher RSA padding oracle, a related issue to CVE-2016-0800. CVE-2016-6305 Moderate The ssl3_read_bytes function in record/rec_layer_s3.c in OpenSSL 1.1.0 before 1.1.0a allows remote attackers to cause a denial of service (infinite loop) by triggering a zero-length record in an SSL_peek call. CVE-2016-7052 Moderate crypto/x509/x509_vfy.c in OpenSSL 1.0.2i allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) by triggering a CRL operation. CVE-2015-1794 Low The ssl3_get_key_exchange function in ssl/s3_clnt.c in OpenSSL 1.0.2 before 1.0.2e allows remote servers to cause a denial of service (segmentation fault) via a zero p value in an anonymous Diffie-Hellman (DH) ServerKeyExchange message. CVE-2015-3196 Low ssl/s3_clnt.c in OpenSSL 1.0.0 before 1.0.0t, 1.0.1 before 1.0.1p, and 1.0.2 before 1.0.2d, when used for a multi-threaded client, writes the PSK identity hint to an incorrect data structure, which allows remote servers to cause a denial of service (race condition and double free) via a crafted ServerKeyExchange message. CVE-2015-3197 Low ssl/s2_srvr.c in OpenSSL 1.0.1 before 1.0.1r and 1.0.2 before 1.0.2f does not prevent use of disabled ciphers, which makes it easier for man-in-the-middle attackers to defeat cryptographic protection mechanisms by performing computations on SSLv2 traffic, related to the get_client_master_key and get_client_hello functions. CVE-2016-0702 Low The MOD_EXP_CTIME_COPY_FROM_PREBUF function in crypto/bn/bn_exp.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g does not properly consider cache-bank access times during modular exponentiation, which makes it easier for local users to discover RSA keys by running a crafted application on the same Intel Sandy Bridge CPU core as a victim and leveraging cache-bank conflicts, aka a "CacheBleed" attack. CVE-2016-0705 Low Double free vulnerability in the dsa_priv_decode function in crypto/dsa/dsa_ameth.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via a malformed DSA private key. CVE-2016-0797 Low Multiple integer overflows in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g allow remote attackers to cause a denial of service (heap memory corruption or NULL pointer dereference) or possibly have unspecified other impact via a long digit string that is mishandled by the (1) BN_dec2bn or (2) BN_hex2bn function, related to crypto/bn/bn.h and crypto/bn/bn_print.c. CVE-2016-0798 Low Memory leak in the SRP_VBASE_get_by_user implementation in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g allows remote attackers to cause a denial of service (memory consumption) by providing an invalid username in a connection attempt, related to apps/s_server.c and crypto/srp/srp_vfy.c. CVE-2016-0799 Low The fmtstr function in crypto/bio/b_print.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g improperly calculates string lengths, which allows remote attackers to cause a denial of service (overflow and out-of-bounds read) or possibly have unspecified other impact via a long string, as demonstrated by a large amount of ASN.1 data, a different vulnerability than CVE-2016-2842. CVE-2016-2105 Low Integer overflow in the EVP_EncodeUpdate function in crypto/evp/encode.c in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h allows remote attackers to cause a denial of service (heap memory corruption) via a large amount of binary data. CVE-2016-2106 Low Integer overflow in the EVP_EncryptUpdate function in crypto/evp/evp_enc.c in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h allows remote attackers to cause a denial of service (heap memory corruption) via a large amount of data. CVE-2016-2109 Low The asn1_d2i_read_bio function in crypto/asn1/a_d2i_fp.c in the ASN.1 BIO implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h allows remote attackers to cause a denial of service (memory consumption) via a short invalid encoding. CVE-2016-2176 Low The X509_NAME_oneline function in crypto/x509/x509_obj.c in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h allows remote attackers to obtain sensitive information from process stack memory or cause a denial of service (buffer over-read) via crafted EBCDIC ASN.1 data. CVE-2016-2182 Low The BN_bn2dec function in crypto/bn/bn_print.c in OpenSSL before 1.1.0 does not properly validate division results, which allows remote attackers to cause a denial of service (out-of-bounds write and application crash) or possibly have unspecified other impact via unknown vectors. CVE-2016-6303 Low Integer overflow in the MDC2_Update function in crypto/mdc2/mdc2dgst.c in OpenSSL before 1.1.0 allows remote attackers to cause a denial of service (out-of-bounds write and application crash) or possibly have unspecified other impact via unknown vectors. CVE-2016-2179 Low The DTLS implementation in OpenSSL before 1.1.0 does not properly restrict the lifetime of queue entries associated with unused out-of-order messages, which allows remote attackers to cause a denial of service (memory consumption) by maintaining many crafted DTLS sessions simultaneously, related to d1_lib.c, statem_dtls.c, statem_lib.c, and statem_srvr.c. CVE-2016-2180 Low The TS_OBJ_print_bio function in crypto/ts/ts_lib.c in the X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) implementation in OpenSSL through 1.0.2h allows remote attackers to cause a denial of service (out-of-bounds read and application crash) via a crafted time-stamp file that is mishandled by the "openssl ts" command. CVE-2016-2181 Low The Anti-Replay feature in the DTLS implementation in OpenSSL before 1.1.0 mishandles early use of a new epoch number in conjunction with a large sequence number, which allows remote attackers to cause a denial of service (false-positive packet drops) via spoofed DTLS records, related to rec_layer_d1.c and ssl3_record.c. CVE-2016-6302 Low The tls_decrypt_ticket function in ssl/t1_lib.c in OpenSSL before 1.1.0 does not consider the HMAC size during validation of the ticket length, which allows remote attackers to cause a denial of service via a ticket that is too short. CVE-2016-2177 Low OpenSSL through 1.0.2h incorrectly uses pointer arithmetic for heap-buffer boundary checks, which might allow remote attackers to cause a denial of service (integer overflow and application crash) or possibly have unspecified other impact by leveraging unexpected malloc behavior, related to s3_srvr.c, ssl_sess.c, and t1_lib.c. CVE-2016-2178 Low The dsa_sign_setup function in crypto/dsa/dsa_ossl.c in OpenSSL through 1.0.2h does not properly ensure the use of constant-time operations, which makes it easier for local users to discover a DSA private key via a timing side-channel attack. CVE-2016-6306 Low The certificate parser in OpenSSL before 1.0.1u and 1.0.2 before 1.0.2i might allow remote attackers to cause a denial of service (out-of-bounds read) via crafted certificate operations, related to s3_clnt.c and s3_srvr.c. CVE-2016-6307 Low The state-machine implementation in OpenSSL 1.1.0 before 1.1.0a allocates memory before checking for an excessive length, which might allow remote attackers to cause a denial of service (memory consumption) via crafted TLS messages, related to statem/statem.c and statem/statem_lib.c. CVE-2016-6308 Low statem/statem_dtls.c in the DTLS implementation in OpenSSL 1.1.0 before 1.1.0a allocates memory before checking for an excessive length, which might allow remote attackers to cause a denial of service (memory consumption) via crafted DTLS messages. CVE-2016-2176 is a vulnerability that only affects EBCDIC systems. No Juniper products are affected by this vulnerability. Affected Products: Junos OS: Junos OS is potentially affected by many of these issues. Junos OS is not affected by CVE-2016-0701, CVE-2016-0800, CVE-2016-2107, CVE-2016-2176, CVE-2016-2179, CVE-2016-2181, CVE-2016-6308, CVE-2016-6309 and CVE-2016-7052. ScreenOS: ScreenOS is potentially affected by many of these issues.
ScreenOS is not affected by CVE-2015-1794, CVE-2015-3193, CVE-2015-3194, CVE-2015-3196, CVE-2015-3197, CVE-2016-0701, CVE-2016-2107, CVE-2016-2109, CVE-2016-2179, CVE-2016-2181, CVE-2016-6308, CVE-2016-6309 and CVE-2016-7052. Junos Space: Junos Space is potentially affected by many of these issues. Junos Space is not affected by CVE-2015-1794, CVE-2016-0705, CVE-2016-0798, CVE-2016-2176, CVE-2015-3193, CVE-2015-3196, CVE-2016-0701, CVE-2016-2107, CVE-2016-6305, CVE-2016-6307, CVE-2016-6308, CVE-2016-6309 and CVE-2016-7052. NSM: NSM is potentially affected by many of these issues. NSM is not affected by CVE-2015-1794, CVE-2016-0705, CVE-2016-0798, CVE-2016-2176, CVE-2015-3193, CVE-2015-3196, CVE-2016-0701, CVE-2016-2107, CVE-2016-6305, CVE-2016-6307, CVE-2016-6308, CVE-2016-6309 and CVE-2016-7052. Juniper Secure Analytics (JSA, STRM): STRM, JSA series is potentially affected by these issues. CTPView/CTPOS: CTPView and CTPOS are potentially affected by many these issues.

CTPView and CTPOS are not affected by CVE-2015-1794, CVE-2016-0705, CVE-2016-0798, CVE-2016-2176, CVE-2015-3193, CVE-2015-3196, CVE-2016-0701, CVE-2016-2107, CVE-2016-6305, CVE-2016-6307, CVE-2016-6308, CVE-2016-6309 and CVE-2016-7052. Junos OS: OpenSSL December 2015 advisory: CVE-2015-3193, CVE-2015-3194, CVE-2015-3195, CVE-2015-3196 and CVE-2015-1794 are resolved in 12.1X44-D60, 12.1X46-D45, 12.1X46-D51, 12.1X47-D35, 12.3R12, 12.3R13, 12.3X48-D25, 13.2X51-D40, 13.3R9, 14.1R7, 14.1X53-D35, 14.2R6, 15.1F5, 15.1R3, 15.1X49-D40, 15.1X53-D35, 16.1R1 and all subsequent releases (PR 1144520). OpenSSL March 2016 advisory: CVE-2016-0705, CVE-2016-0798, CVE-2016-0797, CVE-2016-0799, CVE-2016-0702, CVE-2016-0703 and CVE-2016-0704 are resolved in 13.3R10*, 14.1R8, 14.1X53-D40*, 14.2R7, 15.1F5-S4, 15.1F6, 15.1R4, 15.1X49-D60, 15.1X53-D50, 16.1R1 and all subsequent releases (PR 1165523, 1165570). OpenSSL May 2016 advisory: CVE-2016-2105, CVE-2016-2106, CVE-2016-2108, CVE-2016-2109, CVE-2016-2176, CVE-2016-2180 are resolved in 13.3R10*, 14.1R9*, 14.1X53-D40*, 14.2R8*, 15.1F5-S4, 15.1F6-S2, 15.1R4, 15.1X53-D50, 15.1X53-D60, 16.1R1 and all subsequent releases.

Fixes are in progress for other supported Junos releases (PR 1180391). OpenSSL June to September 2016 advisories: CVE-2016-2177, CVE-2016-2178, CVE-2016-2179, CVE-2016-2180, CVE-2016-2181, CVE-2016-2182, CVE-2016-6302, CVE-2016-6303, CVE-2016-6304, CVE-2016-6305, CVE-2016-6306, CVE-2016-6307, CVE-2016-6308, CVE-2016-6309, CVE-2016-7052 are resolved in 13.3R10*, 14.1R9*, 14.2R8*, 15.1R5*, 16.1R4* and all subsequent releases.

Fixes are in progress for other supported Junos releases (PR 1216923). CVE-2016-2108 was resolved when fixes for OpenSSL Advisories in June and July 2015 were implemented in Junos.

At that time OpenSSL version was upgraded to 1.0.1p in Junos 13.3 and later releases which included a fix for this issue. Please see JSA10694​ for solution releases. Note: * - These Junos releases are pending release at the time of publication. Note: While Junos is not affected or impacted by certain CVEs, fixes for those get included with the relevant OpenSSL version upgrade. Hence these are stated as resolved. ScreenOS: CVE-2015-3195 is resolved in 6.3.0r22.

This issue is being tracked as PR 1144749. Please see JSA10733 further details. Rest of the applicable issues in OpenSSL advisories until May 2016 in have been resolved in ScreenOS 6.3.0r23.

These issues are being tracked as PRs 1180504 and 1165796. Fixes for issues in OpenSSL advisories from June to September are being tracked as PR 1217005. Junos Space: OpenSSL software has been upgraded to 1.0.1t in Junos Space 16.1R1 (pending release) to resolve all the issues included in OpenSSL advisories until May 2016.

These issues are being tracked as PRs 1144741, 1158268, 1165853, 1180505, 1212590. Fixes for issues in OpenSSL advisories from June to September are being tracked as PR 1216998. NSM: OpenSSL software has been upgraded to 1.0.2h in NSM 2012.2R13 to resolve all the issues included in OpenSSL advisories until May 2016.

This upgrade is being tracked as PR 1198397. Fixes for issues in OpenSSL advisories from June to September are being tracked as PR 1217003. Juniper Secure Analytics (JSA, STRM): OpenSSL December 2015 and March 2016 advisories: CVE-2015-3194, CVE-2015-3195, CVE-2015-3196, CVE-2015-1794, CVE-2015-3193, CVE-2016-0702, CVE-2016-0703, CVE-2016-0704, CVE-2016-0705, CVE-2016-0797, CVE-2016-0798, CVE-2016-0799 and CVE-2016-0800 have been resolved in 2014.6.R4.A resolution for other issues is pending release.These issues are being tracked as PR 1151137, 1165861. CTPView CVE-2015-3194 and CVE-2015-3195 have been resolved in 7.1R3, 7.2R1 and all subsequent releases (PR 1144746). CVE-2016-0702, CVE-2016-0703, CVE-2016-0704, CVE-2016-0797, CVE-2016-0799 and CVE-2016-0800 have been resolved in 7.1R3, 7.2R2, 7.3R1 and all subsequent releases (PR 1165849). CTPOS CVE-2015-3194 and CVE-2015-3195 have been resolved in 7.2R1 and all subsequent releases (PR 1144964). CVE-2016-0702, CVE-2016-0703, CVE-2016-0704, CVE-2016-0797, CVE-2016-0799 and CVE-2016-0800 have been resolved in 7.0R7, 7.1R3, 7.2R2, 7.3R1 and all subsequent releases (PR 1165847). Standard security best current practices (control plane firewall filters, edge filtering, access lists, etc.) may protect against any remote malicious attacks. Junos OS Since SSL is used for remote network configuration and management applications such as J-Web and SSL Service for JUNOScript (XNM-SSL), viable workarounds for this issue in Junos may include: Disabling J-Web Disable SSL service for JUNOScript and only use Netconf, which makes use of SSH, to make configuration changes Limit access to J-Web and XNM-SSL from only trusted networks ScreenOS Methods to reduce the risk associated with this issue include: Limit access to SSL ports to only trusted hosts. Disabling web administrative services will mitigate the risk of this issue:unset int eth0/0 manage web Refer to KB6713 for enabling SSH on the firewall. General Mitigation It is good security practice to limit the exploitable attack surface of critical infrastructure networking equipment. Use access lists or firewall filters to limit access to the HTTPS or SSL/TLS services only from trusted, administrative networks or hosts.

Meet PocketBlock, the crypto engineering game for kids of all ages

Enlarge / The US Navy Bombe used during World War II to break Germany's Enigma encryption system.National Security Agency reader comments 12 Share this story When you're an applied cryptographer, teaching your preteen daughters what you do for a living isn't easy.

That's why Justin Troutman developed PocketBlock, a visual, gamified curriculum that makes cryptographic engineering fun. In its current form, PocketBlock is a series of board-like grids that allows players to transform plaintext messages into secret ciphertext and convert it back again, one move at a time.

By restricting the operations to little more than addition and subtraction performed by rearranging squares on a piece of paper, PocketBlock helps students understand the fundamentals of encryption without requiring a formal background in mathematics.

At the same time, it stays true to the principles of modern cryptography and goes well beyond the classical cryptographic concepts, like the Caesar cipher, reserved for the most kid-centric material on cryptography today. "The goal is for kids to feel like they've worked with something of substance, to an extent that intrigues them," Troutman, a trained cryptographer who is currently the project manager at the Freedom of the Press Foundation, told Ars. "[PocketBlock] introduces cryptography as everything from a pillar of the modern Web to the tradecraft of spies past.
It introduces the same cryptographic concepts that I work with as a cryptographer in industry—the same underpinnings you'll find in academic papers.
It reduces these concepts to easy-to-solve problems and uses a visual language to map what happens to bits as they travel through a cryptographic algorithm." Enlarge While suitable for kids eight and older, PocketBlock is by no means restricted to kids.

Troutman said it's also suitable for professional developers who want to deepen their understanding of the way cryptographic algorithms work, given that they're often implementing them.
So far, Troutman has used PocketBlock in four workshops: for kids of all ages at r00tz Asylum (Defcon 24), for middle school girls at a Hackers Girls Summer Camp sponsored by Facebook, for high school students at Cal Poly SLO's EPIC engineering summer camp, and for professional developers at Facebook's internal Hacktober event. The first entry in the PocketBlock series is called Pockenacci (pronounced POCK-uh-notch-ee), an authenticated encryption scheme that introduces the inner workings of a block cipher. Pockenacci includes a simple key schedule based on Fibonacci-style addition, which transforms a password into a cryptographic key; two P-boxes that permute, or shift, the location of characters inside the plaintext message; an S-box that substitutes one character for another; and a Message Authentication Code for verifying that an adversary hasn't tampered with an encrypted message while it was in transit. Adolescent Encryption Standard The next entry will be "aes," or the "adolescent encryption standard," a version of the Advanced Encryption Standard that has been simplified enough to be done by hand. While it has been scaled down, Troutman said it will retain the full structure of AES. In its current form, PocketBlock mostly resembles a crude board game, but Troutman said this is just the early curriculum-based stage. He has plans to expand PocketBlock to an interactive app for tablets with tangible components like physical, programmable blocks that work with the app for more of a hands-on experience.
In addition, Troutman is also planning to integrate a narrative interactive fiction environment in which players use their newfound crypto skills to complete missions.

The first installment of this narrative adventure will be titled "Mudspeak." "The goal of this narrative, interactive-fiction-esque component is to gamify things even more, by having players both build and break ciphers in order to level up," Troutman said. "They'll need to build ciphers in order to set up secure and private communication, break ciphers in order to read secret messages, and forge new ones.

Completing missions will depend heavily on keeping their secrets safe while learning the secrets of their opponents." The PocketBlock curriculum source is free and open source and available on the official PocketBlock repo on Github. Project updates and upcoming workshops can be found at the official PocketBlock website.

Researchers crack homomorphic encryption

Thankfully nobody's using it yet Homomorphic encryption is one idea offered to secure data in the cloud: the idea is to let software work on data without encrypting it. It's mostly a research project at this stage, because it's very processor-intensive and therefore slow, and now one such scheme has the added problem of being vulnerable. A trio of boffins from the Swiss Federal Institute of Technology in Lausanne has published their work at the IACR, here. They took a look at a 2014 scheme proposed by MIT's Hongchao Zhou and Gregory Wornell. The EPFL paper, by Sonia Bogos, John Gaspoz and Serge Vaudenay, demonstrates attacks against the scheme's broadcast encryption, a “chosen ciphertext attack”, and a plaintext attack. Strike one: The scheme proposed encryption for broadcast messages, to support data sharing. However, the EPFL paper says an attacker that eavesdrops on broadcast traffic would get “enough information to solve the system”. “A valid scenario for this attack would be one where a service provider has to send an activation key to its customers.

The activation key is the same for all the customers.
In such case, when the service provider has to send the encrypted activation key to enough customers, an unauthorised user could recover the activation key”, the authors write. Strike two: In the chosen ciphertext attack, they write, an attacker with access to an oracle that decrypts the text can run a brute-force to recover the encryption key. Strike three: As with the chosen ciphertext attack, the plaintext attack is a successful brute force against the encryption. All of which means the EPFL boffins have sent the MIT homomorphic encryption scheme back for some warranty fixes. ® Sponsored: Global DDoS threat landscape report