# 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://

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.

## Blueprint information

- Status:
- Not started

- Approver:
- Alexey Kopytov

- Priority:
- Undefined

- Drafter:
- George Ormond Lorch III

- Direction:
- Needs approval

- Assignee:
- George Ormond Lorch III

- Definition:
- Pending Approval

- Series goal:
- None

- Implementation:
- Unknown

- Milestone target:
- None

- Started by

- Completed by

### Related branches

### Related bugs

### Sprints

### Whiteboard

It would be very beneficial if this supported multiple recipient public keys (so you could support a mandatory recovery key for example) and an optional signing key (to verify a backup was intact).

Also, generating a new AES key and encrypting it with RSA for each chunk will be relatively expensive. If you can switch to an AES counter cipher (CTR or GCM) you can use the same key across different chunks so long as you also let the thread doing a particular chunk know what the starting offset is. See http://