True Random Servis

[Filip Jirsák]

Jistě posoudit pro a proti, ale u cizího řešení u kterého absolutně nemůžeš vědět kde se ty data berou vidím jen nevýhody o proti řešení co si uděláš sám a pokud o tom člověk nic neví, neměl by to dělat, měl by projekt nechat někomu povolanějšímu, to je snad jasné...

Když o tom nic nevím, nevím absolutně nic ani o vlastním řešení. U cizího řešení můžu mít nějaké smluvní záruky, takže o tom budu vědět alespoň něco.

[Reklama]

[robotron]

(..)A než XOR více nedůvěryhodných zdrojů, tak radši něco, co nedokážou ty zdroje ani při spolčení přímo ovlivnit, třeba SHA(zdroj1 + zdroj2 + tajný_klíč), ještě lépe pak SHA(zdroj1 + zdroj2 + tajný_klíč + lokální_zdroj_náhody_třeba_/dev/random)

Proto jsem psal s nejakou solbou a belenim.

Zaujimalo by ma, ako je ta nahoda nahodna ;-). Ja som sa snazil spravit nieco take "na kolene" tahanim LSB zo sumu a skoro vzdy bola ta nahoda "zaujata" v prospech frekvencie 50Hz. Pri nepravidelnych meraniach ovplyvnenych tazko predvidatelnym cakanim (viac procesov) to zanikalo, ale aj tak...

To nesmíš použít přímo ty LSB, musíš jich nabrat spoustu, a pak je nasypat do nějaké funkce, která dobře extrahuje entropii, třeba SHA.

Ano, ale doporucil bych neco, co ma nekonecnou casovou odezvu (nelinearni obdobu IIR), jako treba tou nahodou "ze zvukovky" perturbovat stav PRNG s dlouhou periodou. To bude prakticky betonovy.

Pokud tazateli stacej ty jednotky MB, pak ani nema cenu, abych zapinal svoje GHz sumaky a postup vyse je zcela OK.

[knedla]

3 indovia, 8x3=24hod generator

naklady: 3x100€/mesiac