Miscellaneous questions

[Christoph Anton Mitterer]

Dear David.

On Tue, 2008-04-15 at 17:54 -0400, David Shaw wrote:
> > > 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.
> Not exactly.  It contains what the user prefers **among the algorithms
> that his implementation supports**.  It's the intersection of the
> algorithms the user prefers for one reason or another and the
> algorithms that his implementation supports.
I first must admit that it was my idea,... to use the preference
subpackets that way (I mean that they should only represent the
preference of the user).
But I also agree that this is not really implied by the standards (I'll
suggest the WG to consider a change of this), but on the other hand:

>5.2.3.7.  Preferred Symmetric Algorithms
>
>
>   (array of one-octet values)
>
>   Symmetric algorithm numbers that indicate which algorithms the key
>   holder prefers to use.
That would support my idea that it's only the user preference.

>  The subpacket body is an ordered list of >   octets with the most
preferred listed first.  It is assumed that only >   algorithms listed
are supported by the recipient's software. That just says that no
algorithms are listed which the implementation does _not_ support.
While this is a good decision for the average user, it should not be
forbidden to list an algorithm, even if not supported by one's own
implementation. But it does not say that it has to contain the
must-have algos. Thus I think that my idea of the meaning of those
packets is not only possible, but (because of "Symmetric algorithm
numbers that indicate which algorithms the key holder prefers to use.")
even logical.

>   Algorithm numbers are in Section 9.  This is only found on a self-
>   signature.


But of course there are the notes at the end which (in my opinion) lead
to the current usage of those subpacktes:

>Since TripleDES is the MUST-implement algorithm, if it is not
>explicitly in the list, it is tacitly at the end.  However, it is
>good form to place it there explicitly.  Note also that if an
>implementation does not implement the preference, then it is
>implicitly a TripleDES-only implementation.
I think this passage is very strongly influenced from a developers view:
Tacitly (implicit) at the _end_ simply says,... by putting 3DES at the
end we automatically have a fallback if no other algorithm is found,
without the need of any code.


What it all comes down to is, I agree with you that this section is a
hint for your cited use ("It contains what the user prefers **among the
algorithms that his implementation supports**."), but I still think that
my idea would be a cleaner approach as it separates different things.
I'll suggest this to the WG.

Even if those subpacktes would be used in my suggested way, each
implementation would know "Nanana, 3DES is a fallback, so in each case I
can find my algorithm match", but in addition to that a user could force
his implementation (via a non conforming switch) to ignore that fallback
stuff, and just look at the preference. If he'll have problems with this
(interoperability) it's his own problem.

And of course each implementation should (at least for the average user)
allow only to add algos that it supports (or at least make some heave
noise if the users decides to add unsupported algos).

What do you think?





> > 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.
> It will work.  It's foolish and you'll hurt yourself doing it, but it
> will work.
While I don't want to disturb Herbert's questions I'm interested in
this, too:
Of course such a key might not work with some not conforming
implementations and is perhaps fools from that perspective. As far as I
understand, when the implementation fully conforms to the RFC this MUST
work.

But I'd like to know it this leads to improved security or not:


If I understood it correctly all the selfsigs go directly over the
keymaterial (+UID or subkey material or so), right? As far as I
understood, e.g. SHA512 are considered to be better than SHA1 (meaning
it's not "so easy" to find collisions), right?

So it should be more
difficult to attack an SHA512 selfsig than and SHA1 selfsig?


One might argue that an attacker could still try a downgrade attack but
then he'd have to hack the signature algorithm itself (e.g. RSA) which
is the same for SHA1/RIPEMD160/SHA512/etc sigs.
So the danger of a downgrade attack is equal for all of them, right?
But if we hope that nobody is able to efficiently hack RSA, then
selfsigs with "better" hash function should be more secure against
attacks, or did (and if so what) I understand this wrong?

btw: I assume that this is the reason why Herbert would like to revoke
his SHA1 selfsigs, because as long as they're valid,.. the whole idea
brings of course nothing.


> > 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.
> This is another thing that GPG will accept from the outside, but not
> generate itself.
Ah nice to know,.. the WG list will probably the right place to discuss
if some of the subpacktes should be allowed only on some types of
subpacktes. So I hope to see you there (in a few days or a week or
so ;) ).


> > Which one is chosen now? But when I only include AES256 I can at least
> > somewhat control it.
> No, you can't.  If you only include AES256, your preference list is
> effectively "AES256, 3DES".  You can't get rid of the 3DES.
Ok in fact this belongs also to the WG,.. but (apart from the fact that
I'm really unsure if I like the idea of must have algos at all - in each
case they have some very practical use) it would be an idea, to change
them or at least add some other must haves.

As Robert already pointed out,.. one big advantage of AES is its speed.
So i assume that a lot of especially embedded devices will only support
AES,.. so this might become the de facto standard (or it even is it
already).


Thanks in advance for your insight :-)
-- 
Dipl.-Inf. (FH) Christoph Anton Mitterer

eMail:
christoph.anton.mitterer at physik.uni-muenchen.de
mail at christoph.anton.mitterer.name

Jabber/XMPP:
chat at christoph.anton.mitterer.name

Ludwig-Maximilians-Universität München
Lehrstuhl für experimentelle Physik – Elementarteilchenphysik
Sektion Physik
Am Coulombwall 1
85748 Garching bei München
Germany