maria-developers team mailing list archive

[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
>
>