Lazán kapcsolódik a témához (és az elmúlt hónapokban is több helyen gondot okozott) a megfelelő RANDOM SEED hmm előállítása.

Nálam a saját Tool.java osztályomban a random(int ceiling) metódusba elég funny seed előállítást írtam ->

Ez a fő metódus, remélem tetszik az ötlet ;)

public static int random(int ceiling) throws IllegalArgumentException {

if (ceiling < 1) {
throw new IllegalArgumentException(“Random ceiling can’t be smaller than one!”);
}

if (random == null) {
long seed = System.currentTimeMillis() / Long.parseLong(getDate(“SSHssh”));

random = new Random(seed);
}

return (random.nextInt(ceiling));
}

loolek.tumblr.com/post/25468022579/seed

@loolek: Hasonló megoldással elég sok helyen találkoztam (bár ilyen getDate() API-t nem találtam a referenciában), időszinkronnal triviálisan támadható. Az osztással a seed felső és alsó határát is feleslegesen korlátozod.

FYI:
docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html#getSeed(int)

@buherator: He he köszönöm a profi választ!

Nem gondoltam rá, hogy a szakértő review attitude trigger fired lesz ;)

Amint írtam a Tool.java nem egy biztonsági rendszer része, hanem egy sima üzleti EE framework -ben figyel. A feladata hogy egyszerűsítse bizonyos pld. unit tesztekhez "véletlen típusú" tesztadatot lehessen legyártani munkát.

ps:

A fő célja egyébként (neked itt elmondom szívesen) pont az, hogy >>> már annyi (más) hibáját kellett javítanom ami abból eredt, hogy

1.) nem tudják értelmezni pont azt a doksit amit linkeltél ;)

2.) Nem tiszta nekik gyakran, hogy mit jelent a határ érték -> "Most akkor max 10 vagy sose lesz telibe 10 az érték?!" stb. ;) >>> az én javadoc -om rövid, de konkrét (azt megértik ;)

3.) az idő faktor természetesen támadható sec vonalon! True!

Szóval, ha azt a metódust mutattam volna, akkor ott ez a rész hmm egy kicsit komolikáltabb (és több tagból áll)

Üzeleti titok (he he) de három tagot a blog kedvéért itt titokban kiemelnék =)

A szoba pillanatnyi hőmérséklete / a kinti szélkerék rpm -jével * a cpu hőmérséklettel ...

Ha nem minősíted reklámnak akkor az egyik posztom elejéről egy gondolat Neked ;)

Motto

"Bárki, aki aritmetikai módszerekkel akar előállítani egy véletlenszámot,
a bűn állapotában leledzik.

Any one who considers arithmetical methods of producing random digits is,
of course, in a state of sin.” ~Neumann János

“This case rests on Sony’s misguided belief that it has the unfettered ability to control
how consumers use the products they legitimately purchase.” ~Stewart Kellar, the lawyer

loolek.tumblr.com/post/2767695349/the-ps3-jailbreak-strory

loolek

@buherator: Szóval elnézést a rosszul feltett kérdés miatt, de azért a választ is megadtad ;D

> (bár ilyen getDate() API-t nem találtam a referenciában)

Furcsa a véletlen, éppen ezt olvasgatom közben =)

www.usenix.org/legacy/events/sec2000/full_papers/smart/smart_html/

@loolek: " A feladata hogy egyszerűsítse bizonyos pld. unit tesztekhez "véletlen típusú" tesztadatot lehessen legyártani munkát."

Lehet hogy rosszul értem, de ezek szerint attól függően lehet pass/failed egy unit test, hogy mikor futtatod? Miben jobb ez a megoldás, mint a paraméter nélküli Random() konstruktort használni (a seed a nextInt() határértékeit nem befolyásolja)?

@buherator: Értem hogy min csúszunk meg..

Ahogy írtam ennél a random(int plafon) hívásnál csak EE szempontok vannak. Te pedig csak SEC szempontból látsz.... (ez a munkád, ilyen a rutin semmi gond ;)

Szóval ilyen 444 stílusban, ha szabad:

1.) ez a hívás elrejti is intézi a seed kezelést, a használónak nem is kell tudni róla (hogy az első hívásnál init seed is futt) ésez jó =)

2.) az üzelti gyakorlat/feladat az nem egy nextInt() aztán jó lesz az amit add a véletlen!

Mert EE esetben a probléma/feladat így szól:

Itt van ez a bigyoType nevű mező, aminek az értéke (egy enum -ra van mappelve) 1-10 lehet CSAK! Mert egyébként írásnál BLException -t fog kapni (az meg nem cél itt) és ez jó =)

Magyarra fordítva EE vonalon nagyon sokszor kötött a mezők értékhatára, és nekem ehhez kell igazodnom (és segítenem ez a lényeg egyébként! ;)

Pont emiatt van még egy random metodus is a Tool.java osztályban.

public static int getRandom(int min, int max) throws IllegalArgumentException

Mi ezt hívjuk ha kell pld egy 20-200 közti értékhatár szám. És ennél a hívásnál garantált, hogy mind a kettő plafon előfordulhat! és ez jó =)

Bocsi a sok smiley miatt..

@loolek: A második hozzászólásomban már nincs szó security-ről.

Ha a unit tesztekben olyan paramétereket használsz, ami az időtől függően random, akkor rohadt nehéz lesz reprodukálni a teszteseteidet (de még1x mondom, lehet h félreértem amit írsz).

Másodszor annak, hogy hogyan seedelsz, semmi köze ahhoz, hogy milyen értékhatérok között mozog a nextInt(). Értem, hogy el akarod rejteni a seedelést, meg egységes API-t akarsz, amit nem értek az az, hogy miért kell az idővel varázsolni pluszban, mikor a sima Random() is kb. ugyanezt csinálja ha jól rémlik.

@loolek: ROFL

Igen tényleg igazad van, kellett nekem SEC blogra EE kódot másolni, aztán még kitárgyalni =)

loolek

De mi lenne velünk kihívások nélkül:

> akkor rohadt nehéz lesz reprodukálni a teszteseteidet

A munkám 70% perftest 30% regressziós teszt ott pedig kell a véletlen adat (már egy sima teszt adatbázis feltöltéshez is) De regressziós teszteknél is simán kellhet,ha nem azt a mezőt reg-tesztelem éppen...

> A második hozzászólásomban már nincs szó security-ről.

Az a rész nem kifejezettem a második hozzászólásod miatt ment ;)

@loolek: Pusztán java-s szempontból:

A paraméterek nélküli Random() konstruktor beseedeli az RNG-t. Bár itt security szempontok nem számítanak, de egy sokkal szélesebb tartományból ad seedeket, mint a te implementációd (ez anélkül is biztos, hogy tudnám, hogy a getDate(..) függvényed hogy működik, feltéve, hogy long-ot ad vissza :-) ).

A setSeed főleg arra jó, hogyha determinisztikus random sorozatot akarsz előállítani. Ez például unit tesztek esetén tud hasznos lenni, ahol kb. íratlan szabály, hogy a unit teszt legyen determinisztikus. (Ha random adatokon akarsz unit tesztelni, akkor meg a random adatok előállítását illik determinisztikussá tenni. És ha a determinisztikusság a fő szempont, akkor meg főleg nem érdemes globálisan shared Random instanceot használni, kivéve ha garantált a hívási sorrendje.)

A smiley-kből úgy ítéltem, hogy a te javadoc-od a paraméter ceiling-ként való elnevezése, de szerintem ebből még ugyanúgy nem látszik, hogy benne van-e az intervallumban a paraméter értéke vagy sincs.

"ahol kb. íratlan szabály, hogy a unit teszt legyen determinisztikus. (Ha random adatokon akarsz unit tesztelni, akkor meg a random adatok előállítását illik determinisztikussá tenni."

Nem is akarok azon gondolkozni, hogy nem tudtad eszrevenni a kicsit vicces getDate("sshSSH"); hivasban a poent! RTFM SSH bahh

Es hogy a picsaba keverted be magad unit determinisztikusba ?
?!

ps:

Lemerem fogadni majd jon meg egy k*csog aki ezt szitut meg tovabb magyarazgatja... ',)

I will monkey You.....

...

@loolek: Az, ha a segítő szándékú kritikát támadásnak veszed, csak téged minősít. Ajánlott olvasmány: en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect