if a server uses /dev/random to generate the random session key with a client. How you can launch a Denial-Of-Service (DOS) attack on such a server?

  • Is this homework? Have you done any research? Commented Oct 2, 2018 at 23:14
  • What happens if you delete (or worse replace with a malicious variant) /dev/random? Though this does sound like a homework question... :-/
    – HashHazard
    Commented Oct 3, 2018 at 0:55
  • it is not homework lol. Commented Oct 3, 2018 at 0:57

2 Answers 2


Aside from all the normal DoS attack methods that are likely to work against the system, you may under certain conditions be able to DoS the system by requesting an insanely large number of new session ID's.

Note that I say 'may under certain circumstances' here for two reasons:

  • The attack relies on exhausting /dev/random's entropy. This won't work on some UNIX systems, such as OpenBSD, which will happily supply secure random numbers from /dev/random until the heat death of the universe without blocking. This is because on OpenBSD /dev/random is a symlink to /dev/arandom, which is a free-running CSPRNG that periodically gets more entropy injected..
  • Sane services only use /dev/random to seed their internal RNG, and then use that for generating things like session keys, which means they have no issues beyond startup or re-seeding with an empty entropy pool. Even smarter ones use /dev/urandom for seeding instead, so they have literally no issues at all with an empty entropy pool.

Even assuming that the rest of the system isn't affected by the lack of entropy, you might not be able to have much direct impact on that service itself. Depending on the way it's designed, you may have exactly zero impact beyond your own connection to the service.


You might refer to the problem that reading from /dev/random will block on some systems if there is not enough entropy available. Quickly drawing entropy from the system by creating lots of session ids might thus lead to the application blocking when creating another session id, thus making at least this specific part of the application not respond for some time - a denial of service attack.

How exactly one can make the application create new session ids depends on the application but for typical implementations it might be enough to send a single HTTP request which does not have a session cookie yet and sending lots of such requests can easily be automated.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .