ls -1Itt lakik a HUP PartnerünkHUP tweetjeiNépszerű témákNépszerű fórum témákÚj felhasználók
|
fájltartalom[i] xor jelszo[i mod hossz(jelszo)] módszerrel titkosított fájlokatSaját, általam írt algoritmussal fel tudom törni 14% (26 szavazat) Tudom az elméletét, hogy lehet az ilyet feltörni, ha kell írok rá algoritmust 16% (30 szavazat) Tudok, és használok olyan programot ami ezt tudja törni 1% (1 szavazat) Próbáltam már programot írni a szóbanforgó titkosítás törésére, de nem sikerült 2% (3 szavazat) Töltöttem már le programot a szóbanforó titkosítás törésére, de nem járt sikerrel. 2% (3 szavazat) Csak az eredmény érdekel / nem tudom / nem érdekel / wtf? / stb. 67% (129 szavazat) Összes szavazat: 192
»
|
KeresésNavigációBelépésÚj Világ NKft. állásajánlatokÁllásajánlatokHWSWFriss blogbejegyzések
HUP napi hírlevélInformációKövess minket! |
programozás tanulásánál vetődött fel ez az egyszerű algoritmus... kíváncsi vagyok...
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
és ha hossz(jelszo) > hossz(fajl)? :)
+1
-----
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."
akkor feltaláltad a one-time padding-ot, főleg, ha nem használod újra.
Az legalább biztonságos!:)
akkor a jelszónak csak az első hossz(fájl) darab karaktere használódik.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
Oké, és erre milyen algoritmust írsz? Side-channel tanadasokon kívül persze.
Nem one time padding, tehát elvileg törhető... ha pl. tudjuk a fájl típusát, akkor különösen egyszerű a header miatt.
>tudjuk a fájl típusát, akkor különösen egyszerű a header miatt.
helyes meglátás
----------------------------------
szélsőségesen idealista, fősodratú hozzászólás
Ja, ja, amúgy meg csak nagy mennyiségű fájl esetén lenne értelme nekifogni, de inkább neki sem állnék, ha nem lenne életbevágó.
... főleg, ha előtte egy gzip-pel összenyomom :D
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
mert annak nincs ám headerje :D
Azzal visszafejted a jelszó headernél használt részét. Ezzel még mindig csak töredékeket tudsz megfejteni a fájlból. Ha sima szövegfájl csúsztatod amíg nem talált értelmes dekódolást és akkor megvan a jelszó hossza. Így még mindig csak töredékek lesznek visszafejtve. De ha legalább egy csúszóablakos tömörítést végignyomtak a fájlom mielőtt titkosították xor-ral nem sokra jutsz a headeres visszafejtett kulcsrésszel. Még a kulcs hosszát sem fogod tudni meghatározni.
Lehet ezt akármeddig bonyolítani, de használjunk egyszerűen one time padding-et, aztán annyi.
Helyes, hogy már az iskolában a való életre készítik fel a gyereket.
Cryptovírus forevör. :)
--
"Sose a gép a hülye."
Azért ezek fontos kérdések. Egy x éves informatikai képzésről ne menjenek már úgy ki emberek, hogy cleartext jelszavakat tárolnak egy adatbázisban vagy épp saját crypto algoritmusokat akarnak feltalálni.
Viszont ennek semmi köze a topik témájához.
Lehet. Én hasonló feladatokat jellemzően azért szoktam feladni, hogy a tanuló érezze, hogy mennyire könnyű ezeket a hiányosságokat kihasználni.
-
Erről ez a klasszikus jut eszembe: https://lkml.org/lkml/2015/11/18/9
ezen jót röhögtem
"all submitted complaints will be forwarded to /dev/null for further investigation"
expectations versus reality
Valamikor nagyon régen fel tudtam törni, de ahogy oly sok mindent, mára ezt is elfelejtettem. :(
(És megkötésekkel pl. a jelszó hosszára, de akkoriban még a 8 karaktert is elégnek gondoltuk)
Igazából nincs jelentősége a jelszó hosszának, ha tippelni tudsz az eredeti, plain-text tartalomra legalább ugyanolyan hosszúsággal.
Najó, de itt már jött olyan is, hogy len(password)>=len(file)
:)
szélsőségesen idealista, fősodratú subscribe, elvégre pont az én egyik szélsőségesen idealista, fősodratú hozzászólásomra reagáltál ezzel, te szélsőségesen idealista, fősodratú sigellef. (vagy legalábbis ugyanaz a szélsőségesen idealista, fősodratú thread volt)
----------------------------------
szélsőségesen idealista, fősodratú hozzászólás
Az kimaradt, hogy "Elfelejtettem/sose tudtam az elméletet, de 10 perc Google után meg tudom írni az algoritmust."
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o
Nem úgy van, hogy csak úgy fel lehet törni, nincs rá algoritmus csak akkor ha sejtjük, hogy mi van a fájlban. Például ahogy fentebb írták, a fájltípus.
Például ha tudjuk, hogy ASCII vagy UTF szöveg, akkor statiszikailag elemezhetjük a fájlt, és így kijöhetnek a bitek maszkjai egyesével. De ha nem tudjuk mi van a csatornán, akkor azért nehéz rájönni és lényegében "ésszel" kell nekiállni. Vagy olyan AI-jal, amit egy rakás fájllal tanítottunk.
Tegyük fel, hogy egy eleve OTP-vel titkosított fájlról van szó. Ezt "titkosítjuk" újra ezzel a módszerrel. Soha nem fogjuk megtudni, hogy mi a kulcs, mert nincs fogódzó.
+1 Nekem is a nagy mennyiségű fájl jutott eszembe, ha nincs header.
wav-ot viszont 100% nem érdemes így titkosítani, mert titkosítás után audio raw-ként visszatöltve kihallani belőle a zenét.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
ezt ki kell próbálnom :D
"all submitted complaints will be forwarded to /dev/null for further investigation"
expectations versus reality
Az a lényeg, hogy pusztán az adatmennyiség idő függvényében elég információt hordoz a beszédhang tartalmának meghatározásához. Zenére még nem olvastam, hogy hasonló elv működne. Nyilván függ a zene típusától is.
Telefonos beszélgetés titkosításánál éppen ezért nem elég a beszédhangok titkosítása, ballaszt adat is kell mellé.
álvéletlenszámok hozzákeverésével a hangtitkosítás is megoldható. Ha a blokk akkora, hogy egy 100 Hz-es sinushullámhoz tartozó adatmennyiséget lefed, akkor már kizárt dolog, hogy bármi kihallható belőle.
Ha meg
adat[i] xor kulcs[i mod hossz(kulcs)] xor (random_byte div 2)
akkor is csak egy erősebb sistergés keveredik hozzá.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
Ha a jelszó és a plaintext közös információtartalma 0, valamint a jelszó legalább olyan hosszú, mint a plaintext, akkor nem tudom/lehet visszafejteni.
Mindenféle megszorítással már relatíve könnyen törhető is lehet.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 14.2 | 4.4.37-janos
+ többet nem használod titkosításra ugyanazt a kulcsot
Ha a jelszó elég hosszú és véletlenszerű (főleg ha hosszabb mint a fájltartalom), akkor törhetetlen, nem?
Ebben van valami... amivel anno (20 éve vagy több) szórakoztam, annak volt valami megkötése a jelszó hosszára...
Ha turbo pascal-ban írod meg, és jelszóbevitelhez string-et használsz, akkor 255 karakter a maximum hossza.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
és már fel is találtad a one-time-padding-ot (amennyiben a jelszót nem használod újra :D)
2x ment
Nem látod, hogy a szavazók több mint tíz százaléka IQ-ból töri a lehetetlent, 15 százaléka meg tudja hogy hogyan kellene csinálni. Most akkor mi tudjuk rosszul vagy ők?
Fel tudom torni, csak adjatok egy vilegegyetemnyi idot.
A bruteforce mindig mukodik. Csak neha nehez kivarni a veget. :DDD