Miscellaneous questions

[Robert J. Hansen]

Herbert Furting wrote:
>> The standard allows for terabit RSA keys.  Should GnuPG allow them?
> 
> Yes why not,... but only in an expert mode.

You may want to consider re-reading your answer a few times and asking
yourself, "why do I feel this way, and why do other people feel the way
they do?"  It may be informative.

> Ah you think cryptography is engineering? Always thought it would be
> math.

There's a reason why University computer science departments are
distinct from the math department.

At a very high level, computer science is just an applied mathematical
discipline.  The reality is that very little programming work is
actually computer science; it's software engineering.

Developing the math behind an algorithm is a mathematical task.
Implementing the algorithm is definitely a software engineering task.
Coming up with a protocol in which these algorithms are used is even
more clearly a software engineering task.

> Yes,... but despite of the the only thing I hear from you is,.. don't
> need this, don't need that, etc. etc.

Yep.  Welcome to software engineering.

One of the best techniques available to us for controlling complexity in
software--and definitely the simplest--is to take a chainsaw to the
feature list.  Go through the specification and copy down every single
MUST.  Stop right there.  Implement the MUSTs, make them rock solid
reliable.  Only then allow yourself to start worrying about SHOULDs and
MAYs.

This is how GnuPG was developed, by and large.  In the very early days,
GnuPG supported only the bare minimum necessary to conform to the RFC.
Features like Twofish support were not added until the MUSTs were well
in hand.

> Apart from that I had some discussions with Christoph and we both 
> think, that the RFC should be much stricter, especially in what is 
> required.

Bring it up with the working group.

I am not being sarcastic or facetious when I say that.  I'm absolutely
sincere.  If you feel this strongly about it, then bring it up with the
working group.  However, complaining about the RFC here isn't going to 
accomplish anything.

> Apart from the fact that most of such organisations probably use X509
> (unfortunately),... what would they do if an security update to gpg
> is published?

I know of at least one major telco which was, for a while, using OpenPGP
to secure billing information on a national level.  That was some years
ago, though, and they may have changed their system since.  (Due to NDA,
I'm unable to disclose the telco name.)

In the event of a security update to GnuPG, they look for ways to limit
the problem without changing source.  If they have to change source,
they backport the fix and go through an abbreviated approval process
which still costs them a good bit of money.

> And for your specific example, no one forces the insurance company or
> the bank to use the newer versions/features.

Except for people like you, who say "it's not hard to upgrade GnuPG, so
there's no reason to be concerned about interoperability with old versions".

> So perhaps let's ask David. He's both member of the WG (and even a 
> named author since 4880 :-) ) and gnupg developer. Why did he agreed 
> to the features in 4880 (as author) if (as developer) he thinks
> nobody needs them?

I'm not going to presume to try to answer for David.  I will suggest
that you change the question.  In English, the kind of question you've
just asked is called "leading", if not outright "loaded".  (A loaded
question is an extreme form of a leading question.)

Try asking instead: "it appears that OpenPGP is a very large
specification, and few people need all of it.  Is this true?  If it's
true, why does GnuPG support so much of it?"

Same question, but not leading and not loaded.  If David chooses to
answer, I'm pretty sure his answer will be insightful and one which both
of us will disagree with.  But hey--he's writing the code, so he gets to
do that.  :)

>> Section 13.2 of RFC4880.  "Since TripleDES is the MUST-implement 
>> algorithm, if it is not explicitly in the list, it is tacitly at
>> the end."
> 
> So I'm right, or not? It doesn't have to be explicitly in the list.

If it is not in the list, it is tacitly at the end.

Tacit: "implied by necessity."  A tacit agreement is one which no one
has explicitly stated, but which is true nevertheless.

Like many adjectives, it may be discarded from a sentence without
changing the meaning of the sentence.

"Since TripleDES is the MUST-implement algorithm, if it is not
explicitly in the list, it is in the list."

Regardless of whether 3DES is explicitly listed or not, it's going to be
in your preference list.