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.
OpenPGP_0x4E72AF09097DAE2E.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
