Researchers at UCSB have demonstrated a "quantum processor" that correctly operates "Schor's algorithm for factoring primes" all of 48% of the time (Photo left, courtesy of UCSB). This has produced all sorts of dire predictions about existing cryptographic mechanisms.
This is nonsense. We don't know enough about quantum computing to believe that a practical quantum computer architecture can follow Moore's law. And so-called "quantum cryptography" is not the answer.
I installed Lion last night and spent today figuring out what does - and does not - work. As a huge fan of full-disk encryption (FDE), I'm disappointed in their drive encryption.
RAID may have been improved, but Lion's encryption features, including Time Machine encryption, are not compatible with Apple's RAID.
The diagram at right (from Elementary Information Security) shows how full-disk encryption (FDE) typically integrates into the system software. The diagram doesn't show where the RAID software might reside. I'd expect it to be very closely tied to the device driver. However, it appears instead that Apple placed the FDE below the RAID software. Perhaps this improves performance, or perhaps the choice was driven by design decisions invisible outside Cupertino.
The Time Machine improvement: they have explicitly documented how to switch in a new mirrored drive for an old one. I haven't tried their suggested process since the upgrade. I'd tried the suggested process a couple of years ago, only to have it fail. So we'll see how it goes.
When Joanne emailed me this video a few days ago, I responded with "Yes, yes, of course. Copiers are digital. They save stuff." But then I watched the video. THIS IS BAD:
This is why all hard drives should have built-in encryption.
A while back, Popular Science asked me to identify the Best New Security Technology. At the time I simply couldn't think of anything, and they've long since published their issue filled with Best New ____ Technology.
I finally thought of something - self-encrypting mass storage. This can be anything from an encrypting USB drive - the IronKey if you like theatrics - to a self-encrypting hard drive like Seagate's Momentus line of laptop drives.
While I also rely heavily on software drive encryption (TrueCrypt) I wish that all my hard drives had full disk encryption (FDE). If all drives had FDE, I could recycle drives (i.e. give them to my kids) just by erasing the key. Instead, I have to hook each drive up to an idle machine for a day or so to run a wiping process.
So FDE isn't just for security paranoids and folks hogtied by compliance regulations. They're useful for everyone. That is, assuming that the vendors make it easy to use them.
I've always been a fan of graphic presentations. More people understand graphs and diagrams than understand equations. While this is a bad thing in some ways, it remains a fact. So it's always great to see a graphical representation of a really difficult set of concepts.
Jeff Moser Fisher has posted A Stick Figure Guide to the Advanced Encryption Standard (AES). He has wisely structured it in layers.
Gilbert Vernam was a digital systems designer from the early 20th century. He invented the stream cipher, what browsers often use today to encrypt messages exchanged with protected web sites. In his days, however, the mechanism of choice was the relay: an electromagnetic switch. Vernam also described the one-time pad, and noted the danger in reusing the key stream.
What, then is a Vernam cipher? Is it a stream cipher or a one-time pad? I've seen the term used both ways.
Now we can check the source. Steve Bellovin recently blogged on Vernam's work, and posted a PDF of Vernam's original paper. Vernam wrote the paper for an AIEE conference (that's one of the precursors of today's IEEE - Bellovin negotiated permission to post the historic paper).
If we look at the historical description, Vernam does not restrict his cipher to the one-time pad case. Thus, a Vernam cipher in practice might - or might not - be a one-time pad. [revised 9/7/09]
Cousin Jon sent me this Wired link: how to bypass iPhone's 3GS encryption using jailbreaking tools. I haven't paid serious attention to the iPhone (AT&T hasn't had a strong signal in my town) but crypto bypass always gets my attention.
In fact, the weakness has nothing to do with protecting personal information on an iPhone. It's all about third parties: Apple, the cell provider, and possibly an employer who provides/manages the iPhone.
If you're not troubled by being limited to the iPhone Apps Store, then the threat's relatively small, especially compared to desktop systems. Moreover, I doubt we'll see real iPhone viruses as long as most people are happy with Apple's app restrictions.
A while back I used graphical images to illustrate why you never, ever want to reuse the keystream of a stream cipher. Recently I've constructed similar examples to show the role of modes in using block ciphers. There's a nice set of block mode examples in Wikipedia, but I wanted to include the real result of applying the mode.
While cryptographic neophytes may want to know why the second encryption clearly failed (if you can read the message, the encryption failed), cryptographic experts may find it interesting to see other examples of cryptographic failures appearing graphically.
A while back I used graphical images to illustrate why you never, ever want to reuse the keystream of a stream cipher. Recently I've constructed similar examples to show the role of modes in using block ciphers. There's a nice set of block mode examples in Wikipedia, but I wanted to include the real result of applying the mode.
While cryptographic neophytes may want to know why the second encryption clearly failed (if you can read the message, the encryption failed), cryptographic experts may find it interesting to see other examples of cryptographic failures appearing graphically.
I installed Lion last night and spent today figuring out what does - and does not - work. As a huge fan of 
While I also rely heavily on software drive encryption (
