Miscellaneous questions

[Herbert Furting]

On Mon, 2008-04-14 at 18:06 -0500, Robert J. Hansen wrote: 
> 1.  You didn't ask for the option to allow zero-length UIDs.  If you'd
>     asked for that option, I would have given it.  You asked "why does
>     GnuPG have a minimum size of five characters", "is this imposed by
>     RFC4880", and "where can I report this bug".  Your questions were
>     answered.  Don't blame me if you asked the wrong questions.
Well I don't want to go into such quibbling, but I've seen that gpg
complained for UIDs shorter than 5 characters,... I've seen that RFC4880
doesn't require this, and I've asked why.
Not more not less.

btw: as far as I remember,... zero-length UIDs are allowed by the
standard, aren't they?
While this doesn't make sense ("nothing" is bound to the key) it
wouldn't hurt either.


> 2.  The beautiful thing about open standards is that anyone can
>     implement them.  The beautiful thing about open source is that
>     anyone can change it.  If you really think it's so stupid to forbid
>     short UIDs, then hack the source and submit a patch.  It's a trivial
>     change.
Of course it is,.. but as I've learned,.. this is not necessary because
it already works.

And please don't put my words into a light,.. that I tried to say
somebody or something might be stupid.
I just think, that an implementation should not forbid things, that are
allowed by the standard. Of course it makes sense to have things like an
expert mode or a beginners mode,.. to prevent people from doing thing
that are normally not so useful.


> > OpenPGP is said to be open,... and the specification of the UID 
> > packet only says, that the intended uses is a mail name-addr. It 
> > doesn't say that it must be one.
> You're misunderstanding the purpose of a specification.
Did I? So probably I should burn my diploma ;)


> A specification does not set a high-water mark for implementations.  It
> sets a low-water mark.  Implementations are free to restrict keys in any
> way they want, so long as the low-water mark is met.  If you want to
> write an RFC2440 implementation that supports only DSA, SHA-1 and 3DES,
> nobody will stop you.  You're meeting the low-water mark.
Of course. But I didn't talk about this at all? Did you read my
arguments? I probably didn't explain it correctly (*not a native English
speaker*):
Preferred * Algorithm => Tells what the user prefers (and not what his
implementation support.
Neither does it strictly make sense to include these must-have algos in
the lists (because it is obvious that a conforming implementation will
support them), nor is it (or should it be) the intention of that packet.

And that's why I've argued, that one could use it to show up algorithms
that - even while supported - are not liked or accepted by a user.

If that breaks the best practise idea of the RFC,... it think - in all
doing respect - the RFC should be changed in that matter.

However... if my previous explanation were clear and you just don't like
my ideas, views (for whatever reason) we don't have to discuss it any
longer ;)


> GnuPG would be entirely within rights to require that all UIDs be set to
> "aaaaaaa".
> Or to leave them utterly blank.  Or to not give users a
> choice in them at all. As long as GnuPG understands RFC-conformant
> UIDs and generates RFC-conformant UIDs, that's all it has to do
> according to the RFC.
Of course it would, but why should it do so (apart from the
expert/beginners mode idea).
gpg is probably THE main implementation of OpenPGP (sorry to the
commercial PGP folks ;) ),... as such I think it should support most of
the stuff from OpenPGP, or not?
How many other major implementations are there? Not too much right? And
if none of these use all (or at least most) of the "features",.. why did
we included it at all? I don't talk just about the UID size (which is
already cleared) but also on stuff like the 0x0F sigs.
Is there an implementation the uses third party signatures? Or timestamp
sigs? Can I use the critical bit with gpg? etc. etc.

Please don't understand me wrong,... I'm _not_ saying "stupid Werner
Koch, stupid David Shaw and all the other developers,... go and
implement this!" ;-)
I know that this is opensource and all have their own lives and
business, but I have the felling that the attitude here is,.. most
average people don't need it,... it will perhaps break older/other or
even historical implementations (which ones ;) ) so don't even talk
about it or think about the idea the we could implement it.

Got the point?


> In reality, GnuPG is guided by concerns beyond just strict RFC
> conformance: interoperability, ease of use, and others.
Agreed,... well strict conformance should be meet in each case, this (as
you've said does however not mean that gpg can not implement just a
subset of the standard).
Interoperability,.. of course important,... but we should perhaps (at
least slowly) move to newer stuff (e.g. the sha512 sigs) or we won't
have any advancement at all...
Ease of use,.. of course important to,... but that does not mean,.. that
one shouldn't be able to use every little bit of the standard (=>
expert/beginner modes).


> > Imagine a closed software system that uses simply numbers for 
> > identifying the participants. When it starts at 1, we have UIDs 
> > smaller than 5 characters.
> Imagine the interoperability problems you will have when your UIDs do
> not conform to the de-facto standard.  If you want to do things that
> will deliberately mangle your interoperability, go ahead:
You're funny ;) You just said,.. an implementation can do what it want
(as long as it's meeting the lower mark) now you said it should not.
Of course it would be an interoperability problem,.. but not in a
totally closed (in the sense of autonomous) system.
...

> --allow-freeform-uid will let you do that.  GnuPG will, by default, try
> to keep you very interoperable.  That's clearly the Right Thing To Do.
... and of course I agree with you,.. that the default (non-expert mode)
should at least strongly suggest the user to use name mail-addr UIDs.
But it should not completely forbid to make something different. It's
GnuPG and not GNOME_PG (sorry folks *g*,... and no I use GNOME and not
KDE ^^)


> > Hm why? I'd loose a lot of certifications and I don't see any 
> > security problem with my approach (of course, as David said, SHA-1 is
> > still used in some other places).
> Interoperability.  There are a lot of people out there using old,
> decrepit versions of PGP and GnuPG.  Old versions tend not to react very
> well when people decide to get creative in ways that were not foreseen
> back when the old versions were written.
Of course,.. that was clear,... but I'm not very happy with such really
old stuff. Of course it should receive an specific amount of support and
interoperability,... but I think it's more important to move further.
And to be honest,... it's not so difficult to update gpg ;)

However,.. all of this does not answer my original question,.. whether
it works and makes sense (from a security and not interoperability point
of view) do revoke the old SHA1 selfsigs and create new (e.g.) SHA512,
if it works with _current_ versions of gpg, if it's possible at all, and
which revocation reason one should use.


> > Uhm,.. is there any reason why gpg doesn't support it?
> Yes.  Because you haven't written a patch for it.
Ah,.. I waited for such a comment... this is the
you-dont-develop-so-you-dont-have-any-rights-to-ask-or-discuss answer...
So I translate your answer to: "No there is no reason, except that no
developer had the time to implement it, yet"

btw: are you a gpg developer? 


> > I mean it exists,.. and there are several things (e.g. the examples 
> > from my inital post) that would be better of with an 0x1F?
> You're ascribing magical meanings to things.  You're not going to be
> safer under your scheme.  It's different--it's not better.
Not?
When looking at the prefered * algos it definitely makes sense to allow
putting them on UIDs, because one might e.g. have different locations
(home, work) with different implementations that support different
algos.
But I think that actually it _is_ better to make a global (key wide)
setting first (on a 0x1F) and just modify UIDs that really need other
settings. This is common sense in the world of computing, like you
have /etc/vim/vimrc with global settings first,.. and only create a
~/.vimrc if you relly need to do so.

But for the preferred * algo subpackets I agree that it is not really
necessary (although I think it would be cleaner).
But I consider other subpackets e.g. key usage to be really key and nod
UID related. So why putting them on 0x13 selfsigs if we have the
possibility to use the indented signature on key. (Yes I know that the
RFC allows it on all self-sigs, but I think that could be improved).


> And this is the problem: you _are_ including it.  The RFC requires them
> to be present, and if they're not present, requires all implementations
> to add them.
Could you please show me the place where it says, that those algorithm
IDs must be part of the prefered algorithm subpacktes?


> You're not communicating anything other than "I am not paying attention
> to the best practice outlined in the RFC."  Your correspondents are not
> going to say "oh, you don't like 3DES".
But they should... otherwise this it would contradict the idea of the
user preferences of algorithms.
You understand the difference between what a user prefers and what the
implementation has to support?

> They're going to say "oh,
> you're using a badly-written OpenPGP implementation, here, let me fix
> that for you."
This is only possible internally at all,.. (except when the preference
subpacktes would be in the unhashed subpacket data set).


> > Hm yes,.. but in all doing respect,... this practise is probably not
> > the best as it does not tell the users preference but a mix of the 
> > users preference and the minimal algorithm subset.
> Then join the WG and advocate for this position.  It's an open WG.
A friend of mine (Christoph Mitterer) is going to do so these days,...
he's currently preparing a deep review and lots of questions to
RFC4880,...
But in the meantime I fear,.. that he will run against closed doors and
highly conservative (not to say narrow-minded) attitudes :-(


> Speak for yourself.  My personal-cipher-preferences has 3DES explicitly
> listed as my first preference.
Fine. If mine has listed AES256 (and yours too) first and lacks 3DES gpg
should choose AES256,... if yours doesn't list it,.. it should choose
3DES (or of course another working match).
But imagine the following:
Yours: 3DES, AES256
Mine: AES256, 3DES
Which one is chosen now? But when I only include AES256 I can at least
somewhat control it. 


> I see no reason not to use 3DES and I know 3DES will be supported by
> everyone, so why not use 3DES and avoid the risk of a problem existing?
> 
> > Yes it will work (even if I said,... I don't like 3DES). But an 
> > implementation could provide options to warn a user, if he receives 
> > such messages.
> Why?
Because A user might think 3DES is unsafe for his needs.


> You're assuming 3DES is a weak cipher.  It's not.  It's really quite
> grotesquely overdesigned.  The best attack against it, _in thirty-four
> years of intense cryptanalysis_, requires:
I cannot discuss with you about algorithm details (have only little
knowledge about this)... but I know that e.g. NIST decided to replace
DES by AES and the only thing I can do is follow such hints,... to
decide which algorithm is currently "the best".


> Assuming a thermodynamically perfect computer running at a nice chilly
> three point two Kelvins, you're talking about an energy usage that's
> plenty enough to launch you on a one-way trip out of the Solar System.
Hmm I should ask Christoph whether he can put a computer to one of the
cryostats at CERN... :P


> > Well then why does OpenPGP allow us to use newer algos?
> Because OpenPGP has fallen victim to the Second System Effect.  Because
> everyone and their grandmother wants to get their own personal pet
> algorithm in the mix.  Because people who don't know better scream about
> the injustice of TIGER192 being removed from the mix.  Because people
> who read somewhere on a web forum that SERPENT is better than Rijndael
> and Rijndael is better than AES
Rijndael is AES (well not exactly but more or less ;) )


> insist that GnuPG include Rijndael and
> SERPENT.  Because...
afaik,.. serpent was considered to be more secure,... however... deep
cryptoanaltics are probably missing. 


> ... Rijndael is AES, incidentally.  Rijndael was the name it was
> submitted under to the AES competition.  Once it was chosen as the
> winner, it became AES.
That's not completely true...


> And yes, I have seen people passionately
> advocating for the inclusion of Rijndael in OpenPGP, despite the fact
> it's already there, just under the name AES.
http://en.wikipedia.org/wiki/Rijndael#Description_of_the_cipher


> 3DES is not weaker than AES.  It's different.  It's slower.  It's less
> efficient.
> 
> It's not weaker.  Not in any sense that matters, at least.
*g* who decides which sense matters?


>   168 bits of
> effective 3DES key versus 128 bits of AES key--which wins?  Past a
> certain point additional key length ceases to matter.
Of course,.. but the quality of an alogorihtm doesn't depend on its key
length (see RSA vs. ECC).


> > ... again: If so,. why do we make all that effort? We could simply 
> > keep using MD5/IDEA because for most cases that would be enough.
> 
> In fact, a lot of people are still using MD5 and IDEA.  The biggest
> problem facing OpenPGP's adoption is the enormous amount of ClassicPGP
> installations out there which are not upgrading because they see no need
> to upgrade.
Ok.... but if MD5 hashes are easily forgable,... it's perhaps not so
clever to keep using those keys...


> ... Also, to anyone who's thinking "wow, 3DES is really good!" after
> reading this: yes, yes it is.  So is AES.  The defaults GnuPG gives you
> are safe.  You don't need to tweak them.
You probably should "correct" the wiki on
http://en.wikipedia.org/wiki/3DES#Usage which claims "Finally, AES
offers markedly higher security margins: a larger block size and
potentially longer keys."


Herbert.