Fájltitkosító szoftver fejlesztése - projectbejelentés

Security-all

A téma valahol programozás, biztonságtechnika, s projectbejelentés is egyben, tehát ha nem feltétlen ide illik, elnézéseteket kérem :)

Tehát:
egyik barátom részére kerestem Windows alá fájltitkosító programot. Meg is találtuk a neki szimpatikus alkalmazást, de elkezdett mocorogni a kisördög odabent. No, nekiálltím kutakodni, hogy linux alatt milyen programok vannak a témában.
Találataim között csupa olyat találtam, amit laikus elég nehezen tud használni, illetve egy-két olyat, ami nem túl bonyolult, de nincs hozzá GUI. Ez elég könnyen orvosolható lenne, de mivel másnap azon kaptam magam, hogy munkahelyen algoritmus vázlatokat vetek papírra, nyilvánvalóvá vált számomra, hogy nem ezt az utat választottam. :) Sebaj, legalább növekszik a csomagok száma.

Itt jön a project bejelentése:
egy olyan szoftvert terveztem meg, mely fájlok titkosítását végzi, mindezt olyan formában, hogy az egyszeri felhasználónak se okozzon különösebb fejtörést. Rendelkezik GUI-val, de parancssorból is elérhető. A feljesztést Mono-ban kezdtem (lehet fujjogni!). Hogy miért is nem C/C++ lett a vége? Hordozhatóvá szerettem volna tenni. Tudom, GTK-val C-ből is lehetne ilyet csinálni (egyébként még ez sincs elvetve, nem tart túl sokból átültetni az algoritmust). Itt jön az első kérdésem (lesz még pár, szertném a felhasználók igényeihez igazítani a project-et): mi a véleményetek, melyikben szülessen a végeredmény?
A Mono ilyen téren azért tűnik számomra jobb megoldásnak, mert a programot csak egyszer kell fordítani, a keretrendszer pedig minden OS-en elfuttatja azt. GTK esetén sem úsznánk meg pl.: Windows alatt a plusz telepítést, tehát installálási számban ugyanott van a user. Azaz Mono esetén számomra kényelmesebb a közreadás, hiszen nem kell minden egyes OS-re fordítgatni. Ellene az szól, hogy a Mono körüli huzavona mit fog eredményezni a jövőben, lesznek-e licensz problémák.
A keretrendszer működik, az általam most rábízott feladatot ellátja, egyelőre nem találtam hibás működést a készülő programban.

Leírás:
alapvetően matematikai alapon működik (mi máson lehetne) a titkosítás. Két darab 4 jegyű "PIN"-kódot kér, s ezekkel, no meg még sok egyéb mással karöltve hozza létre a végeredményt. A két kód összesen 100.000.000 variánst enged, ami egy BruteForce-al való törésnél már elég meredek vállalkozás lenne (gondolom én).
A két "PIN"-re utaló bejegyzés nem kerül bele a titkosított fájlba, tehát az alapján nem fejthető meg a két kulcs. A választott módszer ugyan biztonságosabbá teszi a titkosított fájlt, viszont van egy szépséghibája, mégpedig az, hogy ha jó a "PIN", ha nem, akkor is legyártja a fájlt (még ha hibás lesz a végeredmény, akkor is). Ez jócskán nehezíti a BruteForce módszert, hiszen százmillió fájlt átnézni nem egy leányálom :)
Második kérdés: valakinek van ötlete a "lecsekkolás" megoldására olyan módon, hogy az alap koncepció ne sérüljön, azaz ne kelljen fájlba helyezni a két kódot? Sajnos én még nem jöttem rá, pedig lehet, hogy pofon egyszerű (vagy mégsem).

szerk: olyan jutott még eszembe, hogy az eredeti fájl md5 értékét beleteszem, s visszakódolás után ezt leellenőrzi. Ennek ismeretében vajon könnyedén visszakódolható a fájl? Létezik olyan eszköz, ami helyre tudja állítani az md5 értéket? Illetve visszaszámolhatóvá válna a "PIN" ez alapján?

A módszeremnek szerintem az az előnye, hogy nyugodt szívvel teszem nyílt forrásúvá, ugyanis hiába ismerjük a kódolási algoritmust, szinte lehetetlen a fájl kikódolása (kivéve ugye a százmilliós brute módszert), ellenben a fájlban elhelyezett kulcsra utaló "nyomokkal", ahol az algoritmus és a kódolt fájl párosával már sokkal reálisabb esély mutatkozik a visszafejtésre.
Harmadik kérdés: nagyon szeretném a közösség részére átadni a forrást, de felmerült bennem a kétely, hogy biztonságtechnikai program lévén jó ötlet-e. A fentiek alapján mi a véleményetek? Közzé lehet tenni a forrást anélkül, hogy bárki is vissza tudjon élni vele?

A jövő:
ha időm is úgy engedi, 1-2 hónap múlva már elő tudok rukkolni az első stabil kiadással. Most még ugyan nem látom át, hogy az algoritmusban mit lehetne majd a jövőben továbbfejleszteni, de szolgáltatásokban biztosan lehet bővíteni (halovány elképzeléseim már derengenek).

Várom véleményeiteket, javaslataitokat!

Dávid

  • 2493 megtekintés

( eax | 2008. 06. 27., p – 19:56 )

"Két darab 4 jegyű "PIN"-kódot kér, s ezekkel, no meg még sok egyéb mással karöltve hozza létre a végeredményt."

Ez eleg keves.

"A két kód összesen 100.000.000 variánst enged, ami egy BruteForce-al való törésnél már elég meredek vállalkozás lenne (gondolom én)."

Ne gondold, pl. az AES kulcsterehez kepest ez semmi.

Egyebkent milyen algoritmust hasznalnal? Ugye nem valami hazilag tenyesztettet? (~10 eves kriptografusi tapasztalat nelkul sajatot tervezni erosen ellenjavalt, arrol nem is beszelve, hogy semmi ertelme, van igy is egy csomo).

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Nem godolom, hogy több lenne, mint az AES-é, egy szóval sem állítottam.
Hát igen, sajátot "tenyésztettem" ki. Nincs 10 éves tapasztalatom benne, de úgy gondolom, egy próbát megér.
Szívesen kiteszek majd egy kódolt fájlt, ha kész a kódoló, kiváncsi lennék a véleményetekre, hogy mennyire törhető (ez most nem cinikus megjegyzés volt, félre ne értsd, tényleg érdekel).
S miért ne lenne értelme egyébként, ha esetleg beválik? Ezzel az erővel ne írjunk több audió/videó kódeket, hisz van egy csomó (igaz, hogy a fele akkora veszteséget termel, mint ide Lacháza).

szerk.: a két pin hosszát bármekkorára lehet növelni, tehát szorozható még egy párral a variánsok száma. Én csupán úgy gondolkodtam, hogy a felhasználónak azt azért meg is kell ám jegyezni (bár tárolhatunk 16 jegyű kódokat a farzsebünkben egy cetlin is, de akkor már megette a fene)...

"Nem godolom, hogy több lenne, mint az AES-é, egy szóval sem állítottam."

Nem, nem ugy ertem. Ugy ertem, hogy iszonyatmod brutalisan keves. 2^256 kb. 1.15*10^77, a tied pedig 10^8. Hacsak nem csinalsz valami nagyon-nagyon lassu algoritmust, ez egy kulturaltabb pc-vel percek alatt bruteforce-olhato.

"Hát igen, sajátot "tenyésztettem" ki. Nincs 10 éves tapasztalatom benne, de úgy gondolom, egy próbát megér."

Hajra, probalkozni szabad, de ebben az esetben egy jateknal nem erdemes tobbnek tekinteni.

"S miért ne lenne értelme egyébként, ha esetleg beválik?"

Az eddigiek alapjan nem fog, szakman belul legalabbis.

"Ezzel az erővel ne írjunk több audió/videó kódeket, hisz van egy csomó"

Lenyeges kulonbseg, hogy egy audio/videokodek minden minosegi parameteret egyszeruen lehet merni, vagy legalabbis a vegeredmenyrol az egybites user is el tudja donteni, hogy jo-e. A kriptografiai algoritmusoknal ez nem ennyire egyszeru.

Egyebkent azt nem teljesen latom, hogy konkretan hogy szeretned a filekodolast megcsinalni? FUSE? (annyi a hordozhatosagnak), kernel modul? (meginkabb), siman beolvasod, es kidumpolod a titkositott verziot (nem lesz lassu? wipe-olassal egyutt sem? mi lesz a nemcsak-metadata-journaling-fsekkel?)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Egyebkent azt nem teljesen latom, hogy konkretan hogy szeretned a filekodolast megcsinalni? FUSE?

Szerintem egyszerűen csak egy sima program, amely a paraméterben kapott file(oka)t titkosítja le, szó nincs itt FDE-ről vagy hasonlókról... Mindenesetre nagyon várom a letitkosított file-t, lehetne előtte egy szavazást indítani, hogy mennyi idő alatt lesz visszafejtve. ;D

Ahogy mondod, Egy bemeneti fájlt letitkosít, majd kiköpi a doboz másik oldalán.
Tudom, hogy nem egy korszakalkotó megoldáson dolgozom.
Tisztázzuk is: nem a professzionális felhasználás a cél, hanem az egységsugarú user jpg-je, amit nem lenne jó, ha anyu meglátná, mert kitér a hitéből.
Ebben a kategóriában úgy gondolom (lehet, hogy hibásan), bőven elegendő ez a tipusú kódolás.

Ha gondoljátok, szívesen "leszámolok" valamit papíron, mondjuk egy egyszerű txt tartalmát, ami mondjuk egy mondatot tartalmaz.
Annyi a gubanc egyelőre, hogy a végkimenet "zanzásítását" még nem fejeztem be, de számokban már működik (azaz a kimeneten számok halmazát láthatod).
Szerintem már ez is elég lesz első körben. Ha visszafejtitek, akkor tényleg kútba esett történet.

"nem a professzionális felhasználás a cél, hanem az egységsugarú user jpg-je, amit nem lenne jó, ha anyu meglátná, mert kitér a hitéből."
És miért lenne jó ennek az usernek a te programodat használni, mikor vannak erre jobb programok is, amelyek ráadásul sokkal biztonságosabbak is?
Az általad felvázolt tipikus használat esetben sokkal jobban jár az user egy teljes partíció-titkosítóval, márcsak azért is, mert adott esetben elegendő egy pendrive, amit ha bedug, akkor láthatja a fájlok tartalmát, hameg kihúzza, akkor anyuci nem látja azt. Még a fájlok neveit sem látja.
A te programodat használva, egy 150.000 fájlból álló jpg gyűjteményhez 150.000x2 db 4 jegyű "PIN" kódot kellene megjegyezni.
És a programod ráadásul nem is biztonságos.

"Ha visszafejtitek, akkor tényleg kútba esett történet."
Amíg nem hozod nyilvánosságra az algoritmust, a megvalósítást, kútba esett történet.
Amíg nem bizonyítod matematikailag a az algoritmus helyességét, kútba esett történet.
Ha csak simán egy betűhelyettesítéses kódoló, keverés nélkül, kútba esett történet.
Ha ECB módon kódol egy fájlt, kútba esett történet.
stb.stb.stb.

jelzem az h kiteszed a kodolt fajlt senkit sem erdekel

pl. kesz a szoftver es felrakom a gepemre aztan fogok egy filet amiben azvan ABC es eltitkositom megnezem mi lett belole
aztan fogok egy filet amiben azvan h ACB azt is, es igy tovabb
(asszem multkor linkelte snq h mi a neve ennek a modszernek)

ha nem vagy jaratos a kriptografiaban akkor bizony konnyen elofordulhat h hasonlo "erre nem is gondoltam" modszerrel feltorheto rendszert alkotsz tettek azt mar joparan elotted

mondjuk amig az egesz hekkelosdi penzkerdes biztos vagyok benne h nem fognak tizesevel szekjuriti szakertok nekiugrani h megnezzek mit is csinaltal :)

szerintem

http://www.governmentsecurity.org/archive/t14922.html

pl. ilyennel lehet zuzni, persze ez fs szintu

#toy like ppl make me boy like

"pl. kesz a szoftver es felrakom a gepemre aztan fogok egy filet amiben azvan ABC es eltitkositom megnezem mi lett belole
aztan fogok egy filet amiben azvan h ACB azt is, es igy tovabb
(asszem multkor linkelte snq h mi a neve ennek a modszernek)"

Differencialis kriptoanalizis?

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Most ne haragudj, de ez a hozzászólás eléggé mutatja a inkompetenciádat.

"szerk.: a két pin hosszát bármekkorára lehet növelni, tehát szorozható még egy párral a variánsok száma. Én csupán úgy gondolkodtam, hogy a felhasználónak azt azért meg is kell ám jegyezni (bár tárolhatunk 16 jegyű kódokat a farzsebünkben egy cetlin is, de akkor már megette a fene)..."

Eleve a kulcsteret bitekben mérik, nem a "PIN"-ek hosszában.
Amúgy létezik szabványos algoritmus, ami tetszőleges jelszóból előállítja a megfelelő hosszúságú titkosító kulcsot.
(salt -olja a jelszót.)
Az is mutatja eléggé a hozzá-nem-értésedet, hogy szerinted a 100.000.000 variáció elég nagy.

Eszembe jutott egy hasonló eset, még régről, a prog.hu -ról.
Ott is előállt valaki egy szerinte "űber" titkosító programmal, saját "űber" algoritmussal.
Még aznap megtörték, kizárólag a titkosított szöveg ismeretében!
(Ja, és nem brute-force -val.....)
Okkulásként itt a topic, javaslom, hogy olvasd végig, hogy jutottak el a törésig, és javaslom, figyeld meg, hogy a titkosítás "kifejlesztőjének" mekkora arca volt végig:
http://www.prog.hu/tarsalgo/18911-90/Felhivas+Wolfman+szovegtitkosito+p…

szerk.: ha a nyílt szöveg md5 -jét is elmented a titkosított szöveg melé, akkor szépen segítesz a brute-force próbálkozóknak, de esetleg az ismert md5 gyengeségek kihasználni próbálóknak is...

( miq | 2008. 06. 27., p – 20:19 )

Tekintve, hogy a mostani asztali gépek 10-50 millió műveletet végeznek másodpercenként... az a 100.000.000 bruteforce akár 2 másodperc is lehet.

Egyébként én is azt javaslom, hogy még 5-10 év matek, kiptográfia tanulás, addig meg használd a rar-t, vagy ha komolyabbat akarsz, akkor csinálj valami gui-t az RSA-hoz. Hidd el, jobban jársz vele, mint a saját algoritmusokkal.

( Zahy v | 2008. 06. 27., p – 21:11 )

Esetleg javasolnám, hogy csinálj frontendet a GPG-hez - parancssoros és elérhető mindenhez - és esetleg hogy kicsit belekavarjak, javasolnám a Java-t multiplatform nyelvként. (Szerintem jelenleg még több gépen van JRE, mint Mono - és remélem ez még marad is.)

( Hiena v | 2008. 06. 27., p – 21:41 )

[idota on]
En az alabbi titkositast hasznalom:
cat titkositatlanfile.txt > /dev/null
Csak meg nem sikerult visszafejtenem az elkodolt filet.
[idiota off]

Akár közzéteszed a kódot, akár nem, előbb-utóbb valaki készíteni fog olyan alkalmazást ami képes lesz feltörni a titkosításodat. A kérdés csak az, hogy megéri-e feltörni, az-az milyen értékeket is őriznek azzal.
Az md5 beletételével csak a visszafejtők dolgát könnyited meg, mert könnyebben válogatják ki a brute-forcal generált fileok közül az "érdekes" pédányokat.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( asci v | 2008. 06. 28., szo – 00:25 )

Hajrá, ne add fel! Eredménytől függetlenül tapasztalatot biztosan szerezhetsz.

Egy ötlet esetleg:
- Nem tudom mennyire nehezen kivitelezhető, de jó lenne ha egyszerűen lehetne titkosító "plugin"-eket (algoritmusokat) írni a programhoz. Megoldható?

Nem adom fel, bár egy kicsit "elszontyolodtam" a fentebb írottaktól.
Én úgy gondolom, hogy minden programozási munkálat egy tanulás, hiszen ha csak nem rutinfeladatot írunk, akkor mindig vannak újdonságok.
Valószínűleg ebből is fogok tanulni.

A plugin-ezés megoldható, minden további nélkül. Bár akkor már csak egy egy üres keret lesz a progi egy fájlírási művelettel, amibe bedobjuk a motort :)

Örülök, hogy ha másokat is érdekel, bár az első verzió már elméletben összeállt, gyakorlatilag a fele nagyjából készen van.
Amennyiben kész vagyok vele, linkelni fogom a forrást, s akkor szívsen fogadom a segítséget (hiszen biztosan lesz benne javítanivaló).

( Yorirou | 2008. 06. 28., szo – 00:54 )

Tipp: egy java program és egy AES implementáció? Az AES bizonyítottan erős kódolás, és nagyon gyors. Én, ha ilyesmiben gondolkodnék, tuti az AES-hez nyúlnék.

Andi, really. Take it from me. If I tell you something, I'm usually right.

Akkor tervezz kódolási algoritmust, ha már kódtörésben profi vagy.
Magyarul először törögessél titkosított állományokat hobbiból.
A fájltitkosítás egyébként halott ügy, brute force-hoz mindig ott a "minta", a fájlformátum maga. Legyen az .doc, .zip, vagy bármi.

------------------------
Debian testing KDE amd64
MSI K8N-Neo-4, Athlon64 3800+, Leadtek 6600GT

A helyedben én is inkább bevált algoritmusok implementációjával próbálkoznék először. Tanulságos tud ám az lenni! Közben rengeteg dolgot megért az ember.
Ad-hoc módszerek általában nem vezetnek jó eredményre egy kriptográfiai algoritmus megtervezésénél. Ilyenkor gyakran az szokott történni, hogy újra-felfedezel valamit, amit már az ókori görögök is tudtak.

( csizmadia_zoltan v | 2008. 06. 28., szo – 15:18 )

Szervusz !

Akár a Nagytestvér, akár amatőr rájön, hogy belátható időn belül visszakódolható a titkosítás, nem köti az orrodra, mert az előbbit érdekli, hogy mit akarsz titkosítani, a másik pénzzé tehető tudás birotkában van.

CSZ

( banyek | 2008. 06. 28., szo – 15:31 )

Szia!

Csak egy kérdés: mivel volna ez jobb mint a jó öreg pgp? Fogsz egy gpg-t, írsz hozzá egy frontendet, ha nem tetszik amik vannak, utána hajrá!

( Dacr (nem ellenőrzött) | 2008. 06. 28., szo – 19:06 )

Mindenkinek nagyon köszönöm a hozzászólásokat, javaslatokat!
Sok hasznos információt kaptam, amin átrágom magam, s a végén (lehet, pár év) majd csak kisül valami (vagy nem) :)

Dávid