"Poul-Henning Kamp" <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]>, "Perry E. Metzger" writes: >>The best I can say, however, is that the US >>government has approved the use of AES with 256 bit keys for very >>highly secure communications, and they have a very demanding user >>community. > > (There is a big difference in what crypto you need for communications, > storage, and archiving.)
In general, yes, but not in this context. In communications you need stuff like authentication that you don't always need in archiving. Anyway, the need for long term safety on a government top secret message is unlikely to be lower than the requirement in a storage context. That's because the adversary can store your message for 30 years just as you can. > My philosophy in this, (as implemented in GBDE), is to trust the > algorithms to do their job, but to not offer an attacker any more > leverage against them than I absolutely have to. In theory, that's a fine sentiment. The problem is that it is very hard to achieve that. > It has been said by various people that "there are [currently] > no cause to think that using the same key for many millions of > sectors is a problem". > > I belive that is a fair and balanced summary, and I trust the > people to know what they talk about and I belive them. > > Nontheless, I do not consider it good engineering to expose the > algorithm to unnecessary stress, even if we currently belive we > have a 220 bits margin of safety, if by trivial means, I can avoid > that stress on the algorithm and maintain 256 bits of margin. Let me phrase this in software engineering terms, but it applies also at the crypto layer. In theory, this is a nice idea, but imagine if, in the course of producing your "improved" version, you are actually increasing the risk because there is more code to audit and that code is more complex. (On the crypto side, the issue is that you're combining operations in complex ways that are hard to analyze. Even if you wish to do such a thing, you are in general better off doing it in a way that is designed to be easy to analyze. Often changes that are seemingly trivial to a layman make a big difference in what you can analyze in cryptography and cryptographic protocols.) > But in the case something unforeseen happens, I know that GBDE will > yield its secrets only one sector at a time and CGD will spill all > the eggs at once because it has only one basket. You have one basket too -- the master key. What if there's a nice time/memory tradeoff attack to locate it on your disk? At very best, I can gain a security factor of N this way, where N is the number of disk sectors. In truth, however, one can probably do much better if you're willing to spend some money. Then, of course, what if your algorithm for turning your master key into a sector key key isn't very good? That last bit is equivalent to the "key scheduling" problem you find in many cryptosystems -- and bad key-schedulers are notorious for causing serious trouble. You may think that you've increased the work factor, but perhaps you haven't. The literature is full of unfortunate instances of that. In any case, cracking AES-128 on every sector is pretty clearly cheaper than cracking AES-256 assuming AES is good. If AES is bad, well, your lock sector or attacking the whole disk are again possibilities. I suspect that the security you add by slowing down your crypto enough to do all the master keying you do is likely a lot smaller than simply moving to AES-256 would have given you. If AES isn't good enough for you, you can do stuff like triple-AES, but I think that's likely overkill. > As for making user selectable ciphers and keysizes I decided against > it for two reasons. > > The first reason is that it adds complexity. The code is easily verified though by using test vectors for standard algorithms. In any case, it is a lot simpler to do that than what you have done. You've added substantial complexity behind the scenes, much of which is hard to analyse. > The second is that it offers complexity. > > Adding complexity in the implementation is wrong for all the reasons > we all agree on. To justify that complexity, a benefit must be > proven. The benefit is straightforward -- the user can select their tradeoff between speed and security, and between simplicity in keying and added security from multi-factor keying, and the user can switch to a new algorithm if an old one proves wanting, without even having to compile a new kernel. > In all my interviews and talks with people, I found nobody who > wanted that level of flexibility. Everybody, almost in unison sang > from the "AES is the annointed king and 128 bit is the his key > size." hymn. Then why didn't you stick to AES-128 throughout? :) > The other complexity is for the user. The more questions the user > has to determine the correct answer to, the less likely he is to > get it all right if he is not a subject matter specialist. That's what friendly install software is for. You need not emasculate a system, however, for fear that an advanced user might want to turn knobs. You can simply make sure that the defaults are okay. > Finally, on keying schemes: I didn't put a keying scheme on GBDE > because I belive in the "tools not policies" dogma. The gbde(8) > userland program should be (but isn't quite) flexible enough to > support any keying scheme people decide to use. CGD is similar in that the kernel isn't doing all the flexible key management stuff -- that's userland. > PS: Will you be at BSDcan ? It would be a good chance to corner > a whiteboard and some beer. Possibly. If I am, see you there. -- Perry E. Metzger [EMAIL PROTECTED] _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
