Article View: pl.comp.lang.c
Article #310059Re: Generator liczb pseudolosowych bezpieczny kryptograficznie
From: M.M.
Date: Fri, 10 Jan 2020 10:16
Date: Fri, 10 Jan 2020 10:16
89 lines
5225 bytes
5225 bytes
On Wednesday, January 8, 2020 at 12:22:05 PM UTC+1, M.M. wrote: > On Tuesday, January 7, 2020 at 6:15:44 PM UTC+1, Piotr Gałka wrote: > > W dniu 2020-01-07 o 15:23, M.M. pisze: > > > > Dzięki za odpowiedź. > > Nie jest dla mnie wielkim pożytkiem, ale zaspokaja ciekawość. > > > > > Moje udoskonalenie(?) wyhash mniej-więcej na tym: > > > > > > if( i1 >= size(dane1) ) i1 = 0; > > > dane1[ i1 ] += liczba_pierwsza1; > > > > > > if( i2 >= size(dane2) ) i2 = 0; > > > dane2[ i2 ] += liczba_pierwsza2; > > > > > > DANE = dane1[i1] ^ dane2[i2]; > > > i1 = i1 + 1; > > > i2 = i2 + 1; > > > > > > return hash( DANE ); > > > > Jeśli wszystko rusza 'od zera' to kolejne wyniki aż do przepełnienia > > jednego z liczników będą takie same: DANE = Lp1^Lp2, > > A potem znów seria takich samych danych: DANE = (2*L1)^L2, > > > > Zapewne nie rusza 'od zera', ale w ramach 'dmuchania na zimne' > > próbowałbym unikać takiej możliwości. > > Tak, unikam, tablica na początku powinna zawierać chaotyczne i unikalne > dane. Inicjuję wszelkie tablice (także w generatorze Fibonacciego) > tą funkcją: > https://github.com/mmarszik/MRndCPP/blob/master/init_chaos.h > > > > > >> funkcjom SHA i nie znając się postanowiłem po prostu przyjąć ich racje. > > >> Szybkości działania mnie w ogóle nie interesowała. > > > > > > Niektóre moje programy wyraźnie przyspieszają po zmianie generatora na > > > szybszy. Dlatego mnie bardzo interesuje szybkość generowanych liczb. Gdyby > > > mnie nie interesowała to bym wziął ranlux48. Zresztą mój kod jak najbardziej > > > umożliwia użycie standardowego ranluxa48 i Mersenne Twister. Standardowego > > > Knutha i ministd zakomentowałem bo zawieszały diehardera i dawały same > > > faile w programie PractRand ;-) > > > > To niestety poza 'domyślaniem się' nic mi nie mówi, ale to mój problem. > > Nigdy nie użyłem żadnego innego kodu, niż to co mam z definicji w > > Builderze i to co sam napisałem (jak. AES, SHA, ...). > > Programowanie w moim przypadku to tydzień dwa w roku. > > P.G. Kontynuując: Generator Mersenne T. w wersji 64bitowej nie przeszechodzi testów w programie PractRand nawet jak się bierze z niego tylko 32 bity. Padł po 260 minutach: https://github.com/mmarszik/MRndCPP/blob/master/use_rnd_mt19937_64.h --------------------------------------------------------------------- Kombinacja 16 generatorów na typie uint128 według wzoru: r = random() % 16; return (x[r] = x[r] * A[r] + B[r]) >> 95 Przechodzi cztero-dobowe testy: https://github.com/mmarszik/MRndCPP/blob/master/use_rnd_mlin_0.h Wygenerowała w testach 11.339 terabytes danych. --------------------------------------------------------------------- Generator wyhash64 przechodzi cztery doby testów: https://github.com/mmarszik/MRndCPP/blob/master/use_rnd_wyhash64_0.h Wygenerował w tym czasie length= 11.544 terabytes danych. --------------------------------------------------------------------- Moja rozbudowa wyhash też przeszła 4 doby testów: https://github.com/mmarszik/MRndCPP/blob/master/use_rnd_wyhash64m_0.h Niestety jest wolniejsza niż oryginał, wygenerowała 11.238 terabytes danych --------------------------------------------------------------------- Wartości typu p=1-3.4e-3, a nawet p=1-3.5e-5 zdarzają się, ale takie wartości PractRand domyślnie uznaje za dopuszczalne. Pozdrawiam
Technical Details
Message-ID:
<ce016dc1-90a4-4758-ad3c-59871cfde3d5@googlegroups.com>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!feeder.erje.net!2.eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!g89no6218945qtd.0!news-out.google.com!w29ni551qtc.0!nntp.google.com!g89no6218936qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mailReferences:
<f55958c3-26d2-42da-b677-ad2bc3e61c22@googlegroups.com> <5e11fa14$0$540$65785112@news.neostrada.pl> <9519b70b-f91d-4b8a-83d6-38412be2113e@googlegroups.com> <qv1sgp$t9s$1$PiotrGalka@news.chmurka.net> <adf17bb9-8221-45bb-b6ed-b812aa3ac91f@googlegroups.com> <qv2ebt$7kt$1$PiotrGalka@news.chmurka.net> <00625ab5-4de9-4e57-9b5f-bbdbd5a93617@googlegroups.com>Show Full Headers
Complete Article Headers
X-Received: by 2002:ac8:1835:: with SMTP id q50mr1613103qtj.210.1578651412097; Fri, 10 Jan 2020 02:16:52 -0800 (PST) X-Received: by 2002:a25:ab81:: with SMTP id v1mr1803240ybi.277.1578651411788; Fri, 10 Jan 2020 02:16:51 -0800 (PST) Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!feeder.erje.net!2.eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!g89no6218945qtd.0!news-out.google.com!w29ni551qtc.0!nntp.google.com!g89no6218936qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: pl.comp.lang.c Date: Fri, 10 Jan 2020 02:16:51 -0800 (PST) In-Reply-To: <00625ab5-4de9-4e57-9b5f-bbdbd5a93617@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=159.205.34.176; posting-account=xjvq9QoAAAATMPC2X3btlHd_LkaJo_rj NNTP-Posting-Host: 159.205.34.176 References: <f55958c3-26d2-42da-b677-ad2bc3e61c22@googlegroups.com> <5e11fa14$0$540$65785112@news.neostrada.pl> <9519b70b-f91d-4b8a-83d6-38412be2113e@googlegroups.com> <qv1sgp$t9s$1$PiotrGalka@news.chmurka.net> <adf17bb9-8221-45bb-b6ed-b812aa3ac91f@googlegroups.com> <qv2ebt$7kt$1$PiotrGalka@news.chmurka.net> <00625ab5-4de9-4e57-9b5f-bbdbd5a93617@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <ce016dc1-90a4-4758-ad3c-59871cfde3d5@googlegroups.com> Subject: Re: Generator liczb pseudolosowych bezpieczny kryptograficznie From: "M.M." <mmarszik@gmail.com> Injection-Date: Fri, 10 Jan 2020 10:16:52 +0000 Lines: 104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit