Legerősebb titkosítási algoritmus
2003-09-10T22:57:09+02:00
2003-09-21T15:24:21+02:00
2022-06-29T08:35:50+02:00
  • 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.
    Mutasd a teljes hozzászólást!
  • 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
    Mutasd a teljes hozzászólást!
  • 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
    Mutasd a teljes hozzászólást!
  • 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.
    Mutasd a teljes hozzászólást!
  • 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?

    netchan
    Mutasd a teljes hozzászólást!
  • A titkositas az adatatvitelt vedi, vagy a feltoltes utan is titkosnak kell maradnia a file-nak? Kinel lesz a jelszo?


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

    Nem lenne egyszerubb, ha egy sima titkositott rar-t toltenel fel? A rar nagyon jo titkositast hasznal.


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

    Meg egy: ftps nem sftp akar lenni?


    FTPS akart lenni. FTP with SSL (Explicit)
    Mutasd a teljes hozzászólást!
  • 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.

    Meg egy: ftps nem sftp akar lenni?

    netchan
    Mutasd a teljes hozzászólást!
  • 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?
    Mutasd a teljes hozzászólást!
  • 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)

    Üdv. ax
    Mutasd a teljes hozzászólást!
  • 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
    Mutasd a teljes hozzászólást!
  • 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.
    Mutasd a teljes hozzászólást!
  • XOR power.

    Mutasd a teljes hozzászólást!
  • 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
    Mutasd a teljes hozzászólást!
  • 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.
    Mutasd a teljes hozzászólást!
  • Mihez akarod hasznalni? Altalanos celu titkositasra egy PC kaliberu hardverrel, uj projectnel ma az AES-t erdemes hasznalni, szvsz.
    Mutasd a teljes hozzászólást!
  • 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ó :)
    Mutasd a teljes hozzászólást!
  • 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
    Mutasd a teljes hozzászólást!
  • 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
    Mutasd a teljes hozzászólást!
Címkék
abcd