Support asymmetric/public-key encryption

There is a need to introduce the concept of parallel asymmetric encryption (a.k.a. public key encryption) to XtraBackup which would operate in a similar manner to the existing symmetric (AES) encryption.

Public key encryption refers to a cryptographic algorithm which requires two separate keys: one of which is secret, or private; and one of which is public. Although different, the two parts of this key pair are mathematically linked. The public key is used to encrypt a data payload; whereas the private key is used to decrypt the data payload. The term "asymmetric" stems from the use of different keys to perform these opposite functions, each the inverse of the other – as contrasted with conventional ("symmetric") cryptography which relies on the same key to perform both.

Due to the mathematically intense nature of asymmetric encryption and greater required equivalent key sizes, most current implementations use a hybrid approach where a random key is generated and encrypted via asymmetric encryption along with other metadata. The random key is then used to encrypt the data payload via a symmetric encryption algorithm. This offers both the benefits of public key encryption and the performance and security of symmetric encryption. This same method will be employed by XtraBackup.

Currently, XtraBackup makes use of the libgcrypt library (http://www.gnupg.org/documentation/manuals/gcrypt) to perform the symmetric encryption. libgcrypt also supports a full suite of asymmetric encryption functions from key generation and management, random number generation, encryption and decryption. Unfortunately the libgcypt key formats are incompatible with other common RSA/DSA keys used in ssh and gnupg (gpg) and no fully portable mechanism exists to integrate any of these keys with libgcrypt without having to write various new parsing and conversion mechanisms.

For the initial implementation, only the RSA algorithm will be utilized.

A note on asymmetric key sizes from Wikipedia and NIST: “Asymmetric algorithm keys must be longer for equivalent resistance to attack than symmetric algorithm keys. As of 2002, an asymmetric key length of 1024 bits was generally considered the minimum necessary for the RSA encryption algorithm. As of 2003 RSA Security claims that 1024-bit RSA keys are equivalent in strength to 80-bit symmetric keys, 2048-bit RSA keys to 112-bit symmetric keys and 3072-bit RSA keys to 128-bit symmetric keys. RSA claims that 1024-bit keys are likely to become crackable some time between 2006 and 2010 and that 2048-bit keys are sufficient until 2030. An RSA key length of 3072 bits should be used if security is required beyond 2030. NIST key management guidelines further suggest that 15360-bit RSA keys are equivalent in strength to 256-bit symmetric keys.”

The following changes/additions will be made to XtraBackup in order to provide this feature:

- Add “-g N” option to xbcrypt to generate a new pair of public/private keys where N is the size of the key, in bits, to generate. If “-o NAME” is specified, this will become the base file path/name that the resulting keys will be placed in as NAME.pub and NAME.priv for the public and private key files respectively. If “-o NAME” is not specified, the public and private keys will be printed to stdout upon completion and can be captured, parsed and directed into whatever files the user desires. These key files will be required input to perform encryption and decryption when asymmetric encryption is used. Note: This may take quite a while to run and generate secure keys, several minutes at a minimum.

- Add RSA as a new encryption algorithm which will make use of the current --encrypt-key-file option on xtrabackup and xbcrypt as input to specify the public/private key file to be used to encrypt/decrypt.
+- Within the xtrabackup binary, there will be a new random AES256 key generated per encryption thread and it will be used only within that threads block encryption routine. Only this AES256 key will be encrypted with the RSA algorithm and the RSA encrypted result will be added to the XBCRYPT chunk header. The remainder of the chunk data will be encrypted with the AES256 algorithm using this AES256 key.
+- Within xbcrypt, there will be a new random AES256 key generated for each invocation of xbcrypt to encrypt a stream or file. Similar to above, only this AES256 key will be encrypted with the RSA algorithm and the RSA encrypted result will be added to the XBCRYPT chunk header. The remainder of the chunk data will be encrypted with the AES256 algorithm using this AES256 key.
+- This option will slightly increase the overall size of the resulting backup depending on the encrypt-chunk-size and overall number of chunks utilized but should be significantly faster than the RSA-FULL method.
+- To properly support the RSA algorithm, the XBCRYPT header version will need to be increased to version 3 (XBCRYPT03) to include the RSA encrypted AES256 key for each chunk.