Legerősebb titkosítási algoritmus

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.

netchan

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.

netchan

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.



Tehat, ha jol ertem, akkor lesz egy kulcs, amit a kozpont es az alkalmazas ismer, es ezzel lenne titkositva az allomany?

netchan

A feltöltés után is titkos marad. A központban található alkalmazás letöltés után fogja decryptelni.



Én azért jobban bíznék egy komolyabb algoritmusban, bár nem ismerem a RAR-ét.



FTPS akart lenni. FTP with SSL (Explicit)

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

Meg egy: ftps nem sftp akar lenni?

netchan

Aszimetrikus jól hangzik.

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?

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)



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)

Üdv. ax

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.

Üdv,
Ferenc

Azt hiszem akkor maradok az AES-nél.
Közepes méretű fájlok (10-100 MB) titkosításához fog kelleni, így a sebesség is sokat számít.

XOR power.

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

Üdv. ax

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.

Mihez akarod hasznalni? Altalanos celu titkositasra egy PC kaliberu hardverrel, uj projectnel ma az AES-t erdemes hasznalni, szvsz.

Annyit tennék hozzá, hogy a gyenge pont általában nem a kódolás típusa, bonyolultsága, hanem a felhasználó által megadott "password" jelszó :)

A válasz: "Nem megállapítható, nem mérhető"

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.

Erősség = sebesség + káosz nagysága

Nem találtam sehol normális összehasonlítást az alábbi titkosítási algoritmusok között. Melyik a legerősebb?

Blowfish
Cast-128
Cast-256
DES
3DES
Ice
Thin Ice
Ice 2
IDEA
MARS
RC2
RC4
RC5
RC6
Rijndael (AES)
Serpent
TEA
Twofish