Re: [Cfrg] Outline -> was Re: normative references

Watson Ladd <> Thu, 16 January 2014 21:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3F0121AC85E for <>; Thu, 16 Jan 2014 13:17:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N-9yy9llXEK0 for <>; Thu, 16 Jan 2014 13:17:02 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::22d]) by (Postfix) with ESMTP id 257151AC4AB for <>; Thu, 16 Jan 2014 13:17:01 -0800 (PST)
Received: by with SMTP id d13so5846725wiw.6 for <>; Thu, 16 Jan 2014 13:16:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rXpjT/SU3sxQ++ze26Jh+LAgW+/uNoB1yGD0ExHAvC0=; b=A8JvO3dGMQn7DY+noRQi/Ih0dTnjuxGk30uM1BwfNoIYLBOlZG8WJwEwuXuujOdlx5 3arfOFgLFl3+SJKR/wd8iN0BEBCyz47JoNAggOtj7Uyp8MmDg54HwBpASIIRgPn9x2QA y5cOjqT5hyjV9FB9FJ0Fa27oB1NMTyOEtiEyD3ys/MZLGn2FrfgGrubTBluMQAdbvbM3 XIqMhFaqS/3TQzFybhFmhg6PS2KTdpWIEsuP4IdJjJ7tFHj1uLUF7HxBG+ZUL+dEmggX SkSr88Rg8nSN3e4+XAzu77J8nEgO8gb4NUjNTCYmvdu//IzU+XvIf4U97XT3cUQp1Ci/ qh1g==
MIME-Version: 1.0
X-Received: by with SMTP id gi4mr10520594wjc.5.1389907009195; Thu, 16 Jan 2014 13:16:49 -0800 (PST)
Received: by with HTTP; Thu, 16 Jan 2014 13:16:49 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Thu, 16 Jan 2014 13:16:49 -0800
Message-ID: <>
From: Watson Ladd <>
To: Paul Lambert <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Yaron Sheffer <>, David McGrew <>, "" <>
Subject: Re: [Cfrg] Outline -> was Re: normative references
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jan 2014 21:17:04 -0000

On Thu, Jan 16, 2014 at 12:10 PM, Paul Lambert <> wrote:
> Hi Kevin,
> ⨳|> A truly ‘unified' public key system would support both signatures
>  ⨳|and
>  ⨳|> key establishment with the same key.
>  ⨳|>
>  ⨳|
>  ⨳|Received wisdom is that using the same key for both key establishment
>  ⨳|and signatures is a bad idea.  I believe the concern is that one
>  ⨳|protocol might be used an Oracle to subvert the other.
> [ ⨳]
> Yes - greatly appreciate the transfer of wisdom.  General guidelines are well documented to this effect.
> This makes complete sense in the general case where a curve may support generic  key establishment or signature algorithms.

> However, for specifically selected signature and key establishment methods I would assume that and examination could be made of this potential subversion.  The general guideline seems to be blocking the examination and evaluation of the sensitivity of such combined modes.

Signcryption has been an area of research. I think what you want is to
use the same private and public key for multiple purposes.
> As a protocol designer, being able to use the same key for signatures and key establishment makes for a simpler design and trust model.  The session key security (e.g. from ECDH) would be implicitly bound to the any signed information from the same key.

If I understand correctly you want to use something like HMQV with
keys that can be used in a signature scheme, thus saying "The person I
share key X with is the person who signed messages M_1,\ldots M_n".
This can be done by having a master key sign a key exchange key and a
message signing key. However, people can sign whatever messages they
feel like, so I don't know how helpful the semantics are.

> I is possible to just consider a combined public key that is the concatenation of two types ... but then you need another mechanism to validate the binding.  Right now if you have two public keys Pe and Ps (public to sign and public to encrypt) This would be P = Pe|Ps ( concatenated).  Binding could through and be Id = h(P)=h(Pe|Ps) or
> Ps signing Pe, etc.
> Still ... it doubles the effective required key size and adds additional steps in an authenticated key exchange.

The key exchange and PKIX we have now works with this restriction just
fine. The naive solution I mentioned above doesn't require
any extra rounds, just some more data. Yes, it is sort of a pain in
highly restricted environments, but I'm having trouble thinking
of a highly restricted environment with lots of public key ops taking
place that need those semantics.
It's never going to amount to a high percentage of the load anyway.
> Thanks,
> Paul


"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin