Added a comment: Maybe add a very slow KDF first?
This commit is contained in:
parent
0be6cad7a8
commit
c14e15fd1a
1 changed files with 23 additions and 0 deletions
|
@ -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/
|
||||
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue