RSA in Android, VC, Java encryption and decryption to achieve interoperability.

Recently, the company's project needs to upload/download data to AES+RSA encryption and decryption requirements, the client has the VC RSA encryption interface, and said to be compatible with their system, that is, VC to use their module to implement encryption and decryption. During the process there are several pits, the reason is that they are not familiar with these cryptographic protocols/guidelines/specifications, recorded in this article.

Pit 1:

First of all, Baidu Java rsautils, online a lot of ready-made, such as: http://www.2cto.com/kf/201408/328112.html, public key use X509 resolution class, the private key uses Pkcs#8 parsing class. Write a test program everything is OK ...

Then is to debug customer-provided VC module, test procedures such as

Then went to Rsa_encrypt when the error occurred, lack of 0xc0000005 unknown error. (Definitely not output not allocated memory or out of memory-_-!! This is a bit difficult to do, call to consult each other, the other side said to follow the OpenSSL standard generated key Oh ~ and then I embarrassed back he said, I was using your demo generated key into the interface used, will also error? Then the other side also despised me for a moment to say that you sent your test program to see.

After the last half hour, the other side returned to me.

And then said: The above approach is correct, but if you pass the key or the private key string parameters, you need to maintain the format, such as in the VC you can add a \ n after each line, if you read the entire text is maintained after each line is \ r \ n, this is the standard PEM format requirements, In fact, if you use the OpenSSL command line to generate a key pair and save as text, it is also separated by \ n, the direct text open is not see carriage return line.

Well, the above sentence is pit 1 conclusion, said above: With the traditional Notepad open with OpenSSL generated PEM is really not the format of a string, and may be a Java tool class inside the string has been processed in the format of the key, The actual application of hard-coded or test will make the first impression of my small white error, and the interface of OpenSSL need to maintain this text format to parse successfully.  Also, the begin and end also need to be written in!!! Pit 2 Good, since Java has a tool class, VC has interface, that is to achieve mutual decryption it ~ First VC with public encryption, Java with Privatekey decryption, nn. In practice, however, there are all sorts of unknown reasons, and it is not so wrong to know. First of all, the encryption of the content of the world 99.99% of people are using Base64 to encode it, decryption before you need to use this string of Base64 decoding to restore, hmm. Using the client-side provided by the demo generated public-private key pair, VC encryption after the encrypted content to the Java platform, and then Java using Privatekey decryption, unfortunately, the Java decoding failed, the cause of the error is Privatekey resolution is not successful, this is not touched the mind, Isn't that all about the standard of OpenSSL? Sun's not going to come up with another standard? Confusion for a while, carefully check the log is PKCS8 coding error, and then Baidu Pkcs8 why things, straight call me life and death Xu ~.~http://bbs.csdn.net/topics/190044123 <--- This link explains the classification of these keys in detail, and then sees the introduction to the PKCS series, and then http://blog.csdn.net/jdsjlzx/article/details/41441147 the brother says: The key is basically generated, However, the private key of the key pair is not directly used in the code, and to use it requires the help of the Rsaprivatekeystructure class, Java is not self-contained. So for ease of use, we need to have a private key PKCS#8 encoding!!!  Then a guess appeared in my mind, in my dreams, in my heart, in my records ... is not the VC not according to Pkcs#8? Call customer side, get reply is: not pkcs#8, but do not remember is pkcs#12 or what. =_= OK, and then see where pkcs#12 is sacred, link I will not be attached. The egg hurts, pkcs#12 is the protocol of the certificate and with the password ah, you just a key string, where is this?   Once again in the confusion of thinking calm down, the client has been said to comply with the OpenSSL standard, VC OpenSSL I am not useless, the most primitive Java can not use the Pem file is what format? After Baidu is pkcs#1, eh hum!? Here are the mystery, immediately search have no tools to change the pkcs#1 pkcs#8, http://tool.chacuo.net/cryptrsapkcs1pkcs8 <-This URL is to turn pkcs#1 's private key into the format of pkcs#8 , OK, use the VC demo again to generate a public-private key pair (assuming pkcs#1), and then extract the private key using the tool to generate a string of pkcs#8-formatted keys. Put in the Java test, decryption success!  summary under the pit 2:java existing tools are x509-pkcs#8 public-private key pair, and VC use OpenSSL is very primitive very open, blame the two sides did not communicate well, cause pit 21 series of trouble.      pit 3,android RSA hidden pit =_= According to the truth, Java System jar package can be found on Android, then why the Java platform RSA encryption and VC interoperability, Android failed? Android encrypted content sent to JAVA/VC decryption is an empty string? It is also strange that the content of JAVA/VC RSA encryption is random, why the string of the encrypted content of Android is the same? Search the following articles http://blog.csdn.net/yanzi1225627/article/details/26508035 and  http://blog.csdn.net/anod/article/ details/8734608 finally is this http://my.oschina.net/cwalet/blog/35867, and this http://juliusdavies.ca/commons-ssl/pkcs8.html (<-needs Fq .Slowly understand that Android virtual machines are really different from virtual machines on Windows. The most standard algorithm that comes with Android that contains only one default RSA is not populated with "rsa/ecb/nopadding"
Cipher Cipher = cipher.getinstance (Keyfactory.getalgorithm ());
So every time Android runs the same
And then this cipher provides you with a second parameter to replace the algorithm provider.
Cipher Cipher = cipher.getinstance ("rsa/ecb/pkcs1padding", New Org.bouncycastle.jce.provider.BouncyCastleProvider () );
This is filled by PKCS1 and is different every time. That's the difference.

Pit 3 Conclusion: speechless. 4 days from the need to communicate with clients to three platforms.

RSA in Android, VC, Java encryption and decryption to achieve interoperability.