On 2021/10/26 17:33, Yura Sokolov wrote:
> Yes, AES with AES-NI is fastest. But not so much.
>
> And, AES-CTR could be easily used instead of ChaCha12 in Adiantum.
> Adiantum uses ChaCha12 as a stream cipher, and any other stream cipher will
> be ok as well with minor modifications to algorithm.
not so much ~= half speed.
I prefer to use AES on all devices because AES is faster and more power
efficient. using chacha only on low-end arm devices running complex
program which most people do not have this device.
I reserve my opinion on this point, but I agree with you on the rest.
And I also agree and think it should add more algorithms. The current
implementation does not have any reserved fields, which makes any
upgrade like adding a new algorithm unfeasible.
On 2021/10/26 17:33, Yura Sokolov wrote:
> That is argument. But, again, openssl could be used for primitives:
> AES + AES-CTR + Poly/GCM. And Adiantum like construction could be
> composed from them quite easily.
implement Adiantum is a small problem (which doesn't look good, lack
security audits). the real problem is there are too many code path can
trigger disk IO.
TDE need modify them. each code path has different behavior (align or
unaligned, once or more than once). and front-end tools even not use VF
layer, they use pread with offset. TDE need fix them all. at the same
time, keep the patch small enough.
I still think there need a unified IO API, not only modify
BufFileDumpBuffer() and BufFileLoadBuffer(). the front-end tools also
use this API will be great. with that API, TDE can focus on block IO.
then give out a small patch.
Other works can also benefit from this API, like PostgreSQL with AIO,
PostgreSQL on S3 (BLKSZ=4M), PostgreSQL on PMEM(no FS) and many.
