Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Cryptonite - RSA algoritmus: a jó paraméterek jellemzői

2014.02.14. 13:37 | buherator | 13 komment

A kriptográfiát fejlesztői, tesztelői, kódelemzői szemmel nézve fontos ismerni azokat az ökölszabályokat, amelyek alapján a függvényeket biztonságosan meg lehet hívni, a jó prímeket ki lehet választani. Pontosan ezen ökölszabályok kerülnek bemutatásra az RSA algoritmus esetén Szabó István (ELTE) előadásában:

  • mik a jó prímek tulajdonságai, mennyire legyenek egymástól távol, milyen legyen az arányuk,
  • prímtesztnél hány ciklusig kell azt futtatni ,
  • kell-e aggódni a beégetett kicsi "e" értékek miatt chipkártyás kulcsgenerálásoknál,
  • a kulcsokat milyen méretű adatra kell legalább alkalmazni 

Időpont, helyszín: 2014. február 21. 19:00, H.A.C.K  (Az erre fogékonyabbaknak Facebook event)

Címkék: esemény programozás kriptográfia rsa cryptonite

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

loolek · http://loolek.tumblr.com 2014.02.14. 23:20:15

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

buherator · http://buhera.blog.hu 2014.02.15. 10:04:54

@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)

loolek · http://loolek.tumblr.com 2014.02.15. 10:30:29

@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

loolek · http://loolek.tumblr.com 2014.02.15. 10:31:42

@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)

buherator · http://buhera.blog.hu 2014.02.15. 10:51:54

@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)?

loolek · http://loolek.tumblr.com 2014.02.15. 11:12:50

@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..

buherator · http://buhera.blog.hu 2014.02.15. 11:20:02

@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 · http://loolek.tumblr.com 2014.02.15. 11:25:51

@loolek: ROFL

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

loolek

loolek · http://loolek.tumblr.com 2014.02.15. 12:05:13

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 ;)

axt · http://axtaxt.wordpress.com/ 2014.02.16. 17:03:10

@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.

loolek · http://loolek.tumblr.com 2014.03.06. 23:58:00

"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.....

...

buherator · http://buhera.blog.hu 2014.03.07. 07:25:53

@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
süti beállítások módosítása