Re: SERPENT in OpenPGP?

Christoph Anton Mitterer <calestyo@scientia.net> Fri, 27 August 2010 20:00 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7RK0RF5014976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Aug 2010 13:00:27 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id o7RK0RZk014975; Fri, 27 Aug 2010 13:00:27 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mailgw01.dd24.net (mailgw01.dd24.net [193.46.215.41]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7RK0PO1014968 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <ietf-openpgp@imc.org>; Fri, 27 Aug 2010 13:00:26 -0700 (MST) (envelope-from calestyo@scientia.net)
Received: from localhost (amavis01.dd24.net [192.168.1.111]) by mailgw01.dd24.net (Postfix) with ESMTP id 739287CCC02 for <ietf-openpgp@imc.org>; Fri, 27 Aug 2010 20:00:24 +0000 (GMT)
X-Virus-Scanned: domaindiscount24.com mail filter gateway
Received: from mailgw01.dd24.net ([192.168.1.191]) by localhost (amavis01.dd24.net [192.168.1.105]) (amavisd-new, port 10191) with ESMTP id 4+tDUJe4IGX8 for <ietf-openpgp@imc.org>; Fri, 27 Aug 2010 20:00:20 +0000 (GMT)
Received: from webmail.dd24.net (webmail01.dd24.net [193.46.215.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA id 0588D7CC8A9 for <ietf-openpgp@imc.org>; Fri, 27 Aug 2010 20:00:20 +0000 (GMT)
MIME-Version: 1.0
Date: Fri, 27 Aug 2010 20:00:15 +0000
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: ietf-openpgp@imc.org
Subject: Re: SERPENT in OpenPGP?
In-Reply-To: <83BF96BC-A771-4511-B431-9B9B1545E351@callas.org>
References: <1282856536.11340.29.camel@fermat.scientia.net> <87pqx4mm0b.fsf@vigenere.g10code.de> <04ac7894a29b891da7cbde98adb287e5@imap.dd24.net> <83BF96BC-A771-4511-B431-9B9B1545E351@callas.org>
Message-ID: <49ee22eb2e5747f077b3bc885f197083@imap.dd24.net>
X-Sender: calestyo@scientia.net
User-Agent: RoundCube Webmail/0.3.1
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, 27 Aug 2010 10:51:10 -0700, Jon Callas <jon@callas.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@name.surname or so for "official" ones,... and
org.example@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.