[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SERPENT in OpenPGP?
Just all IMHO...
On 27/08/10 8:41 AM, Christoph Anton Mitterer wrote:
On Thu, 2010-08-26 at 15:00 -0700, Jon Callas wrote:
OpenPGP has Twofish, for which pretty much all the same things can be
said. If you don't like AES, you should likely be using Twofish or
Serpent. OpenPGP happens to have Twofish in it.
Yes I know...
Just don't see the reason why OpenPGP is rather conservative with it's
Not only for ciphers, but also e.g. compression algorithms (supporting
XZ would IMHO make sense).
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)
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.
(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.)
For all these reasons, the history of "algorithm agility" has been
rather fun for developers and rather a headache for users. For the
users, there is an aspirin:
For the developers, there are other fun intoxicating things to work on ;)
Another issue, which comes just in my mind.... would it make sense
add support for stacked encryption?
I mean, having a literal packet encrypted with a symmetrically
data packet say with cipher A, which in turn is encrypted with
symmetrically encrypted data packet say with cipher B.
Of course the session key packet would have to be large enough to
provide key material for both.
What problem are you trying to solve? People have done that before.
You could build this up in an only slightly klugy manner with existing
No specific, problem,... I'd just like to see that OpenPGP allows for
even more higher-grade security. I mean really for a very long time
In in case one cipher is broken (ok I know that this is rather unlikely)
the other ciphers might be still safe (when multiple are used).
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.
( I for one do that all the time -- put myself above the cryptographers.
But only in my area of expertise, which is computer science, and not
in their area of expertise, which is cryptography! :)
I have seen this done with AES and another algorithm XOR'd in parallel.
The conjecture is that it is then stronger than either alone. E.g.,
if one breaks.
But this is just conjecture. Such a claim is not easily distinguishable
from developers having too much fun....
Unfortunately, OpenPGP development seems to be quite slowed down to me.
Of course this has advantages but on the other hand I'd like to see many
things that were previously discussed here, e.g.
- phasing out SHA1
- ECC (ok this is on its way :) )
- some of the ideas presented in the threads "Series of minor questions
about OpenPG" here, especially:
- making the standard more strict in several aspects and work against
- much more use of the user attribute packet (which IMO should replace
the User ID packet on a long term scale), adding _many_ possible values
that can be signed,... e.g. things like brithday (time), birthplace,
color of eyes ;) ... much more types of names (a common name which would
be about what we have right now in the user ID, family name and given
name (for western contries), other types for different cultures) ... I
could even think of stuff like address and so on.
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.
The reason for this is that OpenPGP includes the best of our
understanding from a long time ago. Around PGP 5, etc.
And in the last decade we've learnt a lot more ... which we're probably
missing out on if we spend another decade tuning PGP 5 :)