[ Tyler Durden @ 08.01.2010. 18:43 ] @
Provjeravam ovih dana neke varijante za cuvanje podataka u kriptovanom formatu, ali sa uslovom da se to moze ponovo dekriptovati.
Sve sto sam nasao podrazumijeva koncept tajnog kljuca koji se koristi za enkripciju i dekripciju kasnije. Naravno, znao sam da to i jeste osnovna ideja dvosmjerne enkripcije, ali u jednom trenutku mi je zasmetala ideja da u slucaju nekih skripti, web sistema, progama ili bilo cega sto podrazumijeva "automatsku" manipulaciju kriptovanim podacima, vi taj kljuc morate da upotrebite negdje u kodu i samim tim srozate sigurnost i otvorite 50 mogucih puteva do kriptovanih podataka.
Prakticno, uvodite jedan master password, koji cak i nije kriptovan (?) i na istom ste taman kao da ste koristili i plain text...
Moje pitanje jeste - da li sam ja pogresno shvatio citav koncept i da li nesto propustam da uvidim, a sto u stvari ipak podize stvari na mnogo sigurniji nivo.
[ toplim @ 08.01.2010. 18:58 ] @
Enkripcija je samo pisanje drugim fontom ili na drugom jeziku. Kljuc mora da postoji, ako ga ne uneses ti rucno, koristice ga sistem negde u algopritmu. E sad ova druga varijanta je bolja, jer kljuc ne cuvas kao jednodimenzioni kod vec kao algoritam ili izraz. A sistem moze da resi taj izraz a ti ne mozes i ako znas postupak. Ali i postupak se uglavnom ne zna.
[ mmix @ 08.01.2010. 19:42 ] @
Dobro si shvatio, separacija kljuca i podatka je fundamentalno vazna i predstavlja najtanju kariku. Ako ti neko provali na masinu koja sadrzi kljuc bitka je vec izgubljena, pitanje je samo koliko je kljuc obscure i koliko ce napadacu trebati vremena da prokljiuvi gde se kljuc nalazi. Security through obscurity je felerican ali je dobar kao poslednja linija odbrane (ono u rangu sa cupanjem ethernet kabla :D), medjutim u nekoj lezernoj intrusion varijanti nema spasa jer ako tvoja automatika moze da dodje do kljuca moze i napadac analizirajuci tvoju skriptu/program i tu ne pomaze ni dinamicko kreiranje kljuca. Algoritam mora biti deterministicki da bi uvek generisao isti kljuc i napadac samo treba da obezbedi pristup algoritmu, u najgorem slucaju pozivajuci tvoj kod :)

Ako ti ne treba automatika onda mozes da koristis neki dobar hasher da pretvoris password u kljuc gde se onda tezina provaljivanja svodi na tezinu razbijanja lozinke (u najboljem slucaju pun brute force) plus naravno uobicajeni problemi sa intruzijom (keylogeri poimence)




[ EArthquake @ 10.01.2010. 09:46 ] @
ako tvoja skripta "zna" kako da dekriptuje podatke , zna i napadac koji ima tvoju skriptu

neko je pre oko godinu, godinu ipo dana pitao kako bi mogao da cuva lozinke sigurno
kao sto to rade razni IM chat programi , firefox i sl

odgovor je da nema nekog previse pametnog resenja

sto rece mmix , ako zahtevas neku automatizaciju , skripta/program mora da zna sve sto joj/mu je potrebno za dekriptovanje

naravno , uvek je bolje imati enkripciju, bar ce napadacu trebati vise vremena ...

Citat:
toplim: E sad ova druga varijanta je bolja, jer kljuc ne cuvas kao jednodimenzioni kod vec kao algoritam ili izraz. A sistem moze da resi taj izraz a ti ne mozes i ako znas postupak. Ali i postupak se uglavnom ne zna.


kljuc cuvas kao algoritam ili izraz ? sistem moze da resi taj izraz a ti ne ?
kako to ? sta mene sprecava da , u krajnjem slucaju, "rucno" izvrsim isti algoritam ?
postupak se uglavnom ne zna?
ako imam kod, cak kompajliran program, mozes da smatras da se i postupak zna
program moze da se reversuje , hardver moze da se reversuje...

zar niste videli da se security trough obscurity pokazao u pravom svetlu kod ove vesti GSMu ?