Added a comment: Maybe add a very slow KDF first?

diff --git a/doc/todo/encrypted_keys_in_git_repository/comment_1_4d17c427756127f22dc472984259f8d7._comment b/doc/todo/encrypted_keys_in_git_repository/comment_1_4d17c427756127f22dc472984259f8d7._comment
new file mode 100644 (file)
index 0000000..58c4f33
--- /dev/null
+++ b/doc/todo/encrypted_keys_in_git_repository/comment_1_4d17c427756127f22dc472984259f8d7._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Maybe add a very slow KDF first?"
+ date="2022-12-27T20:26:45Z"
+ content="""
+Hey joey,
+
+As a simple-to-implement yet quite effective approach to the problem of storing some secrets in a public git-annex repo, wouldn't a very slow hash/key derivation function (like scrypt) as keys for those specific files be enough? The hash can be public when brute-forcing is infeasible. So for git-annex:
+
+- add an scrypt key backend
+- makes the params n,r,p configurable (slowness of hashing) and put them i to the key name (e.g. `SCRYPT-n10-r100-p1--...`)
+- the salt could also be configurable or generated randomly per file but needs to be present in the key name (base64-encoded?) and uses either the file content or as such or some cryptographically secure hash of it as scrypt 'password'
+- file size shouldn't be included in the key
+
+With sane defaults (maybe settings that make hashing take several seconds?), this would make git-annex a very nice way of hiding some files' content in public repositories while still tracking it.
+
+Some resources:
+
+- https://stackoverflow.com/questions/23985540/whats-the-is-maximum-length-of-scrypt-output#23985541
+- https://words.filippo.io/the-scrypt-parameters/
+
+"""]]