On Fri, 27 Aug 2010 10:51:10 -0700, Jon Callas <jon(_at_)callas(_dot_)org>
wrote:
I'll be just a bit softer than Werner. The obstacle to your suggestion
is
adoption.
Of course,.. and if Werner as lead developer behind one of the tow major
implementations (the major in opensource) says "no",... than things are
pretty clear, that any work towards it would be rather wasted.
On the other hand, so what? Your name on an RFC is a resume-builder. And
you could code it up yourself. If a real break comes to AES, you could
end
up looking prescient.
Well it's not my intention to become "famous" or so ;)
It's just that I (and I really like OpenPGP in contrast to its
"competitors") see three problems (be aware that, while having visited
some
crypto lectures when I studied,... I'm by far no expert):
- IMO the current standard is too lax in many aspects, or not clearly and
strictly enough.
Of course the major implementations are simply doing the right thing
usually... so this is rather a formal problem than a real.
Guess there is not much need to elaborate this again,.. I've already
discussed some parts of that here before,...
- It could easily happen that we sleep to long on our success and at some
day we get into real trouble when something (e.g. SHA1) is broken (or at
least much closer to be so than now) and we have no alternatives up and
working. That's also why I personally think it would be a good idea to
have
alternatives like Serpent,...
Even though unlikely that this happens soon or from one day to the other,
just imagine that AES might get broken.
The only alternatives now would be Twofish, 3DES and Camellia.
And as you said yourself, it can take very long as new things are adopted
in the real world.
That's also why I'm very pleased about the ID on ECC,... having it sooner
than later available makes me sleep much better.
If you take for example the suggested keysizes (http://www.keylength.com/)
you already see that there are sources suggesting sizes far beyond the
4096
for the long term scale.
- As again noted about, OpenPGP could offer much more attributes to be
signable. At best using strings for each attribute type, e.g. things like
ietf(_at_)name(_dot_)surname or so for "official" ones,... and
org(_dot_)example(_at_)someSpecificAttribute for everybody).
Looking at mainstream server SSL, OpenPGP already lost against X.509. But
there are still many communities where OpenPGP is mainly used.
However, just having username/email is often not enough for them.
Can tell you from the LHC Grid community,... where we're using X.509
because we need to store additional attributes in the certificates.
OpenPGP is designed to be to be welcoming to new algorithms -- all you
need is a new algorithm number, really. But it's also designed to have
easy
rejection of algorithms that individuals or the community don't like.
The
algorithm preferences and negotiation ensures that no sender can ram
something down a receiver's throat.
Of course,.. but again,... little use when the majors have no intention
anyway.
The upshot of this is that if *you* want to use Serpent and some new
compression algorithm and other things, you can. But if you want *us* to
do
it too, then you have to convince us.
Well,.. guess I've already tried that. May main argument are probably the
advantages of diversity.
But I can understand Werner's arguments, that one would have to maintain
the code (which opens the window for security problems), that e.g. Serpent
is less analysed than the mainstream AES, etc. pp.
Cheers,
Chris.