Težave tičijo v generatorju psevdonaključnih števil (PRNG), ki je pri šifriranju izjemno pomemben. Algoritem Dual EC DRBG za tvorjenje psevdonaključnih števil je na primer imel ranljivost, ki jo je NSA izkoriščala za prisluškovanje. Pregled kode LibreSSL je pokazal, da ima ta pomanjkljiv PRNG.
Zgodi se namreč lahko, da začne PRNG vračati ista naključna števila. To se lahko primeri, kadar ima več inačic procesa v Linuxu isto številko PID. Linux sicer vedno poskrbi, da ima starševski proces drugačen PID od procesa, ki ga je skloniral (fork), a lahko se zgodi, da imata bolj oddaljena (starševi starši itn.) procesa enak 16-biten PID. Običajno se to zgodi sila redko, a je vseeno to detajl, na katerega robusten algoritem ne bi smel biti občutljiv. OpenSSL ni, ker v vsakem primeru spremeni seme za PRN, LibreSSL pa tega ne stori, zato je občutljiv.
Druga težava je poganjanje LibreSSL v izoliranem načinu s spremenjenim korenskim direktorijem (chroot jail). V tem primeru LibreSSL ne bo mogel klicati generatorja psevdonaključnih števil v /dev/urandom, zato bo poiskal alternative, ki pa so slabe, sploh ko bo sysctl odstranjen. Uporabil bo PID, datum, pomnilniške naslove in podobne vire entropije, ki so zelo slabi in predvidljivi. Tudi OpenSSL ne more klicati /dev/urandom, a dvigne zastavico z napako, za katero lahko programer preverja, medtem ko LibreSSL tega ne stori in začne uporabljati zanič entropijo.
To kaže, da prepis in čiščenje kode OpenSSL v LibreSSL ni enostaven problem. Res je postal OpenSSL tako glomazen in nepregleden, da nihče ni več točno vedel, kaj počne vsaka vrstica kode. A ravno ob takih ugotovitvah se izkaže, da je lahko brisanje nekaterih rutin tudi dvorezen meč. LibreSSL 2.0.0 je še vedno preizkusna različica in ni namenjena uporabi v kritičnih okoljih, zato ji ranljivosti ne smemo preveč zameriti. Je pa vsekakor prav, da si jih pogledamo.
