One of the key problems of the security industry is that even when the design of a product is excellent and guarantees security, much can go wrong in the implementation stage. A product that uses IPsec or SSL to carry out secure communication, but is careless about how it manages keys, or doesn't properly check the signatures and so on, will not be secure. Likewise, a buffer overflow or other flaw could be used to completely bypass the secure protocol. This is actually very worrisome because it means that it is not enough to carry out an in-depth code review on the portion of code that deals with security; flaws in other parts of the code can still cause a compromise. Despite the above, in many cases we have good solutions that provide a good level of security.

But, what happens when we get to applications where security is critical. No, I am not talking about the military or the intelligence community; I am talking about elections. There are many secure election schemes that have been proposed, and some of them come with rigorous proofs of the security guarantees. However, these proofs only talk about the design. There can be no proof that the scheme is still secure when it is badly implemented, because it just isn't true. This introduces a serious problem which is that we now have to trust the implementation. Anyone with experience in the software development industry knows that trusting the code to be bug-free is somewhere between stupidity and blind naivity. Is there any solution?

A very interesting suggestion that Ron Rivest mentioned at this year's Cryptographer's panel at RSA is that of software independence. A software independent eVoting solution is one that guarantees that an undetectable bug in the software cannot change the election outcome. Although this may sound impossible to some, it can be achieved by combining a real-world paper trail with the electronic voting software; see here for more details.

I strongly believe that this is the right direction. We can guarantee that even if the software is buggy, the election outcome will not be changed. This doesn't mean that other bad things won't happen (like a programmer inserting malicious code that will let it learn who voted for which candidate), but at least we can protect the most crucial element: the election outcome.

IBM set a new record with a supercomputer than can carry out one thousand trillion calculation per second (otherwise known as a petaflop); go here for more details. Does this have any influence on the security of cryptosystems? The answer is an unequivocal NO, as long as you are using keys that are long enough. For example, if you are encrypting with plain DES (something that you shouldn't have been doing already 15 years ago), then your secret key could be found by such a machine in just a few minutes. This is because there are about 72,000 trillion possible DES keys. Assuming that 1,000 trillion keys can be tried per second (this probably isn't true, it would take a bit longer than this), this means that 70 seconds or so is enough to try all possible key. OK, but we already know that we shouldn't be using DES. What about 3DES or AES with 128 bit keys? Well, for AES-128, the number of keys is 2¹²⁸, or about 2⁷⁸ thousand trillion keys. Assuming that you can check one thousand trillion keys per second, it would take about 9,583,696,565,945,500 years to find the secret key. Stated differently, 128 bit keys are way long enough to protect against such attacks, even using the best supercomputers today, and for many many years to come. (Of course, if a weakness is found in the encryption scheme, then it becomes a completely different ballgame.)

Meanwhile, don't worry about your encryption scheme. If you're using a standard algorithm with a long enough key, then you're safe there. Unfortunately, this doesn't mean that you're really safe, because there's much more to a secure solution than a secure cryptographic algorithm; crypto is where it starts (and this is far from where it ends).

This summer I will be teaching a full two-day training course at the BlackHat USA conference. My training session is titled  Cryptographic Primitives - A Close Look Inside, and will show how cryptographic primitives are constructed and broken. More specifically, on the first day we will focus on Block Ciphers and will study the basic construction paradigms, and how DES and AES work. We will then study basic and advanced cryptanalytic techniques (like differential and linear cryptanalysis). On the second day, we will study asymmetric primitives (e.g., RSA) and the different attack methods that are known in this area as well. The training will be hands-on and will include interactive and group work sessions where participants will apply the material and techniques in various ways. This will give the participants the chance to experience the fascinating process of cryptanalysis.

It is my strong belief that a deep understanding of how cryptographic primitives are designed and broken is of great importance to every security professional. The view of cryptographic primitives as "perfect black boxes" is problematic and leads to errors by designers, developers and IT professionals. Also, an understanding of what is inside the cryptanalysts tool-box is crucial in order to really be convinced as to why only standardized algorithms should ever be used.

Finally, this is a fascinating topic and one that I'm sure will be very enjoyable to all those who participate.

Computer science is a field that is torn between theory and experimentation. On the one hand, it has a rich theory that has proven to be effective in advancing practical solutions. On the other hand, fields belonging to applied computer science often rely on experimentation to make (or strengthen) a claim. Where does computer security fit into this spectrum between theory and experimentation?

First, it is clear that cryptographic primitives and protocols are strongly rooted in theory, and experience tells us that this is necessary. We cannot use experimentation to test if an encryption algorithm is secure. (This is unless one calls years of attempts by teams of cryptanalysts to attack a scheme experimentation; I do not.) Thus, our methodologies must be as rigorous as possible.

However, there are questions that are central to security that can only be solved using experimentation. One such question is related to a central object (or subject) in any security solution: the user. Many security solutions can only work if users understand them, and know how they should act. For example, it is a great idea to pop up a warning box telling users that what they are about to do may be dangerous. However, if they receive such warnings frequently and know that typically nothing dangerous is really going to happen, then they learn to ignore the warnings. This leads us to the already well-accepted conclusion that the experimental side of security actually has a lot to do with psychology and sociology. Despite this quite obvious fact, new proposals for security solutions rarely include in-depth studies on how users react to them. Some such studies are carried out (notably in research relating to methods to prevent phishing). However, these studies are typically not very rigorous, and almost never rigorous enough to meet the standards of experimental science. It's time that we improve!

The dream of having everything in one small device is coming closer and closer. Today, a single device can contain a cellphone, PDA, MP4 player, and high-quality digital camera. Furthermore, the device can be used to read email, play games, open and edit Office documents, surf the Web and more. Although not everyone has such a device, many (if not most) cellphones provide users with the ability to surf the web, download software, play games and so on.

What most people are not yet aware of is the huge security risk that such a device poses. Well, maybe people are aware that if they lose their device then they are in trouble (and so passwords and file encryption should be used, where necessary). However, a potentially greater risk, in my opinion, is that of malware. I would argue that we have pretty much failed at educating users not to download software to their PCs. For this reason, most work places have stringent firewalls and security policies that just prevent users from doing this. Further protection is provided by anti-virus software that sits on the users' personal computers.

When it comes to cellphones, we have double trouble. First, although we haven't succeeded in properly educating users regarding their personal computers, at least some awareness has gotten through. In contrast, there is almost zero awareness as to the dangers of downloading applications to a cellphone. Second, when these devices contain sensitive information relating to work, the organization has much less control. The users connect directly to the cellular network and so firewalls and network policies don't apply. Furthermore, on most devices there is very little that an employer can do to prevent misuse.

In conclusion, these new devices provide great potential but also great risk. We have a lot of work to do in order to both educate users and develop tools to protect the uneducated!