Ha érdekel valakit egy Total Commanderhez írt AES plugin Delhi forrással innen letölthető:
http://clubtotal.free.fr/tc_wcx/wcx_aes.zip
128 bites kulcsot használ, de ez pont elég.
Viszont ha jol ertelmeztem a kollegat, akkor ugyis felejtos lesz a szimmetrikus megoldas, mert ahhoz bele kellene pakolni a kulcsot a kliensbe ami nagyon nem jo otlet. Marad ket verzio:
- a file-t biztonsagos csatornan feltolteni, es a szerveren titkositani
- aszimmetrikus titkositas a kliensen a szerver titkos kulcsaval, erre valo pl a GnuPG, es egy nagyon hasonlo esetet targyal ez a doksi.
Azert a zip-pel vigyazni kell, a legutobbi verziokig a titkositas ultragagyi volt, az uj WinZip es PkZip eros titkositasa viszont a hirek szerint inkompatibilis egymassal. Hurra.
Megbízhatsz a RAR-ban, a lényeg az, hogy úgy 9 karakter felett adjál neki jelszót.
Off:
Régebben töltöttem le, ez ZIP-elt fizetős komponenst a netről, ahol a bolond szerző belerakta a mindenki által letölthető ZIP-be a forrást is, de azt jelszóval védte.
A komponens forrásáért 100 USD-t kért volna, de a "CORE" jelszóval a brute-force eljárással dolgozó program kb. 0.6 sec alatt végzett... Ilyen gyorsan sem kerestem azóta sem 100 USD-t :)))))
Szóval hosszú és bonyolult jelszót adjál neki, olyat amit nem lehet "szótárazni". Akkor nem lesz gond a RAR-al, ZIP-el.
WinRAR AES-t hasznal es eleg korrektul van implementalva, ez tehat nem gond. Az viszont igen, hogy csak a kitomorito rutinok elerhetok .dll formajaban, szoval nem tudom, hogy hogy lehetne integralni kesz alkalmazasba, pedig ez lenne a legegyszerubb megoldas.
FTPS: ezt teszteltetek a majdan hasznalando kornyezetben? Eleg maceras tud lenni, pl. ha tuzfalakon kell keresztulmennie.
A feltöltés után is titkos marad. A központban található alkalmazás letöltés után fogja decryptelni
Tehat, ha jol ertem, akkor lesz egy kulcs, amit a kozpont es az alkalmazas ismer, es ezzel lenne titkositva az allomany?
Aszimmetrikus titkositast onmagaban nem nagyon hasznalnak, mert kb 100x lassabb, mint a szimmetrikus titkositok. Arra viszont tokeletesen alkalmas, hogy a szimmetrikus session elinditasahoz vedett kozeger biztositson.
A konkrét feladat az, hogy egy delphi alaklmazás zip-pel tömörít fájlokat, majd azt titkosítja, es FTP-n feltölti (pontosabban FTPS-en).
A titkositas az adatatvitelt vedi, vagy a feltoltes utan is titkosnak kell maradnia a file-nak? Kinel lesz a jelszo?
Nem lenne egyszerubb, ha egy sima titkositott rar-t toltenel fel? A rar nagyon jo titkositast hasznal.
A konkrét feladat az, hogy egy delphi alaklmazás zip-pel tömörít fájlokat, majd azt titkosítja, es FTP-n feltölti (pontosabban FTPS-en).
Ebben az esetben szerintem érdemesebb az aszimetrikus megoldást alkalmazni.
A gyenge pont szerintem az, hogy a decrypt-hez használt jelszó a keretalkalmazásból "könnyen" kinyerhető. Vagy tévedek?
Ja meg az is fontos, aszimmetrikus titkosítást szeretnél (mint a PGP) vagy szimmetrikusat
Nem kötözködésként mondom, de a PGP nem asszimetrikus titkosítási módszert használ, hanem kombináltat.
A titkosítandó szöveget először is tömöríti, aztán generál 1 szimmetrikus kulcsot, amit ráenged a tömörített szövegre. A generált szimmetrikus kulcsot pedig kódolja DH (vagy RSA) asszimetrikus titkosítással, hozzáírja, és mehet a kimenetre.
Ez már csak azért is jobb, mert kevesebb kriptoszöveg áll rendelkezésre a DH v. RSA kulcs feltöréséhez + nagyobb adatmennyiségek esetén sokat javít a sebességen. (az asszimetrikus titkosítási módszerek _sokkal_ lassabbak, mint a szimmertikusak)
Az is számít, hogy milyen módon kapcsolod össze a titkosított blokkokat. Ez a sebességre és a 'titkosítás mértékére' is hatással van. Pl. van olyan módszer, hogy az előző titkosított blokkot felhasználja a következőhöz, így a blokkokat megcserélve nem lehet manipulálni az eredeti forrást.
Igazad van, ECB-t (amikor csak egymás után tesszük a titkosított blokkokat) nem szabad használni.
Itt van helyette a CBC vagy a CFB.
CBC: a titkosító algoritmus bemenetét nem csak a titkosítandó szöveg képezi, hanem még xor művelettel beleveszik az előző blokk titkosított kimenetét.
A CFB kicsit bonyolultabb, de jobb. (ha érdekel vkit, leírom, hogy müxik)
Az is számít, hogy milyen módon kapcsolod össze a titkosított blokkokat. Ez a sebességre és a 'titkosítás mértékére' is hatással van. Pl. van olyan módszer, hogy az előző titkosított blokkot felhasználja a következőhöz, így a blokkokat megcserélve nem lehet manipulálni az eredeti forrást.
Régebben találtam at RSA-nál egy jó összefoglaló PDF-et, ha nem találnád meg a hálón, előkotorhatom...
Ja meg az is fontos, aszimmetrikus titkosítást szeretnél (mint a PGP) vagy szimmetrikusat, azaz ugyanaz a jelszó való kódolásra és dekódolásra. Szerintem feladattól függ, hogy melyiket érdemes használni. Az általad említettek nagy része szimmetrikusnak tűnik nekem.
Mindenek előtt DES-t ne használj! Az 56 bites kulcs már régen nem biztonságos.
A 3DES elég jó, még nem találtak módszert, amivel fel lehetne törni, de fontos valóban 3 különböző kulcsot használj, 2 nem elég. Ezen kívül a 3DES _nagyon_ lassú.
A Blowfish, Twofish még nagyon új, az életemet nem bíznám rá, de ígéretesnek tűnik. Az RC szériát nem ismerem részletesen, de úgy tudom, hogy csak a 6-os biztonságos.
Amit én ajánlok: CAST-256,AES vagy IDEA (az IDEA üzleti célú felhasználás esetén jogdíjköteles)
Az egyetlen 100%-ig biztonságos titkosító algoritmus az OTP, de sajnos a gyakorlatban nem használható.
Nem könnyű egy ilyen összehasonlítás, de részleges eredményeket azért a különböző psw törő oldalakon találhatsz.
Pl egy 40 bites RC4 egy 800-as P3-ason átlagosan 10 nap.
Egy 128 bites X titkosítás nehezebben törhető mint a 64 bites X (X ugyanaz). Mindegyiknek van valamilyen jó tulajdonsága és néhány rossz. Sebesség vs. teremtett káosz nagysága.
A legjobb lenne, ha b@aromi gyorsan csinálna mindent és nagy káoszt teremtene, de ilyen nincs.
A választás esetén a sebességet figyelembe kell venni, esetleg lassú gépen is mennie kell, illetve fontos, hogy az oprendszer támogassa a választott encrypt-et. (lehetőleg támogassa).
DES, 3-DES, BlowFish, RC5 elég elterjedtek, jól működnek. AES egy új (1-2 év) próbálkozás.