Most of us are willing to connect to wireless networks at cafe's and airports. The problem is that we don't really know who we are connecting to. Let's first make it clear that this is a highly undesirable situation. Think of your favorite malicious hacker. Now, ask yourself if you would plug your laptop into his/her personal network, and surf the web via his/her router. OK, the answer is pretty clear... The easiest thing to say is that you should only use your wireless at home and at work. However, this isn't very realistic for most of us. (I would hope that users with highly sensitive information on their laptops would take greater care, but for most of us, this isn't going to happen. The "need" to be connected is just too great!) In any case, there are a few things that you can do that are of little bother and can significantly help you.

Typically, every time you connect to a wireless network, the network name is stored by your machine. You can view the networks that you have connected to by clicking on "Wireless Network Connection", going to "Advanced Settings" and then clicking on the "Wireless Networks" tabs in the dialog that opens. Most of these networks will be labeled "Automatic" meaning that next time you get in their range, you will be automatically connected. However, the only thing that your machine checks is the network name. So, if your home network is "home" or "default" (which is the case for a very high percentage of users), then anytime someone sets up a wireless router with that name, your computer will automatically connect to it without asking you. (Needless to say, the same is also true of tmobile and other popular names.) This is a really easy attack and it yields very high success. So, what can you do?

• Turn off your wireless network when you don't need it (my laptop has an external button to do this). This will also save you battery power.
• Erase wireless networks that you connected to in the past and don't need anymore. (You can erase the network that you used at a hotel after you leave.)
• Don't use a generic name for the wireless network that you have at home (change it to something specific for you).
• Require authentication on your network at home (preferably WPA-AES), and use a long key (you don't need to remember it anyway). This will prevent your computer connecting to another router with the same name (because the other router won't know your encryption key).

This doesn't fully protect you, but it greatly reduces the risk, and it's easy to do as well!

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!