I see 16 bytes of hex after the anchor slug for the encryption feature, e.g. for 'https://nofile.io/f/86JiUNYM6QK#5827800f46cef978' https://nofile.io/f/86JiUNYM

I see 16 bytes of hex after the anchor slug for the encryption feature, e.g. for 'https://nofile.io/f/86JiUNYM6QK#5827800f46cef978' https://nofile.io/f/86JiUNYM6QK#5827800f46cef978', the key is '5827800f46cef978'. The key is absolutely does not contain enough entropy, because your key material is only comprised of the ascii-printable hex chars converted into a byte value. So instead of a byte having 256 different possibilities, a byte now will only be one of 16 values. Bruteforcing these keys would be incredibly trivial. To decode the hex into actually random key material, you would have needed to do something like hexToBytes("5827800f46cef978"), which would yield a correctly random byte array of [88, 39, 128, 15, 70, 206, 249, 120]. Note that this is half the proper key size required for AES-128. I also want to echo the concerns already voiced by others in saying that key material needs to be generated from a strong random provider, and not just from the hash of the file. I say this in the interest of privacy of those who might use your service, so please don't take any offense: please disable the encryption feature entirely until you can get assistance from someone with extensive experience in implementing crypto, because as it exists now, the implementation is fatally flawed.