Closed ronaldtse closed 7 years ago
@ronaldtse Ouch. OK well no change required in RNP proper, I will push a change for botan SM2.
Thanks @randombit. When I saw "123" I thought -- I remember the sequence wasn't not straightforward like that... ðŸ˜
@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)
@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...
Ah, messy. OK let me know when you can confirm.
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:
GmSSL is compliant after all.
@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.
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?
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).