When will people learn that you can't remove obvious identifiers and then expect that the result is anonymized data that won't breach anyone's privacy? Google (YouTube) will release "anonymized" data to Viacom as part of a court order regarding copyright infringements; see here.

If you have a short memory, here are two recent examples of what can be done to anonymized data. First, AOL released a huge amount of search keywords (in anonymized form), but it was quickly shown that the result was very far from anonymous. Second, Netflix released anonymized data for the Netflix prize, which too was completely deanonymized.

In short, data is not easily anonymized, and don't trust anyone who says that it is. In this specific case, the claim is that the data is not being released to the public, just to Viacom. So, what's the problem (I won't dignify this claim to even bother answering).

OK, the answer to the title of this blog is clearly NO. Let's take a bug that causes a program to crash as soon as it starts running. Unless the program is used to protect something else, crashing it as soon as it starts is probably the safest thing you can do (you are guaranteed that it won't leak anything!). But, barring such obvious exceptions, is it possible that all bugs can somehow be utilized to breach security? I don't know the answer. However, when I see something like this, I get nervous. Kris Kaspersky has demonstrated that it's possible to use bugs in Intel's CPUs in order to carry out attacks that cannot be patched. This is another suprise attack, utilizing bugs that until now were never considered "security flaws". So, are all bugs security flaws? I would guess that most definitely have the potential...

Have you thought lately about how much information you give up while browsing the Internet? Here are some examples:

• Have you used an online translation tool? Did you think about the fact that the document you translated contains confidential information (personal or work oriented)?
• Have you searched the web to understand your illness better? Did you think about the consequences if your employer has access to these search words (and s/he probably does)? 
• Have you researched your confidential new project by searching the web? Did you think about the fact that your computer ID (which may contain the name of your company) is freely available and linked to these searches?
• Did you search the web for self-help articles about difficulties in your marriage or with your kids? Did you think about the fact that your kids and spouse can easily see what you searched for (because the keywords are by default remembered by Google "for your convenience")?
• Do you remember that it's not difficult to actually find your true identity through your search words (remember AOL two years ago)?

The above are just a few examples, and I haven't even started on the amount of information we consciously put up on social networking sites. We are a society that is concerned about privacy while freely giving it up, sometimes consciously and sometimes without realizing it! If you really want to get frightened, then think about the ramifications of someone linking all of the above together in order to build a detailed profile about you. Who would do such a thing? Well, potential employers may (they are already searching MySpace and Facebook to see what you say about yourself there).

So, what should you do? That's already a difficult question. One possibility is to use an anonymous routing service like TOR. Otherwise, you can just be a bit careful:

• Try not to use social networking sites beyond a minimum, and if you must, keep in mind that a future employer may be looking (your kids may also have a look at what you posted, next year or in 20 years time).
• Clean up your search history and set the defaults on your browser to not remember your searches. (You can also disable automatic fill-in).
• Be careful about what you search for at work. This includes your personal searches (that you don't necessarily want your employer to know about) as well as searches that may give away confidential company information.
• Before you use any online service, make sure that you are not transferring confidential information to an outsider that has no interest in protecting it.

These are just a few short ideas. The main lesson is to be aware. If you don't watch out for your privacy - at least minimally - then you can't expect to have it.

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).