Re: [openpgp] Dealing with clock skew

"Derek Atkins" <> Fri, 15 November 2019 12:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F65A120824 for <>; Fri, 15 Nov 2019 04:03:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B-HBrS6ZqekR for <>; Fri, 15 Nov 2019 04:03:04 -0800 (PST)
Received: from (MAIL2.IHTFP.ORG []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0F65120823 for <>; Fri, 15 Nov 2019 04:03:02 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80C62E2040; Fri, 15 Nov 2019 06:38:13 -0500 (EST)
Received: from ([]) by localhost ( []) (amavisd-maia, port 10024) with ESMTP id 10511-04; Fri, 15 Nov 2019 06:38:06 -0500 (EST)
Received: by (Postfix, from userid 48) id 1C05BE2044; Fri, 15 Nov 2019 06:38:06 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1573817886; bh=4hUH9krsRgR0/Vilyi7nYViMOU07lOHB149aNhUnS3Y=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=G3avkb8MjV3ZyeSFFLAJsdEKRxQVPgG5D+UbqjiqGP7iq0hF8CRTtqlkBfk+TfT/6 qO/jbzmHsmPsByWRjCoXcZzUCIxSQimGDIv7t+v/8fKpCgcvcH8datexXbSV9uzIAK ty1PU4LMwbMbO96W5q3L+mHjK6TLZmv/xu0RduBs=
Received: from (SquirrelMail authenticated user warlord) by with HTTP; Fri, 15 Nov 2019 06:38:06 -0500
Message-ID: <>
In-Reply-To: <>
References: <>
Date: Fri, 15 Nov 2019 06:38:06 -0500
From: "Derek Atkins" <>
To: "Neal H. Walfield" <>
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <>
Subject: Re: [openpgp] Dealing with clock skew
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: Fri, 15 Nov 2019 12:03:06 -0000

Hi Neal,

There is plenty of prior art on dealing with time skew.  Kerberos, for
example, has been dealing with it since the 1980s!  In short, you have a
sliding window of acceptance.  Kerberos sets this as +/- 5 minutes.  So if
the timestamp is within that 10-minute range it is considered current

If you are seeing 20-minute clock skew on a VM, then you should really set
up ntp.

As for your second issue, my questions to you are:
1) are the messages are guaranteed to be in order (or could they be
2) can the validator maintain per-sender state?

If YES to both questions, then the easiest thing to do is maintain the
last timestamp sent and reject if the next message has a timestamp prior
to the last one seen.  Note that this state must be per-sender, so if you
have Alice talking to Bob and Charlie, Alice needs to maintain separate
last-seen numbers for both Bob and Charlie, because their clocks can be
skewed differently.

Hope this helps,


On Fri, November 15, 2019 6:17 am, Neal H. Walfield wrote:
> Hi,
> Our OpenPGP library is being used in an application that does a
> real-time exchange.  Specifically, two MUAs sometimes communicate via
> an imap folder.  During testing, the application developers observed
> that the message exchange would sometimes fail, because a signature
> was considered invalid.
> Eventually, we figured out that the problem was due to clock skew: the
> sender would sign a message at, say, 9:00 and the receiver would
> correctly reject it because its clock said that the current time was
> 8:59, and 9:00, the time stored in the message's Signature Creation
> Time subpacket, is clearly in the future.
> It turns out that a second of clock skew is actually pretty good.  The
> testing was done on a VM and the application developer reported that
> up to 20 minutes of clock skew are not unusual.
> Adding a tolerance seems like a reasonable way to deal with this
> problem.  But, there are situations where a tolerance would cause
> other problems.  Consider, for instance, an application that generates
> messages that contain its current state, and we want to know its state
> at some point in time.  Specifically, consider messages, Ma and Mb,
> and a time T.  If Ta < T < Tb (< current time), then we should use Ma.
> But, if T is significantly close to Tb, we may not reject Mb and use
> it instead!
> An obvious example of this type of message is self signatures.  It is
> tempting to just not use tolerances with self-signatures, but if an
> application generates a key, and immediately sends it to another
> computer, the second computer may reject the key as being invalid,
> because it doesn't consider it to have any valid self-signatures!  So,
> some tolerance is also needed for self signatures.  Also, the example
> also applies to normal ("user data") messages, so specially handling
> self-signatures is not the right approach, anyway.
> Perhaps the best thing to do is to only use a tolerance when asking if
> a signature is valid "now".
> How do other implementations deal with this?  Thoughts?
> Thanks!
> :) Neal
> _______________________________________________
> openpgp mailing list

       Derek Atkins                 617-623-3745   
       Computer and Internet Security Consultant