Fixed IV used in Xtrabackup encryption
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Percona XtraBackup moved to https://jira.percona.com/projects/PXB |
Fix Released
|
High
|
George Ormond Lorch III | ||
| 2.1 |
Fix Released
|
High
|
George Ormond Lorch III | ||
| 2.2 |
Fix Released
|
High
|
George Ormond Lorch III | ||
| percona-xtrabackup (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
| Saucy |
Won't Fix
|
High
|
Unassigned | ||
| Trusty |
Fix Released
|
High
|
Unassigned | ||
Bug Description
Currently a fixed IV (constant string) is used while encrypting the data. This
opens the encrypted stream/data to plaintext attacks among
others.
Also, we use a CTR mode - GCRY_CIPHER_
stringent requirements on its IV - http://
So, we should either use CBC with a random IV (but its encryption
is not parallelizable, only decryption is) or CTR with a strong
IV.
Even just CTR with a random IV should be fine since - " With counter
mode, the rule is that you cannot reuse the same IV with the same key.
However, it is perfectly fine to use the same IV with different keys"
So, assuming we generate a random IV we should add either
a) Have it provided as a parameter in the stream (so other side
knows to decrypt it).
b) Without stream, put it in one of xtrabackup metadata files to
decrypt later.
Related branches
- Alexey Kopytov (community): Approve
-
Diff: 493 lines (+199/-27)8 files modifiedsrc/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)
- Alexey Kopytov (community): Approve
-
Diff: 493 lines (+199/-27)8 files modifiedxtrabackup/src/ds_encrypt.c (+12/-3)
xtrabackup/src/xbcrypt.c (+26/-8)
xtrabackup/src/xbcrypt.h (+12/-7)
xtrabackup/src/xbcrypt_common.c (+22/-1)
xtrabackup/src/xbcrypt_read.c (+81/-5)
xtrabackup/src/xbcrypt_write.c (+13/-3)
xtrabackup/test/inc/decrypt_v1_test_file.txt (+9/-0)
xtrabackup/test/t/xbcrypt.sh (+24/-0)
CVE References
| Raghavendra D Prabhu (raghavendra-prabhu) wrote | #1 |
| tags: | added: pxc |
| Sergei Golubchik (sergii) wrote | #2 |
| George Ormond Lorch III (gl-az) wrote | #3 |
| Changed in percona-xtrabackup (Ubuntu Trusty): | |
| status: | New → Fix Released |
| importance: | Undecided → High |
| Changed in percona-xtrabackup (Ubuntu Saucy): | |
| importance: | Undecided → High |
| status: | New → Triaged |
| Rolf Leggewie (r0lf) wrote | #4 |
| Changed in percona-xtrabackup (Ubuntu Saucy): | |
| status: | Triaged → Won't Fix |
| Shahriyar Rzayev (rzayev-sehriyar) wrote | #5 |
Regarding
>So, assuming we generate a random IV we should add either
>
>a) Have it provided as a parameter in the stream (so other side
>knows to decrypt it).
>
>b) Without stream, put it in one of xtrabackup metadata files to
>decrypt later.
This won't be required. The salt needs to be prepended (separated
by a delimiter) to the
encrypted stream/text (in case of text, in the beginning of the
file). This convention is used elsewhere as well - crypt(3),
openssh etc.