Re: [Qirg] QKD in OpenSSL

"Diego R. Lopez" <diego.r.lopez@telefonica.com> Mon, 18 November 2019 09:35 UTC

Return-Path: <diego.r.lopez@telefonica.com>
X-Original-To: qirg@ietfa.amsl.com
Delivered-To: qirg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7A61208F1 for <qirg@ietfa.amsl.com>; Mon, 18 Nov 2019 01:35:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhgC4uhf8Dv5 for <qirg@ietfa.amsl.com>; Mon, 18 Nov 2019 01:35:02 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30092.outbound.protection.outlook.com [40.107.3.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CDD12094C for <qirg@irtf.org>; Mon, 18 Nov 2019 01:35:01 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VX1U62SchJw+AvSS7x07VSZVs1Mkw8hqK/WkZL+AB6SOBNVr6oqc3u51AijrTDyN322zN2X7WpyrhLiSv2wSNZPjw3MewHPspHmgXzRAIa0FVg3fnkqYH/XTZZfqs2EMmVlWcKiraHrvzmO6mafQLf2fwZMCmwVtYpdkpoT9qkzCjptXSiShLFW+ibKjODt1ia0KxEZCmK2GUIBHW+Gu2xsbL6+EdamMPUqCSZjZ/kEXHM1EPuAu89GTDZq16nXnmpISAXWFwVK6o472fqRabk9qMsswGmGPzHh9IfGlgyNSRb8L0weF7gyZkrR7EnYMFYMDA5hvQXzZteGo8tZRrw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jdcEqDNj1ygxEDmo8sMj6DTOMfP5acuhZnUWcJHrs0k=; b=gYgj2QAiRp91nbiEDGxFj+xdNAqJFZZgv87OYIH8zRrduWbqZEc6A3ZEwa/nPuKMe7kicuFs802W7uQplH8kjow177MA4KHhXos6wNX0o/Q/ht6DGS/CCswZzsJcPK5osZ/6pKfgPNx6TWxGpNtT2cHJkRyohWDqIKolSTBoe3tSwYsYgUnDkJN7dSNYTM+dQF9ZLWHU92/tg0K8hfWc8cDvTrBLHTxDA9wQ7ybZUfjgzie+nNEMNtNTnL1WSHO7BcaqkQ/FPXytnqmIIWkzp8+skSuf2LQrJJ8iaWR+SnLXCuJrP3DOgBG8jiRxx/iIJIf8J6FCdgMVhw3VYPhbxw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telefonica.com; dmarc=pass action=none header.from=telefonica.com; dkim=pass header.d=telefonica.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jdcEqDNj1ygxEDmo8sMj6DTOMfP5acuhZnUWcJHrs0k=; b=Ug5eEekHHk44C29+wY3gKNoZYkDH05XDo8BX7Sgtl95KAPZR8ICoiTo62CBUKBi0eZwqD0cJJfp4SMPI6kUcKJUW6o6cEMZOUELWKriqMUSxkEI2IB6Zc/PbIMqy/MOaEbYNpu3DMdGTtJU7D5b+ACuJOaGKDS5IDIj9lLLOS10=
Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com (52.134.70.148) by DB3PR0602MB3785.eurprd06.prod.outlook.com (52.134.67.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.26; Mon, 18 Nov 2019 09:34:59 +0000
Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::110f:5653:9dc2:14ee]) by DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::110f:5653:9dc2:14ee%7]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 09:34:59 +0000
From: "Diego R. Lopez" <diego.r.lopez@telefonica.com>
To: Bruno Rijsman <brunorijsman@gmail.com>, Rodney Van Meter <rdv@sfc.wide.ad.jp>
CC: "qirg@irtf.org" <qirg@irtf.org>
Thread-Topic: [Qirg] QKD in OpenSSL
Thread-Index: AQHVmiB6fH0MBJuhJk2WR8VftBVEUKeQdruAgAATCYCAADmhAA==
Date: Mon, 18 Nov 2019 09:34:59 +0000
Message-ID: <B4D330A6-0DF8-4846-B16D-518BFC51E0B6@telefonica.com>
References: <331F2FAA-6B26-40E7-BE68-379943AECF8F@gmail.com> <9E1CC1FD-A06E-4996-A2A7-EEE618BBFB78@sfc.wide.ad.jp> <A18993AF-F31A-4B4F-BEF6-E9CC474241D2@gmail.com>
In-Reply-To: <A18993AF-F31A-4B4F-BEF6-E9CC474241D2@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.10.191111
authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com;
x-originating-ip: [31.133.153.167]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: fcfb8187-a12d-49be-7464-08d76c0a9486
x-ms-traffictypediagnostic: DB3PR0602MB3785:
x-microsoft-antispam-prvs: <DB3PR0602MB3785569F66147EE5E82B53D4DF4D0@DB3PR0602MB3785.eurprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0225B0D5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(39860400002)(346002)(396003)(366004)(376002)(40134004)(189003)(199004)(102836004)(7736002)(53546011)(66446008)(64756008)(256004)(66556008)(6246003)(6486002)(5660300002)(66574012)(86362001)(110136005)(8676002)(71200400001)(99286004)(8936002)(446003)(476003)(786003)(2906002)(316002)(58126008)(81166006)(76176011)(11346002)(81156014)(66946007)(66476007)(6512007)(4326008)(6506007)(26005)(486006)(71190400001)(14444005)(606006)(6436002)(236005)(14454004)(36756003)(25786009)(54896002)(76116006)(478600001)(45080400002)(91956017)(229853002)(186003)(3846002)(6116002)(2616005)(66066001)(966005)(33656002)(6306002)(493534005); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR0602MB3785; H:DB3PR0602MB3788.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 231Z+jzpqGJZWR4RRj4+hApJF3mvxbg/OkXmQimm0Dnwpa80v22UxV89O73gElaXDDGMedaDCkOhO8Y9UtiDNw1aOdj62ZadrYcS3UXiaSiLRxXkruNaC9RbdRiwLYep6z3srZvvZPOPvUOoayZMob1synjoGjoPYyUD5lRwh/cdjy/3Ejo0e8zxvDKa69Pn4KDCu5JcZval/NwVsL1YHSFeNCyMNSKopAHpbKF/FQk1EXOHvfmjP4DeIhWlLTCe6ltcCN1lQub8AcM+NnUOXah5Y8GrbvCEvc1eU3+HAzYuye9tRyhzhlsfHqcb7JXSOZ/YEn78N8Dg4np/aL1qku47S5kB0zyxw34SinGNIhM8XI9rgVlP4kqYlkEPJTlVn6NOeeDhBnA+Tkz63whB54491eGH1dyIpybI6itfLoq8G18MEy/PgpuIxYpvx6wo
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_B4D330A60DF84846B16D518BFC51E0B6telefonicacom_"
MIME-Version: 1.0
X-OriginatorOrg: telefonica.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fcfb8187-a12d-49be-7464-08d76c0a9486
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 09:34:59.2627 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QjXWPp+TpMv5rq2OcnhxHO72ZBHRij3Be+cUhJakKhKVu8284uIAOxzE4a3z43yawCk7LDFpM4eNgzgi9UMEI7pa/Y/9EOIVapcJnzxoMiE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0602MB3785
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/Aho7O3kGOQBy1r-v11M8uvdyoZ8>
Subject: Re: [Qirg] QKD in OpenSSL
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Quantum Internet \(proposed\) RG" <qirg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/qirg>, <mailto:qirg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/qirg/>
List-Post: <mailto:qirg@irtf.org>
List-Help: <mailto:qirg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/qirg>, <mailto:qirg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2019 09:35:06 -0000

Hi Bruno,

It looks I’m becoming the “physical argument” guy in the group, but the fact is that QKD (and I guess quantum communication at large) has to do with physical effects, and we have not achieved (not sure if we eve would) the levels of abstraction and virtualization we see in classical digital environments. So observation in QKD implies physical access, and therefore the capacity of direct physical interference. And, FWIW,  cutting a fiber is always cheaper than any quantum-level observations…

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: diego.r.lopez@telefonica.com<mailto:diego.r.lopez@telefonica.com>
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 18/11/2019, 15:08, "Qirg on behalf of Bruno Rijsman" <qirg-bounces@irtf.org<mailto:qirg-bounces@irtf.org> on behalf of brunorijsman@gmail.com<mailto:brunorijsman@gmail.com>> wrote:

Yes, this is something that has always bothered me about QKD.

In classical key exchange (e.g. Diffie-Hellman), if an eavesdropper Eve passively observes a key exchange (e.g. by passively tapping a fiber), then Alice and Bob neither need to know nor care that Eve is doing that. Alice and Bob can just use the key “knowing” that Eve (if she is present) cannot determine the shared key by just observing the key exchange (assuming Eve doesn’t have a quantum computer).

But in QKD, if Eve passively observes the key exchange, then Alice and Bob will detect that Eve has “observed" the key exchange and by doing so Eve has invalidated the key exchange. Hence, Alice and Bob cannot use the shared key and must start over or fall back to classical key exchange, just because Eve was there “observing" the key exchange.

Just as you say, just “passively observing” a fiber constitutes a Denial-of-Service attack.

Of course, the terminology “passively observing” is kind of meaningless in quantum mechanics, because observing = interfering.

But still, this bothered me a lot, and made me feel that QKD is more “vulnerable” than classical key exchange to DoS attacks.

The standard defense that I always read in the QKD literature is that if Eve is in a position to passively monitor a link, then she is also in a position to initiate a DoS attack by simply cutting the fiber. So, the argument goes, QKD is no more vulnerable to a DoS attack than classical key exchange.  I am not sure if I agree with that — it does not feel quite right to me.

— Bruno


On Nov 18, 2019, at 7:00 AM, Rodney Van Meter <rdv@sfc.wide.ad.jp<mailto:rdv@sfc.wide.ad.jp>> wrote:

Very cool.

You might check out some of the work we did five years ago that never made it to RFC.
https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01

One interesting, and controversial, topic is what to do when an eavesdropper *does* interfere with a QKD connection.  It’s a great, and easy, DOS attack.  So, should the rekeying stop, and the connection depending on the rekeying be killed when the key lifetime expires?  Or should there be a fallback mechanism of potentially lower security?

This is more of an issue for IPsec, which has rekeying and explicit lifetimes, than for SSL.

Rodney Van Meter
Professor, Faculty of Environment and Information Studies
Keio University, Japan
rdv@sfc.wide.ad.jp<mailto:rdv@sfc.wide.ad.jp>




On Nov 13, 2019, at 21:47, Bruno Rijsman <brunorijsman@gmail.com<mailto:brunorijsman@gmail.com>> wrote:

For those interested, I just posted a report on how we added support for Quantum Key Distribution (QKD) to OpenSSL during the RIPE Pan-European Hackathon at QuTech last week.

http://bit.ly/openssl-qkd

— Bruno
_______________________________________________
Qirg mailing list
Qirg@irtf.org<mailto:Qirg@irtf.org>
https://www.irtf.org/mailman/listinfo/qirg



________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição