"expert" mode and read-only features

[David Shaw]

On Mon, Dec 08, 2003 at 09:57:52AM -0800, j at erf.sh wrote:

> > > The idea of the read-only features is to have most actual used
> > > releases enabled to allow reading these option when eventually a
> > > new release can create such options.
> > 
> > I'm rather surprised at how well this has worked out.  When 1.2.2
> > added read-only SHA-256, I halfway expected a lot of people to
> > immediately patch around it.  For whatever reason it hasn't
> > happened (people don't actually care about SHA-256, don't
> > understand the code, do understand the code but want to be
> > conservative about hashes, etc) I'm pleased.
> 
> This seems quite reasonable, and quite in keeping with the tendency
> toward extreme conservativeness when it comes to adventurous
> cryptography.  I'm interested to know how you see the widespread
> adoption of these hashes actually taking place though, if software
> like GnuPG has the functionality write-disabled.

There is a more general question whether widespread adoption is good.
Given the design of OpenPGP, if any hash in it is broken, then
effectively all hashes in it are broken.[1] Given this, there is a
decent argument for not including *any* new hashes until they have
been proven in the field.  Then there is the counter argument that
hashes can't be proved in the field unless someone actually uses them.
Then there are number of arguments in between these two.

Including read-only hashes is an attempt for a happy medium - the
hashes are there so that if in the future they are needed/useful, then
there won't be a massive backwards compatibility problem.  At the same
time, because they are read-only for now, there shouldn't be a massive
compatibility problem today.

The current plan with SHA-256 (subject to change, of course) is to
keep it read-only throughout the 1.2.x releases, and enable it for
writing in 1.4.  SHA-384 and SHA-512 are currently read-only
everywhere.  There is a SHA-224 being proposed by NIST at the moment,
and if that becomes part of OpenPGP, I expect we'd treat it the same
as SHA-256 (it's questionable whether OpenPGP needs it though, any
more than it really needs SHA-384).

There are other read-only algorithms: 1.2.4 adds BZIP2 compression.
This is a slightly simpler story in that compression algorithms are
not required to have any particular security properties in OpenPGP.
It's read-only in 1.2.4 purely to avoid backwards compatibility
problems.

David

[1] That's a serious oversimplification - see rfc-2440 for the
    real details.