Miscellaneous questions

[Herbert Furting]

On Mon, 2008-04-14 at 12:19 -0500, Robert J. Hansen wrote: 
> > 1) When creating a new UID, why does gpg have a minimum size of 5
> > characters? This is not imposed by RFC4880? Where can I report this bug.
> It's not a bug.  It's a deliberate design decision on the part of the
> GnuPG authors.
Uhm,.. apart from the answer from David (who told me the correct
parameter) I don't think that an implementation should forbid this
(making UIDs smaller than 5 characters).
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.
I'd be happier if it would clearly say, that it's just an ID that
identifies the user (as the packet name says) but that most people use a
mail name-addr.
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.


> > 2) I have a key that is already published to keyservers. Unfortunately
> > it uses old SHA1 as hasing algorithm.
> I would not recommend this sort of brain surgery on a key.  If you're
> that concerned about the use of SHA1, I would suggest just generating an
> entirely new key that is entirely to your specifications.
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).


> > How can I change this in gpg, that it puts these on 0x1F?
> Hack the source.
Uhm,.. is there any reason why gpg doesn't support it?
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?


> > 5) Last but not least,... when setting the algorithm preferences gpg
> > always automatically adds 3DES, SHA1 and uncompressed. I now that all of
> > these are must-implement algorithms. But RFC4880 does not say, that the
> > preference subpacktes must include them. It just says it's good behaviour.
> > I think the export mode should allow it to not have them set.
> Why?  Your reason doesn't make sense.
Why not? The RFC (and even the meaning of the name "preference packet")
say, that these subpackets are a way for the user to express his
preferences on alorithms. It does not say that they have to include
those fall-back-algorithms, it just says they should. So when a user
wishes not to include e.g. 3DES it should clearly mean,.. I don't like
that algorithm, despite the fact, that his implementation has to
support it.

What the authors of RFC4880 had probably in mind when saying this is a
best practise (at least I think so,.. David?! ;) ) was: As every
implementation has to support it,...put it in the list. But this packet
is not about specifying what an implementation is able to do, but what
the user would like to have. I think they were tempted by the fact,
that a preference list that contains the must-have algorithms could be
used easier for algorithm-negotiation.


> > the preference subpacktes, I make a statement like saying: I don't care
> > what RFC4880 says,.. I consider 3DES as unsafe for my needs and won't
> > accept anything using it... same idea goes with the hashing algorithms.
> Sorry.  This is not a statement about anything other than "I'm not
> following RFC4880's best practice".
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.

But the implementation already knows about that minimal must-have
subset (because of the standard).
It's not necessary to mix it up with the users preference. 


> If I see that you're omitting 3DES from your preference list, I'm not
> going to think you're making a statement about 3DES.  I'm going to think
> you're not following RFC4880's best practice.  Other people in the world
> are not telepathic, cannot read your mind, and cannot rationally infer
> what you want us to infer.
See above.

> I will happily send you 3DES traffic
Yes, but that's already the case because each implementation must
support 3DES, not because you or me put it in our lists.


> regardless, since it happens to be a high preference of mine and it's
> automatically going to be on yours.
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.


> Incidentally, if you can't articulate solid cryptanalytic reasons why
> 3DES is an unsafe choice for you, you really shouldn't be arguing
> against 3DES.  There's a joke I often tell the undergrad computer
> security course here--"3DES: turning brilliant young graduate students
> into burned-out alcoholic wrecks since 1974."
> 
> 3DES has all the aesthetics of a Soviet worker's housing bloc, and just
> as much durability.  It is quite slow by modern standards, but it is
> ridiculously overdesigned for its task--_ridiculously_ overdesigned.
> 
> If there are attacks against 3DES you're worried about, then please
> share them with the rest of us so we can be better-informed.
Well then why does OpenPGP allow us to use newer algos? Why did we
change the fingerprint algo to SHA-1? Ok MD5 is much weaker than SHA1
(as 3DES is probably weaker than AES) but for "normal" people it should
still be impossible to forge MD5 hashes, and if an intelligence service
wants your data,.. they simply kidnap and torture you.

To be honest,.. I don't see your arguments above,... apart from the
fact, that I didn't asked about the pros and cons of algorithms. Why do
we make the whole crypto stuff,... if we stick with old algorithms
(probably weaker than newer ones).


> > implementation does) I don't want,.. that anybody sends me uncompressed
> > data,.. because I fear those attacks.
> If you're this concerned about cryptanalytic attacks, I have to ask how
> many heavily-armed Marines you have guarding your key.
Well,.. I have a fighter australian parrot ;-)
...

> You're talking
> about adding more armor plating to the vault door of your home.  An
> attacker is most likely going to pick up a chainsaw and just cut through
> the wall.
... 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.

Regards,
Herb.