Cleanups for review

[ronaldtse]

• Updated document version to 01
• Elaborated SM2DSA KDF relationship with IEEE1363a KDF2
• Formatting cleanups
• [Important]: updated Public Encoding section to show "C = (C1 || C3 || C2)" instead of the original "C = (C1 || C2 || C3)" -- the old one from draft-shen was actually wrong! 132, not 123. @randombit we need to update rnp for this too.

[randombit]

@ronaldtse Ouch. OK well no change required in RNP proper, I will push a change for botan SM2.

[ronaldtse]

Thanks @randombit. When I saw "123" I thought -- I remember the sequence wasn't not straightforward like that... 😭

[randombit]

@ronaldtse Wait can we double check this? In

http://www.oscca.gov.cn/UpFile/2010122214822692.pdf

section 6.1 (page 87):

A5 t=KDF(x2 ∥ y2, klen)
A6 C2 = M ⊕ t
A7 C3 = Hash(x2 ∥ M ∥ y2)
A8 C = C1 ∥ C2 ∥ C3

In GmSSL on the other hande, the ordering is C1 || C3 || C2, except it's actually storing the entire ciphertext in an ASN.1 structure

ASN1_SEQUENCE(SM2CiphertextValue) = {
        ASN1_SIMPLE(SM2CiphertextValue, xCoordinate, BIGNUM),
        ASN1_SIMPLE(SM2CiphertextValue, yCoordinate, BIGNUM),
        ASN1_SIMPLE(SM2CiphertextValue, hash, ASN1_OCTET_STRING),
        ASN1_SIMPLE(SM2CiphertextValue, ciphertext, ASN1_OCTET_STRING),
} ASN1_SEQUENCE_END(SM2CiphertextValue)

[ronaldtse]

@randombit sure I'm checking. The thing is SM2 has been published 3 times in different standards: 2010 (OSCCA), 2012 (GM/T 0003:2012, an OSCCA standard) and 2016 (GB/T 32918-1:2016, a China Standard).

In the 2010 version, it is 123.

In this version here, it is 132. I have a feeling this is newer. http://dacas.cn/sharedimages/ARTICLES/SMAlgorithms/SM2_4.pdf

I am trying to find the latest one 32918-1...

[randombit]

Ah, messy. OK let me know when you can confirm.

[ronaldtse]

Maybe this settles it.

http://www.tc260.org.cn/file/20160801094501413290.doc

Section 7.2: SM2 encrypted data in ASN.1 is defined as:

SM2Cipher   ::= SEQENCE{
XCoordinate   INTEGER,
YCoordinate   INTEGER,
HASH              OCTET   STRING SIZE(32),
CipherText      OCTET   STRING
}

HASH is the SM3 output of 256-bits. CipherText is of equal length to the plaintext input.

9.2 Encryption

SM2 Encryption means using the public key to encrypt data. The encrypted data can only be decrypted by the corresponding private key.

Input: Q: SM2PublicKey m: plaintext to be encrypted

Output: c: SM2Cipher

Where:

• c is represented in the format defined in 7.2
• c's XCoordinate, YCoordinate are the x, y of a randomly generated public key
• the "HASH" value in "c" is calculated as $$HASH = SM3(x || m || y)$$, where x, y are x, y of Q
• output c's CipherText is the encrypted text, equal in length to the input plaintext.

GmSSL is compliant after all.

[randombit]

@ronaldtse OK I just switched ordering of SM2 in botan master, this does mean RNP against 2.2 won't interop against (upcoming) 2.3, but probably not a huge concern as long as everyone knows which version they want.

I did not use the ASN.1 structure because (as I interpreted the doc) that is "here is how to encode an SM2 ciphertext, if you want to use ASN.1" vs "this is the one single correct way to encode an SM2 ciphertext". And there is not much reason I can see to use the ASN.1 encoding in PGP.

[randombit]

Oh but I missed 'c is represented in the format defined in 7.2' so maybe ASN.1 is the one true format for SM2 ciphertexts?

[ronaldtse]

It is the one true format but in OpenPGP it seems that only identifiers use ASN.1, not ciphertext? I suppose if we use ASN.1 for SM2 ciphertext we have the additional benefit of being compliant with one more GB standard (and the GM/T 0012 standard).