maria-developers team mailing list archive

[Roberto Spadim <roberto@xxxxxxxxxxxxx>]

very nice, good work :)

2014-09-19 10:17 GMT-03:00 Elmar Eperiesi-Beck <elmar@xxxxxxxxxxxxxxxx>:

> 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 <roberto@xxxxxxxxxxxxx>:
>
> Very nice :) working only with innodb or any engine?
>
> Em quinta-feira, 18 de setembro de 2014, Elmar Eperiesi-Beck <
> elmar@xxxxxxxxxxxxxxxx> 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