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
implemented algorithms.
Not only for ciphers, but also e.g. compression algorithms (supporting
XZ would IMHO make sense).
If you wanted to write an RFC for Serpent, go for it. Look at the one
for Camillia as a guide and plagiarize all that you need.
Well a) I'm not sure whether David would be very happy if I plagiarize
his work ;) b) I don't consider myself to be enough of a crypto-guru
and/or expert in the RFC/ID writing mechanisms to do that c) without
support form the community/WG,... this has rather limited changes (IMO).
Another issue, which comes just in my mind.... would it make sense
to
add support for stacked encryption?
I mean, having a literal packet encrypted with a symmetrically
encrypted
data packet say with cipher A, which in turn is encrypted with
another
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
OpenPGP components.
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
scale.
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).
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.
- PBKDF2
- 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
possible ambiguities.
- 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.
Cheers,
Chris.