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

From: Bjoern Tackmann <[email-masked]>
Date: Tue, 2 Jan 2018 19:47:33 +0100

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

---

From: Ronald Tse <[email-masked]>
Date: Wed, 3 Jan 2018 15:18:30 +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 <[email-masked]<mailto:[email-masked]>> wrote:

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 <[email-masked]<mailto:[email-masked]>> 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).

The draft Abstract is:

Thank you,
Alexey

_______________________________________________
Crypto-panel mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/crypto-panel

---

From: Bjoern Tackmann <[email-masked]>
Date: Thu, 4 Jan 2018 14:41:13 +0100

Dear Ronald,

On Wed, Jan 3, 2018 at 4:18 PM, Ronald Tse <[email-masked]> wrote:

>
> 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.
>

yes, I am aware of that. The SM3 and SM4 drafts were helpful and seemed to
be in good shape already, and you had told me that you were working on the
SM2 draft. This was not at all meant to be negative, I just think it would
be advantageous to have these documents as RFCs together with the one I
reviewed, so that one can have a full specification available.

> 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.
>

The draft I reviewed [1] had a Section 4.2 called "SM2 Key Exchange
Protocol", and I did understand why it was there. It did not seem to be
necessary to follow the subsequent parts.

Best,
Björn

[1] https://www.ietf.org/archive/id/draft-ribose-openpgp-oscca-01.txt

---

From: Ronald Tse <[email-masked]>
Date: Fri, 5 Jan 2018 21:11:43 +0000

Dear Björn,

Agree with having the documents ready for the full specification.

And you are absolutely correct that the Key Exchange section is unnecessary. Originally we thought the section would better explain why the OpenPGP implementation specifically excludes that particular part of SM2, but the section turns out to be a distraction to the reader. We shall reduce that section into a sentence indeed.

Thank you for the review again and the great suggestions!

Ron

Ronald Tse
Ribose Inc.

On Jan 4, 2018, at 9:41 PM, Bjoern Tackmann <[email-masked]<mailto:[email-masked]>> wrote:

Dear Ronald,

On Wed, Jan 3, 2018 at 4:18 PM, Ronald Tse <[email-masked]<mailto:[email-masked]>> wrote:

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.

yes, I am aware of that. The SM3 and SM4 drafts were helpful and seemed to be in good shape already, and you had told me that you were working on the SM2 draft. This was not at all meant to be negative, I just think it would be advantageous to have these documents as RFCs together with the one I reviewed, so that one can have a full specification available.

The draft I reviewed [1] had a Section 4.2 called "SM2 Key Exchange Protocol", and I did understand why it was there. It did not seem to be necessary to follow the subsequent parts.

Best,
Björn