Okian Warrior writes "As a followup to Linus's opinion about people skeptical of the Linux random number generator, a new paper analyzes the robustness of /dev/urandom and /dev/random . From the paper: 'From a practical side, we also give a precise assessment of the security of the two Linux PRNGs, /dev/random and /dev/urandom. In particular, we show several attacks proving that these PRNGs are not robust according to our definition, and do not accumulate entropy properly. These attacks are due to the vulnerabilities of the entropy estimator and the internal mixing function of the Linux PRNGs. These attacks against the Linux PRNG show that it does not satisfy the "robustness" notion of security, but it remains unclear if these attacks lead to actual exploitable vulnerabilities in practice.'" Of course, you might not even be able to trust hardware RNGs. Rather than simply proving that the Linux PRNGs are not robust thanks to their run-time entropy estimator, the authors provide a new property for proving the robustness of the entropy accumulation stage of a PRNG, and offer an alternative PRNG model and proof that is both robust and more efficient than the current Linux PRNGs.

sfcrazy writes "It has been discovered that Google downgraded the SSL encryption of Android after version 2.3.4 and defaulted to RC4 and MD5 ciphers. It may appear that NSA is at play here as both are broken and can be easily compromised. But after digging the code Georg Lukas concluded that the blame goes to Oracle. 'The cipher order on the vast majority of Android devices was defined by Sun in 2002 and taken over into the Android project in 2010 as an attempt to improve compatibility.'" The Java spec from 2002 specified RC4 and MD5 as the first two ciphers for TLS; Android, however, used DHE-RSA-AES256-SHA by default. The default cipher list for Java 7 was updated, but Android is stuck using JDK 6 and a default cipher list over a decade old.

Nerval's Lobster writes "In theory, the federal government's Health Insurance Marketplace was supposed to make things easy for anyone in the market for health insurance. But fourteen days after the Website made its debut, the online initiative—an integral part of the Obama administration's Affordable Care Act—has metastasized into a disaster. Despite costing $400 million (so far) and employing an army of experienced IT contractors (such as Booz Allen Hamilton and CGI Group), the Website is prone to glitches and frequent crashes, frustrating many of those seeking to sign up for a health-insurance policy. Unless you're the head of a major federal agency or a huge company launching an online initiative targeted at millions of users, it's unlikely you'll be the one responsible for a project (and problems) on the scale of the Health Insurance Marketplace. Nonetheless, the debacle offers some handy lessons in project management for Websites and portals of any size: know your IT specifications (federal contractors reportedly didn't receive theirs until a few months ago), choose management capable of recognizing the problems that arise (management of Healthcare.gov was entrusted to the Medicare and Medicaid agency, which didn't have the technical chops), roll out small if possible, and test, test, test. The Health Insurance Marketplace fiasco speaks to an unfortunate truth about Web development: even when an entity (whether public or private, corporation or federal government) has keen minds and millions of dollars at its disposal, forgetting or mishandling the basics of successful Web construction can lead to embarrassing problems."