Search the Community
Showing results for tags 'rc4'.
Found 4 results
IjxDU9McYeZnUedm44smZuJlZmdqHrxzSLwzYTJc5aJ1XaJmUeJnl4smXCdq IjxDU92o1jxDU9Mc3CJlXatoUetm54ImWmdqHrxzSLwzYTty0vgBPvMCkGtm Uedo34snUidmWaKDVL2yL1wyPX2o29wAJvwBHLgBkKdnUiJm14sm44sm3Cdq NvxzZr3okyJmUiZmY4ImZGJl4idqQ92oWf2CZD3BYrMc5eJlXGZmUuZmUeJn 0a0CJfMBUvMC7OaoX4sm3KJlYqJnUuZma9MzML2yLTJc2iJlYqdmUedmY4co 5aum7eJc4uJlXGZnUetm54sm5auBHDwy6LMB70wyNfMEP5Mc4KJlYqJlXatm UetoOauy7eMc5qJlYiZnUeJmW4ImYqdqQ920kGtoUitmZ4Im14snYaKyVj2o kitmY4cn34sm44In5aeDLjxBP5wySTdDLjxBP5wySbcW4t4WJcXCdoUuto UedoUidqXiZm7eJmZOqm4GJlXetnUudmUedm5auBPngALXwz70wAJHwzSvMc 3KJl24Ym24sm3edqTfMCJ92oTfMCJ9Mc5qJlYedoUutoUitmZa0sHn3CLTZs Hn3CLPaoY4sm1qJl0CJlXmtmaX2BQfwm7W2BQfwm rc4 Titlul e cheia
The noose around the neck of the Internet's most widely used encryption scheme got a little tighter this month with the disclosure of two new attacks that can retrieve passwords, credit card numbers and other sensitive data from some transmissions protected by secure sockets layer and transport layer security protocols. Both attacks work against the RC4 stream cipher, which is estimated to encrypt about 30 percent of today's TLS traffic. Cryptographers have long known that some of the pseudo-random bytes RC4 uses to encode messages were predictable, but it wasn't until 2013 that researchers devised a practical way to exploit the shortcoming. The result was an attack that revealed small parts of the plaintext inside an HTTPS-encrypted data stream. It required attackers to view more than 17 billion (234) separate encryptions of the same data. That was a high bar, particularly given that the attack revealed only limited amounts of plaintext. Still, since the researchers demonstrated the attack could decrypt HTTPS-protected authentication cookies used to access user e-mail accounts, Google and other website operators immediately took notice. Now, researchers have figured out refinements that allow them to recover RC4-protected passwords with a 50-percent success rate using slightly more than 67 million (226) encryptions, a two-order of magnitude reduction over the previous attack used to recover secure cookies. The exploits—laid out in a paper published last week titled Attacks Only Get Better: Password Recovery Attacks Against RC4 in TLS—work against both Basic access authentication over HTTPS and the widely used IMAP protocol for retrieving and storing e-mail. Bar-mitzvah attack A second exploit targeting RC4 was devised by researchers from security firm Imperva and was presented Thursday at the Black Hat security conference in Singapore. The attack uses new ways to exploit the "invariance weakness," a key pattern in RC4 keys that can leak plaintext data into the ciphertext under certain conditions. The weakness first came to light in 2001, and led to the fatal exploit against wired equivalent privacy technology used to encrypt Wi-Fi networks. Given the age of the invariance weakness, Imperva researchers are dubbing their new exploit the "bar-mitzvah attack." "The security of RC4 has been questionable for many years, in particular its initialization mechanisms," Imperva researchers wrote in a research paper that accompanied Thursday's Blackhat talk. "However, only in recent years has this understanding begun translating into a call to retire RC4. In this research, we follow [the 2013 RC4 researchers] and show that the impact of the many known vulnerabilities on systems using RC4 is clearly underestimated." The bar-mitzvah attack requires adversaries to sample about one billion RC4 encryptions to infer a credit card number, password, or authentication cookie key. The known weakness exploited involves a flaw found in one out of every 16 million (224) RC4 keys that leads to "structures" in the "least significant bits" of the keystream. The attack is subject to a significant limitation, however, since the leaky plaintext is contained only in the first 100 bytes of ciphertext. Despite the limitation and the challenge of sampling so many encryptions, the attack may be enough to drastically reduce the cost of doing an exhaustive attack that guesses passwords, credit card numbers or similar data. Rather than try every possible combination, the bar-mitzvah attack allows attackers to hone in on a much smaller number of candidates. The growing body of attacks that defeat SSL and TLS encryption are only one threat facing the system millions of Internet users rely on to encrypt sensitive data and authenticate servers. In 2011 hackers broken into Netherlands-based certificate authority DigiNotar and minted counterfeit credentials for Google and other sensitive Web properties. Earlier this week, shoddy practices at an intermediate CA known as MCS Holdings, allowed its customers to obtain unauthorized certificates for several Google addresses. Poor practices on the part of Microsoft also led to the discovery of misissued certificates, on two separate occasions. “RC4 must die” The TLS protocol has two significant phases. The first "handshaking" phase uses asymmetric encryption to negotiate the symmetric encryption keys to be used by an e-mail or Web server and the connecting end user. During the later "record" phase, the parties use the agreed-upon keys to encrypt data using either the AES block cipher or RC4 stream cipher. The two attacks unveiled this month, combined with the exploit disclosed in 2013, are a strong indication the security of RC4 can't be counted on for much longer and should be phased out in favor of alternative algorithms. Retiring RC4 is proving a challenging proposition. A 2011 attack known as BEAST—short for Browser Exploit Against SSL/TLS—targets an encryption mode known as CBC, or cipher block chaining, which is present in most algorithms except for RC4. After BEAST was demonstrated to pose a credible threat to TLS-protected data in transit many security experts recommended website operators opt for RC4 to blunt the threat. That advice is no longer sound, now that RC4 is under attack, too. Imperva researchers say Web app developers should strongly consider disabling RC4 in all their TLS configurations and tech-savvy end uses should disable RC4 in their Browser settings. In February, the Internet Engineering Task Force submitted a request for comments prohibiting the use of RC4 cipher. Use of RC4 has shrunk from about half of all TLS traffic in 2013 to about 30 percent today, but eliminating it altogether may take years. Hanging in the balance, is the security and confidentiality of millions of Internet users. "RC4 was already looking nervously towards the cliff-edge," Kenny Paterson, a Royal Holloway, University of London professor who helped author last week's research, as well as the 2013 research it built on, wrote in a blog post published last week. "Our work pushes RC4 a significant step closer, leaving it teetering on the brink of oblivion for SSL/TLS. After all, attacks can only get better…" Source
Security researchers have banged another nail into the coffin of the ageing RC4 encryption algorithm. The latest password recovery attacks against RC4 in TLS by Christina Garman of Johns Hopkins University, Prof. Kenny Paterson and research student Thyla van der Merwe (both of Royal Holloway, University of London) show that attacks against the scheme are getting better and easier so RC4 "needs to die", as the researchers themselves put it. The continued use of RC4 in TLS is "increasingly indefensible", the researchers conclude in an abstract of their work. The research - which also involved the development of "proof of concept" implementations of the attacks against the BasicAuth and IMAP protocols – is explained in full in a paper here (PDF, 34 pages). Independent researchers agree that RC4 needs to be pensioned off even though some question whether the attack developed by is a practical concern. "RC4 must die. Despite, not because of, attacks like the one described here which is extremely impractical," said Martijn Grooten, editor of Virus Bulletin and occasional security researcher. Caveats about whether or not attacks could be economically pulled off aside, there's little or no disagreement about the direction of travel, which is that the cipher ought to be consigned straight towards the cyber equivalent of Boot Hill cemetery. The only reason it's still around is that websites are reluctant to drop support even for obsolete technology. RC4, developed in 1987, is a popular stream cipher that's often used in HTTPS connections to protect sensitive network traffic from eavesdroppers, among other uses. Potential attacks have been documented for years but they are now decreasing in complexity to the point where using the cipher is risky even before considering the implication of the revelations from NSA whistleblower Edward Snowden. Leaks from Snowden suggested that US and UK spies have developed "groundbreaking cryptanalysis capabilities", which ultimately allow the intelligence agencies to break RC4 encryption. Distrust of the cipher is spreading. Microsoft urged Windows developers to ditch the RC4 encryption algorithm and pick something stronger back in November 2013. Cisco also told its customers to "avoid" the cipher around the same time. The IETF moved towards killing off the venerable-but-vulnerable RC4 cipher with a proposal that net-standard clients and servers need to quit using RC4 in Transport Layer Security (TLS) that surfaced in December 2014. Source