Re: RFC: DSA key lengths; Elgamal type 16 v. type 20

Jon Callas <> Sun, 25 August 2002 07:00 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id DAA04981 for <>; Sun, 25 Aug 2002 03:00:40 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by (8.11.6/8.11.3) id g7P6sLd17590 for ietf-openpgp-bks; Sat, 24 Aug 2002 23:54:21 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g7P6sJ217585 for <>; Sat, 24 Aug 2002 23:54:19 -0700 (PDT)
Received: from [] ( by with ESMTP (Eudora Internet Mail Server 3.1.2); Sat, 24 Aug 2002 23:54:11 -0700
User-Agent: Microsoft-Entourage/
Date: Sat, 24 Aug 2002 23:47:39 -0700
Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20
From: Jon Callas <>
To: "Brian M. Carlson" <>, OpenPGP <>
Message-ID: <>
In-Reply-To: <20020824220506.GC12225@stonewall>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 7bit

On 8/24/02 3:05 PM, "Brian M. Carlson" <> wrote:

> I'd like to nitpick for a second. Section 12.6 states, "Note that present
> DSA is limited to a maximum of 1024 bit keys, which are recommended for
> long-term use." Actually, it is DSS (the *standard*), not DSA (the
> *algorithm*) that is limited to 1024 bits. I'd like to suggest that we
> replace that sentence with, "DSA keys SHOULD NOT exceed a size of 1024
> bits." This way, we can maintain backwards compatibility and compliance
> with DSS, while providing adequate security for people who really want
> it. Might I point out that IEEE P1363 allows for DSA keys longer than
> 1024 bits, so there is precedent in the cryptographic community.

So far as I know, DSS or DSA, or whatever, mandates SHA-1. What hash
algorithm does P1363 use with longer keys? What semantics does it have to go
with it?

> I'd also like to suggest that we deprecate Elgamal type 16 in favor of
> Elgamal type 20 combined with key flags. This is exactly what we did with
> RSA types 2 and 3. It encourages implementations to implement key flags,
> and it will lessen the usage of an encrypt-only type. It still allows
> implementations to maintain backwards compatibility, because it does not
> remove the type altogether.

Well, there are people who believe that Elgamal signatures should be
deprecated, and were a mistake to put in the standard to begin with. I think
it's better to leave it as it is and let gentle persons continue to