Subject: Simplified OpenPGP

From: [email-masked] ("Hal Finney")
Date: Tue, 6 Nov 2007 15:04:49 -0800 (PST)

My personal biggest wish list item is one we have discussed before. We
need to do something to make OpenPGP easier to implement. IMO we need
to rationalize and simplify our data structures. Too many warts have
grown up over the years in the name of backwards compatibility and
over-optimization.

I see two directions we could go. The first is to specify an OpenPGP
subset. We would remove as many of the alternative ways of doing things
as possible: "Old" packet headers. String2Key specifiers other than
salted+iterated. Non-MDC'd encryption packets. Unprefixed symmetrically
encrypted packets. Signature packets without 1pass headers.

The goal is to create a subset of OpenPGP which is backwards compatible in
that messages created in this subset can be read by old OpenPGP clients,
but not vice versa. The most widely used OpenPGP clients that participate
here can be updated to only create in the subset. Then new implementors
can ignore some fraction of the spec, making their job somewhat easier.

However as the list above illustrates, this only gets us so far. We need
to consider the essence of OpenPGP as being the options and crypto, and
not the specific data formats. Imagine the set of transformations that
could be executed reversibly by a straightforward program that converted
between traditional and simplified formats. It would not understand crypto
at all, but it would just do a reversible transformation into some other
form. Of course it could not change the plaintext of encrypted packets,
but imagine that this transformation program could be hooked into the
encrypt/decrypt pipeline and apply as well to plaintext.

My point is that creating a new OpenPGP format which is interchangeable
with the current one via such a program would not be a semantic change to
the OpenPGP spec, merely surface syntax. I am not proposing that such a
program would exist, rather that the existence of such a transformation
would guide and constrain the kinds of syntactic changes we should
consider.

This would allow us to get rid of the whole concept of old and new packet
headers, and instead define a simple and extensible header concept, that
can support either prefixed-length or dynamic-length packets.  We can
fix our other data structures to simplify parsing and packet creation.
The hodgepodge of different ways of specifying lengths, the kludges
related to secret key packet encryption, over-optimized bitfield packing,
can be streamlined.

I don't see creating a new specification based on these principles
as an enormous task. It is merely another way of encoding the same
information that is already described in the spec. Ideally we could
make this change independently of other proposed extensions to OpenPGP
semantics or cryptography.

Several problems remain. How would we make a transition to using a
new and completely incompatible format? And what about legacy messages
and keys? Some keys have expiration dates decades in the future; key
signatures using current packet formats were expected to retain their
validity for that long. We can't change packet formats on signed data
without breaking signatures.

These appear solvable. We can handle the switchover exactly as we have
handled the introduction of other incompatible changes such as new packet
types. At first we support both versions and create one or the other kind
of message depending on clues about the recipient, like the vintage of
his key. At some further point we start using the new formats 100%.

As far as legacy data: First, expectations of multi decade validity of
signatures may be unreasonable due to the inherent relative weakening
of cryptography as time passes. In practice it may be acceptable to
demand that signatures get re-issued periodically to confirm their
validity. However in the mean time we would still have a number of years
in which such expectations would be arguably more reasonable, and we
cannot realistically just start ignoring today's signatures any time soon.

In that case it may be helpful to consider the transformation program I
described above not just as a figure of speech to motivate the distinction
between semantics and syntax, but as an actual tool. Perhaps an open
source version of such a program could be created and distributed
which could turn an OpenPGP message of one format into the other. Then,
keys and signed messages could be transformed into the new format and
stored in that way, and when it was time to verify them they could be
automatically transformed back.

Well, this message has become quite a bit longer than I intended. I don't
claim to have all the answers, and there may be other objections which
make the idea untenable. But if we think of this standard as something
which will last for decades, as I would suggest we should, maybe it makes
sense to make changes now which will bring benefits for many many years
to come.

Hal Finney

---

From: Ian G <[email-masked]>
Date: Wed, 07 Nov 2007 12:37:04 +0100

> grown up over the years in the name of backwards compatibility and

I don't need to read any further to know that it gets my vote!

(But I will anyway.)

iang

---

From: "Arturo 'Buanzo' Busleiman" <[email-masked]>
Date: Wed, 07 Nov 2007 08:57:27 -0300

> I don't need to read any further to know that it gets my vote!

I read it from head to tail, and I quite like the idea. Given how big is getting OpenPGP, a
simplified, well-defined subset is an important need that will open the doors to more OpenPGP Mobile
and embedded implementations, and will also be (on a personal note here) of great use for the
OpenPGP Extensions to HTTP I'm working on.

- --
Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica
Servicios Ofrecidos: http://www.buanzo.com.ar/pro/
Unase a los Foros GNU/Buanzo - La palabra Comunidad en su maxima expresion.

---

From: Werner Koch <[email-masked]>
Date: Wed, 07 Nov 2007 13:37:43 +0100

> can ignore some fraction of the spec, making their job somewhat easier.

I agree to define a subset for a minimal implementation.

However I don't think we will ever be able to drop all of the old cruft
from the specs.  Too many data has been encrypted and signed using
OpenPGP and thus there is a real need to be able to process such data.

BTW, the bit twiddling we use and the various ways of encoding packet
headers are still much simpler than the X.509 or CMS way of describing
and encoding things.  Creating a fully compliant OpenPGP parser is not a
big task and actually very simple code.  Compare that to a full BER/DER
parser as required by X.509/CMS.

> information that is already described in the spec. Ideally we could

That would not be anymore OpenPGP but a new protocol.  I doubt that
there is a community interest in doing so.  CMS is getting used more and
more and OpenPGP already has a hard time to stand up against CMS.
Adding a new variant of OpenPGP would be the death for it.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.

---

From: Jon Callas <[email-masked]>
Date: Wed, 7 Nov 2007 11:20:27 -0800

I also agree this is a great idea. It's one of those things I wanted  
to do a decade ago.

What we're talking about is creating a *profile* of the base  
standard. The idea is that in general, you stick to the profile, and  
the profile allows less work on implementers. If the profile is  
successful in the wild, you can start deprecating the other features.

Here are some things I might put in a profile:

* Use only new-style headers and 5-byte lengths.

* Use only AES-128 or AES-256. You have to implement 3DES, but don't  
use it.

* Use only RSA 4096 bit public keys

* Use SHA-256 and SHA-512 only.

* Never use anything but an iterated-and-salted S2K.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Thu, 08 Nov 2007 08:38:44 +0100

> * Use only RSA 4096 bit public keys

it is not a real problem for a modern desktop box but for small or
embedded devices it is not going to work.  There are also no smartycards
in the foreseeable future that will support such a key length.  Before
settling on this we should investigate ECC based algorithms.

Salam-Shalom,

   Werner

---

From: Jon Callas <[email-masked]>
Date: Thu, 8 Nov 2007 00:54:37 -0800

> settling on this we should investigate ECC based algorithms.

Then pick a different size. I picked 4096 because it's big and apt to  
stay viable for the forseeable future. NIST's numbers say that 3072  
is equivalent to a 128-bit key. On the other hand, I know there's  
still a lot of smartcards and the like that are stuck at 2048. I  
wouldn't go below 2048.

	Jon

---

From: Hironobu SUZUKI <[email-masked]>
Date: Thu, 08 Nov 2007 18:51:38 +0900

> still a lot of smartcards and the like that are stuck at 2048. I  

I agree. Simplified OpenPGP should be just simplifed, I mean it is not
used for financial B2B online service or so on.

   AES 128 / SHA256 / DSA 2048-224 / RSA 2048 / ECC 224

I think it is enough for a sort of casual cryptographic usage for next
ten years.

Regards,

---
Hironobu SUZUKI <hironobu at h2np dot net>
Tokyo, Japan.
http://h2np.net

---

From: Ian G <[email-masked]>
Date: Thu, 08 Nov 2007 17:42:08 +0100

Jon Callas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 

Again, violent agreement.

I would say that the core OpenPGP thrust should be to create 
the profile for the biggest 800lb gorrilla market, which is 
the Intel-based PC.  It's been the big platform for the last 
25 years, and will be for the foreseeable future.  Which has 
plenty of power to spare.

So picking RSA and 4096 sounds good as a pencilled-in number 
for now.  SHA-3 when it turns up.  AES-256.  Some new mode 
that is to be chosen in future violent & agreeable debate.

Then, for the mobile guys, let them form a subgroup to 
create the "mobile profile."  It will be completely 
different, and "weak" by the standards of the main group. 
No problem, different model.

I am a great believer in one entire suite of algorithms 
melded together as a cohesive whole.  No agility within.  So 
I think the way forward is to pick a spot in the future, and 
create a great combination for then.

And then stick to it.  I say more on my singular view here:

https://financialcryptography.com/mt/archives/000983.html
http://iang.org/ssl/h1_the_one_true_cipher_suite.html

which reflects the good old days of pgp 2 :)

iang

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 09 Nov 2007 14:29:34 +1300

Hironobu SUZUKI <[email-masked]> writes:

>Simplified OpenPGP should be just simplifed, I mean it is not used for
>financial B2B online service or so on.
>
>I think it is enough for a sort of casual cryptographic usage for next ten
>years.

Sounds good, with one minor nitpick: I'd recommend combining DSA 2048 with
SHA256, SHA224 is an oddball hash algorithm that seems to be rather poorly
supported (compared to the mainstream SHA256/512), and if you're requiring
SHA256 anyway there's no good reason not to just use that with DSA.

Peter.

---

From: [email-masked] (Daniel A. Nagy)
Date: Fri, 9 Nov 2007 14:50:22 +0100

Here are my thoughts on simplified OpenPGP.

I don't think that there is one size that fits all. I think, we need at
least three profiles:

1. Backwards compatibility profile.

3DES, SHA1, RSA2048 (for both encryption and signature)

This is supported by most software and hardware and is reasonably secure.

2. Lightweight/mobile profile.

Mobile considerations:

Communication costs over GSM networks are measured in the multiples of 140
bytes (or 1120 bits), which cost about €0.10.

Asymmetrically encrypted session keys are equal to the public key length for
RSA and twice that for ElGamal.

Digital signatures are the size of the public key for RSA, and twice the
size of the hash function for DSA variants. El-Gamal sitnatures weight twice
the public key length, but that is irrelevant because there is no advantage
in using El-Gamal over DSA.

Randomness available in mobile phones is typically very poor. The reference
implementation of SSL for mobiles has recently been broken because of that.
Now, DSA signatures can reveal the private key(!) if the randomness source
they use is bad. Thankfully, mobile SSL uses RSA signatures, thus poor
randomness only hurts confidentiality but does not reveal any private key or
theaten authenticity and integrity.

As you can see, some of these considerations are in conflict. My take is
that we should play it out in the real world and standardize on what works
best later.

3. General PC profile.

Go for Pareto-complete algorithms, with over-designed symmetric
parameters (because those are much cheaper):

AES256, SHA512, RSA4096 (for both encryption and signature)

Any news on algebraic attacks on AES?

-- 
Daniel