On Fri, 27 Aug 2010 16:57:56 +1000, Ian G <iang(_at_)iang(_dot_)org> wrote:
There is a cost to supporting more algorithms - interoperability. In
practice, this cost is greater than any marginal benefit gained by
introducing additional algorithms. (I claim, IMHO)
Of course,.. that's why I wrote that this has advantages in my initial
post.
But we already request conforming implementations to support a least
common subset of algorithms, and the preference mechanism should do the
rest IMHO.
I'd rather suggest on a mid-term-scale to add new ones the required algos,
e.g something like:
DSA -> RSA (or DSA2)
3DES -> AES
For example, we don't have much experience of algorithms being crunched.
Even the old TDES is pretty strong, and while MD5 is looking shaky, it
hasn't in practice resulted in much more than embarrassment and
arguments. Users have not lost because of these choices.
In contrast, we have a lot of experience with users not being able to
use additional algorithms, because one user has it but others do not.
Most of this reduces to using the compulsory set, but some of it reduces
to not using crypto at all.
Ok all true,.. but again,.. as far as I understand the system...
preferences and the least required algorithms should solve all this.
Even for those implementations of OpenPGP which don't support the
bleeding-edge.
(Also there is the cost of coding it up, and the weakness inherent in
having switches in the code, where without the alternatives there would
be no switching.)
Agreed... but IMHO,... using a variety of ciphers (I don't mean at the
same time here) could be even an advantage for security.
Of course the non-mainstream algos are less analysed like e.g. AES, but
this of course also means, that attackers know probably less about them.
This is a tricky area. By trying to create a stronger cipher (and that
is what you are doing, combining A + B to make cipher C) you are putting
yourself above the cryptographers ... who presumably tried to make A and
B quite strong already.
That was my idea,... just without the putting myself over the
cryptographers ;)
mmmm possibly. I wrote a while ago that (IMHO) we should not try and
fiddle with the current OpenPGP structures, instead we should finish the
RFC ... then start a complete rewrite.
Sounds nice to me,... although I wouldn't completely throw away with what
we have.
And I don't mean (of course) the semantics behind our PKI (which I
consider far superior to the X509 PKI), but also the technical stuff like
byte format etc.
And it would have to be possible to use the new one with the old one.
Perhaps even more possible representations (XML in addition to the current
ones)... lots of possible ideas (of course not all worth their efforts ;) )
Cheers,
Chris.