Superconductor

Hacking hotels

According to a recent article in The Wall Street Journal, more credit card information is being stolen from hotels than from any other industry. This probably explains why Marriott is now involved in ASC X9F, the group that writes information security standards for the American financial services industry.

I wasn't quite sure why Marriott decided to get involved in security standards. Few users of security technology do. Most just leave it to security vendors to figure out how things ought to work. In light of the recent WSJ article, Marriott's participation in X9F makes a lot more sense. Other users ought to follow their lead in this area and make sure that their voices are heard.

If you don't get involved in the definition of standards then you shouldn't complain about them once they're done.

Divisors on elliptic curves revisited

When we talk about divisors on elliptic curves, we're often careless (well, at least I am), which makes it hard for people who are just figuring out divisors to understand what's going on. Here's an attempt to clarify things a bit, yet still without using terminology from algebraic geometry. There's still some handwaving here, but not as much as in my first attempt at this.

Suppose that we have points P₁ and P₂ on an elliptic curve and that their sum is P₁ + P₂ = P₃. Let u be a function that has zeroes at P₁, P₂ and –P₃ and v be a function that has zeroes at P₃ and –P₃. The picture that we usually draw of this looks like this:

We'd like to write

div(u) = (P₁) + (P₂) + (-P₃) – 3(O)

and

div(v) = (P₃) + (-P₃) – 2(O)

How do we think of u and v so that this makes sense?

First, a quick comment about poles of polynomials. It's clear what the zeroes of a polynomial are. What about their poles? A function f(x) has a pole at infinity if f(1/x) has a pole at 0, so if we have

f(x) = a x + b

then

f(1/x) = a/x + b

= (a + b x) / x

so that f has a pole or order 1 at infinity. Similarly, any polynomial of degree n has a pole of order n at infinity.

Now suppose that we have an elliptic curve defined by

y² = x³ + a x + b

and that the line through P₁, P₂ and –P₃ is given by

y = c x + d

Squaring the equation for the line gives

y² = (c x + d)²

So that where the elliptic curve intersects the line we have that

x³ + a x + b = (c x + d)²

or that

x³ + a x + b - (c x + d)² = 0

That's a polynomial of degree 3 that has zeroes at P₁, P₂ and –P₃ and because it's of degree 3 it also has a pole of order 3 at infinity. So if u is where the elliptic curve intersects the line through P₁, P₂ and –P₃ then u has zeroes at P₁, P₂ and –P₃ and a pole of order 3 at O so we can write

div(u) = (P₁) + (P₂) + (-P₃) – 3(O)

Similarly, if the line through P₃ and –P₃ is given by

x = c

then where the elliptic curve intersects this line we have that

y² = c³ + a c + b

That's a polynomial of degree 2 that has zeroes at P₃ and –P₃ and because it's of degree 2 it also has a pole of order 2 at infinity. So if v is where the elliptic curve intersects the line through P₃ and –P₃ then v has zeroes at P₃ and –P₃ and a pole of order 2 at O so we can write

div(v) = (P₃) + (-P₃) – 2(O)

Maybe that will clarify things a bit.

Crypto - the song

My recent attempt to create a good spin-themed song (as briefly mentioned here) reminded me of a crypto-themed song by Bob Rivers. Oddly enough, I don't recall ever hearing this song being blasted from a crypto vendor's booth at any trade show.

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.

What's coming from IDTrust 2010

It looks like the agenda for the IDTrust 2010 workshop is now available. This workshop will be held from April 13-15 at NIST, in Gaithersburg, MD. The talks at this workshop are an odd mix this year. I have no idea what some people were thinking when they submitted the proposals for their talks. The group from Dartmouth that will be talking about "Computational Techniques for Increasing PKI Policy Comprehension by Human Analysts" is an example of this.

Trying to find ways to make PKI policies more human-friendly doesn't really seem to be that useful. Let's just admit the fact that PKI failed and move on. Even this workshop had to change its name from the "PKI R&D Workshop" to "IDTrust" to keep people interested. That alone ought to tell you something.

Other talks could be much more interesting. An example of this is the panel on identity proofing. Although I really have no interest in this particular topic, lots of bankers that I've talked to do, and those sorts of people will probably be very interested to hear this particular panel.

The rest of the program seems to be an odd collection of topics related to either PKI or government identity-management programs. There's definitely going to be some useful information available at this meeting, but I'm not sure that it will be worth the $180 registration fee to hear it.

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.

Does this count as spam?

I received an interesting email recently that began like this:

Dear Luther Martin:

We would like to inform you that the final set of deadlines for submitting a paper/abstract in the area of "Operation Research and Management Science" (or other area) included in The 14th World Multi-Conference on Systemics, Cybernetics and Informatics: WMSCI 2010 (http://www.sysconfer.org/wmsci) to be held on June 29th-July 2nd, 2010 in Orlando, Florida, USA, is the following:

Papers/Abstracts Submissions and Invited Sessions Proposals: April 7th, 2010
Authors Notifications: May 5th, 2010
Camera-ready, full papers: May 26th, 2010

I was about to delete this email when I realized that this conference is the one that accepted the randomly-generated paper Rooter: A Methodology for the Typical Unification of Access Points and Redundancy that was created by the SCIgen tool. That didn't stop me from deleting the email, of course. It just made me take a minute to do this blog post about it. Then I deleted it.

The Soghoian and Stamm compelled certificate creation attack

Christopher Soghoian and Sid Stamm recently released a draft of their paper "Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL." In this paper they argue that national governments have forced public CAs to issue certificates that let them carry out man-in-the-middle attacks against SSL. They call this a "compelled certificate creation attack" and it works by an attacker getting a CA to issue them a valid certificate for a particular server or domain even thought the attacker is not the legitimate owner of the server or domain. If an attacker can carry out a CCCA, they can freely eavesdrop on SSL-protected sessions and their victims will probably have no idea that this is happening.

Soghoian and Stamm suggest a workaround to the vulnerability to CCCAs in the form of a browser add-on that checks the country of origin of the server certificates used to make SSL connections. If the last time that connected to https://www.example.com the SSL certificate was issued by an American CA and your next connection to this URL uses a certificate issued by a French CA, for example, you might get a warning message telling you about this inconsistency and asking if you really trust the French government.

National governments can probably easily force public CAs to issue bogus certificates, like those needed to carry out a CCCA, and this shouldn't really surprise anyone. Without passing a value judgment on whether it's really a good idea of not, the reality is that businesses essentially exist only because their governments let them exist. They pretty much have to do what governments tell them to do, and this includes issuing bogus certificates.

Note that the same type of problem exists for any business, not just public CAs. If your company issues its own SSL certificates, then your national government might ask your IT department to issue their law enforcement or intelligence agencies a bogus certificate that they can use to carry out a CCCA. And although you might want to deny such a request, if you do this they can make life extremely difficult for you, perhaps even impossible. They might even show up with a court order directing you to comply with their request. So the reality seems to be that governments can probably easily implement CCCAs and there's probably not much we can do about it.

In the big picture, the existence of CCCAs seems to be yet another indication that the "trust model" on which PKI depends is fatally flawed. You cannot implicitly trust anyone, and that includes public CAs and national governments. This means that the security of protocols based on such trust is also fatally flawed. That should be the lesson that protocol architects learn from the Soghoian and Stamm paper.

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.

Adding points on an elliptic curve

It's actually fairly easy to derive the formulas for adding points on an elliptic curve. Here's how to do it.

Suppose that we have three points

P₁ = (x₁,y₁)

P₂ = (x₂,y₂)

and

P₃ = P₁ + P₂ = (x₃,y₃)

on the elliptic curve

y² = x³ + ax + b

First, let's assume that P₁ != P₂. Let m be the slope of the line through the points P₁ and P₂ so that

m = (y₂ – y₁) / (x₂ – x₁)

From the point-slope form of a line we have that

y – y₁ = m(x – x₁)

so that

y = m(x – x₁) + y₁

and that

y² = (m(x – x₁) + y₁)²

= m²(x – x₁)² + 2my₁(x – x₁) + y₁²

We also have that

y² = x³ + ax + b

so that we have that

x³ + ax + b = m²(x – x₁)² + 2my₁(x – x₁) + y₁²

or that

x³ + ax + b - m²(x – x₁)² + 2my₁(x – x₁) + y₁² = 0 (∗)

This polynomial has three roots: x₁, x₂ and x₃, so we can also write it as

(x – x₁)(x – x₂)(x – x₃) = 0

or

x³ – (x₁ + x₂ + x₃)x² + … = 0 (∗∗)

Equating the coefficients for x² in (∗) and (∗∗) we see that

- m² = – (x₁ + x₂ + x₃)

Solving this for x₃ gives us that

x₃ = m² – x₁ – x₂

Now because (x₃,y₃) is on the line defined by

y – y₁ = m(x – x₁)

we have that

y₃ – y₁ = m(x₃ – x₁)

or that

y₃ = m(x₃ – x₁) + y₁

This gives that

m = (y₂ – y₁) / (x₂ – x₁)

x₃ = m² – x₁ – x₂

y₃ = m(x₃ – x₁) + y₁

If P₁ = P₂ then we find m in a different way. In this case we have

y² = x³ + ax + b

so that

2yy′ = 3x² + a

so that

y′ = (3x² + a) / (2y)

so that we want

m = (3x₁² + a) / (2y₁)

but everything else is the same. We can then write

m = (3x₁² + a) / (2y₁)

x₃ = m² – 2x₁

y₃ = m(x₃ – x₁) + y₁

The Story of Spin

Over the past few weeks, I've been reading The Story of Spin, by Sin-itiro Tomonaga. This book tells the story of how physicists developed early versions of quantum mechanics, and it includes lots of interesting stories about how various physicists were working on ideas that turned out to be dead ends, which ideas ended up working, etc. When I learned physics, I just learned about the ideas that worked out and learned absolutely nothing about the ideas that didn't, so I found this to be fascinating.

I also found it interesting to see Tomonaga obviously in of awe of the abilities of people like Dirac, Heisenberg and Pauli. Tomonaga shared the 1965 Nobel Prize in Physics with Richard Feynman and Julian Schwinger for his role in the invention of quantum electrodynamics, so he was definitely an extremely smart guy. This might give you an idea of how clever the early inventors of quantum mechanics really were.

Reading The Story of Spin got me to spend a few minutes trying to work out the lyrics to a song about spinors set to the music from the "Toreador Song" from Carmen, much like Gilligan's Island did with Hamlet in episode 4 of season 3. (It sort of went downhill after "Neither a vector nor a tensor be, ...") It also made me wonder when someone is going to write a similar book about the history of cryptography.

It seems that most of the key people from the early years of cryptography are still around, so there's still a chance for one of them to write such a book. There have been lots of papers published about cryptography in the past 30 years or so, but these just tell you about the ideas that worked, at least to some degree. I'm sure that the original inventors of the technology still remember the mis-steps that they made as clearly as their successes, and it would be very interesting to hear the stories of these. If someone took the time to write down all of those stores, that would make a book that I'd definitely buy a copy of.

Hacking chips

I recently came across an interesting blog post that describes how a clever hardware hacker managed to make a single-chip CMOS inverter at home. The hacker apparently worked out her own CMOS fabrication process using just equipment that's cheap and readily available.

A single inverter isn't that impressive - it has just a single PMOS transistor and a single NMOS transistor - but the fact that this hacker managed to develop a process to make a single-chip version at home is extremely impressive. The success of this project made me wonder about how successful hardware hackers who operate with a similarly-modest budget can be.

I have always said that the protection provided by hardware is fundamentally different from the protection provided by encryption. Once you have the right tools and expertise, a wide range of attacks become feasible. If you have a big budget, perhaps just a few million dollars, you can probably beat any hardware security mechanism at all. The more interesting question is really whether or not relatively low-budget attacks can beat the security provided by hardware.

The fact that a clever hardware hacker managed to make a single-chip CMOS device at home leads me to believe that hardware hackers may be much more capable then we might first think, and that they might be able to carry out some impressive attacks against smart cards and HSMs. Hardware security isn't perfect, but we tend to think of it as being better in some vague and ill-defined way than software-only security. Maybe the difference isn't really that big.  

Webinar: Reducing PCI Audit Costs and Protecting Sensitive Data

It looks like our marketing guys are having another webinar. This one is "Reducing PCI Audit Costs and Protecting Sensitive Data," and is sponored by Voltage, Thales and the Financial Services - Information Sharing and Analysis Center (FS-ISAC). It will be held on March 31, 2010, at 10 am PST (1 pm EST) and runs for 60 minutes.

From the page of the web site that describes this webinar, here's what it's about:

Reducing the costs associated with PCI Audits is on everyone’s mind and by reducing audit scope, audits are easier, faster, and less expensive. Data encryption combined with robust key management is a PCI Security Council recognized method to reduce scope for PCI compliance. In a recent survey, PricewaterhouseCoopers found that end-to-end encryption and tokenization are among the most promising methods that merchants, service providers and QSAs believe can reduce scope cost-effectively.

But the challenge is always how to protect cardholder data without incurring huge application development costs by changing applications, database schemas, and business processes. And, on top of this, how can the encryption process and keys be kept safe from compromise from internal and external threats?

If that sounds interesting, you can sign up for this webinar here. The webinars that our marketing people put on seem to be fairly popular, particularly with Voltage's competitors. This tells me that they're probably a good source of useful information.

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.

Another visualization of elliptic curves

Here's another way to visualize an elliptic curve. The elliptic curve

y² = x³ - 2x + 3

is the intersection of the surfaces

z = -x³ + y²

and

z = -2x + 3

Here's what that looks 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?

Another standard for tokenization

It looks like a tokenization vendor has taken it upon themselves to organize a group of vendors to create a standard for tokenization and its secure implementation. Having a standard that describes tokenization and how to do it securely is definitely a good idea, but I'm not sure that a vendor-led group that's not part of any recognized standards organization is the best way to do this.

A group organized by a single vendor probably won't have decision making processes that are as transparent as those that established standards organizations have. This probably isn't good. Although all standards organizations have their problems, you at least have a known process by which these organizations create and review their standards. These processes may not be perfect, but they're at least well known, and they almost always try to keep any single vendor from unduly influencing the content of any particular standard. With vendor-led groups, however, there's often little attempt at transparency, and there may even be little incentive for the group to act on feedback that they get on their standard as it's being developed. This often results in standards that aren't as useful as they could be.

I also have to wonder why a vendor-led group is necessary in this particular case. The Accredited Standards Committee X9, the organization that creates the American National Standards for the financial services industry, is currently working on a standard (X9.119) that will define requirements for the secure implementation of tokenization. This X9 standard will only reflect the requirements of the financial services industry, but because that's the main user of tokenization, that really shouldn't be a problem. I'm fairly confident that an organization that specializes in standards for the financial services industry will have a better chance of creating a standard that reflects the needs of the financial services industry than an organization comprising tokenization vendors will.

I'm also a bit puzzled by the fact that many tokenization vendors don't seem to participate in X9 at all. Voltage has been an X9 member for quite a while, and both the X9 community as well as Voltage have benefitted from this. The other members of X9 have essentially received lots of free cryptography and security consulting from Voltage, and Voltage has received lots of useful information about exactly what the needs of its customers are in return.

I'm not sure why tokenization vendors don't actively participate in X9, and the fact that they don't makes me wonder how much they really understand the requirements of their customers and how well they'll be able to create a useful standard for the secure implementation of tokenization.

I'm fairly sure that Voltage will end up participating in this vendor-led effort to define a standard for secure implementations of tokenization, but from what I know now, I'm not sure that the standard that this group creates will be very useful. In this particular case, I hope that I'm wrong. That doesn't happen very often, does it?

Do we really need another tokenization standard in addition to X9.119?

The virial theorem in the workplace

There's a theorem from mathematical physics that may have an application in the workplace. This is the virial theorem, and its workplace analogy may explain why every job has its annoying parts.

One version of the virial theorem roughly says that for a finite collection of point particles interacting gravitationally, the time average of the kinetic energy is half the time average of the potential energy, or

<K> = - <U> / 2

The virial theorem is useful to astronomers because you can use it get a good idea of masses of distant objects, which you can't really observe, from their kinetic energy, which you can observe. The reason that we think that dark matter exists is basically from observations like those plus the virial theorem.

Driving in to work today, I had the thought that an appropriate analogy for the virial theorem the workplace might be that the bad parts of a job are always proportional to the good parts of a job. In my experience, this seems to have always been true.You probably have some relationship like this, for example:

<Bad> = - <Good> / 2

When I was an officer in the US Army, there were lots of good aspects of the job. There's nothing in the world as rewarding as working with soldiers, for example, and getting paid to work with explosives and fire guns is also lots of fun. To make up for this, however, there's also the fact that the military is really part of the government, so you're really part of a large, mind-numbingly bureaucratic organization.

Or when I used to do what's probably best called applied physics research, it was great fun working with things like lasers and electron microscopes. To make up for this, however, there's the never-ending battle that you have to fight to get funding for those expensive gadgets.

Or when I did mergers and acquisitions consulting, it was great fun getting a look inside lots of different companies in lots of different industries and seeing how they worked. The pay wasn't bad, either. To make up for this, however, there were the 20-hour days and the backstabbing from other consultants (particularly the lawyers) involved in the M&A projects that you had to keep a constant eye out for.

So although I'm not sure that you can write down a set of assumptions that lets you rigorously prove an analogy for virial theorem for the workplace, it certainly seems to be true. If there's a job out there for which it doesn't hold, I'd definitely like to hear about it.

Right hand, say hello to the left hand

At the recent X9 meeting, I noticed an interesting pattern in the discussions about the appropriate level of security around various on-line banking transactions. In every case that I can remember, we had a discussion that went something like this:

Bank A representative: So we think that this new technology has the potential to really revolutionize banking. Bank A loves it.

Bank B representative: Our concern with that particular technology is that we'll never be able to make it secure enough. Plus, our customers really don't want it.

Bank A representative: We don't see security as a problem at all. We've actually been using this technology for over two years now and customers love it.

Because these opinions were often so far apart, I had to wonder exactly how much thought went into creating some of the banks' positions. Had they really thought through the security implications of using a new technology? Did they really have an idea of what their customers really want?

With opinions as different as the ones that I saw, I suspect that not everyone had been as careful in forming their opinions as they should have been, although it was hard to see which position could have benefitted from some additional research.  

The converse of the Nagell-Lutz theorem

The Nagell-Lutz tells us that rational points of finite order have integer coordinates, but it doesn't tell us that points with integer coordinates have finite order. As a reminder, here's the statement of the Nagell-Lutz theorem.

Let y² = x³ + ax + b be an elliptic curve over the rationals with integer coefficients and let D = 4 a³ + 27 b². Then if P = (x_P,y_P) is a rational point of finite order then P has integer coordinates and either y_P = 0 or y_P²|D.

Here are some examples of points with integer coordinates that don't have finite order.

The point P = (1,2) is on the elliptic curve

y² = x³ + 3

but (1,2) isn't a point of finite order. We have that

2P = (-23/16,-11/64)

for example. Since 2P doesn't have integer coordinates, it's not a point of finite order, so P isn't either.

For another example, consider the elliptic curve

y² = x³ + 17

There are 16 points with integer coordinates on this curve. These are the following

(-2,±3)

(-1,±4)

(2,±5)

(4,±9)

(8,±23)

(43,±282)

(52,±375)

(5234,±378661)

Although we can find a few cases where adding these points gives another point with integer coordinates, like

(-2,3) + (-1,4) = (4,9)

most cases don't. We have that

(-1,4) + (-1,4) = (137/64, -2651/512)

for example.

Even worse, we have that

(5234,378661)  + (5234,378661)  = (187618163896928/143384152921, -1/4)

None of these points actually have finite order although they have integer coordinates. So points of finite order have to have integer coordinates, but not all points with integer coordinates have finite order.

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.

Misunderstanding what was said at the Cryptographers Panel

As usual, the Cryptographers Panel at the RSA Conference was interesting. Unfortunately, some of the remarks made by the panelists seem to have been taken out of context by people who apparently didn’t understand the context to begin with. This has apparently led to some people claiming that cryptography is totally broken and shouldn’t be used to protect sensitive information.

As Dave Barry would say, I’m not making this up.

The remarks that Adi Shamir made about attacks on AES seem to be at the root of this misunderstanding. Let’s look at exactly what Shamir said and see how close it comes to saying that cryptography is totally broken. You can find a recording of the talk here if you missed the RSA Conference last week. Some of the question and answer period has been edited out, and I’m not exactly sure why that happened.

In his opening remarks Shamir notes that progress has been made in the cryptanalysis of AES. Last year, Alex Biryukov and Dmitry Khovratovich found a related-key attack against the full AES-256 algorithm that has both time and memory complexity of 2^99.5.

This attack is much better than an exhaustive search, but it’s also not even close to being feasible. (If that’s not obvious, do a quick Google search to find out roughly how much information exists in the world today and compare it with the 2^99.5 memory required by this attack.) If that’s the best that an attacker can do, then you’re still very safe. The fact that the way that standards require you to use AES also eliminates the possibility of actually carrying out a related key attack should make you feel even safer. If you use AES like the standards specify, then this attack can’t be used against you.

Shamir also mentioned an attack on AES-128 that was also found by Biryukov and Khovratovich that runs in 2⁴⁵ time. That’s so fast that it’s practical to do on a typical PC. On the other hand, Shamir also mentions that this attack also assumes that you use AES-128 in a way that is forbidden by the AES standard. In this case, the attack works if you use AES-128, but try to fake AES-256 using the shorter 128-bit key. Again, this isn’t allowed by the AES standard, so it shouldn’t really come as a surprise that it doesn’t work well. Once again, it you use AES like the standards specify, then this attack can’t be used against you.

So I’m not sure exactly how someone heard Shamir’s remarks and interpreted them as saying that encryption is fatally flawed and isn’t suitable for use in protecting sensitive information. It seems to me that a better interpretation is that you really need to follow the standards that specify how encryption is used. If you do that then it provides protection that’s incredibly secure. On the other hand, if you decide to not follow these standards and instead decide to invent new ways to use encryption that haven’t had any sort of independent review, then there’s a possibility that you can do things that dramatically reduce the security that the encryption provides.

There are definitely innovative ways to use encryption safely. These will always come with a peer-reviewed proof that the new technique is secure. If you use one of these, encryption will still provide an essentially unbreakable level of security. But if you use techniques that don’t have such a proof of security then you’re taking a significant risk. Maybe that’s too subtle an interpretation for the opening remarks at the Cryptographers Panel, but it’s certainly more accurate than saying that cryptography is totally broken and shouldn’t be used to protect sensitive information.

Cloud computing at the RSA show

While too many of the pitches on the expo floor at this year's RSA Conference were about how various products or services could make you PCI DSS compliant, way too many of the talks this year were about cloud computing. Few of these talks really seemed to have anything new and interesting to say. Some seemed to be just thinly-veiled pitches for a cloud computing offering from vendors who had essentially bought speaking slots at the show with their sponsorship dollars.

Now, while cloud computing can be a very useful technology in some cases, it's also one that can create some interesting security challenges. But while talk after talk went on and on about the security challenges of cloud computing, one fairly obvious approach was rarely mentioned: encrypt your data before you put it into an external cloud computing environment.

The RSA Conference started out as a conference about cryptography. Despite this bit of history and the fact that cryptography can go a long way towards solving some of the tricky problems that cloud computing can cause, it was rarely mentioned at this year's conference. This struck me as being a bit ironic.

Wednesday at the RSA Conference

If the number or size of the parties put on by vendors at this year's RSA Conference is any indication, the information security industry has fully recovered from any affects of the recent recession. Luckily, I recently saw an episode of Mythbusters that made surviving these parties much easier than it was in previous years.

The Mythbusters episode that I saw compared the hangover caused by drinking from beer to the hangover caused by drinking liquor. Somewhat surprisingly, they found that beer causes a much worse hangovers.

Armed with this research, I developed a strategy to deal with the numerous parties at this year's RSA Conference: stick to martinis and drink no beer. Drinking martinis also helps in another way. Martinis taste terrible so you're much less likely to drink too many of them. After a single sip from a martini, you're usually more than happy to wait a long time before taking another sip. Beer, on the other hand, doesn't have this built-in rate-limiting feature, so you're more likely to drink too much of it.

This strategy worked perfectly. By sticking to martinis I was easily able to keep my blood alcohol content well within the limits allowed for driving, and the next morning I felt no obvious effects from the parties at the RSA Conference the previous night.  

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.

Monday at the RSA Conference - Miranda?

The exhibit hall of the RSA Conference was open for a couple of hours last night, so I got a chance to walk around and see what vendors were talking about this year. I have to say that I was not impressed in lots of cases - some vendors seemed to actually be moving backwards instead of forwards. It almost reminded me of the horror novella Miranda by John R. Little that won the 2008 Bram Stoker Award for Best Long Fiction. (No - this book has nothing to do with the planet Miranda from the movie Serenity.)

The protagonist of Miranda is a man who moves backwards through time instead of forwards. The book opens with him returning to life in a hospital at age 65 and ends, well, I'd hate to ruin a truly excellent book, so I'll just let you use your imagination. 

The entire book reinforces this backward-through-time theme. It starts with chapter 15 and counts down to chapter 1, for example, and the pages are also numbered in the reverse order. For me, this produced a particularly chilling effect because you could tell exactly how many pages were left of the protagonist's life. You can easily look at the last page of a book to see how many pages are left before the story is going to end, but that doesn't seem to provide the same effect that the reverse page numbering in Miranda does.

In any event, the parallel between a man moving backwards through time and the vendors who seemed to be moving backwards instead of forwards definitely struck me when I made my first circuit through the expo hall of the RSA Conference this year. I doubt that the vendors that I saw yesterday will suffer the same horrific end that the protagonist of Miranda did, but I doubt that things are going to work out well for them in the long run.

The RSA Conference begins

Today's the first day of the RSA Conference. If you can manage to cut through the marketing hype that surrounds this event, you can actually learn all sorts of useful things at it. This year, there are two parts of the conference that look particularly interesting.

The first is the Cryptographer's Panel, which will be on Tuesday at 10:30 am. Brian Snow will be on this panel, along with Whitfield Diffie, Martin Hellman, Ron Rivest and Adi Shamir. Hearing any of these people talk is always an excellent opportunity to learn all sorts of interesting things, but hearing Brian is probably the best opportunity of all. Before he retired, Brian was the Technical Director of the Information Assurance Directorate of the National Security Agency, sort of like the NSA's chief scientist on the defensive side, so he knows what really happened in lots of cases where others can only speculate.

Want to know about what really happened in the early history of public-key cryptography? Listen to Brian talk about it. Want to know about what really happened in the US government's pre-dot-com-era efforts to discourage the use of cryptography through export controls? Listen to Brian talk about it.

Another part of the conference that will probably be very interesting is Phil Rogaway's presentation "Format-Preserving Encryption: How to Encipher CCNs, SSN, and the Like," which will be on Friday at 10:20 am. It was a paper by Phil and John Black that was part of the Cryptographer's Track at the 2002 RSA Conference that gave the first proofs of security for format-preserving encryption, so he's been working on it from the beginning. Today, the technology is now commercially available and is being used by lots of businesses to help them comply with the PCI DSS without causing too many problems with their complex, legacy environments.

Format-preserving encryption is what's described in the FFX mode of AES that NIST is now working on, and here's even a part of the draft of the X9.119 standard: Retail Financial Services — Requirements for Protection of Sensitive Payment Data — Part 1:  Using Encryption / Tokenization Methods that's dedicated to describing how to use the technology to protect payments information.

Phil's presentation isn't part of the Cryptographer's Track this year, so it will probably be at a level that's accessible to people who don't like to worry about all of the details about exactly how format-preserving encryption works and the details of the proofs of why it's secure. Instead, it will probably focus more on system-level issues like why it's useful and how to use it. If that's of interest to you, then you'll probably to make sure that you get a chance to hear Phil talk about format-preserving encryption.