maria-developers team mailing list archive

[Elmar Eperiesi-Beck <elmar@xxxxxxxxxxxxxxxx>]

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.