Kryptografian toteuttaminen (syventävä)¶

Kryptokirjastot¶

Kehittäjän näkökulmasta kryptografiaa käytetään yleensä kryptografisen kirjaston kautta. Se tarkoittaa kokoelmaa algoritmeja ja skeemoja, joihin päästään ohjelmointirajapinnan eli API:n kautta. Saatavilla on monia erilaisia kryptokirjastoja monilla eri ohjelmointikielillä, joista C-variaatiot ja Java ovat yleisimpiä. Kirjastoilla on erilaisia lisenssirajoituksia. Monet ovat saatavilla erityyppisillä avoimen lähdekoodin lisensseillä.

Joissakin kirjastoissa (esim. OpenSSL tai BouncyCastle) on runsaasti ominaisuuksia ja niitä voidaan käyttää monissa sovelluksissa. Toiset ovat rajoittuneempia ja ne on suunniteltu tukemaan vain tiettyjä käyttötapauksia. Osittain tämä heijastaa kirjastojen tekijöiden makua mutta myös niiden ikää ja käytettävissä olevia kehitysresursseja. Esimerkiksi kumpaistakin kirjastoa on käytetty vuoden 2021 TAU-diplomityössä, jossa toteutettiin kortinlukijaan NFC-käyttöä varten PACE-protokolla: OpenSSL iOS:lle ja BouncyCastle Androidille.

Jotkin kirjastot ovat paremmin ylläpidettyjä kuin toiset. Esimerkiksi ennen Heartbleed-haavoittuvuutta (2012–2014) OpenSSL oli pudonnut jossain määrin huonoon kuntoon. Tästä johtuen Google ja OpenBSD loivat siitä toisistaan riippumatta uudet erilliset kehityshaarat, “forkit”. Heartbleed johti myös laajempaan ymmärrykseen siitä, kuinka tärkeä OpenSSL on koko Internet-ekosysteemille. Seurasi OpenSSL-projektin uudistuksia, ja nykyään se on paljon paremmassa kunnossa, sillä on suurempi joukko ydinkehittäjiä, parempi rahoitus ja aktiivisempi kehitys.

Joidenkin kryptokirjastojen kehittäjät ovat ammattimaisia ohjelmistoinsinöörejä, joilla on huomattava kokemus joidenkin tässäkin pääluvussa käsiteltävien ongelmien välttämisestä. Toisissa kirjastoissa näin ei ole. Monissa tapauksissa kehittäjät työskentelevät vapaaehtoisvoimin. Suurin osa OpenSSL:n koodikehityksestä tehdään tällä tavalla. Kryptokirjastossa tulisi olla selkeä prosessi ilmoittaa ylläpitäjille virheistä ja tietoturva-aukoista ja kehittäjien pitäisi olla sitoutuneita puuttumaan näihin ajoissa.

API-suunnittelu kryptokirjastoille¶

Kryptokirjaston tarjoama sovellusohjelmointirajapinta, API, on kriittinen. On löydettävä herkkä tasapaino joustavuuden ja turvallisuuden välillä. Edellinen antaa kehittäjille mahdollisuuden käyttää kirjastoa monilla eri tavoilla, mikä tekee siitä hyödyllisempää. Jälkimmäisessä APIa rajoitetaan niin, etteivät kehittäjät pääsisi käyttämään kirjastoa turvattomilla tavoilla. Asiaa voi tarkastella tapauksessa, jossa API tarjoaa symmetristä salausta. Pitäisikö kirjaston sallia suora pääsy lohkosalaimeen eli antaa syöttää parametrit ja tekstilohkot sellaisinaan? Jotkut kehittäjät saattavat tarvita tätä jossain vaiheessa, mutta kokematon kehittäjä saattaisi hyvinkin käyttää lohkosalainta ECB-moodissa suuren datamäärän salauksen—tunnetusti turvattomin seurauksin. Tämä on vain yksinkertainen esimerkki. Sen sijaan voisi tarkastella esimerkiksi sellaista APIa, jossa on tai josta puuttuu mahdollisuus syöttää APIin AEAD-salauksen tarvitsemat nonce-arvot. Vielä vaativampaa APIn käyttäjän kannalta olisi antaa hänen valita parametrit alkulukutestausta varten. Tämä materiaali ei edes ole käsitellyt tätä aihetta, joka on oleellinen esim. RSA-parametrien muodostamisessa.

Green ja Smith [Green2016] esittävät kymmenen periaatetta kryptoAPI-suunnittelulle. Ne perustuvat tapausesimerkkien analyysiin ja kehittäjien haastatteluihin. Myöhemmin on tehty myös tieteellisiä tarkasteluja, mutta nämä periaatteet sopivat tälle kurssille.

Green ja Smith toteavat, että kryptokirjastot näyttävät olevan ainutlaatuisen alttiita virheelliselle käytölle ja pienetkin virheet voivat johtaa suuriin ongelmiin. He huomauttavat myös, että kryptografian käytön yleistyessä kirjastoja käyttää yhä useampi kehittäjä ilman kryptografista asiantuntemusta. Tähän sopii lisätä paikallinen huomautus: myöhemmät TAU-kurssit edistävät huomattavasti juuri tämän alan asiantuntemusta kyberturvallisuuden kentällä.

Greenin ja Smithin kymmenen periaatetta voidaan tiivistää seuraavasti:

Integroi kryptografiset toiminnot tavallisiin API-liittymiin; eli piilota kryptografia kehittäjiltä mahdollisuuksien mukaan.
Tee APIt riittäviksi täyttämään sekä turvallisuuteen liittyvät että liittymättömät vaatimukset. Argumentti tässä on se, että kehittäjillä ei viime kädessä ole tietoturvatavoitetta mielessään. Tällöin heidän todellisten vaatimustensa täyttäminen—kuten haastatteluissa oli todettu—rohkaisee heitä käyttämään API-liittymää oman kryptografisen koodin kirjoittamisen sijaan.
Suunnittele API niin, että se on helppo oppia ilman kryptografista asiantuntemusta.
Älä riko kehittäjän paradigmaa (tai mielikuvamallia) siitä, miltä APIn pitäisi näyttää.
Suunnittele API helpoksi käyttää myös ilman dokumentaatiota. Kehittäjät eivät todennäköisesti lukisi sitä kuitenkaan.
Tee APIsta vaikea käyttää väärin. Vääränlaisen käytön pitäisi tuottaa selvästi näkyviä virheitä.
APIlla pitäisi olla turvalliset ja yksiselitteiset oletusasetukset.
API-liittymillä pitäisi olla testausmoodit. Muuten kehittäjät hakkeroivat APIsta turvaominaisuuksia pois kehityksen ajaksi, jotta testaus olisi helpompaa, mutta saattavat epäonnistua niiden palauttamisessa. Tässä suosituksessa on toki se ongelmana, että koodi voi päätyä julkaistavaksi testausmoodin ollessa edelleen käytössä. Toivoa sopii, että normaali ohjelmiston laadunvalvonta ehtisi torjua tämän.
APIa käyttävän koodin tulee olla helppolukuista ja ylläpidettävää. Esimerkiksi sitä, montako hash-iteraation kierrosta salasanasta lasketaan, ei pitäisi asettaa APIn kautta vaan tarvittaessa muokata kirjaston sisällä. Yksi ongelma tässä suosituksessa on, että tällaiset sisäiset oletusasetukset voivat olla liian varovaisia ja heikentää suorituskykyä joissain käyttötapauksissa. Tämä on samalla esimerkki joustavuuden ja turvallisuuden välisestä jännitteestä.
APIn pitäisi toteuttaa myös vuorovaikutusta loppukäyttäjän kanssa sen sijaan, että koko taakka jätettäisiin APIa käyttävälle kehittäjälle. Tässä Green ja Smith korostavat virheilmoitusten merkitystä: APIn ja sen kautta käytettävän kirjaston dokumentaation pitäisi auttaa kehittäjiä ymmärtämään, mitä vikatiloja kirjastolla on, mitkä ovat näiden turvallisuusseuraukset ja kuinka kutsuvan koodin tulisi käsitellä syntyviä virheitä.

[Green2016] M. Green and M. Smith, “Developers are not the enemy!: The need for usable security APIs,” IEEE Security & Privacy, vol. 14, no. 5, 2016.

Kryptografian toteutuksen haasteet¶

Suurin ongelma kryptografian toteuttamisessa on kääntää skeemojen puhtaasti matemaattinen tai pseudokoodikuvaus ohjelmakoodiksi siten, että se ajettaessa yhä noudattaa abstraktilla tasolla tehtyä turva-analyysia. Toisin sanoen haasteena on varmistaa, ettei toteutukseen muodostu mekanismeja, joiden kautta arkaluontoinen tieto voi vuotaa ja joita ei ole jo ennakoitu ja poistettu turva-analyysin yhteydessä. Seuraavassa tulee esille useita tapoja, joilla tällainen vuoto voi syntyä. Yleensä kyse on ns. sivukanavasta (side channel).

Viestin pituuteen liittyvät sivukanavat¶

Salauksen AEAD-skeema (authenticated encryption with associated data) ei piilota selvätekstin pituutta. Päinvastoin, AEAD-skeemassa, kuten AES-GCM:ssä, selvätekstin pituus selviää salatekstin pituudesta triviaalisti. Pituustiedon vuoto voi kuitenkin olla kohtalokas turvallisuudelle. Näin olisi esimerkiksi yksinkertaisessa kaupankäyntijärjestelmää, jossa käyttäjä antaa vain kahdenlaisia komentoja, “OSTA” tai “MYY”. Kun nämä koodataan yksinkertaiseen ASCII-muotoon ja lähetetään AES-GCM-salauksella, salakuuntelija saa komennon selville suoraan viestin tavumäärästä (kryptoteksti on selvätekstin mittainen (+tag), koska AES-GCM:ssä teksti ei mene AESin läpi vaan XOR-kryptautuu vuon tapaan). Yleisemmin tietoliikenteen ja salaamattoman metadatan analysointiin perustuvat hyökkäykset voivat johtaa merkittävään tiedon vuotamiseen.

Viestin ajoitukseen liittyvät sivukanavat¶

Kryptokoodin suorittamiseen kuluva aika saattaa vuotaa tietoa algoritmin sisäisistä käsittelyvaiheista. Tämä voi puolestaan vuotaa arkaluonteisia tietoja, esim. tietoa avaimista. Ensimmäisen kerran tämä ongelma tuli julkisuuteen vuonna 1996 tapauksessa, jossa hyökkääjällä oli suora pääsy ajoitustietoihin. Vuonna 2003 osoitettiin, että tällaiset hyökkäykset olivat toteutettavissa jopa etänä, eli ne saattoivat onnistua, vaikka ajoitustiedot olivat verkkomelun saastuttamia.

Tarkastellaan esimerkiksi naiivia elliptisen käyrän skalaarikertolaskua, joka on optimoitu jättämään huomioimatta skalaarin etunollat. Jos hyökkääjä voi jollain tapaa ajoittaa skalaarikertorutiinin suorittamisen, se voi havaita tapaukset, joissa lasku päättyy aikaisin ja päätellä, millä skalaarikertoimilla on tietty määrä merkittävimmistä biteistä nollia. Rutiinin käyttötavasta riippuen tämä voi tarjota riittävästi sivukanavatietoja avaimen selvittämiseksi. Näin on esimerkiksi ECDSA-järjestelmässä, jossa voidaan hyödyntää jopa satunnaisarvojen osittaista vuotoa. Tästä on tutkimusnäyttöä myös 2020-luvulta. (ECDSA on elliptic curve digital signature algorithm, missä DSA on ElGamal-johdannainen.)

Virhetilanteisiin liittyvät sivukanavat¶

Kryptokäsittelyn aikana ilmenevät virheet voivat vuotaa tietoa sisäisistä käsittelyvaiheista. Klassisen ja edelleen toimiva esimerkin tästä on CBC-moodin salaus ja siinä tarvittava viimeisen selvätekstilohkon täyttö (padding) lohkosalaimen vaatimaan pituuteen. Jos täyte on väärin muotoiltu, syntyy virhe purkuvaiheessa. Jos hyökkääjä pystyy havaitsemaan virheilmoituksen olemassaolon, hän voi pystyä huolellisella kryptotekstien syöttämisellä saamaan aikaan sivukanavan, jolla selvätekstiäkin vuotaa.

Käytännössä virheilmoitukset voivat olla itsekin salattuja, mutta niiden olemassaolo voi paljastua toissijaisen sivukanavan, esim. ajoituskanavan kautta. Toteutus saattaa esim. keskeyttää jatkokäsittelyn täytevirheen havaitessaan. Virhesivukanavan poistamisen vaikeus on käynyt ilmi TLS:ää koskevista analyyseista vielä 2013.

Jaettuihin resursseihin liittyvät hyökkäykset¶

Kryptokoodi ei aina toimi täysin erillään mahdollisista hyökkääjistä. Nykyaikaisissa prosessoreissa on välimuistihierarkia, jossa sama nopea muisti jaetaan eri prosessien kesken, ja jokainen prosessi ylikirjoittaa muiden käyttämiä välimuistin osia. Esimerkiksi pilvilaskennassa useiden käyttäjien prosessit voivat olla käynnissä rinnakkain samassa laitteistossa, vaikka ne olisikin erotettu toisistaan tietoturvatekniikoiden, kuten virtualisoinnin, avulla. Hyökkääjä, joka toimii erillisessä CPU-prosessissa, voisi valikoivasti tyhjentää välimuistin osia ja sitten, kun uhriprosessi on suorittanut kriittistä koodia, tarkkailla omien välimuistiviittausten ajoituksella, onko uhri käyttänyt välimuistin niitä osia vai ei. Jos uhriprosessin muistin käyttö riippuu avaimesta, siitä voi tällä tavoin epäsuorasti vuotaa tietoa. Hyökkäys tunnetaan nimellä Flush+Reload ja se esiteltiin vuonna 2014. Useita muitakin välimuistiin perustuvia hyökkäyksiä tunnetaan. Tällaisten hyökkäysten mahdollisuus keksittiin vuonna 2002. Muutamaa vuotta myöhemmin ne osoittautuivat ongelmallisiksi erityisesti AES:lle.

Viime vuosina tutkijoilla on ollut runsaasti tilaisuuksia kehittää välimuistiin ja mikroarkkitehtuuriin perustuvia hyökkäyksiä kryptototeutuksia vastaan. Hyökkäysten mahdollisuus johtuu yleensä siitä, että prosessorien suunnittelijat tekevät arkkitehtuurissa kompromisseja tavoitellessaan nopeutta.

Toteutuksen heikkoudet¶

Kryptototeutuksissa esiintyy myös paljon tavanomaisempia heikkouksia kuin edellä käsitellyt sivukanavat. Avaimet voidaan käytön jälkeen jättää poistamatta, tai ne voidaan vahingossa kirjoittaa varmuuskopioon. Purettu selväteksti voidaan virheellisesti päästää kutsuvaan sovellukseen ennen kuin sen eheys on tarkistettu. Tämä voi tapahtua skeemoissa, joissa MAC:n tarkistus tehdään salauksen purkamisen jälkeen. Samoin voi käydä suoratoistosovelluksissa, joissa purettua dataa varten on vain rajoitetun kokoinen puskuri.

Järjestelmän koostamisesta johtuvat hyökkäykset¶

Useita kryptografisia komponentteja käyttävä järjestelmä voi vahingossa vuotaa arkaluonteisia tietoja näiden komponenttien väärän yhdistämisen vuoksi. Vuotoja syntyy siis järjestelmätasolla eikä suoraan komponenteista. Esimerkiksi käy Zcashin tapaus. Zcash on anonyymi kryptovaluutta, jonka uloimpana kerroksena on julkisen avaimen salaus, jolla tuotetaan rahan vastaanottajan anonymiteetti. Zcash-asiakas päättelee, onko lähetys tarkoitettu hänelle kokeilemalla salauksen purkua yksityisellä avaimellaan. Jos tämä epäonnistuu, jatkokäsittelyä ei suoriteta. Muussa tapauksessa suoritetaan muita komponentteja, joita ovat nollatietotodistus ja sitoutumisen tarkistaminen. Tästä syntyy mahdollisesti havaittava ero kokonaisuuden käyttäytymisessä, ja anonymiteetti särkyy. Näin käy vaikka julkisen avaimen systeemi ja muut komponentit täyttäisivät tehtävänsä.

Laitteistoon liittyvät sivukanavat¶

Kryptografia toteutetaan usein suoraan laitteistossa. Esimerkiksi kryptografisten toimintojen laitteistokiihdytys oli aikoinaan yleistä sekä halvoissa ympäristöissä, kuten maksukorteissa, että vaativissa sovelluksissa, kuten palvelinpuolen TLS-toiminnoissa. Nykyään IoT-toteutukset voivat käyttää laitteistokomponentteja raskaiden kryptofunktioiden toteuttamiseen. Laitteistopohjaista kryptografiaa on myös Trusted Computing Groupin määrittelemissä TPM-moduuleissa (Trusted platform modules) sekä Intelin SGX-järjestelmästä (Software guard extensions) ja ARMin Trustzone-järjestelmässä. Ja yleisesti nykyaikaisen CPU:n käskykanta mahdollistaa tärkeiden algoritmien, kuten AES:n, tehokkaan toteuttamisen.

Kryptografian toteuttaminen laitteistotasolla tuo uusia vuotomahdollisuuksia edellä esillä olleiden sivukanavien rinnalle. Esimerkiksi toimikorttia vastaan hyökkäävä saattaa pystyä hienojakoisella aikaresoluutiolla tarkkailemaan kortin tehonkulutusta, mikä saattaa paljastaa kulloinkin suoritettavan toiminnon tyypin. Jos esimerkiksi RSA-salauksen purku (tai allekirjoitus) on toteutettu neliöinneillä ja kertolaskuilla, niin yksityisen avaimen bitti 1 aiheuttaa neliöinnin ja kertolaskun mutta 0 vain neliöinnin. Jos tätä eroa ei ole peitetty, avain voidaan lukea bitti bitiltä tehojäljestä.

Laitteiston sähkömagneettiset päästöt voivat myös vuotaa arkaluonteisia tietoja. Jopa äänisivukanavat ovat mahdollisia. Esimerkiksi ensimmäisellä toimivalla QKD-prototyypillä (quantum key distribution, 1990) kerrottiin olevan tällainen sivukanava, koska tarkkailija saattoi kuunnella optisten komponenttien fyysistä liikkumista ja siten oppia, mitä polarisaatiota kullekin lähetettävälle signaalille käytettiin. Tämä korostaa vain yhtä monista haasteista, jotka liittyvät ehdottoman turvallisuuden saavuttamiseen fysiikan lakien alaisuudessa. Lisää laitteistopuolen sivukanavista on kerrottu myöhemmässä pääluvussa.

Hyökkäykset vikoja aiheuttamalla¶

Laitteistototeutukset voivat myös olla alttiita vika- tai häiriöhyökkäyksille, joissa aiheutetaan ulkoapäin virhe kryptografisen laskennan tarkasti määrättyyn vaiheeseen. Tällä tavoin saadaan väärä lopputulos, mutta siitä voidaan päätellä arkaluonteista tietoa, tyypillisesti avain. Ensimmäinen (1997) tällainen hyökkäys kohdistui RSA-toteutukseen, joka laski erikseen kummankin alkulukutekijän (p ja q) suhteen ennen kuin muodosti tuloksen moduulin (p·q) suhteen. Oikein ajoitettu vika (“glitch”) saattoi saada tulostetuksi laskun pelkän p:n suhteen, mikä johti tekijöihinjaon onnistumiseen. Tämän hyökkäysmuodon uudempi esiintyminen (2014), nimeltään Rowhammer, tähtää vikojen tuottamiseen muistipaikoissa, joihin avaimet tallennetaan. Tätä yritetään kirjoittamalla toistuvasti vierekkäisiin paikkoihin (ks. Käyttöjärjestelmät, jossa myös sivukanavista.)

Puolustautuminen¶

Kryptografisen toteutuksen haavoittuvuudet ovat eri asia kuin itse algoritmien tai järjestelmien heikkoudet. Yleiset tekniikat toteutuksen haavoittuvuuksilta suojautumiseen tulevat ohjelmisto- ja laitteistoturvallisuuden aloilta. Ne on tiivistetty hyvin tämän materiaalin muissa pääluvuissa. On ilmeistä, että perinteinen ohjelmistoturvallisuus on tärkeämpää kryptografiselle koodille kuin muille ohjelmistotyypeille.

Laitteistossa käytetään yleisesti sokaisua, peittämistä, kynnystekniikkaa ja fyysistä suojausta (blinding, masking, threshold techniques, physical shielding). Ohjelmistojen osalta yleisiä tekniikoita ovat ohjelmisto- ja laitteistosuunnitelmien muodollinen määrittely ja verifiointi, koodin staattinen ja dynaaminen analyysi, fuzzing, tietovirta-analyysi, sovellusalakohtaisten kielten käyttö kryptokoodin luomiseen sekä vahvan tyypityksen käyttö mallintamiseen ja turvaominaisuuksien toteutukseen.

Pituussivukanavat voidaan sulkea täyttämällä selvätekstit johonkin ennalta määrätyistä mitoista ennen salausta ja lisäämällä peite- tai valeliikennettä. Turvallisissa tietoliikenneprotokollissa, kuten TLS ja IPsec, on tätä tukevia ominaisuuksia, mutta niitä ei käytetä laajalti. On kehitetty koodauskäytäntöjä, joilla pyritään niin sanottuun vakioaikaiseen kryptografiaan. Ydinideana on poistaa huolellisen ohjelmoinnin avulla kaikki korrelaatio arkaluontoisten tietojen ja hyökkääjän havaitsemien muuttujien, esim. suoritusajan, väliltä. Tämä edellyttää muun muassa sitä, että vältetään avaimesta riippuvaisia muistihakuja ja haarautumisia sekä tiettyjä matalan tason käskyjä, joiden ajoaika on operandiriippuvainen. Se voi myös vaatia korkean tason koodin kirjoittamista siten, että kääntäjä ei optimoinnissa poista tehtyjä vakioaikaistuksia. Vakioaikakoodin kirjoittaminen olemassa oleville algoritmeille ei ole triviaalia. Joissakin tapauksissa kryptosuunnittelijat ovat ottaneet asian huomioon alusta alkaen algoritmeissaan. Esimerkiksi Bernsteinin ChaCha20-algoritmissa on tehty näin. Vastaavasti tiettyjä koordinaattijärjestelmiä käyttämällä on helpompi saavuttaa vakioaikaisuus elliptisen käyrän algoritmeille.

Satunnaisten bittien luominen¶

Kryptografia perustuu ratkaisevalla tavalla satunnaisuuteen. Ilmeisimmin satunnaisia bittejä tarvitaan symmetrisiksi avaimiksi ja lähtökohdiksi julkisten avainten luontialgoritmeille. Joissain allekirjoitusmenetelmissä on satunnaistettu algoritmi. Tällaisia ovat esim. RSA-PSS, DSA ja ECDSA. Tässä PSS = probabilistic signature scheme, DSA = digital signature algorithm (ElGamal-johdannainen) ja EC = elliptic curve.

Kryptoalgoritmeilla ja myös -protokollilla on oltava pääsy “vahvoihin” satunnaisten bittien lähteisiin. Jotta lähde voi olla yleisesti sovellettavissa, sen tulisi tarjota runsaasti toisistaan riippumattomia ja tasaisesti jakautuneita bittejä, joista hyökkääjä ei saa tietoa. Tietyt algoritmit voivat paljastaa bittinsä, mutta yleinen käyttö edellyttää, että ne pysyvät piilossa.

Ihanteellisessa maailmassa jokainen tietokonelaite sisältäisi aitojen satunnaisbittien lähteen, TRBG (true random bit generator, myös TRNG, missä N=number), jonka ulostulo on piilotettu mahdollisilta hyökkääjiltä. Käytännössä tämä on osoittautunut erittäin vaikeaksi saavuttaa. Intel- ja AMD-suorittimet tarjoavat pääsyn TRBG:n jälkikäsiteltyyn ulostuloon RDRAND-käskyn kautta, mutta generaattoreiden rakenne ei ole täysin avoin. TRBG:n puuttuessa yleinen käytäntö on, että käyttöjärjestelmä kerää tietoja heikoista paikallisista entropialähteistä, joita ovat esim. näppäilyn ajoitukset, massamuistin hakuajat, prosessitunnukset ja pakettien saapumisajat. Tämä data “kaadetaan” ja sekoitetaan ns. entropiapooliin (“arvaamattomuusaltaaseen”). Siitä poimitaan näennäissatunnaisia bittejä tarpeen mukaan siemeneksi kryptografiselle näennäissatunnaisgeneraattorille, eli PRNG-funktiolle (pseudo-random number generator). NIST on standardoinut tämän tyyppiset mallit (2015). Niitä myös käytetään useimmissa käyttöjärjestelmissä mutta erilaisilla ad hoc -rakenteilla, joita on vaikea analysoida. Tutkimus on tuottanut satunnaisbittien generaattoreille kypsät muodolliset turvallisuusmallit ja -rakenteet, mutta tässä on jälleen yksi tapaus, jossa käytäntö meni aluksi teorian edelle. Sitten kehitettiin hyödyllinen teoria, mutta käytäntö jäi jälkeen.

On haastavaa arvioida, kuinka paljon todellista satunnaisuutta voidaan kerätä edellä mainituista heikoista entropialähteistä. Joissakin laskentaympäristöissä, kuten sulautetuissa järjestelmissä, jotkin tai kaikki lähteet saattavat puuttua. Tämä johtaa entropiavarannon hitaaseen täyttymiseen uudelleenkäynnistyksen jälkeen. Tähän liittyvä ongelma ilmenee virtuaalikoneympäristöissä, joissa voi muodostua toisteista satunnaisuutta, jos sitä haetaan isäntäkäyttöjärjestelmästä liian pian virtuaalikoneen resetoinnin jälkeen.

On käyty pitkään keskustelua siitä, pitäisikö satunnaisgeneraattoreiden sulkea ulostulo vai ei, kun käyttöjärjestelmän ylläpitämä poolin entropiaestimaatti putoaa tietyn kynnyksen alapuolelle. Lyhyt vastaus on ei, kunhan uskotaan, että käytössä oleva PRNG on kryptografisesti vahva ja entropiapooli on kunnolla alustettu käynnistyksen jälkeen. Tämä johtuu siitä, että vahvan PRNG:n tuotosta ei voi laskennallisesti erottaa satunnaisesta, vaikka se ei olisikaan aidosti satunnaista. Jotkut modernit käyttöjärjestelmät tarjoavat rajapinnan generaattoriin, joka on tyyppiä “ei-estetä-jos-kunnolla-alustettu”.