Message Cryptography FAQs
Back

From WeChat Official Account Admin Platform
Jump to: navigation, search

Message Encryption/Decryption FAQs

Q: What is the purpose of message encryption function?

A: To help ensure the security of official accounts and their followers.

Q: Is it complex to implement encryption/decryption?

A: It is easy to implement this function. The WeChat team provides code samples. Follow the Implementation Guide to call functions on the WeChat Official Account System based on the code samples. For developers using other languages, review 'Technical Solution' to implement code.

Q: Which important changes result from implementing encryption/decryption?

A: Important changes are as follows:

  • If plaintext mode is selected, message transmission will not change but security cannot be guaranteed. The WeChat team advises developers to develop and debug in compatibility mode and upgrade to security mode after debugging is completed.
  • If compatibility mode is selected, a message is provided as both plaintext and encrypted text, so the message length is nearly doubled. Developers should check their system and avoid generating errors caused by overly long messages.
  • In compatibility or security mode, the WeChat Official Account System will add two parameters to the server URL for the developer's backend system when it pushes messages.
  • In security mode, message is encrypted text. Developers should prepare for message decryption and reply encryption.

Q: What is EncodingAESKey?

A: EncodingAESKey is the encryption key for the AES symmetric encipherment algorithm that the WeChat Official Account System uses to encrypt messages to be pushed to the developer's backend. Developers should use this key to decrypt messages and encrypt reply messages.

Q: How do I determine whether a message is encrypted or not? When does a reply message need encryption?

A: The URL parameter encrypt_type provides this information. If an URL does not contain encrypt_type or its value is raw, the message is a plaintext message, so the developer's backend should reply with a plaintext message. If its value is 'aes', the message is an encrypted message. The developer's backend system should reply with an encrypted message (in compatibility mode, either plaintext or encrypted messages are acceptable).

Q: Is it necessary to save decryption and encryption code after an official account encryption/decryption function goes into production?

A: It is recommended to temporarily save the code. It is better to use the compatibility mode based on parameters.

Q: Common errors A: Reasons for common errors are as follows:

  • The XML formatting is incorrect, e.g., <TimeStamp> is written as <Timestamp > (S is written in lowercases and a space is reserved between p and >).
  • The WeChat Official Account Admin Platform allows developers to change EncodingAESKey. It is recommended that developers save the current and prior EncodingAESKey so that the prior key can be used if decryption based on the current key fails. When replying, the key used for encryption must be identical to the one used for decryption.
  • When the DecryptMsg API is called for decryption, the URL parameter msg_signature, rather than the signature is entered.
  • Java JDK version 1.6 or higher is required.
  • Solution to java.security.InvalidKeyException:illegal Key Size: Download the JCE unlimited policy file from the official Java website. Be sure to download the required version from the corresponding URL. For example, JDK7 download URL: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html) and decompress the package. The package contains local_policy.jar, US_export_policy.jar, and readme.txt. If JRE is installed locally, put the two .jar files in the %JRE_HOME%\lib\security directory and overwrite the original files; if JDK is installed locally, put the two .jar files in the %JDK_HOME%\jre\lib\security directory and overwrite the original files.
Developer Guide
Custom-defined Menu
WeChat JS-SDK