Re: [tcpm] public-private keys for TCP-AO

"Jakob Heitz (jheitz)" <> Tue, 30 October 2018 01:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A4E11288BD for <>; Mon, 29 Oct 2018 18:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 R1lWU-GASROy for <>; Mon, 29 Oct 2018 18:22:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E3F1912870E for <>; Mon, 29 Oct 2018 18:22:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=16424; q=dns/txt; s=iport; t=1540862540; x=1542072140; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GN66AJOY99fycJz6ltOU2yASku73T16vkt2oEycfrqk=; b=DprhupXZK1U58v5kRr3jZJ+dmlf2+soH/uPY+3N3/aKw79SLavHhe1aw 8scXq4q1WEEUREbR1DTkBaG0LvtBnocV+d2573j6DLQDZMm6dX10sST99 bhNxYx18K1RO2khw3DIgULwfGv8tG7uvr5NwU4hQBTDKzK0EJd49XrRll g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAACYsddb/5xdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDUgvZn8oCoNriBiMGYINkVWFS4F6CwEBGAE?= =?us-ascii?q?KhEkCF4MWITQNDQEDAQECAQECbRwMhToBAQEBAwEBIQpBCxACAQgRBAEBKAM?= =?us-ascii?q?CAgIlCxQJCAEBBA4FCIMagR1kD6lygS6KHQWLSR4XgUE/hCNZgkIBAYIXgk6?= =?us-ascii?q?CVwKOSoYiiUlUCQKQeiCNZoJhlnUCERSBJh04gVVwFTuCbIIlAReIXIU+b4w?= =?us-ascii?q?GgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,442,1534809600"; d="scan'208,217";a="193457499"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 01:22:18 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w9U1MIn1002240 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Oct 2018 01:22:18 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Oct 2018 20:22:17 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Mon, 29 Oct 2018 20:22:17 -0500
From: "Jakob Heitz (jheitz)" <>
To: Joe Touch <>
CC: "" <>
Thread-Topic: [tcpm] public-private keys for TCP-AO
Thread-Index: AdRv51Oca8SVyggpTLame1T3B/a0kQAME/iAAApbkFA=
Date: Tue, 30 Oct 2018 01:22:17 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7597333b9a414761be688375acf48dd6XCHALN014ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tcpm] public-private keys for TCP-AO
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Oct 2018 01:22:22 -0000

Can you think of a way to do it that will work?
Like the KDF is just a static list or something.
The sender generates a set of key pairs and numbers them.
It then puts the list of public keys into a file and distributes them to all receivers in the clear.
The KDF is just to index into this file.

Because the use case, at least, makes sense.


From: Joe Touch <>
Sent: Monday, October 29, 2018 6:13 PM
To: Jakob Heitz (jheitz) <>
Subject: Re: [tcpm] public-private keys for TCP-AO

On Oct 29, 2018, at 5:45 PM, Jakob Heitz (jheitz) <<>> wrote:

Why was there not a public-private key algorithm specified for TCP-AO? Or did I miss it?

There has not been. I doubt it would make sense (see below).

For example ECC.
An MKT can specify a private key for the sender and a public key for the receivers.

Yes, but the MKT is derived into public/private keys using a KDF.

I am not aware of a KDF that can take a private key and generate a derived private key that would work with a correspondingly derived public key generated from the corresponding public key.

To use, the sender will hash the data, encrypt the hash and put the result into the MAC field.
The receiver would decrypt the MAC field, then hash the data and verify the hash against the decrypted MAC.
This way, the private key never needs to be exposed to anyone, simplifying key management.
Is there any objection to getting this done?

See above; it doesn’t make sense with the way TCP-AO derives keys for each connection, AFAICT.



tcpm mailing list<>