maria-developers team mailing list archive

[Roberto Spadim <roberto@xxxxxxxxxxxxx>]

Very good news

Em terça-feira, 23 de setembro de 2014, Jonas Oreland <jonaso@xxxxxxxxxx>
escreveu:

> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','maria-developers@xxxxxxxxxxxxxxxxxxx');>
>> Unsubscribe : https://launchpad.net/~maria-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>

-- 
Roberto Spadim
SPAEmpresarial
Eng. Automação e Controle