On 1109809815 seconds since the Beginning of the UNIX epoch "Poul-Henning Kamp" wrote: > >In message <[EMAIL PROTECTED]>, Roland Dowdeswell wr >i >tes: > >>Let's discuss a simple example and see how it works. Let's walk >>through a user login, with /etc/passwd on GBDE and the filesystem >>mounted with mtime. > >These days, on the majority of low cost disks used in enduser >configurations you risk looking an entire track if the disk were >writing when you pulled power. (People complain about this, but >doesn't seem to be willing to pay to avoid it.) > >So the cummulative increase of risk from using GBDE doesn't really >register on the radar for people. > >And therein lies a very important lesson for you: It may not be a >100% theoretical ironclad guarantee, because few people are prepared >to pay for that in the first place.
What if I am running GBDE over raid? I would then have some expectation of reliability which would be counter-intuitively absent. With GBDE, even if I am willing to pay for reliability I will not find it. But, I will not know that it is absent because this behaviour is undocumented. I think that at the very least a note should be added to the GBDE man page that indicates that it reduces the reliability of the file system on it so that people designing production systems will not use it. In FreeBSD and NetBSD, a lot of effort has been put into making the system as reliable as possible, e.g. soft-updates. The results are quite impressive. Both operating systems are quite reliable. A lot of very good work has been done, and some quite difficult problems have been tackled. I cannot understand this completely dismissive attitude about reliability on this one topic. Why do we bother with soft-updates if we are willing to break the underlying systems? >The difference between CGD and GBDE in this area is that for CGD >it is not convincibly shown that it is the only feasible attack >(because you use the same key for all sectors thus exposing the >ciphers possible weaknesses big time), for GBDE everybody so far >agrees that the key is the only feasible attack. Not everybody. I have spoken with a number of people who are unconvinced. GBDE invents what is basically a cryptographic algorithm comprised of SHA2/512, AES256, MD5, Yarrow and AES128 which has not been analysed extensively. So, I do not see how you can assert that anything has been convincingly shown about it. I have seen quite a bit of hand--waving, but I have not seen a proof. Or evidence of enough analysis to make this claim. >>E.g. given the bit-blender >>approach of GBDE [from 7.4 of your paper], if you know the salt >>then you can use a divide-and-conquer strategy to tease the master >>key out in a ``reasonably short'' time. Less than 2^128 steps >>certainly, if I look at things correctly. > >I don't think you do. I do not think that you understood what I was saying. I will write it up in LaTeX to try to make it more clear. This will take me a few days. >By the way: you keep comparing your AES256 version of CGD to >my AES128 version of GBDE, but at the same time you want me >to conceede that your 256 bit key is almost 1024 bits when >seen in the right light. I have never claimed that CGD has ``almost 1024 bits''. >Lets us be fair and use a level ground: Let us compare two 128 bit >version or two 256 bit versions. > >Now, which algorithm is stronger ? I chose CGD with AES256 for two reasons. First I wanted to compare systems with comparable performance. CGD does not have a mode which is as slow as GBDE so I chose the slowest mode. Also, GBDE has 2176 bits of key material. Again, CGD does not have a mode which can use 2176 bits of key material so I chose the closest one. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"