IETF Logo Mail Archive

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Cen Jung Tjhai <CJT@post-quantum.com> Wed, 09 August 2017 19:30 UTC

Return-Path: <CJT@post-quantum.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A23C132490 for <ipsec@ietfa.amsl.com>; Wed, 9 Aug 2017 12:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 YqK1ZDRONJfw for <ipsec@ietfa.amsl.com>; Wed, 9 Aug 2017 12:30:50 -0700 (PDT)
Received: from relay.ezis.com (relay.ezis.com [5.153.73.19]) by ietfa.amsl.com (Postfix) with ESMTP id DC70B132489 for <ipsec@ietf.org>; Wed, 9 Aug 2017 12:30:49 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.41,349,1498518000"; d="scan'208";a="2210881"
Received: from unknown (HELO pqex01.post-quantum.com) ([192.168.142.3]) by ironport.ezis.com with ESMTP; 09 Aug 2017 20:30:50 +0100
Received: from PQEX02.post-quantum.com (192.168.142.18) by PQEX01.post-quantum.com (192.168.142.3) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 9 Aug 2017 20:30:47 +0100
Received: from PQEX02.post-quantum.com (192.168.142.18) by PQEX02.post-quantum.com (192.168.142.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 9 Aug 2017 20:30:46 +0100
Received: from PQEX02.post-quantum.com ([fe80::f470:9812:e4eb:5bd3]) by PQEX02.post-quantum.com ([fe80::f470:9812:e4eb:5bd3%13]) with mapi id 15.00.1320.000; Wed, 9 Aug 2017 20:30:46 +0100
From: Cen Jung Tjhai <CJT@post-quantum.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: [IPsec] Proposed method to achieve quantum resistant IKEv2
Thread-Index: AQHTDE+mPH5PNqQgTkK9LOvm4SvL2qJ0GbUAgAIwNdWABXuFgIAAg/cAgAAp+oA=
Date: Wed, 09 Aug 2017 19:30:46 +0000
Message-ID: <5FBE6EC2-EAEF-419A-BFB7-CA42F65F4B16@post-quantum.com>
References: <BBEB2C9C-9B96-4C6C-BB9B-4415F096FAE1@cisco.com> <041b01d30d21$8d33f230$a79bd690$@gmail.com> <1501968567726.89885@post-quantum.com> <22922.57101.227283.113155@fireball.acr.fi> <7769.1502301632@obiwan.sandelman.ca>
In-Reply-To: <7769.1502301632@obiwan.sandelman.ca>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.3.255.7]
Content-Type: text/plain; charset="utf-8"
Content-ID: <705C203BFDADE8478D9759F2BC8F4243@post-quantum.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/RANK8HcRs1Sz7bQXhYaGMCZj8VE>
Subject: Re: [IPsec] Proposed method to achieve quantum resistant IKEv2
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Aug 2017 19:30:51 -0000

>>> Is the size of QSKE blob that the responder has to return to initiator likely
>>> to be either unknown to the initator or very different than the
>>> initiator->responder direction?

I believe Daniel has touched on this. But let me add more information on this specific query. There are two kinds key-exchange mechanism for post-quantum algorithms, namely Diffie-Hellman-like and KEM. For DH-like, from what we investigated so far, the public data is pretty much of equal size for both directions. On the hand, for KEM, this could be very asymmetric. The blob sent by the initiator to responder could be 1MB in size, and this is the public-key of the initiator. The responder then needs to sample some random data, encrypt it and send it back to the responder. The size of this ciphertext could well just be 1KB. Because the size of this ciphertext is dependent on the size of the random data, a KEM algorithm may need to specify the size of the random data. It could be similar to the case of ENCR where there is an attribute to specify the key size, or it could be fixed.

In both cases, once the parameters are agreed, the blob size is known in advance.

CJ

v2.23.0 | Report a Bug | By Email