On 1/4/06, Nick Holland <[EMAIL PROTECTED]> wrote: > knitti wrote: > > cgd gives users some choice over how to build their encrypted partition. > > you're able to use different ciphers. > > More stuff to test to make sure it works perfectly... > "Knobs" are not a selling feature for OpenBSD developers (in fact, > accusing someone of adding useless knobs is fighting words! :). > Practically speaking, it is just something else to screw up, either in > the code or in the operation. That's more likely to hurt you than a > suddenly found fatal flaw in a particular encryption system.
if choosing ciphers would be like "turning knobs", we should abandon that choice for SSL/TLS, IPSec, different SSH keys or signatures. I don't agree with your statement in this context. I fully support sane defaults, and making it not easy to change them. but in this case "not easy"=="impossible". at least without implementing it myself, which I'm not able to. chosing ciphers is no tuning. and algorithms can be broken, no one was really surprised when md5 got broken, since there was always sha. and as sha was broken, too (in terms of proper implementation fo alternatives naerly at the same time), a lot of projects had no real alternative. (which was in this case not as bad as it sound, most things do function still with md5 or sha, but md5s provides nothing more than a bit protection against random collisions. > > you're able to use passphrases or keyfiles (with some tricks one could also > > do this in OpenBSD, but it'd be a hack and far easier to screw up) > ok, why not improve OpenBSD's solution, then? because OpenBSD's solution is not good enough. I'm not a c coder, and implementing crypto correctly is not trivial, so I can't improve the code. wrapping everything in shell scripts to achieve something similiar in terms of key handling would be OK, but the implementation itself is the bare minimun which can be called "encrypted". and it's not _very_ secure. I'm not complaining, I simply don't use OpenBSD for encrypted storage. Thats ok for me. > > you're able to change your passphrase without reencrypting your container. > > that could be nice. > If there is a design reason this feature couldn't be added to OpenBSD's > solution, you win a point. :) (I'll admit my crypto knowledge is very > lame.). I can't read the implementation very well, but as it seems, it would be easier to rewrite it (thats not an statement about code quality). (don't know about how hard a port of cgd is/ would be) > > in the unlikely case of a cipher getting broken, you have the possibility to > > switch instantly, using a tool you know with stable code an the same way > > you configured it. > > from: http://www.onlamp.com/pub/a/bsd/2005/12/21/netbsd_cgd.html?page=2 > "Once I have an encrypted slice, can I switch cipher or disable cgd? > RD: There is currently no way to change the encryption type of an > existing partition in place." > > Doesn't quite sound "instant"... > Which also means if you turn some of those knobs wrong, you have a lot > of work to do to repair the problem... > sorry for that with "instantly". I meant without having to wait for a patch to arrive to implement another cipher, which would in the current case mean either having really new code probably rather fast or well tested, stable code after a couple of weeks/months. No existing implementation supports in place reencryption. which is probably better. > > this is the way it appears. if there are any reasons, why cgd shouldn't be > > used at all I'd be more than interested to hear them. if there are any > > reasons > > not to port this to OpenBSD, nobody will die not knowing them. > > That's not the way they work... > OpenBSD does not have multiple mail clients, multiple network filtering > solutions, multiple web servers, five different versions of 'vi', etc. > The preference is for one well maintained, highly tested solution than > several poorly maintained solutions, even if some of those poorly > maintained solutions have small theoretical advantages... I fully agree with you for user applications. however, not having a backup solution for something which can be declared broken anytime is neither reliable nor secure. and whether or not it breaks doesn't depend on how well maintained this existing solution is. > CGD would probably need to have a knock-out killer reason to import it, > something to justify the effort and possible forced replacement of the > existing svnd amoung users who use it, not just a few minor features > that are arguably better and a number of features that are just > different. If the features are better, port the FEATURES. If the > design is just a little better, why not work on it a lot and come up > with a CLEARLY better design? svnd is fine and has its applications, and it shines _despite_ the crypto add-on. cgd _is_ a clearly better design. it is designed for secure storage, which is svnd apparently not, it has a minimal crypto feature _tacked on_. and if the posting in the other thread (the cite of the cgd author) is true, svnd would be susceptible to attacks by precomputing blocks (google rainbow table or known plaintext attack). and there are clearly blocks predictable at the start of a volume. > The point is to make the best possible OS, not a few good features on > some poorly implemented and under-tested tools slapped together > carelessly. And yes, avoiding slapping things in "because they are not > horrible" is a difficult challenge. :) I fully agree with you, that is the reason to take the advantage of an existing design, which is already a bit tested, and improve that. and as far as I can tell, cgd is way better than linux cryptoloop or linux dmcrypt.
