Merge lp:~gl-az/percona-xtrabackup/BT23557-bug1185343-2.1 into lp:percona-xtrabackup/2.1
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Alexey Kopytov | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 683 | ||||
Proposed branch: | lp:~gl-az/percona-xtrabackup/BT23557-bug1185343-2.1 | ||||
Merge into: | lp:percona-xtrabackup/2.1 | ||||
Diff against target: |
493 lines (+199/-27) 8 files modified
src/ds_encrypt.c (+12/-3) src/xbcrypt.c (+26/-8) src/xbcrypt.h (+12/-7) src/xbcrypt_common.c (+22/-1) src/xbcrypt_read.c (+81/-5) src/xbcrypt_write.c (+13/-3) test/inc/decrypt_v1_test_file.txt (+9/-0) test/t/xbcrypt.sh (+24/-0) |
||||
To merge this branch: | bzr merge lp:~gl-az/percona-xtrabackup/BT23557-bug1185343-2.1 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Alexey Kopytov (community) | Approve | ||
Review via email: mp+191675@code.launchpad.net |
Description of the change
Fix for https:/
In order to fix this in the safest possible way, followed general advice from various sources but summed up nicely here:
"An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. However, in most cases, it is important that an initialization vector is never reused under the same key. For CBC and CFB, reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared by the two messages. For OFB and CTR, reusing an IV completely destroys security. This can be seen because both modes effectively create a bitstream that is XORed with the plaintext, and this bitstream is dependent on the password and IV only. Reusing a bitstream destroys security. In CBC mode, the IV must, in addition, be unpredictable at encryption time; in particular, the (previously) common practice of re-using the last ciphertext block of a message as the IV for the next message is insecure (for example, this method was used by SSL 2.0). If an attacker knows the IV (or the previous block of ciphertext) before he specifies the next plaintext, he can check his guess about plaintext of some block that was encrypted with the same key before (this is known as the TLS CBC IV attack)." - http://
This fix advances the XBCRYPT chunk header version and adds an iv field to store the iv that was used to encrypt that block.
On decryption, if the XBCRYPT version is 1 then the original fixed iv is used to decrypt, otherwise the iv in the block header is used.
On encryption, for each block being encrypted, an iv of the correct length is generated by using values returned from random() until the iv has been fully populated. This iv will be written into the XBCRYPT chunk header along with its size.
One new test case added, xbcrypt.sh. Added two files in inc: decrypt_
1 - Tests that a file can go through an encryption/
2 - Tests that a file previously encrypted with and earlier version can be decrypted witht he current version.
http://