Added a comment

doc/todo/encrypted_keys_in_git_repository/comment_3_a79ea55e2f8a1095f0110f2f0853dee1._comment

@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 3"
+ date="2022-12-29T10:49:27Z"
+ content="""
+> But... If the attacker only cares about a single file, they only have to run scrypt **once.**
+
+Well, the attacker would still need to run scrypt many times to brute-force the actual content, IIUC.
+
+I understand it like this (might be wrong, I'm no security expert):
+
+- scrypt is an arbitrarily-slow key derivation function taking an input (the „password” - or for us: the file content) and some parameters (salt, n, r, p)
+- knowing the parameters (salt, n, r, p) is necessary to verify file integrity so storing those in an easily accessible way (e.g. directly in the key) would simplify things and we wouldn't need to teach git-annex much more to handle this.
+- A (public) git-annex repo that has some files „scrypt”-ed like this then contains the scrypt hash and the parameters used to generate that hash. So this is equivalent to a database breach where user credentials were secured with scrypt. (right?)
+- An attacker thus now still has to brute-force the content of the desired file. With little information about how that file looks in detail („how exactly is that YAML containing the password structured? How big is it even? What key order? Are there comments? That comment could even contain a random salt itself...”), this brute-forcing should be pretty infeasible if the scrypt parameters are tuned to hash *ridiculously* slow (like multiple seconds even on a beefy machine with much RAM - doesn't bother us if `git annex fsck` is slow on that one file. Big files hash slowly anyway as well...). It should definitely be harder than cracking a breached password database where it is clear that the passwords don't contain newlines and there most likely is a size limit, etc.
+
+If my above assumptions are correct, an `scrypt` key backend for git-annex should make for a nice way of hiding the content of *some* files in a public repo, right?
+
+P.S: Thinking about the 'that secured file could contain potentially large random comments acting as a salt next to the actual secret' together with removing the size from the key ([`git annex migrate --remove-size`](https://git-annex.branchable.com/git-annex-migrate/)) should already be pretty safe with the default SHA256-backend, right? 🤔
+"""]]