lineage of KDF

[rain-1]

This KDF seems to be a homebrew thing https://github.com/skeeto/enchive/blob/master/src/enchive.c#L664

why not use scrypt?

how was this particular KDF designed? is it based on some literature? no links to references are provided in the source. Thanks!

[skeeto]

Being highly-portable and standalone was a core goal. To achieve this, I used drop-in implementations of Curve25519, SHA256, and ChaCha20. The latter two are even in the public domain (like Enchive itself), making them just perfect. Since I couldn't find a drop-in implementation of any memory-hard KDF, I designed this one myself. So, yes, it's homebrew. It's not based on any other design. I wanted something relatively simple that couldn't reasonably be optimized beyond a very straightforward implementation. If the memory-hard property _can_ somehow be bypassed, it is, at worse, equivalent to millions of iterations of SHA256: e.g. essentially the best KDF available in GnuPG for protection keys. I talked about my overall goals in these articles (which should perhaps be linked from the README): https://nullprogram.com/blog/2017/03/12/ https://nullprogram.com/blog/2018/04/13/

[xorhash]

Since I couldn't find a drop-in implementation of any memory-hard KDF, I designed this one myself. So, yes, it's homebrew.

You may be interested in Monocypher. monocypher.c is just one source file with a bit less than 2000 lines and provides you with argon2i, (optionally AEAD) ChaCha20, a wrapped X25519, BLAKE-2 and more, while using nothing of the C stdandard library. You may be interested in switching to that. The licensing is CC0, alternatively 2-clause BSD, so that should work in as more or less a drop-in replacement.

[skeeto]

Thanks for the heads up. It looks like Monocypher was first released the same week I broke ground on Enchive. I wish I had discovered it at the time.