There has recently been some discussion about using DNA simulations to encrypt; see this technical report and subsequent discussion here and here. The basic idea being proposed is to simulate biological processes in order to encrypt; more specifically, the process by which mRNA is generated from DNA. The entire report is strange. First, its entire presumption is that we need new methods because modern cryptographic algorithms keep getting broken. This is the same argument made in favor of quantum cryptographic schemes (like quantum key exchange). However, at least these quantum methods have a strong theoretical basis and achieve proven information-theoretic security (meaning that even an all-powerful attacker cannot learn the exchanged key). In contrast, this report just uses computational methods based on what happens to DNA. Why is this supposed to be any better than any other computational methods that we use today? On the contrary, there is no evidence whatsoever that it is hard to invert the scheme, and in fact, the authors admit that they themselves know of weaknesses (and suggest vague solutions for fixing them).

In addition to the above, the report ignores the fact that the cryptographic playing field is not even. It is true that our hash functions are looking weaker than ever before. It is also true that we are constantly on the lookout for new asymmetric schemes due to the need to use larger and larger keys all the time (even though RSA with long keys is still very safe). However, this does not mean that we don't have good symmetric encryption schemes. The opposite is true! It is well accepted that we know how to construct excellent block ciphers. 3DES has not shown any weaknesses in over 2 decades; AES remains extremely strong after almost a decade of intensive analysis. These schemes are quick and highly secure. The fact of the matter is that we don't need any new symmetric schemes at the moment (personally, I don't think that quantum key exchange is needed either). Moreso, what we definitely don't need are suggestions for schemes by non-experts with no reasoning as to why they should be better. (I know that I sound like a snob now. But cryptography in general is excruciatingly hard to get right and constructing a secure symmetric encryption scheme is even harder. There's just no reason to do it today even if you're an expert. Needless to say, if you're not an expert with years of experience in cryptanalysis you shouldn't try. However, for some reason, everyone thinks that it's easy to encrypt. Just mix things around a lot and it's got to be hard to break; right?)

A final caveat. I may be completely wrong. It's possible that all of our encryption algorithms have been broken by secret organizations out there. However, I highly doubt it. Although I assume that there are some things that are known to some of those secret organizations that we don't know in the open crypto community, I am very skeptical that they are earth shattering...

Self-encrypting hard drives are becoming a reality. One standard, led by the Trusted Computing Group, has been adopted by a number of vendors; see the press release here. I like this initiative a lot and really consider it a win-win situation. The cost of encryption is virtually nill because the encryption itself takes place in hardware on the drive. This means that everything is encrypted by default, without compromising performance. Note that this is a huge advantage. We may remember to encrypt our most sensitive files, but at the same time forget to encrypt our email archive, previous versions of the sensitive file, and of course the swap and hibernate files which can contain everything. Encrypting everything by default protects us from these omissions.

How secure are these drives? Well, the encryption keys are generated and stored internally on the drive. Thus, the security of the system depends on the security of the key inside the drive. This means that the main question to ask encrypted-drive manufacturers is how is the key stored inside, and how secure is it? If a secure smartcard chip is used, and the key is password protected, then this is great. If the key is obfuscated and somehow hidden (of course, and still password protected), then someone stealing the drive can probably get to it given enough effort. However, you have still made their life difficult and they have to take the drive away with them (it's unlikely that they'll be able to do this without taking the drive apart). So, in any case, you have gained a lot. (I am ignoring the possibility of really bad implementations, although experience tells us that this can also happen not too infrequently...) It is worth noting that highly sensitive files should probably still be encrypted on a higher level (using an encryption key that is stored in a separate smartcard that you take with you). Keeping the encryption key in a completely separate place is always the best practice and prevents even the most concerted efforts to decrypt.

On a usability note, since the encryption keys are internal to the drive there is no key management issue. This is good because key management is often the biggest hurdle to adoption. Regarding data loss, it is important to realize that if the encryption key is somehow lost due to a fault in the drive, then this would be the same as if your hard drive was completely destroyed. So it's important to also ask manufacturers what sort of fault tolerance has been built into the system regarding the encryption key. Needless to say, you should backup your files anyway (even if your hard drive is not encrypted).

We amuse ourselves with stories of laptops, backup tapes and flash drives containing sensitive information being lost or stolen. We ask ourselves how people can be so careless and negligent with such sensitive information. However, the truth is that stories like this will continue to happen, even when top secret information is at stake (see this recent story about a US army data leak, and this story at NetworkWorld for some interesting losses in the past year). The reason that I claim that this is inevitable is that there are simply too many people out there who handle sensitive data. Thus, even if we manage to reduce the probability of a leak to be very very small, the chance that there will be data breaches of this kind is still very high. In fact, if you're in a midsize company, the chances of a data breach of this kind happening to you within the next few years is also not very low. So what should you do?

Well, to quote the boy scouts, my conclusion is just that we should "be prepared". This involves ensuring that we have backups in case data is actually lost, and making sure that all data on external devices like flash drives and backup tapes, and all laptops are fully encrypted. It's really not difficult to do this these days, so why not? It also greatly reduces your legal liability... 

With Barack Obama about to take office, the privacy issues related to the digitilization of health records are being heavily debated; see this New York Times article and Slashdot discussion. Most of the controls being mentioned are legal and relate to two areas. The first considers how data may be aggregated and used (this is purely legal), and the second considers the security controls that must be implemented to prevent confidential data from being stolen (this is a combination of law of technology). The technological protections considered here are passive and relate to an organization's responsibilities to prevent raw data from being accessed (e.g., by laptops being lost or stolen or by an external attacker breaking into the organization's database). A third area that is more often ignored relates to technological solutions that enforce appropriate use of the confidential data. This starts with the simple and well-known requirement of access control; only those with a reason to look at a certain piece of data should be able to do so. However, it also extends further to more advanced controls.

In order to illustrate what I mean, let us consider for a moment the issue of ensuring that conflicting medications are not prescribed to the same patient. One way to achieve this is to provide a patient's doctor with access to a list of all of the medication that they are taking. This may make sense, but it may also suffice to have the doctor input the medication he or she wishes to prescribe and then wait for an automated response saying that this medication can be prescribed or should not be, based on the other medication taken by the patient. In many cases this is enough and it reveals much less information. (Note that although it makes sense that a patient's primary physician should have access to all of their medical history, this is not necessarily the case for others. For example, I don't think that someone's dentist needs to know that they are suffering from depression, unless there is the chance of a medication clash. If such a clash can occur, then as I have described above, it can be prevented without actually providing access to the raw sensitive data.)

It is my belief that active technological controls like the above should be considered more. Strict regulations regarding the use of medical data are essential. However, they are not enough! We can use technology to ensure that even those who are willing to break the law will have a hard time getting to data (unless they really need access to the raw data in order to carry out their job).

Recently, seven researchers succeeded in constructing a full-fledged certificate that was never issued by a CA, but will be accepted by any browser who trusts a certain CA; read more here. They did this by finding two certificates that have the same MD5 hash: the first certificate is legitimate and was issued by a given CA, while the second never would have been and can be used to attack a website. The ramifications of this result are significant, but it is important to understand them properly.

First and foremost, the attack has nothing to do with the SSL protocol, but rather is an attack on the MD5 hash function. MD5 was broken a long time ago and should never be used by any self respecting CA. So, if a CA is using MD5, we should remove it's root certificate from our certificate store. Such a CA is at best grossly negligent!

Second, this is yet another reminder that once significant weaknesses have been demonstrated on a cryptographic primitive, it should no longer be used. The argument that a revealed weakness is not yet a practical attack - and therefore one can continue to use the primitive - is a dangerous one. The MD5 collision attacks are an excellent example of this. Until now, most attacks on MD5 did not have any practical use (especially not with respect to web security). However, a real attack did not take too long to come along. Certificate authorities who did not heed this, and are still allowing the use of MD5 in new certificates, are behaving recklessly and irresponsibly.

In conclusion, SSL is fine and the problem is not there. The problem lies in our Public-Key Infrastructure and in the fact that our root certificate store comes with CAs who are irresponsible. The solution is simple: remove all such CAs from your certificate store. Since this is not trivial for the average user (indeed, as a regular user, I may not even know if a given CA allows the use of MD5), I would hope that this will be done in an automatic security patch by Microsoft and others.