FUD about CGD and GBDE

[Poul-Henning Kamp]

In message <20050303165730.8931C3BFDBA at berkshire.machshav.com>, "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
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.