Re: Committing PEFS to CURRENT

On Mon, Oct 7, 2013 at 4:17 PM, John-Mark Gurney <jmg_at_funkthat.com> wrote:
> Gleb Kurtsou wrote this message on Mon, Oct 07, 2013 at 09:31 -0700:
>> Patch is available here:
>> https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch
>
> Is there a reason you are writing your own AES-NI implementation instead
> of using the OpenCrypto framework?

It reuses the same AES-NI implementation used by opencrypto,
but code doesn't use opencrypto directly. Main limitation in opencrypto is
that is incomplete implementation AES-XTS -- it doesn't implement ciphertext
stealing. opencrypto contexts seemed to be too much overhead list time I
looked at them especially in the case of multiple keys per file system in PEFS.
AES-NI interface is not designed to be used outside of opencrypto thus
some minor copy-past.


> I updated the kernel's AES-NI implementation to have a very fast
> AES-XTS...   Upon looking at your implementation, you have a very
> slow implementation as you do not pipeline AES-XTS at all...  Please
> switch to using the opencrypto version..  You'll then be able to make
> use of any accelerators that other platforms may have...

I was looking into incorporating AES_XTS pipeline changes in PEFS.
I'd like to avoid switching to opencrypto at this point. But pipelining is
doable without opencrypto and copying code around.


> Are there plans to add authentication to this scheme?  See that as a
> todo, but w/o authentication, you can't store anything reliably on it..
> And w/ XTS, the attacker can take pot shots at your file in 16 byte
> chuncks...

I have data authentication prototype. It's too far from being complete,
and I keep working on it as time permits. There are a few more ideas
I'd like to work on while redesigning the file system.

Patch also includes hmac and pkcs5v2 implementations which in fact
were generic versions to go under sys/crypto until yesterday.
Considering we are late in code freeze already I've merged them
into PEFS not to touch geli code with the patch.


> The only reason I'm running zfs on geli w/o authentication is that I'm
> using a 256bit checksum, so the chances of someone modifing two blocks
> to fool zfs into decrypting the correct new checksum value for their
> modified block is very small...  In short, I'm trusting zfs to do the
> authentication for me...
>
> --
>   John-Mark Gurney                              Voice: +1 415 225 5579
>
>      "All that I will do, has been done, All that I have, has not."