12 ms·

urandom

186 points by petrosagg 11y ago

aidenn0 11y ago
Is there a patch to make /dev/random behave like /dev/urandom? I've had at least some server software stall blocking on /dev/random, and I already build my own kernels, so incorporating such a patch is easy.
- throwaway2048 11y ago
  you could probly edit udev rules to make random be the same device major/minor as urandom
- iso-8859-1 11y ago
  maybe it is doable with overlayfs?
- mappu 11y ago
  rm /dev/random && mknod -m 444 /dev/random c 1 9
  - throwaway2048 11y ago
    this wont survive reboot, you need udev rules.
  - viraptor 11y ago
    Or run the app in its own namespace with custom /dev.
- robmccoll 11y ago
  mount --bind /dev/urandom /dev/random
  - DiabloD3 11y ago
    That won't stick across reboots, and at that point, I think you can just rm /dev/random; ln -s /dev/urandom /dev/random.
    - pvdebbe 11y ago
      But couldn't you put that in /etc/fstab?
      - DiabloD3 11y ago
        I could do a udev rule to just mknod random with the urandom device instead.
      - robmccoll 11y ago
        You could. I also find myself binding /dev/urandom into /dev/random in a container FWIW.
- mikekchar 11y ago
  Although in most cases it doesn't matter, I wouldn't do this. Remember that the PRNG will only output unpredictable values as long as the initial seed was unpredictable (and unknown). As stated in the article, there is actually one time where you care if you have enough entropy -- the first time you grab a random number. After that the PRNG is seeded with an unknown value and you are fine (assuming you waited until you had enough entropy). Before that, you aren't. BSD's implementation seems sensible -- block the first time and then don't block again. Or potentially block if you haven't reseeded in X amount of time (X being configurable), to defeat the situation where someone figures out your seed. Although, I have a tough time understanding how someone will figure out your seed without completely compromising your system anyway... but systems are supposed to be robust against attacks that one can't immediately imagine ;-)
  - aidenn0 11y ago
    Is there a linux kernel patch to use BSD's implementation then?
- nshepperd 11y ago
  I use a solution based on udev rules, here: https://superuser.com/questions/309840/how-can-i-point-dev-random-to-dev-urandom https://superuser.com/questions/309840/how-can-i-point-dev-r...
- matheweis 11y ago
  An easy hack is to use rngd with /dev/urandom as an "entropy source" (risky if you are going to use /dev/random for anything that REQUIRES true entropy, but otherwise should be safe as the article suggests).
po 11y ago
Why hasn't someone qualified re-written that unix man page by now? I've been reading cryptographers trying to explain all of this for a while now. I feel like that would help put a lot of this to rest and save everyone time.
- AndyKelley 11y ago
  It would have saved me a lot of time, that's for sure. And here I thought I was being responsible and informed by reading the man page.
  - cbsmith 11y ago
    Honestly, anyone who cares & can understand will look at the implementation of the two and grok it. Those who don't will screw up the rest of it anyway, and that will create more than enough trouble even with some helpful guidance. Best to have them fail in pretty obvious ways.
    - tedunangst 11y ago
      I would not classify the /dev/random failure modes as "pretty obvious".
      - cbsmith 11y ago
        I guess it is a matter of perspective. If you understand what you need for your cryptography, you'll know if you want /dev/random or not. The fact that it blocks is very, very well advertised and clear. The fact that the difference is that /dev/urandom won't block is also very, very clear. If you don't know which you want, I'd wager you don't understand your cryptographic protocol's needs terribly well, and are best off outsourcing that work to someone else.
        ghshephard 11y ago
        Last time I tried using gpg on a VM it failed to work (literally would not do anything) because it blocked on /dev/random. Would you say that the gpg people should be outsourcing their work to someone else?
AndyKelley 11y ago
Thanks for this. Time to go fix my code[1]. [1]: https://github.com/andrewrk/genesis/blob/0d545d692110d33068dee36bbc2492d7aa8aa325/src/os.cpp#L47 https://github.com/andrewrk/genesis/blob/0d545d692110d33068d...
- masklinn 11y ago
  Since you're only targeting Linux, if you are fine with requiring recent kernels (3.17), you should probably use getrandom(2): http://man7.org/linux/man-pages/man2/getrandom.2.html http://man7.org/linux/man-pages/man2/getrandom.2.html
theophrastus 11y ago
Interesting and edifying, thank you. I wonder how the recent 4.2 kernel release affects this: Linux 4.2 Released Improving Cryptography Options[1] [1]: http://www.linuxplanet.com/news/linux-4.2-released-improving-cryptography-options.html http://www.linuxplanet.com/news/linux-4.2-released-improving...
snorrah 11y ago
Very interesting article. Clears up the preconceptions I had about using /dev/random over /dev/urandom ("it's more secure!") and explains why in very straightforward language.
panic 11y ago
Why doesn't Linux follow FreeBSD and provide a single interface (under two names, maybe, for compatibility)? Is there any reason to use /dev/random?
- geofft 11y ago
  Ego. They've put a lot of work into the entropy-tracking thing and they don't want to admit that it wasn't needed. (Ego is the reason for a bunch of other security misfeatures in Linux. Securelevel comes to mind, where Linus explicitly said after fifteen years, okay, this was in fact the right model all along, you can merge it, just call it something other than securelevel so I don't have to eat my words about securelevel being a mistake.)
wangweij 11y ago
This is my understanding: /dev/urandom is just a blind producer returning any number in some pool; /dev/random is a producer as well as an inspector, it returns the same number from the pool but it also has an extra eye on the source of that pool and refuse to work if it believes the source is of low quality -- here, not enough entropy.
- mikeash 11y ago
  The problem is that /dev/random is too paranoid. It refuses to work if there isn't enough entropy in the pool, yes. But when it produces numbers, it subtracts that amount from the supposed amount of entropy in the pool. Thus it will refuse to work again pretty soon in a lot of circumstances where it's still completely safe to proceed. For a concrete example, you start out with zero bits in the pool. /dev/urandom will produce a predictable stream of bits. This is extremely bad. /dev/random will block. this is good. Now you add 1024 bits to the pool. Both /dev/random and /dev/urandom will produce good numbers. Now let's say you read 1024 bits from /dev/random. This will reduce the entropy counter back to zero. If you then try to read another 1024 bits from /dev/random, it will block. But this is nonsense! Those 1024 bits you added before aren't depleted just because you pulled 1024 from /dev/random! It is perfectly safe to proceed generating more numbers at this point (or at least it's as safe as it was before), but /dev/random refuses to. Many systems don't add entropy to the pool very quickly so it's entirely possible to "deplete" it in this way. Then your code using /dev/random wedges and you have a problem. However, few systems are ever in a state where they have zero entropy. Thus the advice to use /dev/urandom. Ideally, you'd want a device which blocks if and only if the entropy pool hasn't been properly seeded yet, but which never blocks again after that point. Apparently this is what the BSDs do, but Linux doesn't have one.
  - lsh123 11y ago
    "But this is nonsense! Those 1024 bits you added before aren't depleted just because you pulled 1024 from /dev/random!" An observer of the produced random numbers can potentially deduce the next numbers from the first 1024 random numbers. This is the reason why /dev/random requires more randomness added -- to prevent the guessing of the next number.
msm23 11y ago
I prefer to trust the NSA on these matters. They end up saying much of what the author has written, but they make it clear why you want to use one vs the other. The excerpt below is from https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/Slicksheet_RNG_IntroForAppDev.pdf https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/S... (which in turn also references https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/Slicksheet_RNG_IntroForOpSysDev.pdf https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/S... ) Unix-like Platforms (e.g. Linux, Android, and Mac OS X): Application developers should use the fread function to read random bytes from /dev/random for cryptographic RNG services. Because /dev/random is a blocking device, /dev/random may cause unacceptable delays, in which case application developers may prefer to implement a DRBG using /dev/random as a conditioned seed. Application developers should use the “Random Number Generators: Introduction for Operating System Developers” guidance in developing this solution. If /dev/random still produces unacceptable delays, developers should use /dev/urandom which is a non-blocking device, but only with a number of additional assurances: - The entropy pool used by /dev/urandom must be saved between reboots. - The Linux operating system must have estimated that the entropy pool contained the appropriate security strength entropy at some point before calling /dev/urandom. The current pool estimate can be read from /proc/sys/kernel/random/entropy_avail. At most 2^80 bytes may be read from /dev/urandom before the developer must ensure that new entropy was added to the pool.
- wfleming 11y ago
  Maybe I'm just tired & not able to detect sarcasm right now, but isn't 2^80 bytes more bytes than are currently stored in the world? That's on the order of 10^24, which is something like 1 million exabytes, which is a million squared terabytes, right?
  - raverbashing 11y ago
    No, it's called being safe And I wouldn't put it past them to have an attack (at least theorectical) that exploits this
    - viraptor 11y ago
tytso 11y ago
Actually, the preferred and recommended way to get randomness on modern kernels is to use the new getrandom(2) system call, with the flags argument set to zero. http://man7.org/linux/man-pages/man2/getrandom.2.html http://man7.org/linux/man-pages/man2/getrandom.2.html With the flags set to zero, it works like the getentropy(2) system call in OpenBSD. In fact, code that uses getentropy(buf, buflen) can be trivially ported to Linux as getrandom(buf, buflen, 0).
- plonh 11y ago
  Why didn't we get /dev/getrandom?
  - viraptor 11y ago
    One point of a direct syscall is that you don't have to open any files. That protects you from file descriptor exhaustion attacks.
    - cperciva 11y ago
      Another point is that it still works if you're inside a chroot / jail / container / with no devices visible.
      - rakoo 11y ago
        In a way, that's the point of chroot/jail/container: isolate the host filesystem from the guest, so the script that creates it should take /dev into account if it is needed
        Dylan16807 11y ago
        The point is to isolate access to the host, and single secure random numbers have nothing to do with the host.
  - kalleboo 11y ago
    Here's the original syscall request http://lists.openwall.net/linux-kernel/2014/07/17/235 http://lists.openwall.net/linux-kernel/2014/07/17/235 and discussion https://news.ycombinator.com/item?id=8049180 https://news.ycombinator.com/item?id=8049180
frankzinger 11y ago
Previously: https://news.ycombinator.com/item?id=7359992 https://news.ycombinator.com/item?id=7359992
antirez 11y ago
The root problem is that cryptography is not usable without some understanding. In the latest days we developed an addiction for "best practices" like "use bcrypt", "use /dev/random" or alike which in the field of cryptography are not enough: understanding is the only possible path. Actually, this is true for most things, it just shows up more obviously in the field of cryptography because of the security concerns. So we should replace "use bcrypt" with "Read Applied Cryptography & other books".
- ReidZB 11y ago
  The average guy doesn't have the time to read enough about cryptography to have the sort of knowledge you're wanting. This very article debates an understanding created by incomplete and poor cryptographic knowledge. If there's anything I've learned by studying cryptography, it's that the average person needs to invest significant resources to become a pseudo-expert in cryptography - all before they can make any meaningful decision. Applied Cryptography is not a terribly good starting point for cryptographic understanding these days. That's just another facet of difficulty: where does one even start? Do you want a theoretical baseline understanding? Do you want the high-level, quick-and-dirty overview which only gives a summary? (That'll make it hard to make real, informed decisions...) If we really want to make cryptography accessible to many developers, the best solution is for the cryptographic community to make our libraries and interfaces better. At the same time, there comes a point where a developer has to stop and say "this is beyond what is standardized in ${widely used library}; we need to hire a cryptographer." In that sense, we need to instill a better anti-crypto ethic.
  - antirez 11y ago
    Basically to become an expert cryptographer you need a math degree and ten years of experience, so this is out of question indeed. What I'm referring to is to get enough information in order to understand the big picture: what is a stream cipher, what a block cipher, a cryptographic hash function and its main properties, how many of those primitives are kinda equivalent sometimes and you can use one to create another, the tradeoff between speed and security (and how number of rounds effect the security of crypto building blocks), analyzing simple algorithms in order to really understand why it is so hard for you to create something secure, secure PRNG generation and weak PRNG generation (and how to break a congruential linear generator), algorithms like DH, RSA, basic knowledge on number theory, and so forth. This will not make you an expert, but will give you enough understanding in order to actually undetstand why a rule or a best practice is used and when it is safe or not to break it. About starting point, this is incredibly sad but true: there is no Applied Cryptography of 2015. The book is at this point in some way outdated and no replacement exists, however what you can do is to read it, and then to read the documents that there are around to get updated information. Also there are now the online courses on cryptography that really help. This may look like an overkill, but at this point crypto is everywhere and is the foundation of most things secure, so it is a requirement of everybody involved with computer security.
1_player 11y ago
Is there anyone that, with full access to the machine/kernel, has managed to predict the output of random/urandom? I know that a PRNG is predictable if you know all the input variables, and the code for it is publicly available, but has anybody in practice been able to exploit that? EDIT: that's an honest question. I'd like to read a paper about that.
vbezhenar 11y ago
Java is known to read /dev/random when dealing with SecureRandom class. In particular it might cause extremely slow starting time for Tomcat on fresh virtual machine. There's parameter "-Djava.security.egd=file:/dev/./urandom" and I always felt unsafe using it. Thanks to this article, now I won't regret it even theoretically. Fun thing is, if you pass "/dev/urandom" to this parameter, Java will read /dev/random anyway. May be that was a wise decision 20 years ago.

186 points by petrosagg 11y ago

Is there a patch to make /dev/random behave like /dev/urandom? I've had at least some server software stall blocking on /dev/random, and I already build my own kernels, so incorporating such a patch is easy.

throwaway2048 11y ago
you could probly edit udev rules to make random be the same device major/minor as urandom
iso-8859-1 11y ago
maybe it is doable with overlayfs?
mappu 11y ago
rm /dev/random && mknod -m 444 /dev/random c 1 9
- throwaway2048 11y ago
  this wont survive reboot, you need udev rules.
- viraptor 11y ago
  Or run the app in its own namespace with custom /dev.
robmccoll 11y ago
mount --bind /dev/urandom /dev/random
- DiabloD3 11y ago
  That won't stick across reboots, and at that point, I think you can just rm /dev/random; ln -s /dev/urandom /dev/random.
  - pvdebbe 11y ago
    But couldn't you put that in /etc/fstab?
    - DiabloD3 11y ago
      I could do a udev rule to just mknod random with the urandom device instead.
    - robmccoll 11y ago
      You could. I also find myself binding /dev/urandom into /dev/random in a container FWIW.
mikekchar 11y ago
Although in most cases it doesn't matter, I wouldn't do this. Remember that the PRNG will only output unpredictable values as long as the initial seed was unpredictable (and unknown). As stated in the article, there is actually one time where you care if you have enough entropy -- the first time you grab a random number. After that the PRNG is seeded with an unknown value and you are fine (assuming you waited until you had enough entropy). Before that, you aren't. BSD's implementation seems sensible -- block the first time and then don't block again. Or potentially block if you haven't reseeded in X amount of time (X being configurable), to defeat the situation where someone figures out your seed. Although, I have a tough time understanding how someone will figure out your seed without completely compromising your system anyway... but systems are supposed to be robust against attacks that one can't immediately imagine ;-)
- aidenn0 11y ago
  Is there a linux kernel patch to use BSD's implementation then?
nshepperd 11y ago
I use a solution based on udev rules, here: https://superuser.com/questions/309840/how-can-i-point-dev-random-to-dev-urandom https://superuser.com/questions/309840/how-can-i-point-dev-r...
matheweis 11y ago
An easy hack is to use rngd with /dev/urandom as an "entropy source" (risky if you are going to use /dev/random for anything that REQUIRES true entropy, but otherwise should be safe as the article suggests).

po 11y ago

Why hasn't someone qualified re-written that unix man page by now? I've been reading cryptographers trying to explain all of this for a while now. I feel like that would help put a lot of this to rest and save everyone time.

AndyKelley 11y ago
It would have saved me a lot of time, that's for sure. And here I thought I was being responsible and informed by reading the man page.
- cbsmith 11y ago
  Honestly, anyone who cares & can understand will look at the implementation of the two and grok it. Those who don't will screw up the rest of it anyway, and that will create more than enough trouble even with some helpful guidance. Best to have them fail in pretty obvious ways.
  - tedunangst 11y ago
    I would not classify the /dev/random failure modes as "pretty obvious".
    - cbsmith 11y ago
      I guess it is a matter of perspective. If you understand what you need for your cryptography, you'll know if you want /dev/random or not. The fact that it blocks is very, very well advertised and clear. The fact that the difference is that /dev/urandom won't block is also very, very clear. If you don't know which you want, I'd wager you don't understand your cryptographic protocol's needs terribly well, and are best off outsourcing that work to someone else.
      - ghshephard 11y ago
        Last time I tried using gpg on a VM it failed to work (literally would not do anything) because it blocked on /dev/random. Would you say that the gpg people should be outsourcing their work to someone else?

AndyKelley 11y ago

Thanks for this. Time to go fix my code[1]. [1]: https://github.com/andrewrk/genesis/blob/0d545d692110d33068dee36bbc2492d7aa8aa325/src/os.cpp#L47 https://github.com/andrewrk/genesis/blob/0d545d692110d33068d...

masklinn 11y ago
Since you're only targeting Linux, if you are fine with requiring recent kernels (3.17), you should probably use getrandom(2): http://man7.org/linux/man-pages/man2/getrandom.2.html http://man7.org/linux/man-pages/man2/getrandom.2.html

theophrastus 11y ago

Interesting and edifying, thank you. I wonder how the recent 4.2 kernel release affects this: Linux 4.2 Released Improving Cryptography Options[1] [1]: http://www.linuxplanet.com/news/linux-4.2-released-improving-cryptography-options.html http://www.linuxplanet.com/news/linux-4.2-released-improving...

snorrah 11y ago

Very interesting article. Clears up the preconceptions I had about using /dev/random over /dev/urandom ("it's more secure!") and explains why in very straightforward language.

panic 11y ago

Why doesn't Linux follow FreeBSD and provide a single interface (under two names, maybe, for compatibility)? Is there any reason to use /dev/random?

geofft 11y ago
Ego. They've put a lot of work into the entropy-tracking thing and they don't want to admit that it wasn't needed. (Ego is the reason for a bunch of other security misfeatures in Linux. Securelevel comes to mind, where Linus explicitly said after fifteen years, okay, this was in fact the right model all along, you can merge it, just call it something other than securelevel so I don't have to eat my words about securelevel being a mistake.)

wangweij 11y ago

This is my understanding: /dev/urandom is just a blind producer returning any number in some pool; /dev/random is a producer as well as an inspector, it returns the same number from the pool but it also has an extra eye on the source of that pool and refuse to work if it believes the source is of low quality -- here, not enough entropy.

mikeash 11y ago
The problem is that /dev/random is too paranoid. It refuses to work if there isn't enough entropy in the pool, yes. But when it produces numbers, it subtracts that amount from the supposed amount of entropy in the pool. Thus it will refuse to work again pretty soon in a lot of circumstances where it's still completely safe to proceed. For a concrete example, you start out with zero bits in the pool. /dev/urandom will produce a predictable stream of bits. This is extremely bad. /dev/random will block. this is good. Now you add 1024 bits to the pool. Both /dev/random and /dev/urandom will produce good numbers. Now let's say you read 1024 bits from /dev/random. This will reduce the entropy counter back to zero. If you then try to read another 1024 bits from /dev/random, it will block. But this is nonsense! Those 1024 bits you added before aren't depleted just because you pulled 1024 from /dev/random! It is perfectly safe to proceed generating more numbers at this point (or at least it's as safe as it was before), but /dev/random refuses to. Many systems don't add entropy to the pool very quickly so it's entirely possible to "deplete" it in this way. Then your code using /dev/random wedges and you have a problem. However, few systems are ever in a state where they have zero entropy. Thus the advice to use /dev/urandom. Ideally, you'd want a device which blocks if and only if the entropy pool hasn't been properly seeded yet, but which never blocks again after that point. Apparently this is what the BSDs do, but Linux doesn't have one.
- lsh123 11y ago
  "But this is nonsense! Those 1024 bits you added before aren't depleted just because you pulled 1024 from /dev/random!" An observer of the produced random numbers can potentially deduce the next numbers from the first 1024 random numbers. This is the reason why /dev/random requires more randomness added -- to prevent the guessing of the next number.

msm23 11y ago

I prefer to trust the NSA on these matters. They end up saying much of what the author has written, but they make it clear why you want to use one vs the other. The excerpt below is from https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/Slicksheet_RNG_IntroForAppDev.pdf https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/S... (which in turn also references https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/Slicksheet_RNG_IntroForOpSysDev.pdf https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/S... ) Unix-like Platforms (e.g. Linux, Android, and Mac OS X): Application developers should use the fread function to read random bytes from /dev/random for cryptographic RNG services. Because /dev/random is a blocking device, /dev/random may cause unacceptable delays, in which case application developers may prefer to implement a DRBG using /dev/random as a conditioned seed. Application developers should use the “Random Number Generators: Introduction for Operating System Developers” guidance in developing this solution. If /dev/random still produces unacceptable delays, developers should use /dev/urandom which is a non-blocking device, but only with a number of additional assurances: - The entropy pool used by /dev/urandom must be saved between reboots. - The Linux operating system must have estimated that the entropy pool contained the appropriate security strength entropy at some point before calling /dev/urandom. The current pool estimate can be read from /proc/sys/kernel/random/entropy_avail. At most 2^80 bytes may be read from /dev/urandom before the developer must ensure that new entropy was added to the pool.

wfleming 11y ago
Maybe I'm just tired & not able to detect sarcasm right now, but isn't 2^80 bytes more bytes than are currently stored in the world? That's on the order of 10^24, which is something like 1 million exabytes, which is a million squared terabytes, right?
- raverbashing 11y ago
  No, it's called being safe And I wouldn't put it past them to have an attack (at least theorectical) that exploits this
  - viraptor 11y ago

tytso 11y ago

Actually, the preferred and recommended way to get randomness on modern kernels is to use the new getrandom(2) system call, with the flags argument set to zero. http://man7.org/linux/man-pages/man2/getrandom.2.html http://man7.org/linux/man-pages/man2/getrandom.2.html With the flags set to zero, it works like the getentropy(2) system call in OpenBSD. In fact, code that uses getentropy(buf, buflen) can be trivially ported to Linux as getrandom(buf, buflen, 0).

plonh 11y ago
Why didn't we get /dev/getrandom?
- viraptor 11y ago
  One point of a direct syscall is that you don't have to open any files. That protects you from file descriptor exhaustion attacks.
  - cperciva 11y ago
    Another point is that it still works if you're inside a chroot / jail / container / with no devices visible.
    - rakoo 11y ago
      In a way, that's the point of chroot/jail/container: isolate the host filesystem from the guest, so the script that creates it should take /dev into account if it is needed
      - Dylan16807 11y ago
        The point is to isolate access to the host, and single secure random numbers have nothing to do with the host.
- kalleboo 11y ago
  Here's the original syscall request http://lists.openwall.net/linux-kernel/2014/07/17/235 http://lists.openwall.net/linux-kernel/2014/07/17/235 and discussion https://news.ycombinator.com/item?id=8049180 https://news.ycombinator.com/item?id=8049180

frankzinger 11y ago

Previously: https://news.ycombinator.com/item?id=7359992 https://news.ycombinator.com/item?id=7359992

antirez 11y ago

The root problem is that cryptography is not usable without some understanding. In the latest days we developed an addiction for "best practices" like "use bcrypt", "use /dev/random" or alike which in the field of cryptography are not enough: understanding is the only possible path. Actually, this is true for most things, it just shows up more obviously in the field of cryptography because of the security concerns. So we should replace "use bcrypt" with "Read Applied Cryptography & other books".

ReidZB 11y ago
The average guy doesn't have the time to read enough about cryptography to have the sort of knowledge you're wanting. This very article debates an understanding created by incomplete and poor cryptographic knowledge. If there's anything I've learned by studying cryptography, it's that the average person needs to invest significant resources to become a pseudo-expert in cryptography - all before they can make any meaningful decision. Applied Cryptography is not a terribly good starting point for cryptographic understanding these days. That's just another facet of difficulty: where does one even start? Do you want a theoretical baseline understanding? Do you want the high-level, quick-and-dirty overview which only gives a summary? (That'll make it hard to make real, informed decisions...) If we really want to make cryptography accessible to many developers, the best solution is for the cryptographic community to make our libraries and interfaces better. At the same time, there comes a point where a developer has to stop and say "this is beyond what is standardized in ${widely used library}; we need to hire a cryptographer." In that sense, we need to instill a better anti-crypto ethic.
- antirez 11y ago
  Basically to become an expert cryptographer you need a math degree and ten years of experience, so this is out of question indeed. What I'm referring to is to get enough information in order to understand the big picture: what is a stream cipher, what a block cipher, a cryptographic hash function and its main properties, how many of those primitives are kinda equivalent sometimes and you can use one to create another, the tradeoff between speed and security (and how number of rounds effect the security of crypto building blocks), analyzing simple algorithms in order to really understand why it is so hard for you to create something secure, secure PRNG generation and weak PRNG generation (and how to break a congruential linear generator), algorithms like DH, RSA, basic knowledge on number theory, and so forth. This will not make you an expert, but will give you enough understanding in order to actually undetstand why a rule or a best practice is used and when it is safe or not to break it. About starting point, this is incredibly sad but true: there is no Applied Cryptography of 2015. The book is at this point in some way outdated and no replacement exists, however what you can do is to read it, and then to read the documents that there are around to get updated information. Also there are now the online courses on cryptography that really help. This may look like an overkill, but at this point crypto is everywhere and is the foundation of most things secure, so it is a requirement of everybody involved with computer security.

1_player 11y ago

Is there anyone that, with full access to the machine/kernel, has managed to predict the output of random/urandom? I know that a PRNG is predictable if you know all the input variables, and the code for it is publicly available, but has anybody in practice been able to exploit that? EDIT: that's an honest question. I'd like to read a paper about that.

vbezhenar 11y ago

Java is known to read /dev/random when dealing with SecureRandom class. In particular it might cause extremely slow starting time for Tomcat on fresh virtual machine. There's parameter "-Djava.security.egd=file:/dev/./urandom" and I always felt unsafe using it. Thanks to this article, now I won't regret it even theoretically. Fun thing is, if you pass "/dev/urandom" to this parameter, Java will read /dev/random anyway. May be that was a wise decision 20 years ago.