I would like to propose a new project I'm working on, maybe you'll find it useful and interesting
An encrypted file system in Rust that mounts with FUSE on Linux. It can be used to create encrypted directories.
You can then safely backup the encrypted folder on an untrusted server without worrying about the data being exposed.
You can also store it in any cloud storage like Google Drive, Dropbox, etc. and have it synced
Can be installed from AUR or test it out from docker hub (see more on GitHub)
In future will be available on other package managers like DEB, flatpak, snapcraft
Also planning to implement it for macOS, Windows, Android and iOS
ChaCha20 is widely recognized as secure. It and AES are the only ciphers allowed by TLSv1.3. TLSv1.3 no longer allows a lot of less secure ciphers that TLSv1.2 and lower allowed. If there was doubt about the security of ChaCha20, it wouldn't have been allowed by TLSv1.3.
There's an evidence that NSA is clever. IBM submitted its DES draft, NSA modified the matrix in IBM draft. After some years, cryptographer found it's easy to do differential cryptanalysis to IBM draft but NSA's version is resistant to that attack. I.e., NSA found the differential attack much earlier.
They also made NIST standardize Dual_EC_DRBG which is way slower than the alternatives and is suspected to have a backdoor the NSA can use. Some constants are supposedly randomly generated, but the NSA could have chosen a public key they know the private key for, which would allow them to rewind it and get the internal state.
NSA uses AES for National Security System (NSS), if it contains backdoor, someone outside NSA also has opportunity to find it. Furthermore, Kyber is NOT designed by NSA, it's designed by people from several countries including China, so NSA cannot design any backdoor for Kyber, which is designed by people. Kyber is a Lattice-based post-quantum KEM.
In case of Dual_EC_DRBG only the NSA would be enable to exploit the backdoor, which means that they aren't putting themself at risk.
How is Kyber related to this discussion? Rencfs doesn't use any asymmetric encryption. It used symmetric encryption with a key derived from the user password.
TBH, I think worries about state actor backdoors in the crypto algorithms is negligible compared to the risk that the person writing the code just does it wrong, given this is a new project mostly from a single developer.
I would expect that changing it to use a different cypher ought to be easy enough if you're unhappy with the one it uses.