IOS study 15th: communication encryption

Communication encryption and decryption is basically a technology used by every client involving user information.

Generally, we may do simple anti-tampering and ciphertext encryption.

Most of the time, encryption is just a small psychological comfort, because from a purely security perspective, security is really not high.

For some mobile payment and UnionPay clients, I can see what certificates are useful for implementation.

Because I have never done it, I am not very familiar with it.

Let's talk about the simplest encryption scheme.

I. MD5 digital digest.

To be accurate, MD5 cannot be called encryption/Decryption because it is irreversible.

We generally understand that encryption and decryption can be encrypted and then decrypted.

MD5 only generates a verification code based on the data. After the data recipient receives the content, it also uses MD5 to generate the verification code and compare it with the previous verification code,

To determine whether the data has been intercepted or tampered during transmission.

To put it bluntly, in fact, in the transmission process, only the MD5 Technology, the data is plain text.

Next, let's take a look at the support for MD5 encryption in IOS.

Const char * original_str = [String utf8string]; // convert string to Char/*** system API ~~~~ * ***/Unsigned char result [cc_md5_digest_length]; cc_md5 (original_str, strlen (original_str), result ); // call the system MD5 encryption nsmutablestring * hash = [[nsmutablestring string] autorelease]; for (INT I = 0; I <16; I ++) [hash appendformat: @ "% 02x", result [I]; return hash; // check code

The code is simple, because internal algorithms are completed by the system.

For the above, ciphertext transmission is still not well processed, but a simple anti-tampering mechanism has been made in the data transmission process.

Therefore, a security mechanism class that can generate ciphertext is required.

Ii. 3DES encryption in IOS

3DES is a symmetric encryption method because it uses the same key.

For information about encryption and decryption security, refer to Google and Baidu.

I am simply talking about a feasible solution in communication encryption.

The same 3DES encryption is basically uniform, and the system also provides APIs directly. The basic code is as follows:

// 3DES encryption and decryption + (nsstring *) tripledes :( nsstring *) plaintext encryptordecrypt :( ccoperation) plaintext {const void * vplaintext; size_t plaintextbuffersize; If (Signature = kccdecrypt) // decrypt {nsdata * encryptdata = [gtmbase64 decodedata: [plaintext datausingencoding: Encrypted]; plaintextbuffersize = [encryptdata length]; vplaintext = [encryptdata bytes];} else // encrypt {nsdata * Data = [p Laintext plaintext: plaintext]; plaintext = [Data Length]; vplaintext = (const void *) [data bytes];} cccryptorstatus ccstatus; uint8_t * bufferptr = NULL; size_t bufferptrsize = 0; size_t movedbytes = 0; bufferptrsize = (plaintextbuffersize + kccblocksize3des )&~ (Kccblocksize3des-1); bufferptr = malloc (bufferptrsize * sizeof (uint8_t); memset (void *) bufferptr, 0x0, bufferptrsize ); // memset (void *) iv, 0x0, (size_t) sizeof (IV); const void * vkey = (const void *) [cipher ey utf8string]; // nsstring * initvec = @ "init VEC"; // const void * vinitvec = (const void *) [initvec utf8string]; // byte IV [] = {0x12, 0x34, 0x56, 0x78, 0x90, 0xab, 0xcd, 0xef }; ccstatus = cccrypt (encryptordecrypt, encrypt, decrypt | kccoptionecbmode, vkey, encrypt, nil, vplaintext, plaintextbuffersize, (void *) bufferptr, bufferptrsize, & movedbytes ); // If (ccstatus = kccsuccess) nslog (@ "success");/* else if (ccstatus = KCC paramerror) return @ "Param error "; else if (ccstatus = kccbuffertoosmall) return @ "buffer too small"; else if (ccstatus = success) return @ "memory failure"; else if (ccstatus = kccalignmenterror) return @ "alignment"; else if (ccstatus = kccdecodeerror) return @ "decode error"; else if (ccstatus = kccunimplemented) return @ "unimplemented "; */nsstring * result; If (encryptordecrypt = kccdecrypt) {result = [[nsstring alloc] initwithdata: [nsdata datawithbytes :( const void *) bufferptr length :( nsuinteger) movedbytes] encoding: bytes] autorelding];} else {nsdata * mydata = [nsdata datawithbytes :( const void *) bufferptr length :( nsuinteger) movedbytes]; Result = [gtmbase64 Bytes: mydata];} return result;

The detailed code can also be found online.

Note that:

CCCrypt(encryptOrDecrypt,                       kCCAlgorithm3DES,                        kCCOptionPKCS7Padding | kCCOptionECBMode,                       vkey,                        kCCKeySize3DES,                       nil,                        vplainText,                       plainTextBufferSize,                       (void *)bufferPtr,                       bufferPtrSize,                       &movedBytes);

The parameters in this section may need to be adjusted based on the parameters of the 3DES algorithm used by your server.

For example, the third parameter I saw on the Internet only uses kccoptionpkcs7padding, and the sixth Optional parameter uses the above custom IV.

However, according to the server, this parameter is nil.

The Java-side encryption and decryption code is also attached here.

Public String encryptthreedesecb (string SRC, string key) throws exception {desedekeyspec DKS = new desedekeyspec (key. getbytes ("UTF-8"); secretkeyfactory keyfactory = secretkeyfactory. getinstance ("desede"); secretkey securekey = keyfactory. generatesecret (DKS); cipher = cipher. getinstance ("desede/ECB/pkcs5padding"); cipher. init (cipher. encrypt_mode, securekey); byte [] B = cipher. dofinal (SRC. getbytes (); base64encoder encoder = new base64encoder (); Return encoder. encode (B ). replaceall ("\ r ",""). replaceall ("\ n", "") ;}// 3desecb for decryption, The key must be a length greater than or equal to 3*8 = 24-bit Public String decryptthreedesecb (string SRC, string key) throws exception {// -- convert the string to byte array base64decoder decoder = new base64decoder () through base64; byte [] bytesrc = decoder. decodebuffer (SRC); // -- decrypted key desedekeyspec DKS = new desedekeyspec (key. getbytes ("UTF-8"); secretkeyfactory keyfactory = secretkeyfactory. getinstance ("desede"); secretkey securekey = keyfactory. generatesecret (DKS); // -- chipher object decryption cipher = cipher. getinstance ("desede/ECB/pkcs5padding"); cipher. init (cipher. decrypt_mode, securekey); byte [] retbyte = cipher. dofinal (bytesrc); return new string (retbyte );}

There are few contents.

Then there is a key, that is, the client and server that share the key save one.

In simple terms, ciphertext transmission improves the security of data transmission.

However, if the client code is cracked, the key is actually exposed.

This is for Android, because the amount of decompilation is pure, security is not flattering,

IOS looks better, because I have not heard of decompiling IOS apps.

The above is a simple communication encryption solution.

Of course, these are actually general technologies ~