Fossil SCM
Updated the PBKDF2 recommendations in the backup doc to track recent changes in best practice due to all these GPU computing fleets coming online. Added a few paragraphs explaining the limits to all of this and why we chose the passphrase lengths we did as examples.
Commit
6a3d6fa63e05e643133c48b762c7210cb95e3a0d1609197be125520e5f745ecf
Parent
7b5057745a201da…
1 file changed
+24
-3
+24
-3
| --- www/backup.md | ||
| +++ www/backup.md | ||
| @@ -201,11 +201,11 @@ | ||
| 201 | 201 | of noise to anyone without the key: |
| 202 | 202 | |
| 203 | 203 | ---- |
| 204 | 204 | |
| 205 | 205 | ```shell |
| 206 | -iter=52830 | |
| 206 | +iter=152830 | |
| 207 | 207 | pass="h8TixP6Mt6edJ3d6COaexiiFlvAM54auF2AjT7ZYYn" |
| 208 | 208 | gd="$HOME/Google Drive/Fossil Backups/$bf.xz.enc" |
| 209 | 209 | fossil sql -R ~/museum/backups/"$bf" .dump | xz -9 | |
| 210 | 210 | openssl enc -e -aes-256-cbc -pbkdf2 -iter $iter -pass pass:"$pass" -out "$gd" |
| 211 | 211 | ``` |
| @@ -215,12 +215,33 @@ | ||
| 215 | 215 | If you’re adding this to the first script above, remove the |
| 216 | 216 | “`-R repo-name`” bit so you get a dump of the repository backing the |
| 217 | 217 | current working directory. |
| 218 | 218 | |
| 219 | 219 | Change the `pass` value to some other long random string, and change the |
| 220 | -`iter` value to something between 10000 and 100000. A good source for | |
| 220 | +`iter` value to something in the hundreds of thousands range. A good source for | |
| 221 | 221 | the first is [here][grcp], and for the second, [here][rint]. |
| 222 | + | |
| 223 | +You may find posts online written by people recommending millions of | |
| 224 | +iterations for PBKDF2, but they’re generally talking about this in the | |
| 225 | +context of memorizable passwords, where adding even one more character | |
| 226 | +to the password is a significant burden. Given our script’s purely | |
| 227 | +random maximum-length passphrase, there isn’t much more that increasing | |
| 228 | +the key derivation iteration count can do for us. | |
| 229 | + | |
| 230 | +Conversely, if you were to reduce the passphrase to 41 characters, that | |
| 231 | +would drop the key strength by roughly 2⁶, being the entropy value per | |
| 232 | +character for using most of printable ASCII in our passphrase. To make | |
| 233 | +that lost strength up on the PBKDF2 end, you’d have to multiply your | |
| 234 | +iterations by 2⁶ = 64 times. It’s easier to use a max-length passphrase | |
| 235 | +in this situation than get crazy with key derivation iteration counts. | |
| 236 | + | |
| 237 | +(This, by the way, is why the example passphrase above is 42 characters: | |
| 238 | +with 6 bits of entropy per character, that gives you a key size of 252, | |
| 239 | +as close as we can get to our chosen encryption algorithm’s 256-bit key | |
| 240 | +size without going over. If it pleases you to give it 43 random | |
| 241 | +characters for a passphrase in order to pick up those last four bits of | |
| 242 | +security, you’re welcome to do so.) | |
| 222 | 243 | |
| 223 | 244 | Compressing the data before encrypting it removes redundancies that can |
| 224 | 245 | make decryption easier, and it results in a smaller backup than you get |
| 225 | 246 | with the previous script alone, at the expense of a lot of CPU time |
| 226 | 247 | during the backup. You may wish to switch to a less space-efficient |
| @@ -286,10 +307,10 @@ | ||
| 286 | 307 | [grcp]: https://www.grc.com/passwords.htm |
| 287 | 308 | [hb]: https://brew.sh |
| 288 | 309 | [hbul]: https://docs.brew.sh/FAQ#what-does-keg-only-mean |
| 289 | 310 | [lz4]: https://lz4.github.io/lz4/ |
| 290 | 311 | [pbr]: ./private.wiki |
| 291 | -[rint]: https://www.random.org/integers/?num=1&min=10000&max=100000&col=5&base=10&format=html&rnd=new | |
| 312 | +[rint]: https://www.random.org/integers/?num=1&min=100000&max=1000000&col=5&base=10&format=html&rnd=new | |
| 292 | 313 | [Setup]: ./caps/admin-v-setup.md#apsu |
| 293 | 314 | [shun]: ./shunning.wiki |
| 294 | 315 | [tkt]: ./tickets.wiki |
| 295 | 316 | [uv]: ./unvers.wiki |
| 296 | 317 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -201,11 +201,11 @@ | |
| 201 | of noise to anyone without the key: |
| 202 | |
| 203 | ---- |
| 204 | |
| 205 | ```shell |
| 206 | iter=52830 |
| 207 | pass="h8TixP6Mt6edJ3d6COaexiiFlvAM54auF2AjT7ZYYn" |
| 208 | gd="$HOME/Google Drive/Fossil Backups/$bf.xz.enc" |
| 209 | fossil sql -R ~/museum/backups/"$bf" .dump | xz -9 | |
| 210 | openssl enc -e -aes-256-cbc -pbkdf2 -iter $iter -pass pass:"$pass" -out "$gd" |
| 211 | ``` |
| @@ -215,12 +215,33 @@ | |
| 215 | If you’re adding this to the first script above, remove the |
| 216 | “`-R repo-name`” bit so you get a dump of the repository backing the |
| 217 | current working directory. |
| 218 | |
| 219 | Change the `pass` value to some other long random string, and change the |
| 220 | `iter` value to something between 10000 and 100000. A good source for |
| 221 | the first is [here][grcp], and for the second, [here][rint]. |
| 222 | |
| 223 | Compressing the data before encrypting it removes redundancies that can |
| 224 | make decryption easier, and it results in a smaller backup than you get |
| 225 | with the previous script alone, at the expense of a lot of CPU time |
| 226 | during the backup. You may wish to switch to a less space-efficient |
| @@ -286,10 +307,10 @@ | |
| 286 | [grcp]: https://www.grc.com/passwords.htm |
| 287 | [hb]: https://brew.sh |
| 288 | [hbul]: https://docs.brew.sh/FAQ#what-does-keg-only-mean |
| 289 | [lz4]: https://lz4.github.io/lz4/ |
| 290 | [pbr]: ./private.wiki |
| 291 | [rint]: https://www.random.org/integers/?num=1&min=10000&max=100000&col=5&base=10&format=html&rnd=new |
| 292 | [Setup]: ./caps/admin-v-setup.md#apsu |
| 293 | [shun]: ./shunning.wiki |
| 294 | [tkt]: ./tickets.wiki |
| 295 | [uv]: ./unvers.wiki |
| 296 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -201,11 +201,11 @@ | |
| 201 | of noise to anyone without the key: |
| 202 | |
| 203 | ---- |
| 204 | |
| 205 | ```shell |
| 206 | iter=152830 |
| 207 | pass="h8TixP6Mt6edJ3d6COaexiiFlvAM54auF2AjT7ZYYn" |
| 208 | gd="$HOME/Google Drive/Fossil Backups/$bf.xz.enc" |
| 209 | fossil sql -R ~/museum/backups/"$bf" .dump | xz -9 | |
| 210 | openssl enc -e -aes-256-cbc -pbkdf2 -iter $iter -pass pass:"$pass" -out "$gd" |
| 211 | ``` |
| @@ -215,12 +215,33 @@ | |
| 215 | If you’re adding this to the first script above, remove the |
| 216 | “`-R repo-name`” bit so you get a dump of the repository backing the |
| 217 | current working directory. |
| 218 | |
| 219 | Change the `pass` value to some other long random string, and change the |
| 220 | `iter` value to something in the hundreds of thousands range. A good source for |
| 221 | the first is [here][grcp], and for the second, [here][rint]. |
| 222 | |
| 223 | You may find posts online written by people recommending millions of |
| 224 | iterations for PBKDF2, but they’re generally talking about this in the |
| 225 | context of memorizable passwords, where adding even one more character |
| 226 | to the password is a significant burden. Given our script’s purely |
| 227 | random maximum-length passphrase, there isn’t much more that increasing |
| 228 | the key derivation iteration count can do for us. |
| 229 | |
| 230 | Conversely, if you were to reduce the passphrase to 41 characters, that |
| 231 | would drop the key strength by roughly 2⁶, being the entropy value per |
| 232 | character for using most of printable ASCII in our passphrase. To make |
| 233 | that lost strength up on the PBKDF2 end, you’d have to multiply your |
| 234 | iterations by 2⁶ = 64 times. It’s easier to use a max-length passphrase |
| 235 | in this situation than get crazy with key derivation iteration counts. |
| 236 | |
| 237 | (This, by the way, is why the example passphrase above is 42 characters: |
| 238 | with 6 bits of entropy per character, that gives you a key size of 252, |
| 239 | as close as we can get to our chosen encryption algorithm’s 256-bit key |
| 240 | size without going over. If it pleases you to give it 43 random |
| 241 | characters for a passphrase in order to pick up those last four bits of |
| 242 | security, you’re welcome to do so.) |
| 243 | |
| 244 | Compressing the data before encrypting it removes redundancies that can |
| 245 | make decryption easier, and it results in a smaller backup than you get |
| 246 | with the previous script alone, at the expense of a lot of CPU time |
| 247 | during the backup. You may wish to switch to a less space-efficient |
| @@ -286,10 +307,10 @@ | |
| 307 | [grcp]: https://www.grc.com/passwords.htm |
| 308 | [hb]: https://brew.sh |
| 309 | [hbul]: https://docs.brew.sh/FAQ#what-does-keg-only-mean |
| 310 | [lz4]: https://lz4.github.io/lz4/ |
| 311 | [pbr]: ./private.wiki |
| 312 | [rint]: https://www.random.org/integers/?num=1&min=100000&max=1000000&col=5&base=10&format=html&rnd=new |
| 313 | [Setup]: ./caps/admin-v-setup.md#apsu |
| 314 | [shun]: ./shunning.wiki |
| 315 | [tkt]: ./tickets.wiki |
| 316 | [uv]: ./unvers.wiki |
| 317 |