Re: SERPENT in OpenPGP?

[Ian G <[e-mail]>]

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
> implemented algorithms.
> 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:

http://iang.org/ssl/h1_the_one_true_cipher_suite.html

For the developers, there are other fun intoxicating things to work on ;)


>>> 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).


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.
> - 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.


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 :)

iang