Superconductor

That's a lot of users

Our marketing people issued an interesting press release last week. There was some stuff in it about a huge growth rate, lots of consecutive quarters of profitability, and similar things, but what I found the most interesting is that we now have over 4.5 million licensed users of our SecureMail product.

Note that that's 4.5 million licensed users. Our sales guys typically license our email product to an enterprise by the number of internal users, so the actual number of users is actually much greater than that. Perhaps even much greater. So although it's impossible to get an accurate estimate for how many users we really have, it's not hard to believe that there are probably over 20 million users of SecureMail now.

That's a lot of users.

Get your BN curve here

It looks like some researchers at RWTH Aachen University have an on-line tool for creating BN curves. These are elliptic curves that are particularly useful for pairing-based cryptography, like the identity-based encryption that Voltage uses. If you're interested in implementing pairing-based cryptography, this is a very useful resource to have.

It's generally true that there's no such thing as a free lunch, and this even applies to identity-based encryption. From the user's point of view IBE is great because it's simpler to use than alternatives. From an administrator's point of view IBE iss great because it's extremely simple to keep running. These two combine to make its TCO much lower than the TCO of alternatives.

On the other hand, all of these good features don't come for free, but they really involve things that users and administrators don't see. In particular, it can be very difficult to find elliptic curves that are suitable for use in IBE algorithms. Most elliptic curves don't work very well for this and it can be a bit tricky finding ones that do. BN curves happen to be an example of a type of curve that do work well, so having a place where you can get parameters for such curves can be very useful.

The parameters that you can get from this on-line tool aren't optimized to give you very good performance, so they're not what you'd want to use in a shipping commercial product, but if you're just doing development and testing they're very useful.

Practice-oriented Provable-Security

In 2009, Mihir Bellare and Phil Rogaway shared the ACM's prestigous Paris Kanellakis Theory and Practice Award for their creation of the idea of "Practice-Oriented Provable-Security." Here's the citation for the award that explains why they received it:

Historically, cryptographic schemes used in practice were designed in ad hoc ways and subject to failure. Practice-Oriented, Provable-Security (POPS), developed by Bellare and Rogaway in a series of papers in the 1990s, changed this, giving us the means to create high-assurance practical cryptography, meaning schemes that were backed by the theoretical guarantee of provable security while meeting practical needs and expectations.

Today, POPS-based schemes are cornerstones of Internet security, implemented in most communication security protocols and software - these schemes are used every time someone makes a credit card-based Internet purchase. Meanwhile, the models, techniques and approaches that Bellare and Rogaway introduced, including the random oracle model, have become the foundation of a new subfield of cryptography, inspiring a great amount of follow-on work. Their papers are amongst the most cited in cryptography and their work is discussed in dozens of textbooks.

Bellare and Rogaway changed the perception of theory in practice. Prior to their work, practitioners ignored theory or were even antagonistic to it. Today, they not only choose to implement and standardize proven-secure schemes, but make provable security a requirement in some of their calls for algorithms. That this requirement can be met owes much to Bellare and Rogaway's work. 

In other words, Bellare and Rogaway created a framework for cryptographers to use to prove the security of their inventions and this framework is really the single thing that's most responsible for transforming cryptography from an art into a science.

Before POPS, the only way to ensure that a cryptographic scheme was secure was to wait a while to see if anyone could find a weakness with it. With the invention of POPS that's no longer necessary. It might even be a waste of time to wait to see if a weakness can be found because if there's a valid proof because the very existence of the proof tells you that there can't be one.

Many of the technologies that we use at Voltage have proofs of security. This includes both our Identity-based Encryption and Format-Preserving Encryption. The things that we use that don't have proofs of their security are just things that older standards define: techniques standardized before POPS typically don't have proofs of their security, but there's no really alternative to using them.

I'd hope that newer standards won't have this problem. All of the discussions that I've seen recently in various standards groups have required a proof of security before a new crypotgraphic scheme is taken seriously.

SHARE in Boston in August

Phil Smith of Voltage will be talking at the SHARE meeting in Boston next month. His talk will be on Tuesday, August 3 from 9:30 - 10:30 am, and the topic is Enterprise Encryption 101. Here's a quick summary of what he'll be talking about:

We've all seen the seemingly weekly news about yet another data breach: millions of credit card numbers, SSNs, or other personal information exposed. Encryption is the technology that minimizes the cost of such data breaches, by making the "leaked" data useless to the thief. So more and more sites are investigating encryption, some even before a breach occurs. But where do you start with this technology? How do you make a sensible choice among dozens of vendors, between hardware and software? Where and when do you encrypt data, and is that sufficient? What about emerging standards and legislation, such as PCI DSS, Red Flag, GLBA, SB1386, Directive 95/46/EC, et al.? Come hear about implementing encryption from a business perspective -- what you need to worry about and how to approach it. This is not a comparison of encryption technologies per se, but rather a look at the issues surrounding them. While the presenter works for an encryption vendor, this is a general presentation, with minor content at the end that discusses the Voltage SecureData product as an example.

If you can't make it to Phil's talk, you can download the slides for his talk here. That's probably not quite the same as seeing the talk in person, but it's probably much cheaper.

Voltage Security or Lots Creative Guy?

Last weekend I took my sons to a local game store where they run demos of various boardgames. This particular weekend the demo took longer that usual so I had some time to kill and I tried making entertaining anagrams for "Voltage Security."

One of them, "cattle ye vigours," seemed the one that might be deemed "most likely to be said by a pirate." Maybe this September 19 (talk like a pirate day), I'll hear a few people saying something like "Arr, cattle ye vigours matey!"

Another one, "evil cages tryout" seemed to be a reflection on our fairly rigorous hiring process.

When I got to "lots creative guy" I stopped, thinking that that particular anagram was fairly appropriate. We are known for our innovative technologies, after all.

The location of the 2011 Key Management Summit

We're starting to look for good places to hold the 2011 Key Management Summit. It will almost certainly be held somewhere on the west coast of the US, and probably in California. We have several sites that we're looking at now that are good candidates for this, but we haven't yet decided which one we'll actually use. So if you're interested in attending this event and have a preference for a location for it, now's the time to let us know.  

The next Key Management Summit

It looks like Terence Spies, the CTO of Voltage, will be the general chair of the next Key Management Summit. As soon as Terence gets a chance to get organized, we'll have a better idea of where and when the next event will be held.

Explaining the silence here

It looks like another big credit card processor has signed up to use Voltage's encryption technologies. This time it's Elavon, which means that three of the top five processors (Heartland, Fifth Third and Elavon) are now Voltage customers. Four of the top six POS vendors (Hypercom, Exadigm, UIC, XAC) are also.

This might explain why you don't actually see our sales guys in the office much. When they're not around it's much quieter and easier for the rest of us to work, so I certainly hope that their success in the payments industry continues.

Webinar - Managing Third Party Data Privacy

Our marketing guys have yet another webinar planned, this time it will be held on June 16, 2010 from 10 am Pacific/1 pm Eastern and will last for 60 minutes. The topic this time is Managing 3rd Party Data Privacy - Protecting Your Own and Your Partners Information. Like some of our previous webinars, this one's also sponsored by FS-ISAC, the Financial Services - Information Sharing and Analysis Center.

Here's what they plan to talk about:

• How to ensure the protection of partner information and confidently manage third-party access to card holder and personal data, including protecting terabytes of files on mainframe and legacy systems
• Why a comprehensive end-to-end approach to data protection is critical to ensure the privacy of personal and sensitive information
• What market-leading organizations — such as AAA — really require in an enterprise data protection solution

The fact that one of the infrastructure consultants for AAA will be talking about his experiences is probably a good enough reason to check out this webinar. Every industry has it's own interesting set of problems that it faces and it's fascinating to see how they find clever uses of IT to solve these problems. I've never dealt with an organization like AAA, so I have no idea of the particular challenges that they face, but I'm certainly looking forward to hearing about them on this webinar.

PCI tokenization guidance could benefit payment processors

Interesting news article by industry reporter Rob Westervelt who has been following business and technology trends in the payments sector:

	PCI tokenization guidance could benefit payment processors By Robert Westervelt, News Editor 27 May 2010 | SearchSecurity.com

Hyperelliptic curves

Hyperelliptic curves are interesting for many reasons. The reason that we’re particularly interested in them at Voltage is that you can implement pairings using them and it might turn out that pairings on hyperelliptic curves can be more efficient than pairings on elliptic curves.

An elliptic curve is the set of points defined by an equation like

y² = x³ + ax + b

This gives you a structure that’s much like a torus – a shape that has a single hole in it, like a doughnut.

A hyperelliptic curve is defined by an equation like

y² = f(x)

where f is a monic polynomial of degree 2g + 1.

(There's really no reason to restrict the degree of f to being odd, and a polynomial of degree 2g + 2 will also work just as well. This makes some things trickier, so most people just stick to the odd degree case. One complication is that you actually get two different points at infinity instead of just one. More about that in a future post.)

When g = 1 this reduces to an elliptic curve, but the term “hyperelliptic curve” is usually reserved for the case where g is 2 or greater.

The number g defines the genus of the curve, a number which tells you how many holes the structure corresponding to an elliptic curve’s torus has. If the genus is 2, then the curve has a structure much like a doughnut with 2 holes, etc. The graph above is the graph of a hyperelliptic curve of genus 2.

Working with hyperelliptic curves causes some problems that aren’t there for elliptic curves. It’s possible to easily define a way to add points on an elliptic curve using the usual connect-the-dots algorithm, but this can’t be done for hyperelliptic curves. It’s possible, however, to add sets of g points on a hyperelliptic curve instead of single points. On a curve of genus 2, for example, we might add P = {P₁,P₂} to Q = {Q₁,Q₂} to get R = {R₁,R₂}. (Note that I've used brackets here instead of parentheses to make the notation more set-like. The order in which you list the elements isn't important for a set, and the order of the points isn't important here, either.)

The way that we add these sets of points is by thinking them as divisors, so that we're really adding divisors instead of adding points on a curve. The set of divisors on a curve, along with the rule that defines how to add them is called the Jacobian of the curve.

For a curve of genus g, we can reduce any divisor to one no bigger than one of the form

∑_i=1:g(P_i) – g(O)

For a curve of genus g = 2, for example, we can reduce any divisor to one like

P = (P₁) + (P₂) – 2(O)

So that when we calculate something like

P + Q = R

for a hyperelliptic curve we actually calculating

(P₁) + (P₂) – 2(O) + (Q₁) + (Q₂) – 2(O) = (R₁) + (R₂) – 2(O)

How we find R₁ and R₂ from P₁, P₂, Q₁ and Q₂ is very similar to how we add points on an elliptic curve. In the case of an elliptic curve, we fit a line through two points, find the third point where the line intersects the curve, and reflect this point across the x-axis.

In the case of a hyperelliptic curve of genus 2, we fit a cubic polynomial to the points P₁, P₂, Q₁ and Q₂. We then find the two additional points where this polynomial intersects the curve and then reflect each of those points across the x-axis to get R₁ and R₂. Here’s a picture that shows what it looks like when we add to points P (the red points) and Q (the green points) to get R (the black points).

Because doing operations on hyperelliptic curves are defined in terms of divisors, it shouldn't be much of a surprise that pairings, that are also calculated using divisors, work just as well on hyperelliptic curves as they do on elliptic curves. That means hyperelliptic curves might end up be useful in pairing-based cryptography. If there's a good use for them, they'll probably appear in Voltage's products in the future. Right now, however, elliptic curves seem to be good enough.

Another model for usability

After reading the recent post about the usability lessons that software vendors could learn from the MMORPG Progress Quest, an alert reader suggested another good candidate for a very usable product, and that's the Holly Hop Drive, as seen in the episode "Parallel Universe" of the TV Show Red Dwarf.

Here's how the Holly Hop Drive is described in Red Dwarf:

LISTER: (Holding up the Holly Hop Drive) Is this it?

HOLLY: What do you think?

LISTER: It’s just a box with “STOP” and “START” on it!

HOLLY: It’s fairly straightforward. If you want to start it you press “START,” and you can work out the rest of the controls for yourself.

I can't say for sure whether or not the usability of Voltage's SecureMail was modeled on the Holly Hop Drive, but I don't recall it ever being mentioned. They do seem somewhat similar, though. In one case you just need to press "START" to get it working; in the other case you just need to click on "Send Secure."

Is cloud security a distraction?

An alert reader recently pointed me to an on-line comment that said the following about using computers in the classroom:

My school district blocks content but students are very good at finding and sharing proxy sites. They are also not as tech savvy as administrators and school board members seem to think they are. They are no more interested in using the laptops to learn than they are in using books. The laptops simply give them a more exciting way to be off task.

The alert reader then suggested that a similar comment about cloud computing security might be appropriate. Something like "CIOs are no more interested in cloud security than they are in other aspects of security. Cloud security just gives them a more exciting way to waste time."

I don't know how well it's actually understood by CIOs, but one of the biggest security challenges of cloud computing, is also the easiest to solve, and that's the problem of not exposing sensitive data in cloud computing environments. If you just encrypt your sensitive data that goes into the cloud then most of your problems disappear. That's not wasting time. It's solving a real security problem.

The main reason that all of your problems don't totally disappear is that key management is still a problem. There's actually a good discussion of this in the report Using Encryption to Protect Sensitive Data in Cloud Computing Environments that's available from the Burton Group. That's why Voltage is now developing key management technologies that work well in cloud computing. We have some fairly good solutions or this right now and we'll have some even better ones soon.

You'll probably see those discussed at future Voltage webinars.

Usability lessons from Progress Quest

Voltage is known for its innovative encryption technologies, but we're also known for how easy our products are to use. Not too many years ago, it was extremely hard for the average person to encrypt their email. The classic paper "Why Johnny Can't Encrypt" describes exactly how hard this can be for a typical user and anyone interested in the usability of encryption should read it.

With Voltage's SecureMail, on the other hand, a user doesn't have to do anything more than click on the "Send Secure" button instead of the "Send" button. If you're implementing SecureMail at a gateway appliance, they don't even have to do that – it can just happen automatically. Decrypting is just as easy.

Because we worry so much about the usability of our products, I'm very interested in seeing any enterprise security products that might actually be easier to use than SecureMail. If we ever find one of these, we'll probably be able to learn a thing or two from it. That's why I got so excited when I recently learned of an application that may actually be easier to use than SecureMail. In this case, however, it's not enterprise software. It's the game Progress Quest.

Progress Quest is a massively multiplayer online role-playing game (MMORPG). Before I heard of Progress Quest, I had never actually played a MMORPG, but that didn't stop me from being a government expert on the topic. I say that because I was actually the invited speaker at a government workshop on MMORPGs a couple of years ago. Unfortunately, the fact that I had to sign an NDA for this event means that I can't say much more about it.

Here's how the manual for Progress Quest describes the game:

Progress Quest is a next generation computer role-playing game. Gamers who have played modern online role-playing games, or almost any computer role-playing game, or who have at any time installed or upgraded their operating system, will find themselves incredibly comfortable with Progress Quest's very familiar gameplay. Progress Quest follows reverently in the footsteps of recent smash hit online worlds, but is careful to streamline the more tedious aspects of those offerings. Players will still have the satisfaction of building their character from a ninety-pound level 1 teenager, to an incredibly puissant, magically imbued warrior, well able to snuff out the lives of a barnload of bugbears without need of so much as a lunch break. Yet, gone are the tedious micromanagement and other frustrations common to that older generation of RPG's.

You start Progress Quest by picking the class and race of the character that you'll be playing. After that, the game does everything else for you. I even created a Progress Quest character: Elrond Hubbard, a Demicanadian Ur-Paladin with a name that's almost funny. If you're more adventurous you can pick races like Double Wookiee or Enchanted Motorcycle and classes like Fighter/Organist or Battle-Felon. I wasn't.

If you let Progress Quest run, your character will gradually increase in power and gain useful magical treasures. As I write this, Elrond Hubbard is currently Level 60 and has +23 Fine Gilded Plasma Vambraces. I'm not really sure if that's good or bad, but I certainly didn't have to pay any $9.95 monthly fees to get my character to where he is now.

Surprisingly enough, or at least surprisingly enough to surprise to a one-time government expert like me, Progress Quest seems to be fairly popular. The good reviews of it dramatically outnumber the bad reviews. And that's for a game where the player does absolutely nothing.

I'm never surprised to learn that most people really don't want to worry about encryption at all - they're too busy doing their jobs to worry about fighting with software that's hard to use. But I never would have thought that people would actually enjoy a game in which they do absolutely nothing.

In any event, I suppose that the bottom line is that we haven't quite figured out what we can learn from Progress Quest that will help us make SecureMail better, but that doesn't mean that we won't keep trying.

(If anyone wants to quote me about Progress Quest, here's my position on it: "Of all the games available for the PC, this is one of them.")

Visitors to Voltage's web site

According to a web site traffic ranking web site that I came across today, the most common upstream web site for Voltage's corporate web site is actually an on-line dating site. That made me wonder exactly who is coming to Voltage's web site and why. (It also made me question the accuracy of the rankings, of course.) I would have thought that people would come to our site to learn about either Voltage's technologies or products, but I appear to be wrong in this particular case.

An alternative explanation is that there are lots of single, attractive men and women who work at Voltage, and people who view their on-line dating profiles want to learn more about who their employer is. If that's the case, our marketing people might be able to use this slogan as the basis for a campaign of some sort:

Voltage: it's not just our technology that's hot.

That's a lot of tax

A bit of tax trivia. It's based on the data in Wikipedia, so I can't guarantee its accuracy, but according to the leading collaborative reference web site, the country of East Timor, sometimes known as Timore-Leste, has the world's highest tax revenue as a fraction of GDP. In the case of East Timor, it's actually 109.7%.

So it's no wonder there aren't many Voltage customers there. The TCO of our products may be a factor of three or more less than competing products, but when you're paying that much tax, it's probably even hard to justify buying SecureMail.

Key recovery vs. key escrow

An alert reader recently pointed out an interesting blog post that proposes a list of "red flags" that people should watch for when selecting a secure email solution. Apparently unhappy with this particular post, this reader suggested that the list of red flags in the interesting post be amended to include the following:

Red Flag #19. Alleged critics who disguise their opinions in pseudo scientific postings and don't declare their vested interest in competing firms and technology should not be trusted.

Red Flag #20. Industry Experts who quote themselves and reference only their own works in publications should not be trusted.

Red Flag #21. 4 year old competitive analysis papers do not have contemporary value.

I can't vouch for whether or not these additional red flags make sense or not, but I have to say that I was a bit puzzled by this particular red flag that the post mentioned:

Red Flag #3: It Just Works. Beware of hidden liabilities. For example, make sure that your keys are not escrowed in the servers providing the solution, as with IBE (Voltage). Nothing is safe in servers, not only from attackers but also from service providers and employees.

There's a big difference between the ability to do key recovery and key escrow, and this blog post (as well as some of the white papers available from the blog's web site) seems to badly confuse the two. Voltage's SecureMail lets you do key recovery. It doesn't do key escrow.

Key recovery lets you backup and restore cryptographic keys. If your CIO gets hit by a bus and you need access to their encrypted data, key recovery lets you do that. It also lets you recover your systems in the event of a failure, like a natural disaster might cause. Note the use of "you" here. A business doing key recovery backs up and restores their keys as needed and nobody else has access to these keys. Key recovery is often necessary for all sorts of legal and regulatory reasons, so it's a necessary feature of any enterprise encryption product.

With key escrow, on the other hand, a third-party gets copies of a cryptographic key. The US government led the push for key escrow back in the pre-dot-com era. The idea was for law enforcement agencies to have the ability to decrypt encrypted messages if they had the necessary court order. There was even talk of laws requiring all encryption to have this feature. It turned out that people weren't comfortable with the government having this ability and that technical problems plagued the proposed escrow schemes. In the end, the idea failed terribly. It's definitely not a feature that enterprise encryption products need.

Because IBE lets you calculate any private keys that you need, it makes key recovery easy. And because you can calculate any private keys that you need, you'll never be doing key escrow with IBE.

Key recovery is necessary. Key escrow isn't. Let's not confuse the two.

Jack Bauer Day - Spurring Innovation

“I know what it's like to feel like it's never going to end.” – Jack Bauer

One of the challenges which face many world-class engineering organizations is how to maintain an atmosphere of innovation while still delivering on customer commitments and scheduled releases. During the early stages of a start up innovation is rampant; there are typically no customers to worry about, no backward compatibility issues and no upgrade paths to test.

As a company matures I have seen many engineering teams stagnate, innovation slows down, and morale suffers. As a VP of Engineering I spend time on the lookout for the warning signs, at Voltage we are blessed with a strong highly motivated team.

Recently within the Voltage engineering team we held our first “Jack Bauer Day.” 24 hours of the engineering team doing anything they wanted to do. From 9 am in the morning of February 2^nd (2/4 for all us in the USA) until 9 am in the morning of February 3^rd the team had free rein with very little direction. The one condition: you had to present what you worked on to the rest of the team.

It was fascinating to watch how ad hoc teams formed; perhaps one of the most interesting was a team of three engineers who took on the task of developing Format Preserving Encryption on regular expressions as described by Bellare, Ristenpart, Rogaway and Stegers in their Format-Preserving Encryption paper.

Within the allocated time period the team was able to demonstrate features such as:

Given a regular expression R describing a regular language and a plaintext p which matches R, then p can be encrypted to a ciphertext c which also matches R and has the same length as p, and c can be decrypted back to p. For example:

Plaintext: jobs@voltage.com

Ciphertext: 3y90zagb@2GMK.com

Decrypted ciphertext: jobs@voltage.com

The team then expanded the initial implementation with some different length encryption. Given regular expressions R1 and R2 (each describing a regular language, with certain restrictions on R2) and a plaintext p which matches R1, then p can be encrypted to a ciphertext c which matches R2 (with varying options for the length of c), and c can be decrypted back to p.

For example:

Plaintext: 4005 Miranda Ave, Palo Alto, CA, 94043

Ciphertext: 8 Bauzvvbuwg Dr, Szptny Oqo, AZ, 25601

It never ceases to amaze me what a small team of focused engineers can achieve if left alone.

Was Jack Bauer day a success? Yes absolutely. We will be holding them on a regular basis.

Acknowledgments: Portions of this post was taken from team rugby’s write up of their Jack Bauer day.

Another interesting webinar: The Reality of Cyberattacks

It looks like our marketing guys are at it again. They're doing another webinar on yet another interesting topic: The Reality of Cyberattacks: Emerging Solutions for Today's Threats. It will be held twice over the next few weeks: on Tuesday, April 6 at 12:30 pm Pacific/9:30 am Eastern, and again on Monday, April 19 at 10:00 am Pacific/7:00 am Eastern. It's a one-hour presentation on preventing cyberattacks against the US's critical infrastructure.

The webinars that our marketing people do always seem to be useful, and the definitely have lots more useful information that other webinars that I've checked out. I couldn't sit through more than a few minutes of the last one that I signed up for, for example, because it turned out to be little more than someone running through a few sides that showed a series of graphs that were cut and pasted from various analyst reports without any useful analysis of the trends that the graphs showed. I just downloaded a pdf of the slides so that I could keep them around for a day or two before deleting them, just in case I heard that there was actualy some useful information hidden in them somewhere, but then went on to more productive activities.

I've never heard of people having that reaction to the webinars that our marketing people put on. That's probably a good thing.

A surprising place to find good customer service

Years ago, I bought a copy of the Style Guide for The Economist magazine. I can't find my copy of this book, so I'll probably get the exact wording a bit wrong, but according to the far-from-modest Style Guide, there are only two ways in which The Economist is superior to its competitors: in the quality of its analysis and the quality of its writing.

I'm often reminded of this when I hear customers telling us how much they like both Voltage's technology and our customer support, and I sometimes think that it might even make sense to say that there are only two ways in which Voltage is superior to its competition: in the quality of its technology and the quality of its support.

In any event, I found another example of excellent customer support recently, and this was in a place that took me totally by surprise. This was with customer service for my cell phone company (AT&T).

I don't look too closely at my cell phone bill because it gets charged to my credit card every month. Because I wasn't looking too closely at these bills, I didn't notice when the charges stopped being approved. I finally noticed this when there were three months of bills unpaid. When I noticed this, I called customer service to see what was the problem. It turned out that I hadn't updated the expiration date for the credit card that my cell phone was being billed to, and my issuing bank had decided to stop approving charges that AT&T had tried to bill to this credit card. 

I was a bit puzzled by this, because they had cheerfully accepted charges for almost a year without having the updated expiration date, but it didn't take long to sort out. The customer service person who took care of this for me was extremely helpful, and definitely left me with an extremely positive impression of AT&T. I was astounded by this experience because the customer support people that I've talked to at other cell phone providers weren't as helpful. Not even close, actually.

I certainly gained an appreciation for the value of good customer service from this experience. Instead of grumbling about the bad service that I received, I now tell people how good the service was with AT&T. From what I've heard, our customers have a similar experience with our support people. Yesterday I probably didn't understand exactly how this has contributed to Voltage's success. Today, I certainly understand it a bit better. I suppose that I hadn't experienced good customer service in so long that I had forgotten what it was like.

Now that's targeted phishing

I recently received an interesting targeted phishing message. It claimed to be from Voltage's CFO and asked me to download and run a progam (malware) that it claimed would provide input into some sort of insuance paperwork that Voltage needs to fill out. This phishing mail was interesting because it claimed to be from our CFO and had our CFO's real contact information at the bottom of the message.

I was surprised by how targeted this phishing was. Voltage has lots of large customers. The last I heard, we have roughly 1,000 enterprise customers and about 10 million users of our technologies, so there are probably lots of people out there who wouldn't be surprised to get an email from Voltage's CFO. On the other hand, the number of people who could reasonably expect an email from Voltage's CFO is fairly small compared to the number of people who have accounts at Bank of America or Wells Fargo.

So while I can understand why a phisher might think that it's reasonable to send out millions of phishing emails in an attempt to trick a few of the BofA or Wells customers into giving up their username and password, I can't quite understand why a phisher would think that it's worth sending out targeted phishing emails in an attempt to get a few Voltage employees to install malware on their computers.

Maybe this really indicates that Voltage is more successful than I've heard. I remember seeing a press release recently that talked about how we had something like 70% revenue growth last year, are profitable, generating cash from operations, etc. Maybe we're really doing even better than that. Why else would phishers try such a targeted attack?

More on the Cryptographers Panel misunderstanding

After pondering the odd reactions that I saw from some people who saw the Cryptographers Panel at the RSA Conference ("Oh no! Crypto is broken! We can't use it to protect sensitive data!"), I started to wonder why people don't have a similar reaction to tokenization. Except for the article that I recently wrote for the ISSA Journal, there's been absolutely no careful discussion of tokenization at all. Almost nobody can tell you exactly what it is and why you'd expect it to be secure. There are absolutely no standards for tokenization, and tokenization systems receive absolutely no peer review. Despite this, people are cheerfully willing to blindly assume that something is secure just because it's called "tokenization."

Why is this?

Now Voltage sells both encryption AND tokenization products. Which one we recommend to customers depends on exactly how they need to handle sensitive data after it's either encrypted or tokenized. And because we offer both options, we can afford to be fairly impartial in the battle that's apparently being fought by marketing people who don't really understand either encryption or tokenization.

Are people just afraid of encryption because it's hard? I'll admit that encryption is a difficult subject that's hard to master. Is the blind acceptance of the security of tokenization that we see a reaction to the previous generations of encryption technology that actually were too hard and expensive for most uses? There must be some good reason that people are willing to make a huge leap of faith just because a technology is called "tokenization."

Of course to really make people who blindly accept tokenization uncomfortable, ask them about that database of encrypted information that's used in the detokenization algorithm. If you can't trust the security of encryption, why would you trust the security of that database?

The bottom line is that the security of encryption is based on a solid foundation of rigorous research. There's no similar foundation for the security of tokenization. Maybe it's time to correct this oversight.

The PBA attack on RSA

I understand that we’re now living in a world in which everyone feels like they deserve their 15 minutes of fame, but I found the way that unwitting journalists managed to get it for security researchers Andrea Pellegrini, Valeria Bertacco and Todd Austin of the University of Michigan get their 15 minutes to be a bit frustrating.

Pelligrini, Bertacco and Austin actually did some fairly clever work: they found a way to cause bit errors in a microprocessor by carefully altering its input voltage, and then used these errors to help recover an RSA private signing key. For each bit error they were able to recover about 8 bits of private key, and were able to recover an entire 1,024-bit RSA key in about 100 hours.

If you’re interested in side-channel analysis and implementations of cryptography, their paper is well worth reading. On the other hand, their attack really isn’t the sort of thing to worry about too much. Devices that are designed to be secure, like HSMs and smart cards, filter the power so that you can't do attacks like the PBA attack, and with devices that aren't designed to be secure, there's always an easier way to recover a key from them than doing something like the PBA attack. This means that we won't be seeing hackers using the PBA attack any time soon, but you'd never think this from seeing the way it was reported by the media.

One headline read “'Severe' OpenSSL vuln busts public key crypto." That really doesn't seem to be a good summary of the PBA attack. The rest of the article didn't really to do much better.

Another headline said “RSA 1024-bit private key encryption cracked,” which was also a bit misleading. RSA-1024 wasn’t actually cracked. Instead, a particular implementation of it was beaten, and beaten in a way that really doesn’t pose a threat to most people. There’s absolutely nothing fundamentally wrong with RSA, although you really can’t tell that from this particular story.

The big problem seems to be that for each person who read and understood the PBA paper, there are probably thousands out there now wasting lots of time and energy worrying about whether or not the RSA-1024 that they use for SSL is secure enough. It almost certainly is, but you really can’t tell that from the media coverage of the PBA attack. 

Maybe some reporters ought to attend the next cryptography boot camp that our marketing guys hold. They did this at the RSA Conference last week, and from what I heard, the people who attended found it to be a very good use of a couple of hours. Maybe I’ll suggest that they invite some reporters to it the next time they organize it. Encryption is a tricky subject, and it's hard to understand all of the details of how it works. But if we had a few journalists who understood the basics of cryptography, we might not have had to spend so much time explaining exactly why this "severe vulnerability" isn't really worth worrying about.

Fortunately, Voltage's products use DSA for signatures instead of RSA. That will save us lots of time trying to explain to customers that while the PBA attack is actually some very clever research, it can't really be done to our products. Just saying that we don't use RSA for signatures is much easier.

Tuesday at the RSA Conference - Bah-weep-graaaaagnah wheep ni ni bong

(Dozens of menacing SHARKTICONS appear in front of KUP and HOT ROD.)

KUP: Don't act hostile. I'll use the universal greeting.

HOT ROD: Universal greeting?

KUP: Watch. I'll have them eating out of my hand.

(KUP holds out his hands to show that he's unarmed and then addresses the SHARKTICONS.)

KUP: Bah-weep-graaaaagnah wheep ni ni bong.

HOT ROD: (puzzled) Bah-weep-graaaaagnah wheep ni ni bong?

SHARKTICONS: Bah-weep-graaaaagnah wheep ni ni bong.

KUP: See, the universal greeting works every time.

Transformers: The Movie, 1986

Many of the vendors at this year's RSA Conference seem to have adopted the idea of a universal greeting. Maybe they got this idea from Transformers: The Movie. Maybe they didn't, but if they didn't, it sure was hard to tell today.

The universal greeting that many of the vendors at this year's conference seem to have decided upon is "You'll never be PCI compliant without my product." Apparently they tired of the previous universal greetings "You'll never be HIPAA compliant without my product" and "You'll never be SOX compliant without my product."

In a few cases, the vendors could actually give a reasonable explanation of exactly what parts of the PCI DSS their products were designed to help customers address, but in even more cases they clearly hadn't really given this much thought. Instead, they seemed to be relying on the fear, uncertainty and doubt that the PCI DSS seems to have caused to get potential customers interested in their products.

I doubt that this is going to be a successful strategy. It certainly didn't work for the previous universal greetings, and I doubt that it will work this time, either.

On the other hand, I was happy to see that Voltage's partners who were exhibiting at the show didn't seem to have this problem at all. I turned my badge backwards to that they couldn't see that I was from Voltage and asked some of them a few questions about how their technology worked and exactly how it could help someone reach PCI compliance, and they all seemed to understand exactly what was required by the PCI DSS and how their technologies helped their customers comply with the PCI DSS. 

Maybe this was because our business development team is fairly selective about who they partner with. Maybe there's some other reason. I don't know for sure, but I do know that after hearing this year's universal greeting over and over again, it was a pleasant change of pace to actually talk to people who seemed to actually understand their customers' problems and how to solve them.

How to protect test data

Like I mentioned in a previous post, many things are more complicated than you first think. Testing IT systems that handle sensitive data is a good example of this.

You probably don't want to use real data in testing because of the compliance issues that it can cause. On the other hand, you also want your test data to be as much like the real data as possible to make the results of any testing reflect the behavior of the system under real conditions as much as possible. This is actually tricky to do.

It looks like our marketing guys have put together a webinar that talks about how to solve this very problem, so if this is of interest to you, you might want to consider checking it out. You can sign up for it here if it sounds interesting.

Her's a quick summary of this webinar:

Securing Confidential Data in Non-Production Environments
End-to-End Data Protection for Test, Development and Outsourced Systems

Date: December 9, 2009

Time: 10 am PST / 1 pm EST

Duration: 60 minutes

This webinar doesn't have as clever a name as the last one that we had (The Renaissance of Enterprise Key Management and the Barbarian Hordes), but I'm sure that it will contain lots of useful information.

The limits of provable security

I've never quite understood the objections that people have to cryptographic schemes that are provably secure. If you have a proof of security then one of two things must be true: either the scheme is secure or there's a flaw in the proof. There's no other possible case.

All of the technologies that Voltage's products use have such proofs. The Boneh-Franklin IBE, the Boneh-Boyen IBE and our format-preserving encryption technology all have such proofs that have been published in peer-reviewed research journals. Because of this, I often don't understand the questions that I sometimes get about the security of our technologies.

Here's a situation that I've seen more than once. Someone asks about the security of our FPE technology, for example. We'll point them to the paper by cryptographers John Black and Phil Rogaway that has a proof for the security of the scheme. The next question is essentially, "But why should I believe that it's secure?" At that point, I'm never quite sure what to say next. If you have a proof in front of you, then either the proof is correct or there's an error in the proof. If this proof is of the security of a cryptographic scheme, then either the scheme is secure or there's an error in the proof. As mentioned above, there's no other possible alternative.

My recent experiences have led me to believe that there's a fundamental problem with this approach, and that's because many people really aren't comfortable with the idea of a proof. I've seen many cases recently where people essentially accept P and NOT P at the same time and don't seem bothered by doing this.

Every time I see this, I start thinking about the logical implications of it. After all, if you accept both P and NOT P then you can prove that absolutely anything is true. "If 2 = 3 then all cats are dogs" is absolutely true, for example. But because many people either don't understand this or don't believe this, I've come to the conclusion that proofs of security really aren't that useful. They may help specialists make sure that their work is correct, but to non-specialists they really don't say anything useful.

Key management for the barbarian hordes

It looks like our marketing guys are having another webcast about key management. The title of this one alone, "The Renaissance of Enterprise Key Management and the Barbarian Hordes Enterprise Key Management: Fact and Fiction", makes me think that it will be too good to pass up.

This entertaining and educational webcast will be held on November 17, at 10 AM PST (1 PM EST). You can sign up for it here.

More Bayesian thoughts

Encryption isn’t as widely used as it could be, and we might be able to understand this from the point of view of Bayesian statistics. Here’s why.

Much of the negative feelings that people have about encryption can probably be explained by the bad reputation that encryption has, and this reputation is probably justified. Many people who used some of the encryption products that were available back in the dot-com era are probably still suffering from the trauma that using encryption caused them. Older encryption products were hard to use, which made them expensive to support.

Even security specialists couldn’t use some of the early encryption products. When I worked at one of those dot-com era companies that made those early encryption products, I remember being stunned by a demo of an application that we had developed to let users authenticate to a server using the WTLS protocol. It was terrible, and this was from the point of view of a person who thought that using X.509-based client certificates was easy.

Many people suffered through using the early encryption products, and they’ve probably developed a significant bias against using encryption because of this. This is perfectly understandable. From a Bayesian point of view, they’ve built a knowledge base that tells them that encryption is hard and expensive, and this will affect how much they believe that newer products are actually easier to use.

Suppose that you tell a person who used older encryption technologies that the newer ones are much easier to use. If they're using Bayesian reasoning, they probably won't believe you, and this is because of what they're really estimating when you tell them this.

Let E represent how much someone believes that encryption is actually easy to use, N represent the claim that newer encryption technologies are easier to use than earlier ones, and K represent experience with the older technologies. If people are using Bayesian reasoning, instead estimating P(E|N), they're really estimating P(E|K∩N). If you’re really motivated, you can work through calculating P(E|K∩N), much like we did in an earlier post, and if you do this you’ll find that we can’t expect people to believe that the newer technologies are actually usable.

The problem is that they are.

Encryption has become much easier to use in the past five years or so, and it’s now feasible to use in many situations where it wasn’t practical at all in the past. That means that there’s now a solid business case for its use, even though people may not actually believe it. After all, the people who are making decisions about using encryption today are the same people who had to suffer through using the bad implementations of it that we had in the dot-com era. And because their experience has told them that encryption is hard and expensive, we can expect them to not believe that newer technologies are really any better.

One way to address this problem may be for researchers to look at the newer technologies and try to measure their usability. The famous paper “Why Johnny Can’t Encrypt” was followed by “Why Johnny Still Can’t Encrypt” a few years later, but the later work didn’t look at the newer technologies. Instead, it looked at how much the same technology used in the earlier study had improved. A more useful study might look at products like Voltage’s SecureMail, which is much easier to use than the previous generation of products.

The participants in the study that was described in “Why Johnny Can’t Encrypt” had to do some fairly low-level work with their keys. A user of SecureMail, on the other hand, doesn’t need to worry about those details at all. If they can click on the “Send Secure” button instead of the “Send” button in their email client then they can send encrypted messages. I can’t believe that any study would find that particular task too difficult for most people to do.

The problem may be finding a way to get people to believe that it’s really that simple. If they’re using Bayesian reasoning, however, they might not even believe it after they’re shown it. How do you work around that?

Why use Secure Mail?

I predict that some day we'll notice that very few consultants encrypt their email. This will be because of the secure email products that they were forced to use when they worked at larger companies. My experience with ice cream leads me to believe this.

When I was a kid, we would frequently get ice cream on the way home from school. I always wanted to get a clown cone, a scoop of ice cream in a sugar cone that's decorated with candy to look like a clown. Clown cones don't actually taste that good because they've usually been sitting out for quite a while before you buy them, but they certainly look good, and that's why I always wanted one.

My parents, however had different ideas. They knew that clown cones don't actually taste very good, and they never let me get one. After years of being cruelly denied clown cones, now I'm the dad, and nobody (except my wife of course) can tell me that I can't get one. I do this every time I take my kids out for ice cream, cheerfully ignoring the fact that the clown cones really don't taste that good as I do it.

Now consider the people who have to use email encryption on the job. Many of these people aren't lucky enough to be using Voltage's SecureMail, which is extremely easy to use. Some of them even use PKI and S/MIME to protect their email. They probably hate every minute of this, but are forced to use S/MIME anyway.

Some of these people are going to become consultants one day. They'll be their own boss and won’t have a security department to force them to use S/MIME. I expect that many of these people will rebel against their terrible experiences with S/MIME by intentionally avoiding using encrypted email as much as they can, ignoring that fact that they really should be protecting sensitive information.

What's the solution to this? Use Voltage's SecureMail, of course.

A big red flag

Seeing the phrase “up to” should make you very suspicious of what comes after it, particularly when it’s used in phrases like “may be up to 10 times faster.” One of Voltage’s competitors actually used that phrase to describe how the performance of their products compare to the performance of Voltage’s. In this particular case, they weren’t being totally honest.

Consider the statement “my salary could be up to $1 million this year.” The unfortunate and harsh reality is that I make much less than that, but the statement is certainly true nevertheless. Similarly, our competitor's claim that their performance “may be up to 10 times faster” is also true for much smaller multiples. It’s even true if they’re performance is actually worse, isn’t it? A multiple of 0.5 is also less than a multiple of 10, after all.

I’ve seen one case where the phrase “up to” actually made sense. That was in one of Symantec’s reports on the underground economy. When they estimated the value of stolen credit card numbers had to cyber-criminals, they said that it was “up to $5 billion,” but that was because they didn’t know how many of the credit card numbers being sold were actually valid. If all the credit card numbers were valid, they’d be worth the full $5 billion, but because some were probably invalid, the actual value was probably less than $5 billion, and it was hard to estimate by how much. That’s a case where saying “up to” seems to make sense. In most cases, however, it should be a warning that what’s being said probably isn’t very accurate.

I plan to do up to 100 more posts that talk about this in more detail.

Software as a service

I recently stayed at a hotel in which I saw the following label on the minibar in my room: "This minibar has a tamper-evident seal for your protection." Because I was paid to beat things like tamper-evident seals in a previous job, and was actually fairly good at it, I couldn't resist the challenge that this posed. I only had a Swiss Army knife with me, which is a little too big for this kind of work, but it turned out to be good enough. In a minute or two I had the minibar seal removed yet intact.

After looking in the minibar, I had to wonder exactly how the seal was designed to protect me. Should I have felt safer because the seal guaranteed that the minibar wasn't being used by terrorists to store a few spare pounds of weapons-grade plutonium? Instead of protecting me, the seal was really there to protect the hotel's revenue, wasn't it? Why did they feel the need to lie to me about the reason that the seal was there?

It seems like a good rule of thumb to never believe what businesses tell you about why they're doing things. This applies to more than just hotels. It also applies to software. In particular, do customers really want software as a service like some software vendors would have you believe, or is this just another attempt to increase revenues or to do some accounting trick that makes things better for software companies?

I'm not convinced that some things are useful as a service. I have no interest at all in replacing my version of Microsoft Office with a software-as-a-service version of it, for example. Other applications, however, may make sense as a service, and many of these probably relate to security. This is because the controls that you need to run a reasonably-secure security application can be fairly expensive. This means that it may make sense to pay someone else to run a server for you in their secure data center. That way you're only paying part of the costs of the secure facility instead of all of it. If you're big enough to have your own secure facility, that may not be useful to you, but for many smaller businesses, some security applications seem to make sense as a service.

That's probably why most of the customers of Voltage's software-as-a-service offering, Voltage Security Network, are smaller companies. Not all of them are, of course, and the larger ones have an entirely different set of reasons for liking VSN, but the smaller ones seem to use VSN to avoid the costs of running their own key server, provisioning users, software distribution and overall systems management. For the smaller businesses, VSN is probably a good example of a software as a service offering that makes sense. Are there any other obvious examples where it's clearly better to use software as a service instead of licensing and running the software yourself?

Another misunderstanding

There was an interesting press release on February 24 from Cellopoint, a company based in Taiwan that makes information security products. Here's part of it.

Cellopoint today announced the immediate availability of Cellopoint Email Encryption, a modular solution of products for data loss prevention and regulatory compliance that can simply the deployment processes and eliminate the management overhead. For financial institutes, sending and receiving inadequately secured email statement to customers was becoming a potential security risk. So they deployed email encryption products for secure message delivery. But some of them were using identity based encryption which employed social security number and some kind of username as secret keys. The security and strength of the keys were doubtful. Encryption technology can be divided into symmetric and asymmetric key algorithms. Symmetric key is to protect confidentiality while asymmetric key is providing authentication and non-repudiation. Each of them has its own pros and cons, so the better way is combine them into an integrated solution. Public key infrastructure (PKI) is the well-known cryptography system utilizes both symmetric and asymmetric algorithms but it is hard to install, deploy, maintain and is very costly. Cellopoint Email Encryption is an easy-to-use, gateway encryption solution. It simplifies CA management process and provides confidentiality, identity identification and non-repudiation.

I would think twice about buying encryption technology from these guys. It looks like they don't quite understand what identity-based encryption is, so they're probably not really encryption experts. IBE has a very clear and precise definition. It's defined in the paper "Identity based encryption from the Weil pairing" by Dan Boneh and Matt Franklin if you're really curious about it. Some things are properly called IBE while others aren't, and it certainly looks like the people at Cellopoint don't understand that. They also don't seem to understand that IBE is a public key technology, just like RSA or Diffie-Hellman. These aren't the kinds of things that you'd expect the average guy on the street to understand, but they're certainly the kinds of things that you'd expect a vendor of email encryption products to understand.

The IBE that Voltage uses has a formal and rigorous proof of its security, so claims like "the security and strength of the keys were doubtful" won't withstand much scrutiny, and it takes more than a competitor claiming that our technology isn't secure to make it so. If there's actually a problem with the security of our technology, that means that there's a flaw in the proof of its security. Thousands of cryptographers have looked at this proof, and none of them have found that it's incorrect. This means that if someone claims that Voltage's IBE isn't secure then either they really don't have the background to really make such a claim or they've found something significant that will get their paper accepted at the cryptography conference of their choice if they write it up. The chances of all the leading cryptographers being wrong is probably very small, so it's very likely that claims that Voltage's IBE is weak are also wrong.

Maslow's hammer

I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.

Abraham Maslow, Psychology of Science: a Reconnaissance

Although he’s most famous for Maslow’s hierarchy of needs, Abraham Maslow also noted that people with incomplete knowledge or understanding tend to propose the same type of solution to every problem that they encounter. This phenomenon isn’t widely known as “Maslow’s hammer,” although there’s probably a good reason to use that term for it. Maslow may not have been the first person to notice it, but he was probably the first to describe it in a way that’s easy to understand and explain. I see Maslow’s hammer fairly often in the field of information security, but that’s probably just because that’s an area I know something about. It probably happens in other industries too, but I don’t know enough about those industries to see it.

There are lots of people out there that understand a little about PKI, for example. Some of them learned it when PKI was trendy and fashionable during the dot-com boom. Others learn a little about it when they get their MCSE certification. In most cases, they really don’t use it much because very few applications support it. So even if they’ve set up a PKI in their organization, they probably haven’t done much with it. But because they know a little bit about PKI, that becomes the hammer that Maslow’s hammer describes, and they often treat every encryption project that comes along as one that can be solved by PKI. Some can, but even more can’t.

Voltage’s sales managers often meet people who have the PKI hammer in their toolbox, and have to convince them that there’s a better alternative. That can be tricky, but the benefits of using identity-based encryption are fairly significant. In most cases, it turns out to be worth the time and effort that it takes customers to learn about how IBE can be a good alternative to PKI.

One day, someone will probably invent a technology that’s better that IBE in some way. IBE already has lots of users – roughly 10 million users at several hundred businesses. So when the better technology comes along, the company that’s selling it will probably have to overcome the resistance of customers who will be viewing IBE as the hammer with which to solve all of their encryption problems. But with any luck, Voltage will invent that next step.

Has secure email crossed the chasm?

 

The recent large deployment of secure email at Wells Fargo that Voltage recently announced is just one of many large deployments of Voltage's SecureMail in the past year or so. This might be enough to make you wonder exactly where secure email is on the technology adoption life cycle. Has it crossed the Chasm that was popularized by Geoffrey Moore and entered the Early Majority phase yet? Or is it still stuck in the Innovators phase?

To understand this, it might be helpful to describe exactly what the technology adoption life cycle is. It turns out to predate Moore's book Crossing the Chasm by over 30 years, and its first version actually modeled the adoption of a fairly different area: it was actually first used to describe how farmers adopt new agricultural technologies. The first discussion of the technology adoption life cycle was the 1957 report The Diffusion Process, by George Beal and Joe Bohlen that was published as a supplement to Iowa's Regional Extension Publication No. 1, How Farm People Accept New Ideas. This model was then described in the 1962 book Diffusion of Innovations by Everett Rogers, where Rogers generalized the process to more that adoption of agricultural technology by farmers.

Beal and Bohlen modeled the adoption of new technologies by farmers as a process with five stages: Awareness, Interest, Evaluation, Trial and Adoption. In the awareness phase, people know about a new technology, but lack details about it. In the interest stage, people want more information about a new technology. In the evaluation stage, people think about a new technology and whether or not it will benefit them. In the trial stage, people start small-scale experimental use. In the adoption stage people have large-scale, continued use of a new technology. What's interesting in Beal and Bohlen's discussion of these five stages is how the most common way for people to learn about new technologies change at each step in this process. The most common ways to learn about a new technology in each phase are shown below.

Awareness	Interest	Evaluation	Trial	Adoption
1. Mass media	1. Mass media	1. Neighbors and friends	1. Neighbors and friends	1. Neighbors and friends
2. Government agencies	2. Government agencies	2. Government agencies	2. Government agencies	2. Government agencies
3. Neighbors and friends	3. Neighbors and friends	3. Mass media	3. Mass media	3. Mass media
4. Salesmen	4. Salesmen	4. Salesmen	4. Salesmen	4. Salesmen

We can summarize this by saying that when people move past just interest in a technology and start to evaluate it, then the source of their information changes from the media to people that they know. At that point, it seems reasonable to assume that the marketing efforts of technology companies should change. I don't know if sales and marketing people at technology companies use this model, but I wouldn't be surprised if they do. Curiously, salesmen come in dead last in every phase. Maybe they're never perceived as being a good source of information because they can probably be relied on to give information that's biased towards their products.

When it comes to individuals, Beal and Bohlen divided them into categories that are determined by how soon they adopt new technologies. This is where they divided people into the categories of Innovators, Early Adopters, Early Majority, Majority and Nonadopters. This is the model that Moore popularized in Crossing the Chasm, changing Majority to Late Majority and Nonadopters to Laggards when he did. Where is secure email on the technology adoption curve? Has it made it past Moore's Chasm?

Technologies reach Moore's Chasm in the Early Adopters phase. This means that if a technology is in the Early Majority phase then it's definitely past the Chasm. If it's still in the Early Adopters phase, then it might or might not have. People who are early adopters tend to take risks, but only to achieve very focused goals. They'll even work with start-ups to do this. People in the Early Majority are pragmatic. They don’t like the risks associated with new technologies but are willing to look at technologies when they've been tested by others.

Based on my experience at Voltage in the past five years, it seems to me that secure email entered the Early Majority phase in the past year or two. Before then, it was definitely only used by Early Adopters. Back then, Voltage's customers were ones that felt willing to take the risk associated with a small company and a new technology because the technology solved certain problems cheaper and easier than alternatives. More recent customers, however, seem to see secure email as an established and proven technology. They're now willing to deploy it widely, and Voltage now has several customers with over 100,000 users of its SecureMail products.

If Voltage's experience is representative of the entire secure email market, then secure email has crossed Moore's Chasm and is on its way to becoming used by a majority of businesses. That means that we'll probably see even more adoption of secure email in the future, and large deployments like the one at Wells Fargo should get more and more common. They might even become so routine that they're not even interesting any more.

Mehrabian's rule

Albert Mehrabian’s 7-38-55 rule is almost always misinterpreted. These misinterpretations probably aren’t too far from the truth, however, and they can probably explain why the Internet is such an obstacle to communicating effectively. Mehrabian’s 7-38-55 rule actually says that when we communicate face-to-face, how well we like the person that we’re communicating with depends on three factors: the words used, the tone of voice used, and the body language used. He first described this in his 1971 book Silent Messages, where he estimated that 7 percent of the overall level is due to the words used, 38 percent is due to the tone of voice used, and 55 percent due to the body language used. 

This is often generalized to saying that in any face-to-face communication that 7 percent of the information that we send is verbal, 38 percent is sent in our tone of voice and 55 percent is sent through body language. Mehrabian’s research doesn’t actually support this generalized result, but that hasn’t stopped people from calling this conjecture “Mehrabian’s rule,” or inaccurately attributing the generalized result to Mehrabian.

It’s probably the case that most communication is non-verbal, even if it doesn’t follow the 7-38-55 rule, and that’s why the Internet causes so many problems. Even if the exact fraction of the information that’s lost when we communicate on-line isn’t exactly 93 percent, it’s probably a significant part of it, and this causes many more misunderstandings than you would ever get face to face. Here’s an example of how this recently affected me.

There are now three IETF RFCs that describe identity-based encryption and how to use it in secure email. While getting one of these standards through the IETF bureaucracy I had to get three new media types defined for the types of data that get transported over HTTP when IBE is used: IBE public parameters, an IBE private key request and the IBE key that a of key server returns to a user.

There’s a mailing list where you propose new media types and other list subscribers get to critique your proposal. In my case, we had a heated debate over my proposal that turned out to be just over a slight misunderstanding in how one particular parameter was defined. If we were sitting down face to face, this misunderstanding would have been obvious almost immediately. But because we were only communication over email, lots of information was lost. Maybe it wasn’t exactly 93 percent of it, but it was a significant amount. This led to wasting several days in a debate that wouldn’t have taken more than a few minutes to settle face to face.

Lots of communications over the Internet seem to be plagued by the same problem, and because there’s no easy way to indicate tone of voice or body language over the Internet, we’re probably stuck with the imperfect communication that it allows. I suppose that you could write an IETF standard of some sort that might help fill the gaps in communication that the Internet creates, tags like <humor> and </humor> that you could use to indicate where you’re not being serious. But because you’d have to develop this standard over the Internet, it would be much harder to do than it needs to be.

Size does matter

Voltage is known for its innovative technologies. We're also a small company. It turns out that that might not be a coincidence. I learned this while reading "Entrepreneurial Risk and Market Entry," by Brian Wu and Anne Marie Knott. This paper talks about two things that I found interesting. The first relates to how risk-averse entrepreneurs are. The second relates to how big companies behave differently that small ones do.

One of the common misperceptions about entrepreneurs concerns their willingness to accept risks. It turns out that entrepreneurs really don't like to take risks – they're actually more risk averse than average. This is apparently balanced by their overestimation of their own abilities. They think that they're smarter than they really are. This means that they'll do things that others wouldn't think to do. They don't do these things because they willingly accept risk. Instead, they accept the risk because they don't know any better. Economists call this the difference between "demand uncertainty" and "ability uncertainty."

When it comes to big companies versus small companies, it turns out that there are three big differences in how they behave. Big companies tend to have broad and general strategies, which leaves parts of markets under-served. Small companies tend to take advantage of this and go after the under-served parts. Large companies tend to engage in slow and gradual innovation, while small companies tend to engage in more radical innovations. And when big companies do innovate, they tend to abandon their innovations because they don't fit well with their existing plans. Small companies don't do this.

Not surprisingly, this sums up fairly well how Voltage has succeeded. Larger security companies have broad product strategies in which encryption is just a small part. These strategies didn't create products that made secure email easy enough for most people to use, which left the opportunity for Voltage to succeed with its SecureMail products. The ease of use of SecureMail is based on identity-based encryption, a fairly radical innovation that makes encryption simpler and easier to use. Just to show that we follow all three of the differences that Wu and Knott list, I could mention that we don't have any plans to abandon our IBE technology, but that should be fairly obvious.

How many users?

Encrypted email is getting very popular these days. Voltage now has roughly 10 million users of its SecureMail product, for example, and other secure email vendors probably have similar numbers that they could cite. That's why I wasn't really surprised to see the counter on the Zix Corporation web site that shows how many users they have. When I checked this, the number was roughly 14 million. That's a respectable number, isn't it?

But as I looked at this web site, this number increased by one. A short while later it increased by one again. The number of users of Voltage's SecureMail typically increase by several thousand at a time instead of one by one, so this seemed a bit odd. To see what was really going on, I looked at the source code of Zix's web page. You can do this in Internet Explorer, for example, by going to the View menu and then selecting the Source option of the menu that appears.

When I did this, I was a bit surprised to see that the counter that shows how many users they have is based on the clock of the computer where the web browser's running and has no obvious connection to the actual number of users that Zix has! Here's part of what I found. This is the code that creates the number of users that is displayed on the Zix web site.

function ZixCount2()
{
    today = new Date ();
 startDate = new Date (2009,0,06);  //months in js run 0-11 (must reset when changing goal)
 startVal = 13885156;  //starting Value (must reset when changing goal)
 var one_day=1000*60*60*24;
 
 perWeek = 100000;  //set rate per week
 rate = 604800/perWeek;
 
 goalDate = new Date (2009,0,8);  //Set a Goal Date (months in js run 0-11)
 goalVal = 13996467;  //Set a Goal Value
 
 if (goalDate <= today){
  startDate = goalDate;
  startVal = goalVal;
 }
 
 currentVal = Math.round(startVal + (today.getTime() - startDate.getTime())/1000/rate);
 
 if (goalDate > today){
  daysLeft = Math.ceil((goalDate.getTime()-today.getTime())/(one_day));
  daysTotal = Math.ceil((goalDate.getTime()-startDate.getTime())/(one_day));
  dailyOffset = (goalVal-currentVal)/daysTotal;
  currentVal = Math.round(currentVal + (dailyOffset*(daysTotal-daysLeft)));
 }
 
 
 //document.write("Current Val = " + currentVal);
 //document.write("<br />");
 //document.write("daysLeft = " + daysLeft);
 //document.write("<br />");
 //document.write("daysTotal = " + daysTotal);
 ChangeValue(2, currentVal);
    timerID = setTimeout("ZixCount2()",rate) } // -->

So the number of users that the Zix web site shows doesn't really seem to be related to how many users they actually have. Instead, it's just based on what time it is. You can even change the number of users that the web site shows by changing the date and time on your computer's clock!

I'm not sure why Zix did this. I don't doubt that they have millions of users of their email encryption product, but it certainly looks like the number on their web site doesn't really correspond to the number of users that they actually have.

Enterprise key management

There’s a new report, Enterprise Key Management Systems, from the Burton Group. Many vendors talk a lot about key management, but this report seems to show that many of them don’t really have much of an interest in it beyond what’s needed to make their own products work. This report lists 10 areas that use key management: file encryption, laptop encryption, email encryption, etc. For 13 vendors, including Voltage, RSA/EMC, nCipher, NetApp, SafeNet and eight others, it lists which vendors have an offering in each area.

Voltage has more offerings than any other vendor, having something in seven of the 10 areas. RSA/EMC is a close second, offering something in six of the 10. Three more, nCipher, NetApp and SafeNet offer something in five of the 10.

The top five enterprise key management vendors all have an offering in at least half of the 10 areas, and seem to be ones that are fairly serious about enterprise key management. Their offerings overlap in some, but not all, areas, which makes it looks like the five leaders aren't really direct competitors in most cases. There's some overlap between the areas that Voltage covers and the ones that RSA/EMC covers, for example, but not enough to really say that the two companies are really competitors.

The other eight vendors seem to be more niche players, and don’t seem to have an interest in developing solutions tthat address he broader enterprise key management problem. They seem content to just manage keys that their applications need.

Yet another big deployment

Today, Voltage announced that Wells Fargo has dramatically increased the size of their deployment of SecureMail, Voltage's line of products that's used to encrypt email. The new Wells Fargo deployment will be hundreds of thousands of users. While this might have been a big deal a few years ago, these days, it's almost not even newsworthy. After all, there are roughly 600,000 SecureMail users at a large retail business and another 250,000 SecureMail users at a large health care business. Each of these deployment was fairly easy, and required minimal support from Voltage's support team. If you're new to secure email, this may not sound impressive, but if you've used it for a while, this is simply astounding. Just a few years ago, there was no way to realistically deploy secure email to a few hundred thousand users unless you were the US government and didn't mind spending a billion dollars or so.

I almost feel sorry for people who are just getting their first exposure to secure email these days, because it's not really very interesting anymore. Not long ago, it definitely appealed more to computer hobbyists who enjoyed tinkering with the secure email system to get it working much like ham radio operators enjoy tinkering with their radios to get them to work. Now, it's much easier and cleaner, and hobbyists have to find other ways to amuse themselves.

The people for who Voltage's SecureMail is their first exposure to secure email won't be able to tell stories to their coworkers one day about how they overcame seemingly insurmountable obstacles and actually managed to send an encrypted email. Some might not even know they're using it. There's still plenty of difficult software out there, though, so they won't miss out on the experience of fighting with it. This seems to be an unavoidable part of working in the twenty-first century.

Ease of use

Any security product needs to be very simple to use if it’s going to become successful. If they’re not simple to use then the cost of supporting difficult products can easily outweigh any benefits from them. That’s why Voltage’s SecureMail has the minimal level of user involvement. If a person sending an email can click on the "Send Secure" button instead of the "Send" button, the can use SecureMail. There’s nothing else that they need to do.

It’s probably possible for people to use more complicated secure mail systems. President Obama probably has no difficulty using secure email on his BlackBerry, but he has a fairly large staff to configure it for him. He probably has fairly good tech support too. Similarly, generals don’t seem to mind using digital certificate from the Department of Defense’s PKI to send signed and encrypted email, but they also have a staff to take care of any problems that might occur.

People that don’t happen to be the President of the United States or a general officer still need to encrypt email, however, and they normally have to do it on their own. In these cases, ease of use is critical.

There are also probably good reasons why people simply don’t want to use secure email that takes more effort than clicking on "Send Secure" instead of "Send." It’s probably very similar to the reason that many people don’t use the latest social networking application, or whatever the trend du jour is. This may be because they just have better things to do.

When you’re young, you tend to have lots of free time, but also don’t get paid much. This means that you have the time to do what you want to do but sometimes can’t afford to do these things. You’re resource constrained, not time constrained. Not too many years later, most people find that this situation has reversed. At that point, they find that they’re married, have children and that their job now carries more responsibilities than can easily be done in an eight-hour day. At this point, there are more demands on their time than there are hours in the day, and they’re now time constrained instead of resource constrained. When that happens, learning a new security technology is now competing with dozens of other priorities for the little time that’s available.

To most people, spending the time to learn a complicated security application never becomes a high enough priority that they decide to do it. There’s always something else that’s more important. This isn’t limited to security, of course. This may also explain why you see lots of younger people using the newest social networking applications while those that a bit older often don’t get around to using them: there's often a better use of their time.

Algorithm agility with IBE

In his recent blog post, enterprise architect extraordinaire James McGovern mentions that he’s concerned that there’s no algorithm agility with identity-based encryption. His thoughts may be based on a misunderstanding of what IBE actually is. Here's why.

IBE is really a family of public-key technologies that share a common set of properties, and there are actually several different IBE schemes. Voltage’s shipping products actually support two of these:Boneh-Franklin IBE and the Boneh-Boyen IBE. So even within the technology used by a single vendor, there’s still the opportunity for algorithm agility while keeping the useful properties of IBE.

Most of Voltage’s customers use Boneh-Franklin IBE. It was the first IBE scheme that was both practical and secure. It’s also the easiest to understand. Boneh-Boyen IBE is harder to understand. It also has a number of properties that differentiate it from the Bohen-Franklin scheme, most of which only matter to specialists in the field of pairing-based cryptography. Most people really don’t care, for example, whether an identity gets hashed to a point on an elliptic curve or it gets hashed to an integer. Boneh-Franklin IBE hashes an identity to a point on an elliptic curve. Boneh-Boyen IBE hashes an identity to an integer.

The likelihood of a weakness being found in either the Boneh-Franklin of the Boneh-Boyen scheme is also quite low. Both of these schemes have formal proofs of their security. Lots of smart people have reviewed these proofs, so they’re probably correct. This means that it’s very unlikely that there’s a weakness in either the Bohen-Franklin or the Boneh-Boyen IBE scheme that can be exploited.

There are also other vendors that use IBE technology in their products. I can’t say for sure, but I wouldn’t be surprised if their products have the same level of algorithm agility that Voltage’s products do. I can say with certainty that the concerns around algorithm agility really don’t apply to Voltage’s products. You’ll have to ask other vendors about exactly how they do things.

IBE for key management

A few months ago, Trust Catalyst released their 2008 Encryption and Key Management Industry Benchmark Report. Here's the data from this report that shows how challenging the 330 people who responded to Trust Catalyst's survey rated various areas of key management. What's interesting is that all of the top three challenges listed here are ones that are particularly easy to solve if you use identity-based encryption (IBE).

       

With IBE, it's easy to calculate keys as they're needed. This makes it practical to use short-lived keys, and if you do this, there's no need at all to revoke keys.

And because IBE keys are calculated, there's no need at all to back them up. Calculating an IBE key a second time is no more difficult that calculating it the first time, so instead of keeping a secure archive of keys, you don’t need to archive IBE keys at all. Instead of getting a key from the secure archive server, you just recalculate it when you need it, which makes backing up and recovering IBE keys extremely easy.

Similarly, because you can calculate any IBE decryption keys from just a single system-wide master secret when you need them, making IBE keys accessible to a disaster recovery site is extremely easy. Even if you can't reach an IBE key server from a disaster recovery site, it's easy to get a key server up and running in the disaster recover site in just a few minutes. All you need to do is configure a key server with the master secret, and you're done. This takes no more than a few minutes, so this problem is also extremely easy if you're using IBE.

In the light of Trust Catalyst's report, I have to wonder why more people aren't using IBE for things other than email. It seems to be the logical choice because it makes what seems to be the biggest challenges of key management extremely easy.

Should standards be free?

There's one big difference between the IETF and other standards bodies: IETF standards are free while most other standards aren't. The standards that you need to pay for usually aren't very expensive. You might pay $100 or less for most of them, which is a very small cost relative to the other costs that engineering organizations incur. Despite this, the modest prices for standards seem to dramatically limit how widely they're adopted.

One of the IETF working groups that Voltage monitors but doesn't actively participate in received an email from a member of one of the standards bodies that charges for its documents. The email asked why the working group seemed to be reinventing that the other group had already standardized. Although nobody in the IETF working group seemed to be inclined to even look at the other standard, and the reason was almost certainly that they would have had to pay to see a copy of it.

So the IETF working group went ahead and reinvented the content of the non-free standard. They probably ended with up something that's close to the other standard, but totally incompatible with it. I'll never know if this is true or not. I'm certainly not going to spend $100 to find out, and few other people seem to be either. Standards seem to need to be free to useful.

Largest Data Breach

It looks like Heartland Payment Systems is the latest victim of a data breach, although it might be more accurate to say that both they and their customers are the victims. In this case, hackers appear to have sniffed transactions with the Heartland system, all of which were unencrypted. Heartland's CEO has been quoted as explaining that they need to have the transaction data unencrypted to process it. Here's a summary of what's known so far:

• Heartland Payment Systems processes payroll and credit card payments for more than 250,000 businesses
• They reported that they discovered an intrusion last week that exposed consumer credit card data last year
• They were alerted to suspicious activity in processing Visa and MasterCard transactions—auditors then discovered malware that had compromised the company’s data
• Company spokesperson says they “understand that this incident may be the result of a widespread global cyber fraud operation, and we are cooperating closely with the United States Secret Service and Department of Justice"

This incident highlights the fact that achieving PCI compliance does not imply that a business has achieved real security. For example, PCI does not currently require that credit card data be encrypted as it is moved between machines on a corporate network, which is highly likely where this breach occurred. This incident should serve as a wake-up call that PCI should be used as a starting point instead of an end point in the effort to protect sensitive data.

Robust encryption technologies and innovative solutions that leverage them exist today that could have prevented this breach altogether. In fact, best-in-class businesses are currently implementing software that can address these types of attacks. However, Heartland appears to be an example of an organization which assumed that simply passing its PCI audit meant that it was truly secure.

Why were they targeted? Data can now be easily monetized, creating demand for criminal data theft, and increasingly, multi-tiered networks of organized hackers have replaced bored teenagers as the perpetrators of computer attacks. TJX, Hannaford, RBS Worldpay and now Heartland are just a few of the organizations that have fallen prey to orchestrated offensives. The perpetrators here are likely multi-tiered networks of hackers and social engineering manipulators who can gather and auction bulk data to the perpetrators of credit card fraud. This attack could potentially have been enabled or even initiated by an insider, even though Heartland says in this case it was not.

How can organizations reduce this type of risk? Most processors – even if PCI compliant – currently have, as standard practice, sections of their network where data is not encrypted or in the clear in order to communicate with the upstream clearinghouses and card companies (e.g. Visa, Mastercard, American Express). These gaps create excellent attack points for hackers, as data is fully exposed.The only solution to eliminate this threat is end-to-end encryption. New techniques such as Format-Preserving Encryption (FPE) and Identity-Based Encryption (IBE) allow organizations to encrypt information at the point of capture, and data is persistently protected all the way to the trusted clearinghouse. No air gaps, no exposure. Even if a hacker gains access to an intermediary system, no actual data can be stolen.

It's certainly true that many encryption technologies don't protect data as it moves through a network. Database encryption, for example, may protect data while it's in a database, but doesn't do anything for the data once it leaves the database. Even SSL doesn't protect data all the time. SSL may protect data while it's moving, but after it's moved, the sensitive data then typically sits on a server somewhere, where's the protection provided by SSL is gone.

Some encryption technologies, however, do indeed provide the capability to protect data no matter where it goes. Format-Preserving Encryption(FPE), the new mode of AES that's been submitted to NIST, lets you do this. Data encrypted with FPE has the very same format as unencrypted data. A 16-digit number gets encrypted to another 16-digit number, for example. If you use FPE to encrypt sensitive information, it's easy to keep the protection provided by the encryption, even as the encrypted information moves through a network.

Other ways to encrypt sensitive information may cause problems, particularly in legacy environments. In these, there's often a system somewhere that won't be able to handle encrypted information because it's format is different than the unencrypted information that it's expecting. If you encrypt a 16-digit credit card number, for example, and the encrypted credit card number may be longer than 16 characters or may be no longer just digits, This means that many legacy systems will be unable to handle encrypted information gracefully. On the other hand, if the format of the data is unchanged by encryption, then even the most complicated legacy systems will be able to easily handle it.

This is exactly what FPE does, which means that if you use FPE to protect sensitive information then there's absolutely no problem with keeping sensitive information encrypted at all times. If that's the case, all a hacker can get by sniffing a network is encrypted information, which is totally useless to him.

Can you crack a code?

The FBI has just posted the next installment in their cryptanalysis challenge. You can see this year's problem here. It's really not a very hard problem because there's a really long and obvious crib in it.

If you can correctly decrypt the FBI's message, e-mail me your solution and I'll get you a free one-year subscription to Voltage's hosted e-mail and file encryption service - the Voltage Security Network.

VHS, QWERTY and IBE?

It's commonly believed that having the right marketing is often more important than having a good product. The examples that are often used to support this position include the triumph of VHS videocassettes over Betamax and the triumph of the QWERTY keyboard over the Dvorak keyboard. The success of many Microsoft products is sometimes added to this list.

In their book Winners, Losers and Microsoft: Competition and Antitrust in High Technology, Stanley Liebowitz and Stephen Margolis argue that none of these examples will stand up to careful scrutiny, and that superior products almost always win in the marketplace. They give fairly solid arguments that support the position that VHS and QWERRY won on their merits, and claim that even Microsoft can’t use its marketing power to win when they have products that are inferior to the competition.

Now let's go back in time to five years ago. At that time, Voltage had no customers but had a good idea that related to how to make a better e-mail encryption product. Back then, people weren't sure what to make of the new "identity-based encryption" technology. It was based on difficult mathematics, so the average person in a corporate security department didn't really have much of a chance to understand how it worked. Even encryption specialists had a hard time understanding it at first. I know that I did.

But people didn't buy IBE because of the elegant mathematics that it uses. Instead, they found that it actually had some significant benefits compared to other encryption technologies. Not needing to look up keys is a big advantage. Not having to manage certificates is another. Maybe the most important of all is the fact that by calculating keys on the fly, the back end of an IBE system is extremely simple. This means that it's much simpler to support and operate, which also means that it costs less.

Enough people found these advantages compelling enough to convince them to buy a product that uses IBE, and there are now over 10 million users of the technology worldwide. If Liebowitz and Margolis are right, that’s probably proof that it's a useful technology. Maybe it will even up as a case study in a book that they write one day.

What's going on?

People are clearly not losing interest in encryption. There are probably around 10 million users of identity-based encryption today, for example, which is 10 million more than there were just a few years ago. Voltage is doing fairly well. I suspect that other encryption vendors are also.

On the other hand, if you look at the number of Google searches for "encryption," you'll find that the number of searches has been gradually dropping for the past few years. There are now fewer than half as many of these searches than there were in 2004. What's going on? Are people finding information about encryption in some other way? Are more searches being done by other search engines? Or is there some other reason?

It really just works

Encryption has a reputation of being notoriously difficult to use. There were probably good reasons to believe this at one time, but that time has passed. I finally realized this a while ago when I had to deal with the problems caused by a canceled credit card. I found some fraudulent charges on one of my credit cards. I had the old card canceled and a new one issued, but that caused another problem.

I collect books. Some books are hard to find, so I have standing orders placed with several book dealers. If they ever find a copy of books that I’m looking for in the price range that I can afford, they'll bill my credit card and ship me the book. So when the credit card number that I used for these orders was canceled, I had to get a new number to several book dealers throughout the world. I decided to send my credit card number in an encrypted e-mail, and used Voltage's VSN hosted e-mail service to do it.

Unsure that the recipients would be able to read the encrypted e-mails, I also sent another message that explained that an encrypted e-mail would follow that contained my new credit card number and that they should let me know if there were any problems.

Nobody asked for help.

Every single recipient was able to decrypt and read the messages that I sent them and update the credit card number that they had on file for me. That’s almost certainly proof that encryption is now easy enough for the average user.

Imagine trying to do that five years ago. You'd probably have an e-mail exchange that would go something like this:

"OK, you first need to get a digital certificate."

"A what?"

"No, really, it's easy. Just go to this URL and fill in the form."

"OK. Wait a minute. What's my 'organizational unit?' What's my 'locality?' Do I really have to read and understand this 'certificate policy?' That looks like a job for my lawyer."

"Never mind. I'll just e-mail you my credit card number in the clear."

People of gender?

A few years ago, I hacked together a prototype of an IBE-encrypting IM client using an early version of the Voltage IBE Toolkit. It was interesting to use the Toolkit to IBE-enable a new application. Even more interesting was what I learned about usability and user interfaces from the experience.

After having finished the encryption part of the IM client, I thought that I’d ask people how they wanted the IM client’s user interface to indicate that a particular message was encrypted. I found the results to be a bit surprising - they were clearly divided along gender lines.

Men, it turned out, wanted a fairly in-your-face indication that a particular message was encrypted. They suggested things like changing the background color of an IM window to bright red or displaying the text "SECURE" in a large font. Every man that I asked about this gave a similar answer, although the particular way to indicate an encrypted message varied from man to man.

Women didn’t seem to like this idea at all. They all wanted a much more subtle indication. They thought that a small padlock icon was adequate to indicate that a message was encrypted, and that the padlock should be the familiar shade of gold that’s often used to indicate that a browser is using SSL for an encrypted connection. Every woman that I asked about this gave a similar answer. They even described the padlock icon that they wanted to see in a similar way.

Extrapolating from a single point is not a great idea, but based on this one data point, there seems to be a significant difference in the user interface that people would like to see based on their gender. Is there enough of a difference in the user interface that men want versus what women want to justify having two options – one that’s tailored to the expectations of men and another that’s tailored to the expectations of women?

Bart gets an elephant?

After reading the article “Identity-based Encryption Comes of Age” that I wrote for the August 2008 issue of IEEE Computer, I was reminded of the following dialog from the episode of The Simpsons “Bart Gets an Elephant” that happens right after Homer Simpson drives his car off the road and hits a statue of a deer.

Homer Simpson: “D’oh!”

Lisa Simpson: “A deer!”

Marge Simpson: “A female deer!”

The word “d’oh” is so useful that it now has its own entry in the Oxford English Dictionary. I certainly had a good use for it recently.

The editors at Computer always shorten things a bit, probably due to space constraints. To do this, they often rewrite parts of articles, doing their best to keep the original meaning intact. This time I missed an error that crept into “Identity-based Encryption Comes of Age” during the editing process when they did this. Instead of saying this:

“in an IBE system, the PKG’s security becomes as important as the key recovery system’s security,”

the edited version of the article said this:

“in a PKI, the PKG’s security becomes as important as the key recovery system’s security.”

While the first version makes perfect sense, the second version doesn’t, and that’s the version that got printed.

D’oh!