← Back to team overview

maria-developers team mailing list archive

Re: [Maria-discuss] MariaDB encryption


Hi there,
we just managed to get the problems solved much faster as assumed. Thanks to the community!

Perhaps it makes sense to have just one crypto implementation to do not confuse users.
You can find our Source Code under: https://github.com/eperi-GmbH/server . As fork of the actual 10.1 Code base.

By end of this week we will finish the tests for the encrypted external key file and some other features and update the project. 
Please keep in mind, that you have to use the MariaDB Configfile. Please use the mode „innodb_file_per_table“ on the storage engine XtraDB.
To create an encrypt table you can use:
create table a (value varchar(100)) PAGE_ENCRYPTION=1 PAGE_ENCRYPTION_KEY=255;
For the encryption we use aes-128 cvc - until end of this week, it is a fixed key to make testing easier.

If you want to have page compression enabled also, you can use:
create table b (value varchar(100)) PAGE_ENCRYPTION=1 PAGE_ENCRYPTION_KEY=255 PAGE_COMPRESSED=1;
Example Configuration: 

Have fun with this implementation and feel free to play with it!
We are looking forward to your comments.

Am 23.09.2014 um 12:26 schrieb Jonas Oreland <jonaso@xxxxxxxxxx>:

> Hi there,
> our implementation  is in production :)
> but has not yet been open sourced due to other tasks consuming time :(
> it has solved all problems enumerated above...and I think it would be much better to have one crypt implementation than two!
> i'll ask the pavel that does the open-sourcing for more info about what is the current state.
> /Jonas
> On Fri, Sep 19, 2014 at 12:31 AM, Elmar Eperiesi-Beck <elmar@xxxxxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-developers
> More help   : https://help.launchpad.net/ListHelp

Follow ups