Herbert Furting 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).
There are two responses here:
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.
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.
> 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.
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.
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.
In reality, GnuPG is guided by concerns beyond just strict RFC
conformance: interoperability, ease of use, and others.
> 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:
--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.
> 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.
> Uhm,.. is there any reason why gpg doesn't support it?
Yes. Because you haven't written a patch for 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?
You're ascribing magical meanings to things. You're not going to be
safer under your scheme. It's different--it's not better.
I don't know why GnuPG does it this way. I strongly suspect it's for
historical reasons and interoperability concerns.
> those fall-back-algorithms, it just says they should. So when a user
> wishes not to include e.g. 3DES it should clearly mean...
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.
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". They're going to say "oh,
you're using a badly-written OpenPGP implementation, here, let me fix
that for you."
> 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.
>> 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.
Speak for yourself. My personal-cipher-preferences has 3DES explicitly
listed as my first preference.
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?
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:
* 10^9 known plaintexts
* 10^34 operations
* 10^27 DES decryptions
* 10^14 terabytes of memory
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.
So please, explain to me: why do you want to be warned when you receive
3DES traffic?
> 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 insist that GnuPG include Rijndael and
SERPENT. Because...
... 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. 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.
> Why did we change the fingerprint algo to SHA-1?
Because Hans Dobbertin kicked MD5 to the curb and went through its
pockets looking for interesting bits of number theory.
> Ok MD5 is much weaker than SHA1 (as 3DES is probably weaker than AES)
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. 168 bits of
effective 3DES key versus 128 bits of AES key--which wins? Past a
certain point additional key length ceases to matter.
> 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).
Because 3DES is slow, inefficient, and doesn't work well on very small
computers. Really. That's the reason.
AES is fast, efficient, and works well in a whole lot of different
environments. That's why we love AES; it's a great tool across a very
broad swath of the problem domain.
3DES is a more limited tool. There are certain parts of the problem set
where you just don't want to use it.
Email is not one of these certain parts. There is no compelling reason
to avoid using 3DES for email, unless you often send very large
encrypted files.
> ... 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.
... 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.
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
