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.

_______________________________________________
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

Reply via email to