Use Microsoft CryptoAPI for encryption, decryption, signing and verification
Use CryptoAPI write a file protection program having the following functions:
(1) Given a plaintext file, generates an encrypted file, generating a digital signature file; and
(2) given ciphertext file, decrypting the plaintext file and signature verification correctness.
Code: See attached main.cpp
I. Overview of procedure
a) Development Platform: Visual Studio 2005
b) development languages: C / C ++
c) using a password library: CryptoAPI
Second, the main function of
a) the main function
void main (void)
b) encrypted file
BOOL EncryptFile (PCHAR szSource, PCHAR szDestination, PCHAR szPassword);
C) to decrypt the file
BOOL DecryptFile (PCHAR szSource, PCHAR szDestination, PCHAR szPassword);
D) signature file
BOOL the SignFile (PCHAR szSource, PCHAR szDestination);
E) to verify the signature
BOOL VerifyFile (PCHAR szSource, PCHAR szDestination );
F) error handling
void HandleError (char * s);
Third, the encrypted file
a) open the source file
hSource = the fopen (szSource, "RB")
B) made key container (CSP) handle
the CryptAcquireContext (& hCryptProv, NULL, NULL, PROV_RSA_FULL, 0)
C) to create a user-entered password is session key (i.e. symmetric key used to encrypt the original file)
// create a hash object
the CryptCreateHash (hCryptProv, CALG_MD5, 0, 0, & hHash)
// generates a hash of the user password entered
CryptHashData (hHash, ( * BYTE) szPassword, strlen (szPassword), 0)
// generates a session key by hashing
the CryptDeriveKey (hCryptProv, ENCRYPT_ALGORITHM, hHash, keylength, & hKey))
// destroy hash object
CryptDestroyHash (hHash);
NOTE: session key i.e. symmetric key, for encrypting the original document; asymmetric key for efficiency is very low, it is generally not used to directly encrypt the data, but the session key is encrypted, and then transmits it to the other side. The other party to decrypt the session key is obtained by an asymmetric key, and then decrypt the data file. As can be seen, the lifetime of a session key can be limited in this communication, that is, each communication session with a different encryption key, rather than symmetric key must be long-term use. In this embodiment, the encryption and decryption process is not used in the RSA asymmetric key pair, but it is only used to verify the signature and the digital.
d) the encrypted data file
the CryptEncrypt (
hKey, key //
0 // if simultaneous data encryption and hashing, where a hash object passing
feof (hSource), // if it is the last encrypted block input TRUE. If it is not input
// here FALSE if the end of the file to determine whether a final determination by
0, // reserved
pbBuffer, // input data is encrypted, the encrypted data output
& dwCount, // the actual input data to be encrypted length, and outputs the encrypted data length
dwBufferLen) // pbBuffer size
Note: the complete code can be found which is a cyclic encryption process, pbBuffer cyclic memory block of a fixed length encrypted file to be read; of course you can also pbBuffer set very large, once read the entire document, but as a waste of memory space, and the impact scalability (there may be a buffer overflow).
e) cleanup, such as the release Buffer space key handle, handle the CSP and the like.
IF (pbBuffer)
Free (pbBuffer);
IF (hKey)
the CryptDestroyKey (hKey);
IF (hHash)
the CryptDestroyHash (hHash);
IF (hCryptProv)
CryptReleaseContext(hCryptProv, 0);
…
Fourth, the decrypted file
a) open the encrypted file (ibid.)
B) made key container (CSP) handle (supra)
C) creates a session key (i.e., a symmetric key from a password input by the user, for decryption of the original file) (ibid.)
NOTE: this requires a password input by the user with the encrypted password same time. In practice, this so-called input by the user "Password" is really just a produce seed key, once finished the session key is generated, the user can forget the original input "password", the recipient can use a key pass over decrypt the encrypted file directly, without having to repeat the process once the "generate key".
d) decrypting the data file
the CryptDecrypt (
hKey, key //
0 // if simultaneous data encryption and hashing, where a hash object passing
feof (hSource), // if it is the last encrypted block input TRUE. If it is not input.
// here FALSE if the end of the file is determined by determining whether the last one.
0, // reserved
pbBuffer, // input data is encrypted, the encrypted data output
& dwCount)) // input is the actual length of the encrypted data, the encrypted output data length
e) cleanup, such as the release Buffer space key handle, handle the CSP and the like. (Ibid.)
Fifth, the signature file
a) open the source file (ibid.)
B) obtain key container (CSP) handle (ibid)
c) obtain the signature key handle (asymmetric RSA keys)
CryptGetUserKey (
hCryptProv, // handle CSP we've got
AT_SIGNATURE, // here want Key pair Signature
& hKey)) // returns the key handle
d) Export signature key pair of the public key, stored in the pbKeyBlob
CryptExportKey (hKey, NULL, a PUBLICKEYBLOB, 0, pbKeyBlob, & dwBlobLen)
Hash value e) calculating the data file stored in the Hash object hHash
// creates an empty Hash object
CryptCreateHash (hCryptProv, CALG_MD5,0,0, & hHash)
// calculated Hash value of the data file stored in the object Hash
the CryptHashData (hHash, pbBuffer, dwCount -, 0)
F) Hash value of the data file to be signed, a digital signature is stored in pbSignature in
CryptSignHash (hHash, AT_SIGNATURE, NULL, 0, pbSignature, & dwSigLen)
G) cleanup, such as the release Buffer space key handle, handle the CSP and the like. (Ibid.)
Sixth, the signature verification
a) open the file (ditto)
b) obtaining the key container (CSP) handle (supra)
C) introduced pbKeyBlob public
CryptImportKey (hCryptProv, pbKeyBlob, dwBlobLen, 0, 0, & hPubKey)
NOTE: Must be used with signature private key pair of the public key in this embodiment, when the public key to generate a digital signature has been exported in pbKeyBlob.
d) calculating the Hash value of the data file, stored in the Hash object hHash. (Ibid.)
E) verifies the digital signature
CryptVerifySignature (hHash, pbSignature, dwSigLen, hPubKey, NULL, 0)
f) clean-up work, such as the release Buffer space key handle, CSP handles and so on. (Ibid.)
Seven, results
// encrypt files
Encrypt a file.
Enter the name of the file to be encrypted: 1.txt
Enter the name of the output file: 2.txt
Enter the password:123456
The source plaintext file, 1.txt, is open.
Destination file 2.txt is open.
A cryptographic provider has been acquired.
A hash object has been created.
The password has been added to the hash.
An encryption key is derived from the password hash.
Memory has been allocated for the buffer.
Encryption of the file 1.txt was a success.
The encrypted data is in file 2.txt.
// decrypt files
Decrypt a file.
Enter the name of the file to be decrypted: 2.txt
Enter the name of the output file: 3.txt
Enter the password:123456
The source plaintext file, 2.txt, is open.
Destination file 3.txt is open.
A cryptographic provider has been acquired.
A hash object has been created.
The password has been added to the hash.
An encryption key is derived from the password hash.
Memory has been allocated for the buffer.
Decryption of the file 2.txt was a success.
The decrypted data is in file 3.txt.
// Digital Signature
Sign a file.
Enter the name of the file to be signed: 1.txt
Enter the name of the signature file: 11
The source plaintext file, 1.txt, is open.
Memory has been allocated for the buffer.
Destination file 11 is open.
A cryptographic provider has been acquired.
A signature key is available.
Size of the BLOB for the public key determined.
Memory has been allocated for the BLOB.
Contents have been written to the BLOB.
Hash object created.
The data buffer has been hashed.
Signature length 128 found.
Memory allocated for the signature.
pbSignature is the hash signature.
The hash object has been destroyed.
The signing phase of this program is completed.
Signature of the file 1.txt was a success.
The signature data is in file 11.
// verify the signature
Verify a file and its signature.
Enter the name of the file to be verified: 1.txt
Enter the name of the signature file: 11
The source plaintext file, 1.txt, is open.
Memory has been allocated for the buffer.
A cryptographic provider has been acquired.
The key has been imported.
The hash object has been recreated.
The new has been created.
The signature has been verified.
Verification of the file 1.txt was a success.
Reproduced in: https: //my.oschina.net/kivensoft/blog/549369