Re: [openpgp] v5 in the crypto-refresh draft

Peter Pentchev <> Mon, 07 June 2021 11:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FC5B3A3D35 for <>; Mon, 7 Jun 2021 04:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v9IIB-CkdxFy for <>; Mon, 7 Jun 2021 04:46:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CD8E3A3253 for <>; Mon, 7 Jun 2021 04:46:15 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id 1F098125 for <>; Mon, 7 Jun 2021 14:46:12 +0300 (EEST)
Received: from roam (uid 1000) (envelope-from id 6200e2 by (DragonFly Mail Agent v0.13); Mon, 07 Jun 2021 14:46:11 +0300
Date: Mon, 7 Jun 2021 14:46:11 +0300
From: Peter Pentchev <>
To: Peter Gutmann <>
Cc: "" <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6eGISLx4tBDKXnbz"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [openpgp] v5 in the crypto-refresh draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Jun 2021 11:46:30 -0000

On Mon, Jun 07, 2021 at 11:33:54AM +0000, Peter Gutmann wrote:
> Peter Pentchev <> writes:
> >Obviously not speaking for any of the people who actually work on this, but
> >you need to keep in mind that the time field is defined as an *unsigned* 32-
> >bit number, so we'll have another 68 years after the year 2038 to take care
> >of that.
> Except that time_t is signed so it's going to cause breakage if you just
> assign a 32-bit OpenPGP time to a 32-bit time_t.  Making it 64 bits would both
> prevent this and signal to 32-bit time_t users that they need to take special
> care with time values.

Well, if any implementation still uses a signed 32-bit time_t C type in
the year 2038, it will not be able to do anything anyway. ICBW, but is
the point of the standard not to define the wire format, and not
implementation-specific details? An unsigned 32-bit value for the wire
format should be fine for this century.

But maybe I'll just shut up and let the people who have already
discussed modifications to the standard (like you, so yeah, sorry)
say whether anybody has ever raised this before and whether it has been


Peter Pentchev
PGP key:
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13