[Lake] Some questions about CIPHERTEXT_2 of Message 2 in draft-ietf-lake-edhoc-20

"Yanlei(Ray)" <ray.yanlei@huawei.com> Thu, 24 August 2023 10:03 UTC

Return-Path: <ray.yanlei@huawei.com>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED76AC14CF18 for <lake@ietfa.amsl.com>; Thu, 24 Aug 2023 03:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkSXhlBatFWQ for <lake@ietfa.amsl.com>; Thu, 24 Aug 2023 03:03:36 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754FAC151062 for <lake@ietf.org>; Thu, 24 Aug 2023 03:03:36 -0700 (PDT)
Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4RWdpK3QwTz67g0b for <lake@ietf.org>; Thu, 24 Aug 2023 17:59:05 +0800 (CST)
Received: from kwepemm000019.china.huawei.com (7.193.23.135) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Thu, 24 Aug 2023 11:03:33 +0100
Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemm000019.china.huawei.com (7.193.23.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Thu, 24 Aug 2023 18:03:31 +0800
Received: from kwepemm600017.china.huawei.com ([7.193.23.234]) by kwepemm600017.china.huawei.com ([7.193.23.234]) with mapi id 15.01.2507.031; Thu, 24 Aug 2023 18:03:31 +0800
From: "Yanlei(Ray)" <ray.yanlei@huawei.com>
To: "lake@ietf.org" <lake@ietf.org>
Thread-Topic: Some questions about CIPHERTEXT_2 of Message 2 in draft-ietf-lake-edhoc-20
Thread-Index: AdnWZMZV4aEbCiBxSMOEHXebgiTksw==
Date: Thu, 24 Aug 2023 10:03:31 +0000
Message-ID: <c7f1688b1c29405a9ff4543e8e62d4f2@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.39.228]
Content-Type: multipart/alternative; boundary="_000_c7f1688b1c29405a9ff4543e8e62d4f2huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/Ojx69lyUx5ZfqE2zFcaKMARBnbM>
Subject: [Lake] Some questions about CIPHERTEXT_2 of Message 2 in draft-ietf-lake-edhoc-20
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Aug 2023 10:03:41 -0000

Dear authors,

I am confused about how the  CIPHERTEXT_2 is calculated.
In Section 5.3.2 of draft-ietf-lake-edhoc-20, I found there are 2 sentences that contradict each other.
¡° * CIPHERTEXT_2 is calculated by using the EDHOC_Expand function as a binary additive stream cipher over the following plaintext:
- PLAINTEXT_2 =...
...
- CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2¡±
Is the calculation of the CIPHERTEXT_2 using the EDHOC_Expand function or just making the XOR operation?

Another concern is the security level of the encryption using XOR.
In Section 9.1 of draft-ietf-lake-edhoc-20: ¡°EDHOC has similar security properties as can be expected from the theoretical SIGMA-I protocol [SIGMA] and the Noise XX pattern [Noise], which are similar to methods 0 and 3, respectively.¡±
However, Section 3.2 of the referenced paper [SIGMA] said the encryption of the XOR type is not safe : ¡° In this case the above attack against STS is still viable if the encryption is of the XOR type discussed above. In this case, when A sends the message { A , sigA(gy, gx) }Ks, Eve replaces A¡¯s identity (or certificate) by just XORing the value A ¨’ E in the identity location in the ciphertext. When decrypted by B this identity is read as E¡¯s and the signature verified also as E¡¯s.¡±
By the way, is the encryption using XOR quantum-safe?

Regards,
Lei YAN