Re: [Crypto-panel] Request for review: draft-ribose-openpgp-oscca-01

Ronald Tse <tse@ribose.com> Wed, 03 January 2018 15:18 UTC

Return-Path: <tse@ribose.com>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C8212704A for <crypto-panel@ietfa.amsl.com>; Wed, 3 Jan 2018 07:18:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ribose.onmicrosoft.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 qjjaTS4cHZf3 for <crypto-panel@ietfa.amsl.com>; Wed, 3 Jan 2018 07:18:40 -0800 (PST)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0050.outbound.protection.outlook.com [104.47.125.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99A9126DFF for <crypto-panel@irtf.org>; Wed, 3 Jan 2018 07:18:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.onmicrosoft.com; s=selector1-ribose-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8nYNJs3Il27n65K0WoFNpr00faRESLIZ61b2oF0Cx3w=; b=an5p7MSmjJ8NEUsvOWo7JOusZSsc8PSNwpGUQSjCxANHBjIL0AexAMdcUHtlkf1Zl4QXkSOY0gVHk8mhPEzOo5oQDrljVoyXbMvsWti+HcCDi1yffSwOgrgNuTW3p8S+yKnqWzJTGUJefPevFEEPZkZeE4iEzlvPP823WkixjYQ=
Received: from PS1PR01MB1050.apcprd01.prod.exchangelabs.com (10.165.210.30) by PS1PR01MB1051.apcprd01.prod.exchangelabs.com (10.165.211.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.8; Wed, 3 Jan 2018 15:18:30 +0000
Received: from PS1PR01MB1050.apcprd01.prod.exchangelabs.com ([fe80::b8eb:ed00:f921:128b]) by PS1PR01MB1050.apcprd01.prod.exchangelabs.com ([fe80::b8eb:ed00:f921:128b%13]) with mapi id 15.20.0366.009; Wed, 3 Jan 2018 15:18:30 +0000
From: Ronald Tse <tse@ribose.com>
To: Bjoern Tackmann <bjoern.tackmann@ieee.org>
CC: Alexey Melnikov <alexey.melnikov@isode.com>, "crypto-panel@irtf.org" <crypto-panel@irtf.org>, Nancy Cam-Winget <ncamwing@cisco.com>, "draft-ribose-openpgp-oscca.authors@ietf.org" <draft-ribose-openpgp-oscca.authors@ietf.org>, Tim Polk <tim.polk@nist.gov>
Thread-Topic: [Crypto-panel] Request for review: draft-ribose-openpgp-oscca-01
Thread-Index: AQHTaFGk9+I6QWZrjkm2FNPI8aRJY6NhI6mAgAFX64A=
Date: Wed, 3 Jan 2018 15:18:30 +0000
Message-ID: <05BC205B-2975-44D4-A4E3-52FEDC4B89DB@ribose.com>
References: <56db317a-07ad-0ad4-b1d1-31f12283115e@isode.com> <CAFr4q=ABo+YB29CDp0hn1v4czikhhk3UOHUpGRAn0aCes70aPw@mail.gmail.com>
In-Reply-To: <CAFr4q=ABo+YB29CDp0hn1v4czikhhk3UOHUpGRAn0aCes70aPw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tse@ribose.com;
x-originating-ip: [220.71.45.39]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; PS1PR01MB1051; 7:YvlkKzHLP5+0HRULgUTZ9/iEEu2PEKPSy2CyoI4g1uh3zZlWiph6GF7oAfSQ+zyLdxi7xa6AjsSE5z4ROUHEqCcnJnzxb2qaJnai4LmReLI0x0WH75D/5mRdshbDxxQrjJDUWeSGD8LyYiVijAb04fFQrr0Rw602SXBDm+sgdwp+bGfl//grZQKxsoxOoMx9bV0kQPX+QY7dJQ25VcPy4+26maUPcsyH3RobUj332pd36B3mT+TcA+AuoaItlYhF
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 70c0de94-cdc4-433f-65a6-08d552bd3f48
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:PS1PR01MB1051;
x-ms-traffictypediagnostic: PS1PR01MB1051:
x-microsoft-antispam-prvs: <PS1PR01MB1051849D72C9E08C3C638886D71E0@PS1PR01MB1051.apcprd01.prod.exchangelabs.com>
x-exchange-antispam-report-test: UriScan:(278428928389397)(120809045254105)(192374486261705)(21532816269658)(280183299450418);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231023)(944501075)(3002001)(10201501046)(6041268)(2016111802025)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(6043046)(201708071742011); SRVR:PS1PR01MB1051; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:PS1PR01MB1051;
x-forefront-prvs: 0541031FF6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39380400002)(39830400003)(376002)(396003)(24454002)(199004)(189003)(86362001)(3280700002)(966005)(413944005)(4326008)(81156014)(14454004)(59450400001)(81166006)(229853002)(99286004)(478600001)(6506007)(3660700001)(6486002)(5250100002)(8656006)(8676002)(2906002)(53546011)(6512007)(66066001)(6246003)(33656002)(76176011)(25786009)(230783001)(54896002)(6306002)(6436002)(68736007)(236005)(8936002)(105586002)(97736004)(53936002)(106356001)(36756003)(2950100002)(54906003)(82746002)(83716003)(606006)(3846002)(6116002)(2900100001)(316002)(7736002)(102836004)(5660300001)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:PS1PR01MB1051; H:PS1PR01MB1050.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:3; LANG:en;
received-spf: None (protection.outlook.com: ribose.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: tMWdaUrWlcJmpzL58AOiB2kBLLIiAfCUjarWFhHhlFDrbsBjZjPlbGX0qd3WeB7JA5wsTunBXViDGM2iLSrGkA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_05BC205B297544D4A4E352FEDC4B89DBribosecom_"
MIME-Version: 1.0
X-OriginatorOrg: ribose.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 70c0de94-cdc4-433f-65a6-08d552bd3f48
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2018 15:18:30.4611 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PS1PR01MB1051
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/XMwL3j75YCjldFxEH0WgaTJrxRs>
Subject: Re: [Crypto-panel] Request for review: draft-ribose-openpgp-oscca-01
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jan 2018 15:18:45 -0000

Dear Björn,

Thank you very much for the comprehensive review, and a belated Happy New Year!

I agree with most of the comments. It would indeed be useful and beneficial for the SM2/SM3/SM4 schemes to be freely available as RFCs for the establishment of their usage within OpenPGP. If I may clarify, the SM3 and SM4 Internet-Drafts already provide detailed descriptions of the algorithms and also include reference implementations, and are ready for CFRG review. The SM2 draft is currently being updated (apologize for the delay…), and should provide a similar level of detail to those two when the update is complete.

Some idiosyncrasies, as you have rightly pointed out, come from the definition of the SM2 scheme itself and the OpenPGP standard, so there’s not much we can do about. SM2 is a set of three algorithms that include digital signatures, public key encryption and also key exchange. That’s why the SM2 draft included a section on key exchange — it was not included in the OpenPGP draft because it is not suitable for usage in the OpenPGP context. The SM2/SM3/SM4 documents exist independently from the OpenPGP document that is being reviewed.

On a separate note, we could provide access to the ISO standards that detail these SM algorithms for the purpose of the review. Please feel free to email me separately on this if this would be helpful.

Again, thank you very much for the helpful review!

Kind regards,
Ron

_____________________________________

Ronald Tse
Ribose Inc.

On Jan 3, 2018, at 3:47 AM, Bjoern Tackmann <bjoern.tackmann@ieee.org<mailto:bjoern.tackmann@ieee.org>> wrote:

Dear Chairs, dear Authors,

I apologize for the additional delay in producing my review. Please find the full text below.

Best,
Björn

=====================================

The Internet draft suggests to amend the OpenPGP format to add support for cryptographic schemes SM2, SM3, and SM4 standardized by the Chinese Office of State Commercial Cipher Administration (OSCCA), to make OpenPGP compliant with OSCCA regulations for use in China.

As a general remark, the Internet draft does not describe the cryptographic schemes in sufficient detail for implementation, but refers to other sources such as the standardization documents of the OSCCA (in Chinese) or the ISO standards (not freely accessible). As the reviewer was not able to access these sources, this review is based instead on publicly accessible information such as (some expired) Internet drafts and academic papers that describe the schemes in detail, though sometimes inconsistently. The reviewer thinks that a standard-compliant description of the algorithms must be made available in a openly accessible and authoritative way before the present Internet draft can become a standard.

The review discusses first the component schemes individually and then their composition within OpenPGP. It concludes with general and editorial remarks.

SM2 Signature, as in [SM2-ID, SM2-Paper]
- There is a mismatch between the two documents in how the cryptographic parameters are hashed, and the signature algorithm in [SM2-Paper] can generate invalid signatures with small probability. (Neither of the differences affects security.) Furthermore, the data flow depiction in [SM2-ID] does not match any of the the algorithms specified in the documents. (As a side remark, the security statement in [SM2-Paper] is formally meaningless, but this does not affect the validity of the main argument.)
- The structure of the SM2 signature scheme roughly resembles ECDSA, but is different in that (a) the message is extended by a hash of an identity and the parameters and (b) the computation in the exponent is different.
- In [SM2-Paper], the EUF-CMA security of the signature scheme is proved, based on collision-resistance and a uniformity property of the hash function, in the generic group model. Furthermore, recent security results seem to further connect DSA and SM2 in terms of their security [SM2-TCC, DSA1].
- The known weaknesses of SM2, which are cited in [SM2-ID], appear to be similar to those of DSA and are mostly related to bad choices of nonces and side channels.
> Overall, and from the current state of knowledge, the security of SM2 can be seen as roughly comparable to ECDSA, which is already used in OpenPGP.

SM2 Key Derivation, as in the reviewed draft and [SM2-ID]
- The key derivation is used both in SM2 encryption and for generation of symmetric key material.
- It is based on a hash function h, and is defined essentially as h(raw_key | 1) | h(raw_key | 2) | ...
- The scheme is secure under strong assumptions on the hash function; essentially, one needs to assume that h(raw_key | .) is a PRF for the specific distribution of raw_key. This is not argued specifically, but holds if h is modeled as random oracle.
> Overall, the scheme can be considered secure but makes strong assumptions on the security of the underlying hash function. As the proposed hash function SM3 appears to be secure from the current state of knowledge, this does not pose a problem now, but schemes using this key derivation should be retired as soon as doubts in the security of SM3 emerge. (In the sense of distinguishing attacks, not only collision or preimage.)

SM2 Encryption, as in [SM2-ID]
- The public-key encryption scheme is based on ElGamal in elliptic curves. The DH key is then used (a) in the above-described key derivation procedure to obtain a key stream for encrypting the plaintext, and (b) in a hash together with the message to compute an integrity code.
- Although no particular security analysis is referenced, the reviewer believes that the scheme is secure if (a) the CDH problem on the suggested curve is hard and (b) the hash function is modeled as a random oracle; the latter assumption is required both for the key-derivation and for the integrity code.
> Overall, the scheme can be considered secure, with the same caveats as for SM2 Key Derivation mentioned above.

SM2 Curve, as in [SM2-ID]
- The 256-bit curve is supposed to be a drop-in replacement for P256 and provide a security level of 128 bits, which is appropriate for the combination other suggested schemes.
- The reviewer lacks the necessary expertise/time to validate these claims in detail, or to make an in-depth comparison with other curves at a similar level of security. Literature research did not point to any particular weakness of this curve.

SM3 Hash Function, as in [SM3-ID]
- The SM3 function has a Merkle-Damgaard structure with 256-bits of output, and appears to be meant as a drop-in replacement for SHA256.
- SM3 has been cryptanalized in a sequence of papers cited in [SM3-ID], although still not as thoroughly as the SHA2 family.
- The security levels stated in [SM3-ID] indicate that SM3 provides safer security margins than SHA256 for all considered attack types (preimage, collision, distinguishing).
- The reviewer wondered why the security margins for preimage attacks on SM3 are smaller than those for collisions, as a preimage attack should also give rise to a collision attack.
- The reviewer lacks the necessary expertise/time to the hash function from a technical perspective, but the state of the literature suggests that SM3 can be considered safe for the applications in this Internet draft.

SM4 Block cipher, as in [SM4-ID]
- SM4 is an SPN block cipher with 128-bit block size and 128-bit keys.
- The use in OpenPGP will be in CFB mode for encrypting message plaintext.
- The reviewer lacks the necessary expertise/time to evaluate the security of SM4 as a block cipher in more detail, but did not find cryptanalytic results that indicated against using SM4.

Comment on the use of schemes in OpenPGP
Use in OpenPGP will combine the SM2 signature and the CFB-mode of SM4 in an Authenticate-then-Encrypt manner. As CFB is not an authenticated encryption scheme (but instead malleable), and SM2 is not known to be strongly unforgeable (but only existentially unforgeable), the security of the composed scheme cannot be immediately inferred. Yet, as no transformation for computing one valid SM2 signature from another given one (without the use of the private key) is known, this is unlikely to result in exploitable vulnerabilities.


General comment:
The reviewer has mixed feelings about the cryptography proposed in this draft. On the one hand, from a theorist's perspective, some aspects call for improvement, most importantly the reliance of the scheme on strong properties of the hash function and the idiosyncratic use of cipher-feedback mode for message encryption. On the other hand, these aspects are inherited from the OSCCA proposals or even plain OpenPGP. Furthermore, given the security of the SM2 curve, the SM3 hash function, and the SM4 block cipher (for which the reviewer relied on the literature), the construction does not appear to have exploitable cryptographic vulnerabilities.

Editorial:
- I found the beginning of Section 4 on SM2 to be unnecessarily detailed, at least given the discussion in the respective subsections.
- Section 4.3 appears unnecessary; at least I could find no use of the Key Exchange in the proposals.


Result:
From the reviewer's perspective, the main caveat is that there is so far no precise, openly accessible, sufficiently detailed, and authoritative reference for the algorithms SM2, SM3, and SM4. The reviewer believes that this defect must be rectified before the present Internet draft can become an Internet standard. Furthermore, code points for the schemes must be registered. Beyond that, the document is in a good shape, with minor comments listed below.


Minor comments:
- p2: published in public, similarly on p4
- The document should indicate in the public-key format that they refer to version 4 as specified in RFC4880.
- Format in 11.1 is described as a "single MPI" -- but it is not an integer, so rewording may be needed.


References:
[DSA1]      Fersch, M., Kiltz, E., and Poettering, B., "On the Provable Security of (EC)DSA Signatures", ACM CCS 2016
[SM2-ID]    https://www.ietf.org/archive/id/draft-shen-sm2-ecdsa-02.txt
[SM2-Paper] Zhang, Z., Yang, K., Zhang, J., and C. Chen, "Security of the SM2 Signature Scheme Against Generalized Key Substitution Attacks", December 2015, https://link.springer.com/chapter/10.1007/978-3-319-27152-1_7
[SM2-TCC]   https://eprint.iacr.org/2017/890.pdf
[SM3-ID]    Shen, S., Lee, X., Tse, R., Wong, W., and P. Yang, "The SM3 Cryptographic Hash Function", draft-oscca-cfrg-sm3-02
[SM4-ID]    Tse, R. and W. Wong, "The SM4 Blockcipher Algorithm And Its Modes Of Operations", draft-ribose-cfrg-sm4-05


On Tue, Nov 28, 2017 at 3:02 PM, Alexey Melnikov <alexey.melnikov@isode.com<mailto:alexey.melnikov@isode.com>> wrote:
Dear Crypto Panel,

SAAG’s SECDISPATCH chairs have requested review of
<https://datatracker.ietf.org/doc/draft-ribose-openpgp-oscca/>
before the document fate will be decided (it is likely to end up in the CURDLE WG).

Can we have some volunteer(s) please?

The draft Abstract is:

   This document enables OpenPGP (RFC4880) usage in an compliant manner
   with OSCCA (Office of State Commercial Cipher Administration)
   regulations for use within China.

   Specifically, it extends OpenPGP to support the usage of SM2, SM3 and
   SM4 algorithms, and provides the OSCCA-compliant OpenPGP profile
   "OSCCA-SM234".


Thank you,
Alexey

_______________________________________________
Crypto-panel mailing list
Crypto-panel@irtf.org<mailto:Crypto-panel@irtf.org>
https://www.irtf.org/mailman/listinfo/crypto-panel