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

Bjoern Tackmann <bjoern.tackmann@ieee.org> Tue, 02 January 2018 18:47 UTC

Return-Path: <bjoern.tackmann@ieee.org>
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 E1A0E12D811 for <crypto-panel@ietfa.amsl.com>; Tue, 2 Jan 2018 10:47:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.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 4JdJ29kbwqJu for <crypto-panel@ietfa.amsl.com>; Tue, 2 Jan 2018 10:47:36 -0800 (PST)
Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA00312D7F8 for <crypto-panel@irtf.org>; Tue, 2 Jan 2018 10:47:35 -0800 (PST)
Received: by mail-yw0-x241.google.com with SMTP id g191so12174591ywe.7 for <crypto-panel@irtf.org>; Tue, 02 Jan 2018 10:47:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cz2KzBg6ggZRXaF0WeaUAhVzYT81d2qD9R4tkB0FiDE=; b=bTCaHINOcJTE6mJzQC2l1q8I/o6S1nQ63Yg39TakwzQXclvdZiheMaRhAKTtFrEehh BtArBmEqCmMQ1P8pAsc0s62U1XIKBCOpZpp2HjXCc1xXH+x5+SkLQBKe3jqw1sx8kxy8 SCPErTT3LtlskalGl3ZcU2o+9nScTyEB5b/YJcl4HdaxUfutt2AZJhpMknWUDwlARrou Hetq+Sn52pi0eehAk5sgBcupj+lzdWOpIA2BkMvT9kDmYSGaFjOfgRbeA6xqfpG0+al3 lE03NaqJVqFA47fbxAg+nterhp9Lu6WZymXRD5JaremN+ap/KVKafauYNWxoqQlsr0C+ a6PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cz2KzBg6ggZRXaF0WeaUAhVzYT81d2qD9R4tkB0FiDE=; b=DESfz9bCPC4nrVVwX8zqknk3sFzUJnH5lAe2ylmNz+H5rtw4ip2V2k9ZG1MN/x01p5 GhjFHs4jUgRfkA+Y9T4yQeIc9aTQBntyrd3QCXGfldL7naVmvwWBYcrC0M9PxuB0vKzn 7acb4GLw1gEEyRHmyRV2Xpb+OjEqNKGqmeP3kFRwVHiEtUAtDtN9hizxvELoOn5cKafG ClebOjrFIlnI/emAz4uJMyHMQ4Gi5EvwQgorqJT6cjt0rdMFYvyhMuFa0As6c+AqCLSW FT/d9CuNCEv3IUiNKud02ySK85g4egzJY4tXlMibb8nfayoNEHUv/Z76T5i2Xf3v4eAs KkJw==
X-Gm-Message-State: AKGB3mKzS8O3ktPfDPYfvP5/L+nqXy6F2eZZuG3DYHmNmrqKWhn0hgzi vhvK20d3htVepAXQ6u/bynne8kpGGxaBGpRErwCB+A==
X-Google-Smtp-Source: ACJfBotHKvz8NjB9vhzFfJcCQ+rjysVQ02+nZgHLhRwuYU2AGwvv8ho+sPi91pBGc+3237aJr+41naGkIZ5L7i2keRA=
X-Received: by 10.129.200.14 with SMTP id n14mr32274158ywi.367.1514918854645; Tue, 02 Jan 2018 10:47:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.225.12 with HTTP; Tue, 2 Jan 2018 10:47:33 -0800 (PST)
In-Reply-To: <56db317a-07ad-0ad4-b1d1-31f12283115e@isode.com>
References: <56db317a-07ad-0ad4-b1d1-31f12283115e@isode.com>
From: Bjoern Tackmann <bjoern.tackmann@ieee.org>
Date: Tue, 02 Jan 2018 19:47:33 +0100
Message-ID: <CAFr4q=ABo+YB29CDp0hn1v4czikhhk3UOHUpGRAn0aCes70aPw@mail.gmail.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Cc: crypto-panel@irtf.org, Nancy Cam-Winget <ncamwing@cisco.com>, draft-ribose-openpgp-oscca.authors@ietf.org, Tim Polk <tim.polk@nist.gov>
Content-Type: multipart/alternative; boundary="089e08222a643215110561cf887f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/bKFcDd68LZ-x0oh6iXE-o9KShrk>
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: Tue, 02 Jan 2018 18:47:39 -0000

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>
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
> https://www.irtf.org/mailman/listinfo/crypto-panel
>