Re: CGD
I'd like to apologize to all. Fortune told me yesterday that assumptions are the mother of all screw-ups. I assumed I was educated about the subject. I was not. I forget it's not my tree. I assumed that the OpenBSD developers desired cryptographic disks. There may be a want for them, but its obvious to me now that they are not as desireable as other functionality in the system. And, nobody has unlimited time to work on whatever. Hence, I realize that crypo-disks are somewhat unimportant. Especially in the light of other mechanisms such as physical security and _practicality_. Practically speaking, few people have top-secret info! I accused people who did not deserve such accusations. I wish I could aid you to stamp this kind of malarky out of existence on these forums. I can only shut myself up, yet I will try to impart my new-found virtue of doing your research and homework first on the few open source utilizing people who look up to me. Thanks for a great OS. I'm deeply sorry and ashamed for the blather and being an ass. Travers Buda
Re: CGD
Ted Unangst, Well, I don't think I need to articulate anymore why CGD ought to make it in. I already have stated my reasons, so I won't do it again. But there is something I'm lacking from you: I think YOU need to articulate why CGD is not making it in. Why is the burden of proof on me? After all, YOU ported it in the first place! YOUr desire preceded mine. YOU thought using CGD was good long before I ever did. Was there some reason behind this? Was there reason behind then using svnd? Am I to think you're a man sans reason? You clearly think svnd is a better solution, but why? I'm sure you have some really good reasons. Perhaps if you _*share them with us, we will finally understand and stop bitching about it*_. If you take up the burden of proof, then you won't have to deal with pesky little threads such as this. Otherwise, if you continue with your typical behavior, I shall cast my vote of no confidence. OpenBSD is cited by some people as psychotic--the code audits, the stack protection: ProPolice, W^R; secure by default, the development of OpenSSH, the constant vigilance... You tell us that svnd is good enough. Perhaps for you. Rather, the paper detaling the design of CGD speaks of crypto implementations strong enough to use on hard disks at the Los Alamos research labs (several of which went missing.) Where would OpenBSD be? if people said it's good enough, rather than lets do the best job we can do. I'm very impressed with the design of OpenBSD, even the selection of software in the base system rocks my socks. Yet, svnd seems like a blight on an otherwise perfect OS. Travers On Tuesday 03 January 2006 14:37, Ted Unangst wrote: On 1/2/06, Travers Buda [EMAIL PROTECTED] wrote: You've made it very clear that CGD won't be imported into OpenBSD, yet you've never explained why, or why you ported it in the first place. Care to let us in on why? I expect your reply will be a short no just like a few of your replys to this subject. For what it is worth, I'm asking. Because, like everyone else, you've failed to pass the articulation test. http://marc.theaimsgroup.com/?l=openbsd-miscm=112534721521131w=2
Re: CGD
I think YOU need to articulate why CGD is not making it in. Why is the burden of proof on me? After all, YOU ported it in the first place! YOUr desire preceded mine. It's our source tree. End of story. You really need to adjust your attitude. Or, if you won't, please run something else.
Re: CGD
From: Travers Buda [mailto:[EMAIL PROTECTED] I think YOU need to articulate why CGD is not making it in. Why is the burden of proof on me? After all, YOU ported it in the first place! YOUr desire preceded mine. Travers - are you bipolar or just hyper? I think it was made clear earlier when stated that OpenBSD devs don't HAVE to justify their reasons for not including a particular tool in their distro. You can try to produce winning arguments as to why it is undeniably good for it to be included - not anyone else to defend why *not*. Law of the jungle my friend, and you've not earned the right to be a chest-thumping gorilla yet. DS
Re: CGD
On 1/6/06, Travers Buda [EMAIL PROTECTED] wrote: YOU thought using CGD was good long before I ever did. Was there some reason behind this? Was there reason behind then using svnd? Am I to i had an afternoon free and nothing better to do. i probably stored about 10k of data on a cgd partition for about 5 minutes to see if it worked, then deleted it. the stats with encrypted svnd are pretty similar, though i think i used one as long as an hour one time. If you take up the burden of proof, then you won't have to deal with pesky little threads such as this. Otherwise, if you continue with your typical behavior, I shall cast my vote of no confidence. this made me laugh. so long folks, i've enjoyed the ride. i wish my successor only the best.
Re: CGD
On 1/6/06, Travers Buda [EMAIL PROTECTED] wrote: On Friday 06 January 2006 14:46, Ted Unangst wrote: i had an afternoon free and nothing better to do. i probably stored about 10k of data on a cgd partition for about 5 minutes to see if it worked, then deleted it. the stats with encrypted svnd are pretty similar, though i think i used one as long as an hour one time. I'm sorry if I am misunderstanding. So are you saying that you designed svnd because you were bored, that you built it without any ends in mind, and that your purpose was not to protect your data, but only to kill time? i didn't design svnd.
Re: CGD
Travers Buda wrote: On Friday 06 January 2006 14:46, Ted Unangst wrote: i had an afternoon free and nothing better to do. i probably stored about 10k of data on a cgd partition for about 5 minutes to see if it worked, then deleted it. the stats with encrypted svnd are pretty similar, though i think i used one as long as an hour one time. I'm sorry if I am misunderstanding. So are you saying that you designed svnd because you were bored, that you built it without any ends in mind, and that your purpose was not to protect your data, but only to kill time? Why don't you go and educate yourself on the history of vnd: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/vnd.c http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/vnconfig/ then you can stop bugging tedu. -d
Re: CGD
I think I made a good application for the final round of the Moron Of The Year 2006 contest. My comprehension of the matter is obviously not as good as it appeared, as some of the last mails and also some private point out. I am sorry for that. All I really proved was that salting would be a good idea, and perhaps a location dependend IV. Thanks to tedu for not flaming me into the ground, I took some of your time. I think I owe you a beer (or preferred non-alc beverage). Sorry for the noise, I think I will go lurking for a while now. --knitti
Re: CGD
On 02/04/2006 01:05:17 AM, veins wrote: I think you are missing the point, cgd and salting are two different and unrelated things. It's not because cgd isn't making it into OpenBSD, that salting won't make it into svnd. I'd explain, but frankly after a night at work i'd rather go and sleep while you google :-) I know cgd and salting are two different things, but cgd salts and svnd does not. IMO, what the thread is about is the criticisms that came up of svnd, compared with the goodness of CGD, in the interview about CGD. So, people are suddenly wanting CGD... Or maybe I am OT, it is late. :) The svnd salting patch did come up in the CGD thread, which sorta changed the subject to whether or not svnd _should_ salt. ps. tedu just said that he got no comments about his diff, if you really think the idea is valuable, you should be testing the diff. You are right. But another point of my post was to indicate that yes, tedu is right in that most people _won't_ run CGD (or svnd) but people _still_ appreciate having the option open. I, like IMO a lot of people, have only enough interest to kibbutz in the hope of slowly collecting enough information to make an informed choice should the time come to exercise the option. The only apology I make regards this aspect of my post is cluttering up the list in the hopes that what I say will make the people actually doing the work feel appreciated rather than put-upon, by pointing out that the clueless questions are an indication of the large breadth (but not depth) of desire for a crypto fs. It seems tough working on something complex a whole lot of people sorta think they want a little bit. Crypto fs seems to fit that bill more than most. So in way of support I thought I'd try to point this out and give encouragement. Again, sorry if it's a distraction. Regardless, thanks for hitting me with a clue-stick even if I did not need it, because sometimes I do. :-) Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: CGD
On 1/4/06, Ted Unangst [EMAIL PROTECTED] wrote: On 1/3/06, knitti [EMAIL PROTECTED] wrote: cgd gives users some choice over how to build their encrypted partition. you're able to use different ciphers. 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. this is really not that useful. why would you pick anything other than the best when setting it up? because no one knows what the best is. blowfish appears to be the best at the moment, because its secure and fast. some other people don't like block sizes of 64 bit. so perhaps they take aes, which is slightly slower but encrypts blocks of 128 bit. is it for no reason, that swap encryption uses aes over blowfish? and after it's setup, you can't change. the idea that once a cipher is broken you could migrate is nice, but think about it. are you equipping all your servers with double storage so that you can copy and reencrypt everything? i doubt anyone has thougt more than 10 seconds about what the migration procedure would really be. a pain in the ass. but you can plan for it. anyway, it's not that hard to switch ciphers in svnd. how critical is your timeframe? can you wait 24 hours to upgrade? no one besides you (the developers) knows, how quick an upgrade would be possible. 24h _is_ really fast, and a week would probably suffice too, for most people. I think this rocks, but no one knew it would be that fast. you're able to change your passphrase without reencrypting your container. not really, or at least not any more so than with svnd. encrypting with your passphrase (as would be the easy way with svnd) is using a weaker keyspace than encrypting with a generated key. but you are right, that would be possible with svnd too. --knitti
Re: CGD
this is really not that useful. why would you pick anything other than the best when setting it up? because no one knows what the best is. blowfish appears to be the best at the moment, because its secure and fast. some other people don't like block sizes of 64 bit. so perhaps they take aes, which is slightly slower but encrypts blocks of 128 bit. is it for no reason, that swap encryption uses aes over blowfish? If you really meant what you said you should let the people that write an OS make that decision for you. And just for everyone's entertainment, when was it the last time that you saw swap being used?
Re: CGD
On 1/4/06, Marco Peereboom [EMAIL PROTECTED] wrote: because no one knows what the best is. blowfish appears to be the best at the moment, because its secure and fast. some other people don't like block sizes of 64 bit. so perhaps they take aes, which is slightly slower but encrypts blocks of 128 bit. is it for no reason, that swap encryption uses aes over blowfish? If you really meant what you said you should let the people that write an OS make that decision for you. apparently there is no such thing as a general best, only an application specific. or do you suggest there is one? why would the developers then decide to use blowfish for svnd and aes for swap? as it looks, data in swap is more secure than on svnd. known plaintext attacks are far more difficult, and no problem with replay attacks. why shouldn't I be able to have this also for storage? if that's the decision by the developers, I'd rather decide on my own. And just for everyone's entertainment, when was it the last time that you saw swap being used? last year. five days ago. --knitti
Re: CGD
On 1/4/06, knitti [EMAIL PROTECTED] wrote: this is really not that useful. why would you pick anything other than the best when setting it up? because no one knows what the best is. blowfish appears to be the best at the moment, because its secure and fast. some other people don't like block sizes of 64 bit. so perhaps they take aes, which is slightly slower but encrypts blocks of 128 bit. is it for no reason, that swap encryption uses aes over blowfish? aes has faster key setup, which is important for swap but not for svnd. the cvs changelog says as much. swap encryption started out using blowfish as well.
Re: CGD
On 1/4/06, Ted Unangst [EMAIL PROTECTED] wrote: aes has faster key setup, which is important for swap but not for svnd. the cvs changelog says as much. swap encryption started out using blowfish as well. i also should have pointed out that swap was converted to using rijndael, not aes, since aes did not exist at the time the conversion was made.
Re: CGD
On 1/4/06, Karl O. Pinc [EMAIL PROTECTED] wrote: another point of my post was to indicate that yes, tedu is right in that most people _won't_ run CGD (or svnd) but people _still_ appreciate having the option open. I, like IMO a lot of people, have only enough interest to kibbutz in the hope of slowly collecting enough information to make an informed choice should the time come to exercise the option. this is good idea. the first thing you need to do is identify your threat model. can you write it down? and if it starts with somebody stealing, you lose. amidst all the yammering, i think people are just assuming that encrypting their data makes it safe. but if you can't even say what the danger is, how can you know it's safe?
Re: CGD
warning! spoilers! openbsd svnd is not safe for general use. On 1/4/06, Ted Unangst [EMAIL PROTECTED] wrote: this is good idea. the first thing you need to do is identify your threat model. can you write it down? and if it starts with somebody stealing, you lose. amidst all the yammering, i think people are just assuming that encrypting their data makes it safe. but if you can't even say what the danger is, how can you know it's safe? my threat model includes the follwing two cases. for both of then svnd can't protect me really well case 1) lets say someone can predict some blocks in my encrypted data, then she can find every block (64bit) everywhere within the container with the same data. dependend on the nature of the data, if some blocks are known, more can be guessed. the license part of a source file is very predictable. so if some software's source, which is no secret but its possession illegal, can be proved to be on my disk without breaking my key, this is bad. some illustration to prove, that every block of the same data encrypted with the same user-key is the same in every svnd0 in the world: # dd if=/dev/zero of=/tmp/img0 bs=1k count=1 1+0 records in 1+0 records out 1024 bytes transferred in 0.000 secs (1067 bytes/sec) # dd if=/dev/zero of=/tmp/img1 bs=1k count=1 1+0 records in 1+0 records out 1024 bytes transferred in 0.000 secs (1280 bytes/sec) # vnconfig -ckv svnd0 /tmp/img0 Encryption key: test svnd0: 1024 bytes on /tmp/img0 # vnconfig -ckv svnd1 /tmp/img1 Encryption key: test svnd1: 1024 bytes on /tmp/img1 # dd if=/usr/share/misc/license.template of=/dev/rsvnd0c bs=1k count=1 1+0 records in 1+0 records out 1024 bytes transferred in 0.000 secs (12190476 bytes/sec) # dd if=/usr/share/misc/license.template of=/dev/rsvnd1c bs=1k count=1 1+0 records in 1+0 records out 1024 bytes transferred in 0.000 secs (1138 bytes/sec) # vnconfig -u svnd0 # vnconfig -u svnd1 # cmp /tmp/img0 /tmp/img1 # user key==encryption key==Bad Thing(TM) case 2) data integrity. I don't want, that a person can mess with my data without knowing my key. the location of some data can be determined on my disk, this data can be replicated everywhere else on the disk. either by insertion or by overwriting other data. illustration continued: # dd if=/tmp/img0 of=/tmp/img3 skip=1 bs=128 count=1 1+0 records in 1+0 records out 128 bytes transferred in 0.000 secs (1488372 bytes/sec) # cat /tmp/img3 /tmp/img3 /tmp/img3 /tmp/img3 /tmp/img6 # vnconfig -ckv svnd0 /tmp/img6 Encryption key: test svnd0: 512 bytes on /tmp/img6 # cat /dev/rsvnd0c dx should be separated by a comma, e.g. Copyright (c) 2003, 2004 p_h[he copyright. Additional years should be separated by a comma, e.g. Copyright (c) 2003, 2004 p_h[he copyright. Additional years should be separated by a comma, e.g. Copyright (c) 2003, 2004 p_h[he copyright. Additional years should be separated by a comma, e.g. Copyright (c) 2003, 2004 If you add extra text# classical replay attack. I seem to have screwed some block boundary, but you get the general idea. a good implementation would've produced garbage only. thanks a lot for your attention. --knitti
Re: CGD
On Wed, Jan 04, 2006 at 11:11:01PM +0100, knitti wrote: my threat model includes the follwing two cases. for both of then svnd can't protect me really well case 1) lets say someone can predict some blocks in my encrypted data, then she can find every block (64bit) everywhere within the container with the same data. Of course not, that would have been true if it used ecb. It uses cbc which encrypts each disk block with an iv that depends on the block number, so a plaintext block will be encrypted differently depending both on which disk block it is in and what data precedes it in that block. # vnconfig -ckv svnd1 /tmp/img1 [...] # dd if=/usr/share/misc/license.template of=/dev/rsvnd0c bs=1k count=1 [...] # cmp /tmp/img0 /tmp/img1 You are comparing the entire images. Try instead to fill one image with a repeating 8-byte pattern and then check the contents. The encrypted contents will not be repeated. user key==encryption key==Bad Thing(TM) How would it help to generate a random key which is then encrypted with a user key and stored on the disk? A dictionary attack is still quite possible. While I'm here I'd like to ramble for a while about the fact that people seem to be obsessed with the ability to change their passphrases; I've seen it at least twice in this thread and sometimes I even hear people talking about changing the passphrase on pgp keys and similar. That only helps if you are sure noone has seen your previously encrypted key but now has been able to guess your passphrase and may in the future be able to access your encrypted key. See, if they already have a copy of the key encrypted with the old passphrase they will still be able to use your old passphrase on it. By reencrypting it with a new passphrase you only give them another chance to crack it. So changing the passphrase which is used to encrypt a key is stupid, you really need to generate a new key. So it will take a long time to reencrypt the disk, tough luck. The problem with user remembered passwords is that they aren't strong. The only way around that is to store a random number somewhere, e.g. a USB stick or a floppy. Therefore, you may want a combination of a stored random secret and some passphrase. You lose either = you lose your data. If someone finds the stored secret they can mount a dictionary attack or start extracting your finger nails. If you store the random secret on the disk itself it's a salt. While you can use a dictionary on it, it does mean that you have to do that for each disk you want to crack. So, salt + passphrase is good, and if you can store the salt wherever you want it's as good as you can do. case 2) data integrity. I don't want, that a person can mess with my data without knowing my key. the location of some data can be determined on my disk, this data can be replicated everywhere else on the disk. [...] classical replay attack. I seem to have screwed some block boundary, No. I don't know why you assume that ecb is used, the reason your output is messed up is cbc. It is possible to cut and paste encrypted data to some extent, but when you do that you will always mess up one crypto block. No way around that unless you find the key, so while this can be a problem it is a little less severe than you say. This is a problem with cbc, to avoid it you need to use another block chaining mode or add some integrity check. CGD also uses cbc according to http://www.imrryr.org/~elric/cgd/html4/cgd.html so unless there is some additional integrity check (which is a problem for block devices since it requires additional storage) it has the same problem. Andreas
Re: CGD
Andreas Gunnarsson wrote: On Wed, Jan 04, 2006 at 11:11:01PM +0100, knitti wrote: my threat model includes the follwing two cases. for both of then svnd can't protect me really well case 1) lets say someone can predict some blocks in my encrypted data, then she can find every block (64bit) everywhere within the container with the same data. Of course not, that would have been true if it used ecb. It uses cbc which encrypts each disk block with an iv that depends on the block number, so a plaintext block will be encrypted differently depending both on which disk block it is in and what data precedes it in that block. Yeah, and had it been using ECB, still two plaintext would have to be aligned to the beginning of a block and fill the 64 bits for the ciphered block to look the same.
Re: CGD
On 1/3/06, Ted Unangst [EMAIL PROTECTED] wrote: On 1/2/06, Travers Buda [EMAIL PROTECTED] wrote: You've made it very clear that CGD won't be imported into OpenBSD, yet you've never explained why, or why you ported it in the first place. Care to let us in on why? I expect your reply will be a short no just like a few of your replys to this subject. For what it is worth, I'm asking. Because, like everyone else, you've failed to pass the articulation test. http://marc.theaimsgroup.com/?l=openbsd-miscm=112534721521131w=2 OK, I'll try, because I'd be interested in using it on OpenBSD. Since I won't be able to do it myself, any or no answer will qualify ;) cgd gives users some choice over how to build their encrypted partition. you're able to use different ciphers. 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) you're able to change your passphrase without reencrypting your container. 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. 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. --knitti
Re: CGD
Ted Unangst wrote: On 1/2/06, Travers Buda [EMAIL PROTECTED] wrote: You've made it very clear that CGD won't be imported into OpenBSD, yet you've never explained why, or why you ported it in the first place. Care to let us in on why? I expect your reply will be a short no just like a few of your replys to this subject. For what it is worth, I'm asking. Because, like everyone else, you've failed to pass the articulation test. http://marc.theaimsgroup.com/?l=openbsd-miscm=112534721521131w=2 on a related subject: what's keeping that diff you did to add salting to vnconfig from hitting the tree? (or something like it) /kami
Re: CGD
Travers Buda wrote: Ted Unangst, Yes, I've looked at the archives. You've made it very clear that CGD won't be imported into OpenBSD, yet you've never explained why, or why you ported it in the first place. Care to let us in on why? I expect your reply will be a short no just like a few of your replys to this subject. For what it is worth, I'm asking. You have this backwards, we do thing because there are *reasons to do so*, not because there are *no reasons not to*.
Re: CGD
knitti wrote: On 1/3/06, Ted Unangst [EMAIL PROTECTED] wrote: On 1/2/06, Travers Buda [EMAIL PROTECTED] wrote: You've made it very clear that CGD won't be imported into OpenBSD, yet you've never explained why, or why you ported it in the first place. Care to let us in on why? I expect your reply will be a short no just like a few of your replys to this subject. For what it is worth, I'm asking. Because, like everyone else, you've failed to pass the articulation test. http://marc.theaimsgroup.com/?l=openbsd-miscm=112534721521131w=2 OK, I'll try, because I'd be interested in using it on OpenBSD. Since I won't be able to do it myself, any or no answer will qualify ;) 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. 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? 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.). 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... 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... 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? 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. :) Nick.
Re: CGD
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
Re: CGD
On 1/3/06, knitti [EMAIL PROTECTED] wrote: cgd gives users some choice over how to build their encrypted partition. you're able to use different ciphers. 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. this is really not that useful. why would you pick anything other than the best when setting it up? and after it's setup, you can't change. the idea that once a cipher is broken you could migrate is nice, but think about it. are you equipping all your servers with double storage so that you can copy and reencrypt everything? i doubt anyone has thougt more than 10 seconds about what the migration procedure would really be. anyway, it's not that hard to switch ciphers in svnd. how critical is your timeframe? can you wait 24 hours to upgrade? do you have a beeper set to wake you up everytime somebody posts to sci.crypt? 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) this is a change that's fairly easy to bring about. you're able to change your passphrase without reencrypting your container. not really, or at least not any more so than with svnd.
Re: CGD
On 1/3/06, kami petersen [EMAIL PROTECTED] wrote: on a related subject: what's keeping that diff you did to add salting to vnconfig from hitting the tree? (or something like it) nobody commented on it. the lifecycle of this entire conversation has gone something like: whiners demand cgd without explanation. after a bit, we identify something that could be improved. i post a patch. silence. whiners demand cgd without explanation. i don't believe that the people asking for cgd really even intend to use it. they are certainly not capable of actually evaluating their needs. it doesn't matter what the solution is; if it's not spelled cgd they won't be happy. the absurdity of it all amazes me. like maybe if you post an interview with roland
Re: CGD
On 1/3/06, veins [EMAIL PROTECTED] wrote: --- Ted Unangst [EMAIL PROTECTED] wrote: On 1/3/06, kami petersen [EMAIL PROTECTED] wrote: on a related subject: what's keeping that diff you did to add salting to vnconfig from hitting the tree? (or something like it) nobody commented on it. [...] I didn't see that diff :( Still need comments on it ? If so I can patch tomorrow a box @ work and do some testing on it. it's only proof of concept; i wouldn't trust it too far. http://marc.theaimsgroup.com/?l=openbsd-miscm=110474799109884w=2
Re: CGD
--- Ted Unangst [EMAIL PROTECTED] wrote: On 1/3/06, kami petersen [EMAIL PROTECTED] wrote: on a related subject: what's keeping that diff you did to add salting to vnconfig from hitting the tree? (or something like it) nobody commented on it. [...] I didn't see that diff :( Still need comments on it ? If so I can patch tomorrow a box @ work and do some testing on it.
Re: CGD
--- Ted Unangst [EMAIL PROTECTED] wrote: On 1/3/06, knitti [EMAIL PROTECTED] wrote: cgd gives users some choice over how to build their encrypted partition. you're able to use different ciphers. 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. this is really not that useful. why would you pick anything other than the best when setting it up? and after it's setup, you can't change. the idea that once a cipher is broken you could migrate is nice, but think about it. are you equipping all your servers with double storage so that you can copy and reencrypt everything? i doubt anyone has thougt more than 10 seconds about what the migration procedure would really be. anyway, it's not that hard to switch ciphers in svnd. how critical is your timeframe? can you wait 24 hours to upgrade? do you have a beeper set to wake you up everytime somebody posts to sci.crypt? Not to mention that even in the case blowfish is broken at some point, it is unlikely that the attack reduces complexity of a decryption to a timeframe that would allow someone to decrypt data ciphered with a strong key in svnd before OpenBSD has the opportunity to switch cipher.
Re: CGD
On 01/03/2006 09:45:02 PM, Ted Unangst wrote: On 1/3/06, kami petersen [EMAIL PROTECTED] wrote: on a related subject: what's keeping that diff you did to add salting to vnconfig from hitting the tree? (or something like it) i don't believe that the people asking for cgd really even intend to use it. I don't intend to use svnd (and so have not been paying attention but am venturing to comment anyway), but I do _like_ the idea of having it there to use should the need arise. Salting sounds like something I want because, again, in my uninformed opinion, otherwise you wouldn't see it all over the place in password hashes. Apparently the implementation complexity v.s. increase in security trade-off comes out in favor of salting in at least that problem domain. It would be a question I'd investigate should I ever want an encrypted file system. I'm interested enough to pay a little attention now should somebody either decide to implement salting in svnd or explain why I don't want it. I suspect others are in the same frame of mind. Hence the not-necessarily-informed hand waving surrounding all sorts of encrypted filesystem issues (even though, IMHO, salting is the only issue of significance in svnd that was brought up in the CGD article.) Why did I write this? I guess because I'm lazy like everybody else and am hoping for an expert answer vis. svnd and salting. Perhaps I'm thinking you'd appreciate the data point regards my interest in the subject. Feel free to ignore me. Regardless you should know I do appreciate the work done. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: CGD
Karl O. Pinc wrote: On 01/03/2006 09:45:02 PM, Ted Unangst wrote: On 1/3/06, kami petersen [EMAIL PROTECTED] wrote: on a related subject: what's keeping that diff you did to add salting to vnconfig from hitting the tree? (or something like it) i don't believe that the people asking for cgd really even intend to use it. I don't intend to use svnd (and so have not been paying attention but am venturing to comment anyway), but I do _like_ the idea of having it there to use should the need arise. Salting sounds like something I want because, again, in my uninformed opinion, otherwise you wouldn't see it all over the place in password hashes. Apparently the implementation complexity v.s. increase in security trade-off comes out in favor of salting in at least that problem domain. It would be a question I'd investigate should I ever want an encrypted file system. I'm interested enough to pay a little attention now should somebody either decide to implement salting in svnd or explain why I don't want it. I think you are missing the point, cgd and salting are two different and unrelated things. It's not because cgd isn't making it into OpenBSD, that salting won't make it into svnd. I'd explain, but frankly after a night at work i'd rather go and sleep while you google :-) ps. tedu just said that he got no comments about his diff, if you really think the idea is valuable, you should be testing the diff.
CGD
Ted Unangst, Yes, I've looked at the archives. You've made it very clear that CGD won't be imported into OpenBSD, yet you've never explained why, or why you ported it in the first place. Care to let us in on why? I expect your reply will be a short no just like a few of your replys to this subject. For what it is worth, I'm asking. Travers
cgd
Hi, I had read on the mail lists that Ted U. had ported cgd to OBsd for 3.3, but that those patches are no longer maintained and that there are no intentions of re-porting cgd to OBSD. cgd and (s)vnd are the best encryption methods compared with cfs or tcfs, but cgd seems to a more flexible and more fully developed solution designed just for disk encryption, while encryption in (s)vnd seems like an add-on to the loopback system. I was wondering why a permanent port of cgd was not under consideration considering? Thanks, RJ
