maria-developers team mailing list archive

[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