Re: [perpass] relevant LISP discussion

Stephen Kent <kent@bbn.com> Wed, 21 August 2013 19:23 UTC

Return-Path: <kent@bbn.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6401121F9EEC for <perpass@ietfa.amsl.com>; Wed, 21 Aug 2013 12:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.559
X-Spam-Level:
X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llqak8s1qAkB for <perpass@ietfa.amsl.com>; Wed, 21 Aug 2013 12:22:50 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACC521F9BB5 for <perpass@ietf.org>; Wed, 21 Aug 2013 12:22:50 -0700 (PDT)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51744) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1VCDzV-0007Pc-0m; Wed, 21 Aug 2013 15:22:49 -0400
Message-ID: <52151388.80006@bbn.com>
Date: Wed, 21 Aug 2013 15:22:48 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: nick@lupine.me.uk
References: <5214E525.7020702@cs.tcd.ie> <5214F25D.6070707@bbn.com> <521500B4.7040107@lupine.me.uk>
In-Reply-To: <521500B4.7040107@lupine.me.uk>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: perpass@ietf.org
Subject: Re: [perpass] relevant LISP discussion
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2013 19:23:05 -0000

Nick,

> On 21/08/13 18:01, Stephen Kent wrote:
>> I might be more impressed if the sender of the message understood that
>> one does not use
>> EC(DH) to encrypt/decrypt anything!
> Thanks for the input. I am cryptographically naive, yes. The intention
> here isn't to impress anyone; but to hammer out something that might
> actually work in the real world.
>
> So the contention is that sha256( ecdh( public, private ) ) is not an
> appropriate to use as the secret key for a symmetric block cipher like
> aes256... in general? Only for long-lived keys? What happens if peers
> change those keys daily, or every T/G/MB?
My comment is that DH (EC or otheriwse) is a key agreement alg, and thus
does not encrypt/decrypt anything. It generates a shared, secret bit 
string that
can be processed to yield a key for a symmetric encryption or integrity 
alg.
A function used to generate such keys is called a KDF (key derivation 
function).
A symmetric alg with with such a key is used might or might not be a block
cipher. If one wants to generate a different (symmetric) encryption key
frequently, changing a DH key bound to an entity via a repository is not
a viable approach. Instead, one uses a random value as an additional 
input to the
KDF (a value sometimes referred to as a UKM, e.g., in the CMS spec).

Steve