Inside NetBSD's CGD
Pages: 1, 2, 3, 4

How does CGD compare to Linux's Loop-AES?

RD: I first looked at Linux's cryptoloop, which has all of the problems of OpenBSD's svnd and more. Loop-AES addresses these issues in a very different way than CGD does, but from a quick analysis it appears to solve the issues.

What type of differences do you see between CGD and FreeBSD's GBDE?

RD: FreeBSD's GBDE was developed at roughly the same time as CGD, although neither GBDE's author nor I was aware of the other's work. In an accident of fate, I think that I ended up committing CGD about a fortnight before GBDE. We took very different approaches and I was quite interested in the code once it was committed. I quite liked one of the features in GBDE, allowing multiple different pass phrases to decrypt the disk, so I implemented that functionality (although slightly differently in CGD).

GBDE is vulnerable to online dictionary attacks if its 2-factor authentication mechanisms are not used or if the second factor is somehow obtained. This is not quite as serious as the offline dictionary attack that I mentioned in OpenBSD's svnd. An online dictionary attack must be performed separately for each different drive encrypted with GBDE. This is a rather serious disadvantage, as many FreeBSD users must be using GBDE without 2-factor authentication, falsely believing their security to be substantially more impressive than it actually is. And as I noted in my answer about OpenBSD's svnd, this is a solved problem. After even pointing this out to GBDE's author a number of months ago, it has not been addressed.

Another issue with GBDE is that it violates the atomicity assumptions that filesystems have about disks. When you write a sector to the disk, GBDE actually performs two distinct writes, in between which the disk is in an unrecoverable, indeterminate state. If the power goes out between these two operations, then the sector will be lost and you cannot recover it--at least not without cracking AES. GBDE is not resilient to either power outages or OS crashes of any variety. This would give me serious reservations about using it in a production environment.

FreeBSD recently introduced GELI. I have only had a chance to have a quick look at it, so I may be missing something, but so far it looks much better. It is simpler and therefore easier to analyze, and unlike GBDE it uses cryptographic techniques in standard, well-understood ways. It also doesn't appear to have the transactionality issues I just mentioned.

What improvements or new features do you plan to add in the future?

RD: I've been planning for a while to add hardware crypto support to CGD. Also, I've been thinking of adding another IV Method, since there is a modular framework for them and one defined. Steven Bellovin has suggested ways that we might be able to relatively cheaply provide integrity checking, which sounds interesting--but it would involve maintaining a transaction log, so it would impact write performance substantially. Another feature that I've been considering would be to add support for creating CGDs to our installer.

Federico Biancuzzi is a freelance interviewer. His interviews appeared on publications such as,,,,,,, the Polish print magazine BSD Magazine, and the Italian print magazine Linux&C.

Mastering FreeBSD and OpenBSD Security

Related Reading

Mastering FreeBSD and OpenBSD Security
By Yanek Korff, Paco Hope, Bruce Potter

Return to the BSD DevCenter.