In message <[EMAIL PROTECTED]>, "Steven M. Bellovin" writes:
>And Knuth was talking about a situation without an adversary. If the component (well respected etc etc) algorithms I have used in GBDE contains flaws so that they become individually less intrinsicly safe because their input is the output of another such algorithm, then the crypto-world has problems they need to work on. If I have made a blatantly stupid programming error, then the source code is out there for all of you to study and review. Despite my best efforts to get people interested in reviewing GBDE, it doesn't seem to have succeeded in getting any attention until now, and I am very much looking forward to the competent review and input this will generate. >I don't claim that there's a flaw. I do assert that that I haven't seen a >threat model that would justify extra complexity. I have, more places than I expected. Before writing GBDE I spent a lot of time talking to people who are responsible for data which needs to be kept private. In fact I talked with all the people I could find who had in their job description to take care of that function in their organization. I didn't talk with very many crypto specialists at that stage, because I was aiming squarely at deployability: Crypto is no good if it never leaves the lab. It transpires that there are actually many places where information has to be kept secret for a surprising number of years. Medical experients for instance: There are double-blind experiments which run for over 20 years before the blind is lifted. Governmental records. Census numbers. When encryption is done a the disk level, many techniques which are available at the stream level are not available: You can not let individual sectors depend on each other (well, you can but it has prohibitive performance cost). You cannot compress the plaintext to increase entropy and so on. You face a reality of millions of sectors with very low entropy, and high predictability which you need to encrypt as is, no tricks allowed. Considering the protection periods people asked for, I could convince neither myself nor any of the, (often very clued) people I talked to, that just taking a current standard algorithm and applying it using the same keymaterial to each sector of the media would be safe for a sufficient amount of time. Having low entropy data and low entropy keys and millions of data points just sounds too much like "gefundenes fressen" for any attacker. Therefore GBDE was designed so that none of the component algorithms would be subject to any kind of two-way leverage or statistical attack. This resulted in the PRNG/1time sector-keys, and it was the simplest way I could find to negate the massive sector numbers. This obviously adds complexity compared to the textbook scheme applied in CGD and similar. It is all sounds and true advice about simplicity, but only if we don't simplify so much that people do not trust the result. As Einstein said: "As simple as possible, but no simpler". Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
