Wednesday, February 29, 2012
Sunday, February 26, 2012
Friday, February 24, 2012
Wednesday, February 22, 2012
Tuesday, February 21, 2012
Friday, February 17, 2012
Thursday, February 16, 2012
Wednesday, February 15, 2012
TECHNOLOGY Flaw Found in an Online Encryption Method By JOHN MARKOFF Published: February 15, 2012
SAN FRANCISCO - A team of European and American mathematicians and cryptographers have discovered an unexpected weakness in the encryption system widely used worldwide for online shopping, banking,e-mail and other Internet services intended to remain private and secure.
The flaw - which involves a small but measurable number of cases - has to do with the way the system generates random numbers,which are used to make it practically impossible for an attacker to unscramble digital messages. While it can affect the transactions of individual Internet users,there is nothing an individual can do about it. The operators of large Web sites will need to make changes to ensure the security of their systems,the researchers said.
The potential danger of the flaw is that even though the number of users affected by the flaw may be small,confidence in the security of Web transactions is reduced,the authors said.
The system requires that a user first create and publish the product of two large prime numbers,in addition to another number,to generate a public "key." The original numbers are kept secret. To encrypt a message,a second person employs a formula that contains the public number. In practice,only someone with knowledge of the original prime numbers can decode that message.
For the system to provide security,however,it is essential that the secret prime numbers be generated randomly. The researchers discovered that in a small but significant number of cases,the random number generation system failed to work correctly.
The importance in ensuring that encryption systems do not have undetected flaws cannot be overstated. The modern world's online commerce system rests entirely on the secrecy afforded by the public key cryptographic infrastructure.
The researchers described their work in a paper that the authors have submitted for publication at a cryptography conference to be held in Santa Barbara,Calif.,in August. They made their findings public Tuesday because they believe the issue is of immediate concern to the operators of Web servers that rely on the public key cryptography system.
"This comes as an unwelcome warning that underscores the difficulty of key generation in the real world," said James P. Hughes,an independent Silicon Valley cryptanalyst who worked with a group of researchers led by Arjen K. Lenstra,a widely respected Dutch mathematician who is a professor at the École Polytechnique Fédérale de Lausanne in Switzerland. "Some people may say that 99.8 percent security is fine," he added. That still means that approximately as many as two out of every thousand keys would not be secure.
The researchers examined public databases of 7.1 million public keys used to secure e-mail messages,online banking transactions and other secure data exchanges. The researchers employed the Euclidean algorithm,an efficient way to find the greatest common divisor of two integers,to examine those public key numbers. They were able to produce evidence that a small percentage of those numbers were not truly random,making it possible to determine the underlying numbers, or secret keys,used to generate the public key.
They said they "stumbled upon" almost 27,000 different keys that offer no security. "Their secret keys are accessible to anyone who takes the trouble to redo our work," they wrote.
To prevent this,one of the organizations that had collected the public keys has removed the information from the Internet and taken steps to protect it from theft.
To perform their study,the researchers used several databases of public keys,including one at the Massachusetts Institute of Technology and another created by the Electronic Frontier Foundation,a Internet privacy rights group. The foundation's database results from a project, known as the SSL Observatory,originally intended to investigate the security of the digital certificates that are used to protect encrypted data transmitted between Internet users and Web sites.
"We were very careful: we did not intercept any traffic,we did not sniff any networks," Mr. Hughes said. "We went to databases that contained public information and downloaded public keys."
The researchers said they were not able to determine why the random number generators had produced imperfect results,but they noted that the problem appeared in more than the work of a single software developer.
They also stated that if they had been able to discover the flaw,it was also possible that it had been previously uncovered,perhaps by organizations or individuals with malicious intent: "The lack of sophistication of our methods and findings make it hard for us to believe that what we have presented is new,in particular to agencies and parties that are known for their curiosity in such matters," they wrote.
While they said that the publication of results that potentially undermine the security of encryption keys was inappropriate unless the parties were notified first,the researchers noted that the way they discovered the flaw made identifying potentially vulnerable parties a challenge.
"The quagmire of vulnerabilities that we waded into makes it infeasible to properly inform everyone involved,though we made a best effort to inform the larger parties and contacted all e-mail addresses recommended or specified in still-valid affected certificates," they wrote. "The fact that most certificates do not contain adequate contact information limited our options. Our decision to make our findings public,despite our inability to directly notify everyone involved,was a judgment call."
There have been previous failures of random number generators that have undermined Internet security. For example,in 1995,two researchers at the University of California,Berkeley,discovered a flaw in the way the Netscape browser generated random numbers,making it possible for an eavesdropper to decode encrypted communications. Last year a group of computer hackers revealed that Sony had made a crucial mistake in not using a random number in the algorithm used by the security system of the PlayStation 3,making it possible to discover the secret key intended to protect digital content on the system.
The researchers whimsically titled their paper "Ron Was Wrong,Whit Is Right," a reference to two pioneers in public key cryptography,Ron Rivest and Whitfield Diffie.
Mr. Diffie was a developer of the first method for two people who had not previously physically met to share a secret message safely. However,what became known as the R.S.A. algorithm,created by and named after three mathematicians,Mr. Rivest,Adi Shamir and Leonard Adleman,ultimately became the dominant standard. (They later helped found the security company RSA.) The so-called Diffie-Hellman method,developed by Mr. Diffie,Martin Hellman and Ralph Merkle, required only a single secret number.
Friday, February 10, 2012
Tuesday, February 07, 2012
Monday, February 06, 2012
the Superbowl numbers for watching the commercial online (the web) was
was the highest of all superbowl commercials.
It's a blog, so some of the other stories are interesting.
Sunday, February 05, 2012
I was going to write an app for the place I'm working now
It would take a picture and upload it to the website.
I did not want to do it in Java. My alternatives are:
RFO Basic! 4 Android
Scripting Layer 4 Android,
which uses a single library to support several scripting languages
After looking at, and testing, Basic!, it appeared a good choice,
I preferred to use something I'm more familiar with - python or tcl.
After spending several hours with sample code, I was confident
enough to tweak a few of the samples. Things went well with an
example that used a method, cameraCapturePicture() - but it had
a small quirk. The person shooting had less than a second to
stabilize the camera while it focuses, then the camera shoots.
The alternative seemed to be cameraInteractiveCapturePicture().
After several failures, I found out the second method
was intended for the "Front-facing" camera (that would be
the camera on the same side as the screen)
it appeared the only alternative left was for another even less
documented method cameraStartPreview() and cameraStopPreview()
The hack would be that the camera would preview for several
seconds and then after a brief pause would focus and shoot.
It worked -- sort of.
The image was exposed in landscape while I shot in portrait.
As it turns out, the preview mode as in landscape. It appears
that as of this moment there are no other controls, modes, or
methods to use the camera under SL4A.
As it turns out, this round will be won by this dialect of
Dartmouth Basic - example f33_camera.bas does exactly
what I want the camera to do. Now all I have to do is upload
Saturday, February 04, 2012
Wednesday, February 01, 2012
MokaFive runs Windows in what it calls a secure container on Mac OS X and backs up work onto a company’s servers. IT managers can create a common Windows image that they can then push down to an employee’s Mac over the network. They can also update the image over the network, but that virtualized Windows desktop still works when the machine is offline.
Managers can also prevent employees from moving data out of their virtualized Windows desktop, and when data is moved over the network, it’s encrypted. But Gartner’s Cosgrove questions whether the tool is suited for that are handling extremely sensitive data, such as healthcare outfits and government agencies. “[Client-side virtualization tools] tend to be [used] in areas with low security,” he tells Wired.
There are already system deployed in top secret facilities where it's limited to physical access and your eye's only. Their are people who work all day on system where nothing can be sent or downloaded.