mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Added a comment: some further considerations

Browse source
This commit is contained in:
anarcat 2018-07-04 02:17:50 +00:00 • committed by admin
parent 9f3a346f25
commit 5b2bbaaa18
1 changed files with 32 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

32
doc/todo/do_not_block_on_crypto_key_generation/comment_2_34b1e7f04ca17438e2a3e6209993a3a9._comment Normal file
View file

@ -0,0 +1,32 @@
[[!comment format=mdwn
username="anarcat"
avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
subject="some further considerations"
date="2018-07-04T02:17:49Z"
content="""
> This is implemented in Utility.Gpg.genRandom. There is no off-by-one, git-annex intentially makes the same default choices that gnupg does about random quality.
Then you'll be happy to know there is a proposal to change those defaults in gnupg as well, for similar reasons:
https://dev.gnupg.org/T3894
Cargo-culting those defaults does not seem like a reasonable way either. ;)
> --fast makes it use /dev/urandom for people who lean on that side of the entropy controversy. initremote's man page documents this.
I did not notice that, thanks. I would still argue it is better to use `/dev/urandom` for cryptoraphic purposes.
> (\"Some people recommend\" is often not a good basis for security defaults. Some people recommend using RDRAND and trusting Intel...)
That's a straw man. I am not recommending RDRAND. I'm recommending `/dev/urandom`. There are drawbacks in using `/dev/random`. To quote from the above URL:
> djb has argued that an attacker capable of controlling the inputs to your seeding algorithm might gain an advantage in a continuous-seeding scenario that they wouldn't get in a seed-once-and-done approach.
There are, as far as I am aware, no drawback to using `/dev/urandom`. I know there is some sort of controversy about this: I'm actually taking a stand here and asking people to justify why they are using `/dev/random`.
I understand you might decide to not justify this directly in git-annex, however, and defer to projects like GnuPG, but I figured you might like to know the issue is not so clear cut there either... Werner Koch, the main author of GnuPG, says this of using `/dev/urandom`:
> I use it for a long time now and it is really helpful. Do this only on Linux with the getrandom system call or if you are sure that Libgcrypt is not used in the early boot stage.
So I think it might be worth reconsidering this here as well.
"""]]