Slashdot Mirror
Domain: cryptographyengineering.com
Stories and comments across the archive that link to cryptographyengineering.com.
Stories · 9
-
Google Secretly Logs Users Into Chrome Whenever They Log Into a Google Site (zdnet.com)
Catalin Cimpanu, writing for ZDNet: Starting with Chrome 69, whenever a Chrome user would access a Google-owned site, the browser would take that user's Google identity and log the user into the Chrome in-browser account system -- also known as Sync. This system, Sync, allows users to log in with their Google accounts inside Chrome and optionally upload and synchronize local browser data (history, passwords, bookmarks, and other) to Google's servers. Sync has been present in Chrome for years, but until now, the system worked independently from the logged-in state of Google accounts. This allowed users to surf the web while logged into a Google account but not upload any Chrome browsing data to Google's servers, data that may be tied to their accounts.
Now, with the revelations of this new auto-login mechanism, a large number of users are angry that this sneaky modification would allow Google to link that person's traffic to a specific browser and device with a higher degree of accuracy. That criticism proved to be wrong, as Google engineers have clarified on Twitter that this auto-login operation does not start the process of synchronizing local data to Google's servers, which will require a user click. Furthermore, they also revealed that the reason why this mechanism was added was for privacy reasons in the first place. Chrome engineers said the auto-login mechanism was added in the browser because of shared computers/browsers. Well-respected cryptographer Matthew Green was disappointed by the move. In a post, he wrote: [...] In the rest of this post, I'm going to talk about why this matters. From my perspective, this comes down to basically four points:
1. Nobody on the Chrome development team can provide a clear rationale for why this change was necessary, and the explanations they've given don't make any sense.
2. This change has enormous implications for user privacy and trust, and Google seems unable to grapple with this.
3. The change makes a hash out of Google's own privacy policies for Chrome.
4. Google needs to stop treating customer trust like it's a renewable resource, because they're screwing up badly. -
The Juniper VPN Backdoor: Buggy Code With a Dose of Shady NSA Crypto (csoonline.com)
itwbennett writes: Security researchers and crypto experts now believe that a combination of likely malicious third-party modifications and Juniper's own crypto failures are responsible for the recently disclosed backdoor in Juniper NetScreen firewalls. 'To sum up, some hacker or group of hackers noticed an existing backdoor in the Juniper software, which may have been intentional or unintentional — you be the judge!,' Matthew Green, a cryptographer and assistant professor at Johns Hopkins University wrote in a blog post. 'They then piggybacked on top of it to build a backdoor of their own, something they were able to do because all of the hard work had already been done for them. The end result was a period in which someone — maybe a foreign government — was able to decrypt Juniper traffic in the U.S. and around the world. And all because Juniper had already paved the road.' -
Australian PLAID Crypto, ISO Conspiracies, and German Tanks
New submitter Gaglia writes: PLAID, the Australian 'unbreakable' smart card identification protocol has been recently analyzed in this scientific paper (disclaimer: I am one of the authors, and this is a personal statement.)
Technically, the protocol is a disaster. In addition to many questionable design choices, we found ways for tracing user identities and recover card access capabilities. The attacks are efficient (few seconds on 'home' hardware in some cases), and involve funny techniques such as RSA moduli fingerprinting and... German tanks. See this entry on Matt Green's crypto blog for a pleasant-to-read explanation.
But the story behind PLAID's standardization is possibly even more disturbing. PLAID was pushed into ISO with a so-called "fast track" procedure. Technical loopholes made it possible to cut off from any discussion the ISO groups responsible for crypto and security analysis. Concerns from tech-savvy experts in the other national panels were dismissed or ignored. We contacted ISO and CERT Australia before going public with our paper, but all we got was a questionable and somewhat irate response (PDF) by PLAID's project editor (our reply here). Despite every possible evidence of bad design, PLAID is now approved as ISO standard, and is coming to you very soon inside security products which will advertise non-existing privacy capabilities.
The detailed story of PLAID in the paper is worth a read, and casts many doubts on the efficacy of the most important standardizing body in the world. It is interesting to see how a "cryptography" product can be approved at ISO without undergoing any real security scrutiny.
On a related note, the enthusiastic comments to PLAID's design made by a few readers in the old Slashdot story reminds us as a cautionary tale that you need cryptographers to assess the security of cryptography. Quoting Bruce Schneier: amateurs produce amateur cryptography. -
The Network Is Hostile
An anonymous reader writes: Following this weekend's news that AT&T was as friendly with the NSA as we've suspected all along, cryptographer Matthew Green takes a step back to look at the broad lessons we've learned from the NSA leaks. He puts it simply: the network is hostile — and we really understand that now. "My take from the NSA revelations is that even though this point was 'obvious' and well-known, we've always felt it more intellectually than in our hearts. Even knowing the worst was possible, we still chose to believe that direct peering connections and leased lines from reputable providers like AT&T would make us safe. If nothing else, the NSA leaks have convincingly refuted this assumption." Green also points out that the limitations on law enforcement's data collection are technical in nature — their appetite for surveillance would be even larger if they had the means to manage it. "...it's significant that someday a large portion of the world's traffic will flow through networks controlled by governments that are, at least to some extent, hostile to the core values of Western democracies." -
FREAK Attack Threatens SSL Clients
msm1267 writes: For the nth time in the last couple of years, security experts are warning about a new Internet-scale vulnerability, this time in some popular SSL clients. The flaw allows an attacker to force clients to downgrade to weakened ciphers and break their supposedly encrypted communications through a man-in-the-middle attack. Researchers recently discovered that some SSL clients, including OpenSSL, will accept weak RSA keys–known as export-grade keys–without asking for those keys. Export-grade refers to 512-bit RSA keys, the key strength that was approved by the United States government for export overseas. This was an artifact from decades ago and it was thought that most servers and clients had long ago abandoned such weak ciphers. The vulnerability affects a variety of clients, most notably Apple's Safari browser. -
Details of iOS and Android Device Encryption
swillden writes: There's been a lot of discussion of what, exactly, is meant by the Apple announcement about iOS8 device encryption, and the subsequent announcement by Google that Android L will enable encryption by default. Two security researchers tackled these questions in blog posts:
Matthew Green tackled iOS encryption, concluding that the change really boils down to applying the existing iOS encryption methods to more data. He also reviews the iOS approach, which uses Apple's "Secure Enclave" chip as the basis for the encryption and guesses at how it is that Apple can say it's unable to decrypt the devices. He concludes, with some clarification from a commenter, that Apple really can't (unless you use a weak password which can be brute-forced, and even then it's hard).
Nikolay Elenkov looks into the preview release of Android "L." He finds that not only has Google turned encryption on by default, but appears to have incorporated hardware-based security as well, to make it impossible (or at least much more difficult) to perform brute force password searches off-device. -
How I Compiled TrueCrypt For Windows and Matched the Official Binaries
First time accepted submitter xavier2dc writes "TrueCrypt is a popular software enabling data protection by means of encryption for all categories of users. It is getting even more attention lately following the revelations of the NSA as the authors remain anonymous and no thorough security audit have yet been conducted to prove it is not backdoored in any way. This has led several concerns raised in different places, such as this blog post, this one, this security analysis [PDF], also related on that blog post from which IsTrueCryptAuditedYet? was born. One of the recurring questions is: What if the binaries provided on the website were different than the source code and they included hidden features? To address this issue, I built the software from the official sources in a careful way and was able to match the official binaries. According to my findings, all three recent major versions (v7.1a, v7.0a, v6.3a) exactly match the sources." -
Security Researchers Want To Fully Audit Truecrypt
Hugh Pickens DOT Com writes "TrueCrypt has been part of security-minded users' toolkits for nearly a decade — but there's one problem: no one has ever conducted a full security audit on it. Now Cyrus Farivar reports in Ars Technica that a fundraiser reached more than $16,000 in a public call to perform a full security audit on TrueCrypt. 'Lots of people use it to store very sensitive information,' writes Matthew Green, a well-known cryptography professor at Johns Hopkins University. 'That includes corporate secrets and private personal information. Bruce Schneier is even using it to store information on his personal air-gapped super-laptop, after he reviews leaked NSA documents. We should be sweating bullets about the security of a piece of software like this.' According to Green, Truecrypt 'does some damned funny things that should make any (correctly) paranoid person think twice.' The Ubuntu Privacy Group says the behavior of the Windows version [of Truecrypt 7.0] is problematic. 'As it can't be ruled out that the published Windows executable of Truecrypt 7.0a is compiled from a different source code than the code published in "TrueCrypt_7.0a_Source.zip" we however can't preclude that the binary Windows package uses the header bytes after the key for a back door.' Green is one of people leading the charge to setup the audit, and he helped create the website istruecryptauditedyet.com. 'We're now in a place where we have nearly, but not quite enough to get a serious audit done.'" -
RSA Warns Developers Not To Use RSA Products
rroman writes "RSA has recommended developers not to use Dual_EC_DRBG random number generator (RNG), which has been known to be weak and slow since 2006. The funny thing is, that even though this has been known for so long, it is the default RNG in BSafe cryptographic toolkit, which is product of RSA."