Kysymys:
Onko rand / dev / urandom-rand turvallinen kirjautumisavaimelle?
Incognito
2011-05-19 00:47:43 UTC
view on stackexchange narkive permalink

Sanotaan, että haluan luoda evästeen käyttäjälle. Riittääkö yksinkertaisesti 1024 bittisen merkkijonon luominen / dev / urandom -sovelluksella ja tarkistamalla, onko se jo olemassa (silmukkaaminen, kunnes saan ainutlaatuisen)?

Pitäisikö minun luoda avain johonkin muuhun? Onko tämä altis jotenkin hyväksikäytölle?

Ainutlaatuisuuden tarkistaminen on hidasta. Parempi valinta on varmistaa ainutlaatuisuus. Liitä aikaleima merkkijonoon niin alas kuin mahdollista. Tämä varmistaa, ettei kahta merkkijonoa ole koskaan sama, vaikka satunnaisuus olisi jotenkin sama.
@DampeS8N Oletat, että aikaleiman toistuva hakeminen tuottaa monotonisesti kasvavan arvon. Tämä ei ole totta: aikaleima voi pysyä vakiona nopean toimintajakson aikana ja voi siirtyä taaksepäin, koska kello nollataan jostain syystä. (Suositeltava lukeminen: [Salaustekniikka] (http://www.schneier.com/book-ce.html) kohta 16.) Laskuri on luotettava (ja nopea) tapa varmistaa ainutlaatuisuus, jos voit tallentaa sen pitkäkestoinen muisti. Salauslaadun (P) RNG varmistaa (salauksen laadun) ainutlaatuisuuden, mitään ylimääräistä tekniikkaa ei tarvita.
@Gilles: sovittu. Tiski on aina parempi valinta. Mutta pitäisi olla tiedossa, että puhumme ERITTÄIN harvinaisesta ajasta, jolloin sekä satunnaisuus että aikaleima ovat samat. Ja dev / urandom /: lla puhumme kerran universumin tapahtumasta.
@DampeS8N Jos `/ dev / urandom` antaa sinulle toistoja, sinulla on turvallisuusongelma, jota pelkkä laskurin lisääminen ei korjaa. Koska keskustelumme etenee poispäin kysymyksestä, ehdotan, että jatkamme [chatiin] (chat.stackexchange.com/rooms/info/151).
Kaikki tämä näyttää akateemiselta. Kahden samanlaisen 1024-bittisen viestin satunnaisen tuottamisen todennäköisyys on niin järjettömän pieni, että se ei edes ota huomioon.
@NickJohnson ajaa seuraava komento mille tahansa linux-koneelle: `cat / dev / urandom | rngtest -c 1000` useita kertoja. JOS se on vm (niin monta palvelinympäristöä on nyt), epäonnistut FIPS-yhteensopivuuden jokaisen toisen ajon suhteen.
@NickJohnson, Se riippuu ei-ainutlaatuisen yhteenoton ** seurauksesta **. Jos seurauksena on maailmankaikkeuden loppu, niin kyllä, on järkevää tarkistaa ainutlaatuisuus.
@Pacerier Jos olemme ainoat älykkäät olennot maailmankaikkeudessa, jokainen tarkastuksen epäonnistuminen aiheuttaa keskimäärin 6e9 / 2 ^ 512 = 4,5e-145 kuolemaa. Pienelle numerolle ei ole edes SI-päätettä. Meidän olisi keskityttävä korkeamman riskin toimintoihin, kuten salaman iskemiseen kirkkaalta taivaalta laskuvarjohyppyyn päivänä, jona voitat arpajaiset.
@NickJohnson, Olet sekoittamassa voittotodennäköisyyden odotettuun arvoon. Odotus on 4,5e-145, mikä on keskiarvo monilla ajoilla. Mutta jokainen ajo voi hyvinkin päätyä muualle, tässä tapauksessa: 0 * seuraus tai 1 * seuraus. Jotkut satunnaiset ihmiset, joita salama iski kirkkaalta taivaalta, on vähemmän kuin merkityksetön maailmankaikkeuteen verrattuna.
@Pacerier On tilastollisesti pätevää ekstrapoloida todennäköisyys odotettuun arvoon, erityisesti tämänkaltaisissa tilastollisissa tarkoituksissa. Jos antaisit minulle revolverin, jossa on 4,5e145 kammiota ja yksi luodin, ja tarjoat minulle 1 dollaria vetoa kohti, ottaisin sinut sinne joka päivä.
@NickJohnson, Ei, jos asuisit ikuisesti.Vastaisit tarjouksen vain ja vain siksi, että sinulla on kiinteä aika, jonka voit elää joka tapauksessa ja siten, että elämä on ** rajoitettu **.Universumin lopun oletetaan tässä olevan kuitenkin yhtä suuri kuin ** rajaton ** / ääretön.
@Gilles, NickJohnson, Re "akateeminen";Kyllä, mutta kaikki evästeet eivät ole 1024 bittiä.Jotkut ovat vain 36 ^ 16.Ja se riippuu olennaisesti täysin siitä, kuinka monta evästettä hän tuottaa.Jos hän tuottaa 700 * 6b * 9t evästettä mikrosekunnissa ja saa silti eksponentiaalisesti * nopeammin * jokaisen mikrosekunnin mukana, ennemmin tai myöhemmin saataisiin osuma.
@Pacerier Vaikka seuraukset olisivat maailmankaikkeuden loppupuolella, ei ole järkevää tarkistaa ainutlaatuisuutta.On ylivoimaisesti todennäköisempää, että meteori tuhoaa kaiken elämän maapallolla kuin ainutlaatuinen arvo koskaan vapautuu.
Neljä vastused:
#1
+230
Thomas Pornin
2011-05-19 01:46:02 UTC
view on stackexchange narkive permalink

Lyhyt vastaus on kyllä. Pitkä vastaus on myös kyllä. / dev / urandom tuottaa tietoja, joita ei voida erottaa todellisesta satunnaisuudesta nykyisen tekniikan perusteella. "Paremman" satunnaisuuden saaminen kuin mitä / dev / urandom tarjoaa, on merkityksetöntä, ellet käytä yhtä harvoista "informaatioteoreettisista" salausalgoritmeista, mikä ei ole sinun tapauksesi (tiedät sen).

urandom -sivun man-sivu on hieman harhaanjohtava, epäilemättä suorastaan ​​väärä, kun se viittaa siihen, että / dev / urandom saattaa "loppua entropiasta" ja / dev / satunnainen on suositeltava; ainoa hetki, jossa / dev / urandom saattaa merkitä tietoturvaongelmaa matalan entropian takia, on uuden, automatisoidun käyttöjärjestelmän asennuksen ensimmäisinä hetkinä. jos kone käynnistyy pisteeseen, jossa sillä on ollut jonkin verran verkkotoimintaa, se on kerännyt riittävän fyysisen satunnaisuuden tarjoamaan riittävän korkealaatuisen satunnaisuuden kaikille käytännön käyttötarkoituksille (puhun täällä Linuxista; FreeBSD: llä, se hetkellinen hetkellinen lievä heikkoutta ei esiinny lainkaan). Toisaalta / dev / random : lla on taipumus estää esto sopimattomina aikoina, mikä johtaa hyvin todellisiin ja hankaliin käytettävyysongelmiin. Tai sanoa vähemmän sanoilla: käytä / dev / urandom ja ole onnellinen; käytä / dev / random ja ole pahoillani.

( Muokkaa: tämä verkkosivu selittää eroja / dev / random ja / dev / urandom melko selvästi.)

"Evästeen" tuottamiseksi: tällaisen evästeen on oltava sellainen, että kahdella käyttäjällä ei ole samaa evästettä, eikä kukaan ole laskennallisesti mahdotonta "arvata" olemassa olevan evästeen arvoa. Satunnaisten tavujen sarja tekee sen hyvin, jos se käyttää riittävän laadukasta satunnaisuutta ( / dev / urandom on hieno) ja että se on tarpeeksi pitkä . Nyrkkisääntönä, jos sinulla on vähemmän kuin 2n käyttäjiä ( n = 33 jos koko maapallon väestö voisi käyttää järjestelmääsi), sitten n + 128 bitin sarja on riittävän leveä; sinun ei tarvitse edes tarkistaa törmäystä olemassa oleviin arvoihin: et näe sitä elinaikanasi. 161 bittiä mahtuu 21 tavuun.

On joitain temppuja, jotka voidaan suorittaa, jos haluat lyhyempiä evästeitä ja haluat silti välttää törmäysten etsimistä tietokannastasi. Mutta tuskin sen pitäisi olla välttämätöntä evästeelle (oletan verkkopohjaisen kontekstin). Muista myös pitää evästeet luottamuksellisina (ts. Käyttää HTTPS: ää ja asettaa evästeet "suojatut" ja "HttpOnly" liput).

Urandom "loppumassa" -aiheessa olet vain oikeassa. Järjestelmässä, jossa on huono entropialähde (kuten virtuaalikone) ja korkea entropian käyttöaste (paljon SSH-yhteyksiä, VPN-tunneleita jne.), Urandom palauttaa vähemmän satunnaisia ​​tietoja estämisen sijaan. "Vähemmän satunnainen" on löysä termi, mutta se tarkoittaa, että todennäköisemmin näet toistoa. Onko se ongelma? Hakemuksellasi on merkitystä :) Tässä tapauksessa urandom on todennäköisesti hyvä.
@Bill,, joka ei ole * oikea. Mahdollisuudet nähdä toistoa kohteesta "/ dev / urandom" entropian suuren käytön vuoksi ovat käytännössä nolla. (Tarkemmin sanottuna "toistolla" tarkoitan toistojen määrää, joka on tilastollisesti merkitsevästi suurempi kuin sattuma odottaa.) Ei ole oleellista riskiä siitä, että "/ dev / urandom" koskaan "loppuu" elämäsi aikana.
Hyvä vastaus, mukava kattavuus koko kysymykseen, mukaan lukien eväste. Sen sijaan, että tarkastaisit satunnaisarvoa muihin satunnaisiin arvoihin, tarkista generaattorin lähtö khi-neliötestillä. Fourmilabilla on ohjelma [ent] (http://www.fourmilab.ch/random/), joka testaa generaattorin entropian ja sisältää khi-neliötestin.
Mitä tarkoittaa, kun / dev / urandom loppuu entropiasta, on se, että se tuottaa ennakoitavamman satunnaisuuden, eli se, että hyökkääjä, jolla on riittävä prosessointiteho, voi teoreettisesti tehdä satunnaislukujenne tilastollisen analyysin PRNG: n sisäisen tilan määrittämiseksi, ja ennustaa siis tulevaisuuden satunnaislähtösi. Tämä on kuitenkin helpompi sanoa kuin tehdä.
Haluat ehkä katsella J. Alex Haldermanin 30C3: ssa pitämää keskustelua "Nopea Internetin kattava skannaus ja sen suojaussovellukset". He etsivät suuresti SSH-avaimia ja löysivät periaatteessa monia päällekkäisiä avaimia. On käynyt ilmi, että monissa laitteissa oli upotettuja järjestelmiä (kuten reitittimiä), joilta puuttuu hyvät entropialähteet (hiiri, näppäimistö jne.) Ja jotka yleensä muodostavat SSH-avaimen heti käynnistyksen jälkeen. He totesivat, että / dev / urandomille on olemassa "entropiaväli", joka voi kestää 60 sekuntia (!) järjestelmän käynnistyksen jälkeen, jolloin lähtö on todella ennustettavissa.
@dog Ennen kuin CSPRNG on kylvetty riittävällä entropialla, sen tulos on aina ennustettavissa riippumatta siitä, kuinka vähän tietoja luet. Kun se on kylvetty riittävällä entropialla, se ei ole koskaan (käytännöllisesti) ennustettavissa riippumatta siitä kuinka paljon tietoja luet. "Entopian loppuminen" ei ole asia. (CSPRNG: llä on teoreettiset rajat sille, kuinka paljon dataa voidaan tuottaa ilman uudelleentoimitusta, mutta et koskaan osu niihin, ellei kyseinen CSPRNG imeydy.)
@Thomas, Miksi Schneier https://www.schneier.com/blog/archives/2013/10/insecurities_in.html on ristiriidassa vastauksesi kanssa?
Ei ole ristiriitaa (Schneier lainaa myös vain muiden ihmisten kirjoittamaa artikkelia). Tutkimus on huolestunut _ toipumisesta sisäisestä valtion kompromissista_, jo mätänevästä tilanteesta. Jos järjestelmäsi oli täysin vaarantunut, sinun olisi pitänyt purkaa se kiertoradalta sen sijaan, että jatkat avainten luomista sen kanssa; artikkelin mukaan _ jos_ teet väärin (jatkat vaarantuneen koneen käyttöä "sellaisenaan" ja rukoilet parasta), silloin / dev / random (ja urandom) -kohdassa käytetty PRNG ei pelasta ihoa - mutta realistisesti mikään ei olisi.
@ThomasPornin, uudestaan "on aloittanut jonkin verran verkkotoimintaa";Entä airgapped laitteet?
@D.W., "Ei oikein";Ja mikä käyttöjärjestelmä?
@MattNordhoff, uudelleen "sen tuotos on aina ennustettavissa";Sinulta puuttuu asia.asia on, että jos käytät `urandom` ** -ohjelmaa, saat epävarman tuloksen **, kuten J. Alex Halderman on osoittanut yllä.Jos käytät sen sijaan `` satunnaista``, se estäisi, kunnes se on turvallista, joten lähtö on turvallinen.¶ Konteksti ja käyttötapa määrittelevät, onko jokin (ei) turvallinen, Lyhyesti sanottuna: joissakin tapauksissa käytä `satunnaista` ja ole onnellinen;käytä `urandom` ja ole pahoillani.
Pitääkö tämä vastaus paikkansa MacOS: ssa?Olen kiinnostunut kryptovaluutta-lompakko-ohjelmiston kontekstista, joka perustuu käyttöjärjestelmän entropiaan yksityisten avainten luomisessa.
@Scratcha, MacOS perustuu FreeBSD: hen, joten jos olet muuttanut näiden kahden laitteen (`/ dev / random` ja` / dev / urandom`) toteutusta ja olettaen, että lompakkosi ohjelmisto käyttää niitä riittävästi, niin olet hyvä.
#2
+25
D.W.
2011-05-19 11:33:22 UTC
view on stackexchange narkive permalink

Kyllä, se on hieno tapa.

@ Thomasin selitys naulaa sen. Ja hän on täysin oikeassa arvostellessaan / dev / urandom -sivua. Paikan päällä.

Mutta ohita "tarkista onko se jo olemassa". Tämä tarkistus on turha. Sitä ei tapahdu. (Mahdollisuudet tapahtumaan ovat pienemmät kuin todennäköisyys salaman iskemiseen - useita kertoja - samana päivänä.)

Joten kuka on oikeassa, tämä sivu tai https://www.schneier.com/blog/archives/2013/10/insecurities_in.html?
@Pacerier, tässä kommentissa ei ole tarpeeksi tilaa antaa vivahteikas selitys. Riittää, kun sanotaan, että asiakirjan käytännön vaikutukset tähän kysymykseen ovat erittäin rajalliset. Katso esim. https://www.mail-archive.com/[email protected]/msg13301.html (keskity tekniseen sisältöön). Katso myös https://www.mail-archive.com/cypherpunks%40cpunks.org/msg01390.html ja https://www.mail-archive.com/cypherpunks%40cpunks.org/msg01365.html. Jos haluat ymmärtää paremmin, kysy erillinen kysymys Crypto.SE-sivustolta. Älä käytä kommentteja kysymysten esittämiseen; lähetä uusi kysymys.
#3
+1
Tom Hale
2016-11-19 15:02:34 UTC
view on stackexchange narkive permalink

Ole tietoinen reunatapauksista, jos käytät Linuxia tai NetBSD: tä.

Linuxissa haluat varmistaa, että käynnistyksen jälkeen on saatu riittävä entropia CSPRNG: n oikeaan siementämiseen tai getrandom () -järjestelmäkutsu lukea osoitteesta / dev / urandom ja estää vain siinä harvinaisessa tapauksessa, että käynnistämisen jälkeinen alkusiemen entropia on riittävä ei ole käytettävissä.

NetBSD: ssä haluat lukea osoitteesta / dev / random ainakin kerran ennen lukemista kohdasta / dev / urandom sen varmistamiseksi. on kylvetty kunnolla.

FreeBSD: llä ja MacOS: lla ei ole eroa / dev / random ja / dev / urandom välillä.

Lyhyt vastaus on edelleen käyttää /dev/urandom.

Katso lisätietoja kohdasta Milloin käyttää / dev / random vs / dev / urandom yksityiskohdat.

#4
-4
Buktop
2013-08-14 02:01:06 UTC
view on stackexchange narkive permalink

Alkaen http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt "Todellisen entropian luominen tietokoneessa on melko vaikeaa, koska mikään kvanttifysiikan ulkopuolella ei ole satunnaista Linux-ydin käyttää näppäimistö-, hiiri-, verkko- ja levytoimintoja salausalgoritmilla (SHA1) tuottaakseen tietoja / dev / random -laitteelle. Yksi ongelmista on, että syöte ei ole vakio, joten ytimen entropia uima-allas voi helposti tyhjentyä. "" Toinen ongelma näppäimistön, hiiren, verkon ja levyn toiminnassa on se, että tyhjäkäynnillä, miehittämättömissä ja levytöntä järjestelmissä tällaista syötettä on hyvin vähän tai ei lainkaan. "

Minusta näyttää todella mahdolliselta, että / dev / urandom loppuu, koska / dev / random syöttää sitä.

Luitko [Thomasin vastauksen] (http://security.stackexchange.com/a/3939/5947)? Jos näin on, miksi luulet sen olevan väärin?
Kyllä, Keith, luin. Kun / dev / random on estetty, koska entropiajoukko loppuu, / dev / urandom antaa satunnaiset puremat käyttämällä samaa entropiaa jokaiselle uudelle pyynnölle. Jos et välitä ennakointiresistenssistä, voit käyttää / dev / urandom -toimintoa yksinkertaisena satunnaisbittien lähteenä (se vastaa aina, ei estoa). Jos kuitenkin välität siitä, että jokainen seuraava luotu avain (esimerkkinä) perustui vähemmän ennustettaviin satunnaisbitteihin kuin use / dev / random ja syötä entropiasarja muodostamalla järjestelmätapahtumat case / dev / random-lohkoihin.
Thomas näyttää siltä, ​​että `/ dev / urandom` `entropian loppuminen '' ei vain ole ongelma. Se tuottaa edelleen satunnaisia ​​tavuja muilla tavoin, mutta käytännössä se ei vaikuta ennustettavuuteen. En tiedä tarpeeksi asioista arvioidakseni, onko hän oikeassa (vaikka se, mitä hän sanoo, on samaa mieltä asioista, joita olen lukenut muualla). Onko sinulla tarkkoja todisteita (tai vankkaa teoriaa), joka viittaa siihen, että entropia-altaan tyhjentäminen on todellinen ongelma tuotteelle "/ dev / urandom"? Koodi, joka tosiasiallisesti ennustaa `/ dev / urandom` -tuotteen paremmilla tuloksilla kuin sattuma, olisi hyvä todiste.
Olen samaa mieltä siitä, että kun / dev / satunnaiset estot aiheuttavat ei-tarvitun entropian altaassa, voimme käyttää / dev / urandomia - se jatkaa vastaamista. Sen lähdöt perustuvat kuitenkin samaan entropiaan (suoritetaan SHA-1: n läpi) ja ovat mahdollisesti ennustettavissa, jos hyökkääjä kerää / dev / urandom -tuotteen tai vaikka hän kerää sen, mikä on luotu käyttämällä / dev / -yrityksestä saatua entropiaa. urandom. Kaikki tämä tapausta varten, kun entropiapoolilla ei ole tarpeeksi tietoa syötettäväksi / dev / random.
"/ dev / urandom käyttää pieniä määriä dataa / dev / random -laitteesta toissijaisen entropiajoukon siementämiseen. Tämän seurauksena todellinen entropia täytetään, jotta se voidaan säilyttää. / dev / urandomin käyttö voi aiheuttaa / dev / random-ryhmän tulee tyhjäksi, mutta jos näin tapahtuu, / dev / urandom ei estä ja se jatkaa viimeisen käytettävissä olevan siemenen käyttöä.Tämä tekee / dev / urandomista teoriassa haavoittuvan toistuvien tietojen tuottamiselle käytetyn algoritmin rajoituksista riippuen, mutta tämä on erittäin harvinaista, ja tietoni mukaan sitä ei ole koskaan tapahtunut.
/ dev / urandomia pidetään laajalti turvallisena kaikkiin salaustarkoituksiin lukuun ottamatta kaikkein vainoharhaisimpia ihmisiä. "
Viimeisimmät kommenttisi näyttävät melkein olevan ristiriidassa vastauksesi kanssa.
"Viimeisen käytettävissä olevan siemenen käyttö" ei tarkoita, että tulos toistuu.Se on edelleen kryptografisesti turvallinen lähtö, ja se on olennaisesti ikuisesti, ellei joku vaaranna ydintä ja lue siemen muistista.
Jos lähdöt toistavat, kuinka se voidaan salata turvallisesti?FIPS140-2 viestii siitä selvästi. Rakastan olla miinus ainoa oikea vastaus säiettä.NIST ei hyväksy / dev / urandom.NIST hyväksyy vain 128 bittiä kohteesta / dev / random (hyväksyykö NIST silti vielä niin paljon?).Mutta fiksut tietävät paremmin.
/ dev / urandom toistaa lähdöt, kun järjestelmässä ei tapahdu mitään tapahtumia./ dev / random ei tarjoa tässä tapauksessa ulostuloja.Siten kryptografisesti / dev / satunnainen on turvallisempi.


Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...