Re: FUD about CGD and GBDE

• Previous message: Colin Percival: "Re: FW:FreeBSD hiding security stuff"
• Maybe in reply to: Poul-Henning Kamp: "FUD about CGD and GBDE"
• Next in thread: Perry E. Metzger: "Re: FUD about CGD and GBDE"
• Reply: Perry E. Metzger: "Re: FUD about CGD and GBDE"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: "Perry E. Metzger" <perry@piermont.com>
Date: Fri, 04 Mar 2005 15:52:32 +0100

In message <877jknik4w.fsf@snark.piermont.com>, "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.)

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.

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.

Exactly where the line is between overkill and conservative engineering
is always subject to individual preference and taste.

I don't seriously think that either of CGD or GBDE will be broken
through any other path than guessing or otherwise obtaining the
passphrase.

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. (Hans Christian
Andersen wrote quite amuzingly about this 150 years ago in the story
"The woman with the eggs".)

As for making user selectable ciphers and keysizes I decided against
it for two reasons.

The first reason is that it adds complexity.

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.

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.

That surprised me initially.

It transpired that people had a very simple and prosaic reasoning:
"Anything else will give us footnotes during audits". Different
ciphers will make the auditor write "the standard AES should have
been used" even if the cipher used is agreed by everybody to be
stronger. A longer keylength will result in a note about "unneccessary
overkill and waste of resources".

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.

My favourite question from a UNIX installer was something like:

        "Do you want this system configured according the the
        regulations set forth in [45 character of legal reference]
        ? [yes/no] _"

And as you can guess, it didn't even offer a default to hint
what one should choose. (As it later transpired, the option
would disable the support for a locally connected printer.)

Offering options in a situation where users will generally not dare
using anything but the default is not only quite pointless, it is
down right detrimal to user experience, and, probably, security.

It used to be that I, as a UNIX wizard of some renown, knew what
happened when a user logged into a FreeBSD box. But today, between
ssh, opie, PAM, access.conf and what else gets in the way, I have
to say that unless all settings are the default, it will take me
considerable time to determine that no holes have been opened.

I fully agree that we have gained fantastic flexibility through all
these features, but I am not always convinced that they are a net
improvement of security when measured over the set of all FreeBSD
machines in the world.

So I made the choice to structure the source code and the crypto
path so that other algorithms could be slotted in by any minimally
competent programmer, and stuck to the choice of algorithm which
seems to be the king of the hill these days. If the wind or the
king changes, the source code will adapt in less than a day.

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.

And I also belive in the "many hands make light work", so I sort
of hoped that people who knew more about public key crypto than me
would produce scripts or frontends which implement sound keying
schemes for GBDE based on these technologies.

Poul-Henning

PS: Will you be at BSDcan ? It would be a good chance to corner
a whiteboard and some beer.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

• Previous message: Colin Percival: "Re: FW:FreeBSD hiding security stuff"
• Maybe in reply to: Poul-Henning Kamp: "FUD about CGD and GBDE"
• Next in thread: Perry E. Metzger: "Re: FUD about CGD and GBDE"
• Reply: Perry E. Metzger: "Re: FUD about CGD and GBDE"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]