Some time ago, I did DES encryption and decryption, using the DES algorithm under javax. It is very fast to write under windows. Now when deploying to linux for testing, the team leader found , and asked me for The gross test data cannot be decrypted! What JB Mao algorithm did you write! Coming soon to the test! You give me a magic horse!
Heaven and earth conscience, I tested it very well, and I even pulled out that small class and put it on the server and ran! I helped my glasses and quickly started to change them. After searching for a long time, I found that the reasons are as follows:
1. The DES algorithm written under windows is very elegant, but in front of the serious uncle of linux, everything is a cloud, and random numbers are generated.
SecureRandom secureRandom = SecureRandom.getInstance();Need to add a limit, change it to
SecureRandom secureRandom = SecureRandom.getInstance("SHA1PRNG" );
2. The above is only the first step, and it still doesn't work, so I replaced the key generation from KeyGenerator to SecretKeyFactory, but everything is a cloud, and linux still tells me that Given final block is not properly padded. As soon as he turned his face, the team leader's face was almost stretched to Tokyo, so he continued to investigate.
3. In the third step, I thought, is it caused by DES complement? So I changed the padding rule to "DES/ECB/PKCS5Padding", and it was done. The team leader left without saying anything.
To sum up, when the DES algorithm encrypts a string with a number of less than a multiple of 8 digits, it does not fill in bits. The filling method is determined by the programmer. I arbitrarily wrote the NoPadding mode under Windows, that is, the filling method is Add \0 or space, and then trim; the previous test data was generated under windows, when linux took it over to decrypt it, I wiped it, what was it, I threw it away and reported an error; it was changed to the filling method After it is "DES/ECB/PKCS5Padding", that is, PKCS5Padding mode, both windows and linux follow the same set of padding methods. Before encryption, the length of the data bytes is 8. If the remainder is greater than 0, then a few bytes will be added. Byte, the byte value is the number of bytes to be supplemented. If it is 0, 8 of 8 bytes will be added. After decryption, the last byte will be taken. If the value is m, m bytes will be deleted from the end of the data, and the remaining The data is the original text before encryption.
As for
SecureRandom secureRandom = SecureRandom.getInstance("SHA1PRNG" );
Why add
"SHA1PRNG"
, because for direct use
SecureRandom secureRandom = SecureRandom.getInstance();What is written in the java document is Constructs a secure random number generator (RNG) implementing the default random number algorithm. In this way, the default pseudo- random number generation algorithm of linux and windows is different. Linux uses /dev/random to generate pseudo-random numbers, and of course /dev/urandom is a low-intensity copy of /dev/urandom; it is not the case in windows, which uses two algorithms , CryptGenRandom and RtlGenRandom . It is estimated that this is the reason why the "SHA1PRNG" strong random seed algorithm needs to be used when cross-platform! However, even so, the java documentation mentions that there is a thing for formulating a pseudo-random number algorithm provider, such as writing
SecureRandom secureRandom =SecureRandom.getInstance("SHA1PRNG","SUN");
It means to tell the system to use the strong random seed algorithm provided by SUN. However, the implementation of SUN is different from that of Apache. If it is not good, it will be messed up. Therefore, it is generally not necessary to provide a provider, and I hope there is no problem between the systems.
Well, there is the question of the second step, whether to use KeyGenerator or SecretKeyFactory. To tell the truth, these two basically did not play a role in solving this problem, but it is necessary to talk about it. The generation of keys is explained in ORACLE's Standard Algorithm Name Documentation . Let's talk about four first, KeyGenerator, SecretKeyFactory, KeyFactory, and KeyPairGenerator. Among them, KeyGenerator and SecretKeyFactory are both under the javax.crypto package and are mainly provided for symmetric and irreversible encryption algorithms. Among them, KeyGenerator is mainly provided for non-reversible algorithms, and SecretKeyFactory is mainly provided for symmetric encryption algorithms; KeyFactory and KeyPairGenerator are in the java.security package. , mainly for asymmetric encryption algorithms.
OK, figured it out this time