We work with XtraDB in the first run and will extend it to others later on.
Am 19.09.2014 um 15:04 schrieb Roberto Spadim <robe...@spadim.com.br>: > Very nice :) working only with innodb or any engine? > > Em quinta-feira, 18 de setembro de 2014, Elmar Eperiesi-Beck > <el...@eperiesi-beck.de> escreveu: > Of course - we are working with high pressure on this topic. > Unfortunately, we had more problems than expected to get the code up and > running - BUT we made it! > > Currently we have managed to implement a primitive xor encryption on the page > level. We have solved some issues with checksums mainly by deactivating > checksum validation for encrypted pages. This is still work in progress. We > would rather want to recalculate checksums instead of deactivating them. > > We are now working on aes_cbc encryption. Problem with blockcyphers in > general ist hat the cypher text can be larger than the plaintext. This means > that the encrypted data will not fit into the default page size of 16k (4k or > 8k). This has to do with aes_cbc padding, which rounds up the size to a > divisor of the aes blocksize and in addition to that we need to store key id > and iv for the encrypted page and we need to remember the original values of > the non encrypted page. > > Currently we are using the FLUSH LSN field of the page header (Bytes 26-33) > and the old_style checksum (bytes 16376 – 16379) to store some of our data. > We are not quite sure if it is a good idea to reuse these fields. Maybe the > community can help with this question. > > We were also thinking about extending the original page header of 38 Bytes by > a crypto header. From our understanding it should be possible to extend the > header by X bytes whenever it is a crypto pagetype, leaving less space for > payload in that page. We do not yet know how to accomlish this and if it is a > good idea to do so. We might create more problems with extending a header > than we solve with it. From what we understand from page compression, > extending a header seems to be non trivial. > > We are always open to ideas of how to overcome these page size problems and > are willing to try different routes. > > So to sum it up - we think, that we are able to submit a first implementation > by beginning of october. > > > > -- > Roberto Spadim > SPAEmpresarial > Eng. Automação e Controle >
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
