very nice, good work :) 2014-09-19 10:17 GMT-03:00 Elmar Eperiesi-Beck <el...@eperiesi-beck.de>:
> 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 > > > -- 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