[angelasferkel]

vorschlag / request: im grund finde ich die lösung von seed nicht schlecht - ich bin ja eh ein verfechter des "nächster link erst nach komplettem downlad".
könnte man vielleicht einen auto-reupper für den container machen, so dass beim einem gelöschten link eine neue containerversion (so vorhanden) gezogen wird und nur die noch nicht heruntergeladenen files gezogen werden?

@alf: es geht gerade nicht darum, eine sichere verschlüsselung zu knacken. IMHO gibt es auch keine, die das prädikat sicher verdient.

[schneewiesel]

@Alf A. Romeo:
Wo denn ?

[seed]

@angelasferkel: das würde problemlos gehen... wenn rs nicht den hash aller verpetzten dateien speichern würde. naja mir fällt gerade ein workaround ein: man müsste im container die dateigröße mit angeben, damit alle alle angehängten bytes bei der md5 abfrage ignoriert würden... somit würde sich der hash für rs ändern, jedoch nicht für den container. ein autoupdater ist problemlos möglich, jedoch bräuchten wir erstmal eine lösung für den download... also zB. eine implementierung für den USD

@schneewiesel:
xenocode verhindert das decompliieren nicht, es erschwert das nur...

[saltlake]

Das reuppen ist in der Tat ein Problem, da der Hash gesperrt wird. Um die einzige wirklich saubere Loesung zum reuppen zu bekommen, hilft nur ein Packen mit einem beliebigen Archiver. Womit man wieder beim doppelten Verpacken angekommen waere.

Ein Padden mit irgendwelchen Daten ist immer Downloader- oder Formatabhaengig.

greetz

[seed]

@saltlake:
stimmt, doppelt verpacken ist eine möglichkeit, aber könnte nicht den kompletten hash berechnen, sondern nur die anzahl der bytes die im container bestimmt ist...
also wenn der container sowas enthält:

md5.exe:49152:<http://rapidshare.com/files/111111111/md5.exe>
md5.zip:68567:<wLX7erNJUeGquUlFepIqDd2ObWot/4VhGiwAuw0XMu+WYtujA4TjSZnbncBGIOOq>
rijndael.py:10985:<FGbAblxbfPYJZ+EVGnrIkZnrdfU10f84ADCnZ1d0zsgfR73NWqDo3hrP vYWSMLC0SFnFiwrbEQzpbKjccZveQQ==>

wenn dann zB md5.zip verpetzt wird, fügen wir einfach ein null-byte ans ende hinzu, die dateigröße ändert sich von 68567 auf 68568, was uns erlaubt sie bei rs wieder hochzuladen, und der decrypter berechnet den hash weiterhin nur von den ersten 68567 bytes der datei...

//edit: achso . man muss sich dann aber entscheiden: entweder einmal mehr verpacken (die daten werden nicht korrumpiert, kostet aber performance), oder nur teilweise hashen (ist wahrscheinlich schneller, da daten nicht extra entpackt werden müssen, hat aber den von dir genannten nachteil )

-seed

[saltlake]

Dass das System so funktionieren wuerde ist klar. Durch das Padden werden die Daten jedoch korrumpiert, das ist das einzige worauf ich mit meinem Post hinauswollte

greetz

[h264]

Hi,
ich hab mir die Idee von angelasferkel (super idee ) so vorgestellt:

Upper:
1. RAR Teile erstellen
urlaubsbilder.part01.rar
urlaubsbilder.part02.rar
...
urlaubsbilder.part80.rar

2. Upload letztes Teil --> bekommt man den Link
http://rapidshare.com/files/12345678/urlaubsbilder.part80.rar
3. den Link und einen Zufall-Block hinter part79.rar addieren, z.B. in 2 x 256-byte blocke
urlaubsbilder.part79.rar.dat = urlaubsbilder.part79.rar + [http://rapidshare.com/files/12345678/urlaubsbilder.part80.rar] + [zufallsteil, wegen MD5]
4. upload part79.rar.dat
5. so weiter bis part01.rar.dat

Downloader:
1. download part01.rar.dat
2. strip down letzte 512 bytes --> man hat den link zum nächsten teil und orig. rar datei

Wenn z.B. part01,part02,part03 verpetzt sind, braucht der Uploader nur von dem link zu part04 rückwärts wieder generieren und uploaden. Das Zufallsteil sorgt dafür dass RS den reupp akzeptiert

Irgendwie macht ihr zu kompliziert (?) oder kapiere ich nicht? Wo liegt das Problem? Sry wenn es bereits geklärt ist, ich blicke nicht durch

Kann jemand (schneewiesel, saltlake, shira, seed) das implementieren? Der Schutz gegen petzen wird wesentlich sicherer als cryptload container da bei CCF braucht man nur sekunden um alle links zu haben. Im moment ist CCF aber noch gewünscht da es zumindest den Uppper eine (schein)sicherheit bietet und die links leben ja vllt auch länger (mich stört das nicht da ich die links extrahieren kann und muss nicht unbedingt mit cryptload laden)

[schneewiesel]

An der implementierung sollte es nicht scheitern, jedoch müsste man immer ein extra upload tool verwenden.

Ausserdem würde ich die parts von hinten nach vorne uppen, dann fängt man auch mit dem 1. part zu laden an

[Opfer15]

Mal wieder down :P

€so und damit das kein Einzeiler bleibt, führe ich hier mal die Ampel ein

[img=http://img245.imageshack.us/img245/6797/ampelrotbbu7nq7.jpg]

[schneewiesel]

Nein, das war absicht.
Der ccf gen ist leider nutzlos geworden.
In CL0.8 werden die links aus den ccf´s die mit diesem genetator erstellt wurden in klartext dargestellt.
(also wenn du mit diesem ccf gen eine cf erstellt, kannst du in CL0.8 die kompletten links bestaunen). Nun kann man nur noch ccf´s mit BorgLoad (CL) erstellen.

[wellenbrecher]

Ach deswegen schneewiesel. Ich wunderte mich schon darüber
Nun ist alles klar

In der 0.75 werden die mit ccf Generator erstellten Containerfiles auch klar dargestellt. Sehe den vollständigen DL Pfad.
Alles irgendwie nicht so prickelnd

[Ridcully]

nein .. der muss von hinten geladen werden, da ein sinnvolles entpacken nur mit part 1 gegeben ist ..

wenns sequentiell sein soll muss also von 46-1 geladen werden um den jeweiligen link zu bekommen, das programm kann aber nur entpackt werden ,wenn tasächlich part1 als letztes downgeloadet wurde.

[Opfer15]

Achso

BTW: wiesogehen hier keine thumbs ?

[krazyivan]

also ich hab gestern abend überlegt welche version dieser kettencrypt-sache wohl gegen petzen den besten schutz bietet, am schwersten zu umgehen ist und dabei einigermaßen benutzerfreundlich.

1. system nextpart.txt(egal ob doppelt verpackt oder angehängt):

von der sicherheit sehr gut, man kommt grundsätzlich nicht an einen link, ohne das verherige file geladen zu haben.
nachteile sind dass man ein extra upload programm dafür bräuchte, man zwingt den uploadern also wieder ein extra programm auf und viele werden sich nicht umstellen wenn sie gute erfahrungen mit einem anderen prog gemacht haben.
außerdem wenn eine petze alles geladen hat, und anschließend die links abused muss jeder wieder von vorne zu laden anfangen, auch wenn ihm nur noch ein part fehlt, und auch wenn die gere-upten parts kompatibel wären zu den alten archiven.

2. system von seed mit dem md5-container version1:

auch sehr sicher, mit dem wichtigen vorteil dass die uploader an kein upload programm und an keinen hoster gebunden sind. egal welche links und wie sie geupt wurden können mit einem kleinen container-generator sicher verschlüsselt werden.
das problem mit den reups gibts hier aber auch. bei einem reup müssen alle md5 geändert werden, somit stimmen die schlüssel aus den alten files nicht mehr und man muss wohl oder über wieder von vorne laden.

3. system von seed version2:

uploader-programm und hoster-unabhängig, dadurch dass die md5 nur von einer bestimmten dateilänge berechnet wird ändert sie sich bei einem reup nicht, und man kann sofort dort weiterladen wo man von den petzen gestört wurde.
das system ist im prinzip super und gefällt mir gut, allerdings etwas unsicher. schließlich müssen sich die petzen nur die heruntergeladenen md5-summen speichern und sobald der reup da ist können sie wieder alle links abusen, da sich die schlüssel ja nicht geändert haben!
wenn die dann anfangen die summen untereinander zu tauschen und die prüfsummen zu sammeln ist das container-format geknackt.

das war so mein gedankengang, nachdem ich lang hin und her überlegt hab kam mir eine idee für einen neuen ansatz bei dieser verschlüsselung:

und zwar eine art containerfile wie die von seed, die hoster-unabhängigkeit ist einfach wichtig.
damit die files nach einem reup zur verschlüsselung kompatibel bleiben und das ganze nicht durch aufsparen der md5 sofort wieder geknackt werden kann verwende ich zum verschlüsseln nicht die summen, sondern die dateien selber.

beispiel:
es sollen die links zu 5 dateien verschlüsselt werden:

hoster\datei1.rar
hoster\datei2.rar
.
.
hoster\datei5.rar

die verschlüsselung läuft folgendermaßen:

link1 wird im klartext übernommen.

dann wird eine zahl generiert, und zwar zufällig zwischen 0 und dateilänge(part1.rar)-schlüssellänge
hier ergibt sich zb 123456.

die bytes 123456-123459 von datei1.rar werden als schlüssel für den link zu datei2.rar verwendet.
die zufallszahl steht natürlich im conatainer.

dieser schaut jetzt so ähnlich aus:

datei1.rar:<hoster\datei1.rar>
datei2.rar:123456:<verschlüssselter link>

anschließend wird wieder eine zufallszahl erstellt, zb 654321.

der neue schlüssel wird jetzt aus den bytes 654321-654325 von datei1.rar + den bytes 654321-654325 von datei2.rar erstellt.

container:
datei1.rar:<hoster\datei1.rar>
datei2.rar:123456:<verschlüsselter link>
datei3.rar:654321:<verschlüsselter link>

bei datei 5 wird der schlüssel dann aus einer kombination von bytes aus allen verhergehenden parts generiert.


der vorteil dieser methode wäre, dass man nur die links sieht, wenn man auch wirklich alle dateien ganz auf seinem computer hat. es reicht nicht nur die md5 zu speichern.
beim reup werden neue zufallszahlen generiert, das heoßt es reicht auch nicht nur die jeweiligen schlüssel zu speichern.
das system bringt keine nachteile für den normalen downloader, da sowiso keiner die parts löscht bevor alle herunten sind, jedoch gehen die petzen früher oder später in der datenmenge unter wenn sie sich alle parts aufheben müssen um sie wieder verpetzen zu können.

kampf den petzen

[wellenbrecher]

Zitat von schneewiesel

Nun kann man nur noch ccf´s mit BorgLoad (CL) erstellen.

Was ist der BorgLoad, wo findet man den? Stehe hier echt auf dem Schlauch.
Wäre jemand so lieb underklärt mir das einer mal?

[Xeton]

Kann man aktuelle .ccf Dateien (die mit Version >0.8 erstellt wurden) eigtl. knacken? Arbeitet Dexter daran?

[Ridcully]

Zitat von wellenbrecher

Was ist der BorgLoad, wo findet man den? Stehe hier echt auf dem Schlauch.
Wäre jemand so lieb underklärt mir das einer mal?

ist ein insider für aufmerksame leser .. ..

du weisst ja auch nicht was forceload ist

[|Barana|]

Zitat von Ridcully

was forceload ist

ajajaj Ridcully... forcceload

---------------------------------------

Übrigens, um auf das eigentliche Thema des Threads zurückzukommen.
Dexter hat mir gezwitschert, dass er im Moment zwar wenig Zeit hat, aber sich das neue CCF Format dennoch zur Brust nehmen wird.
Ich bin eine der stellvertretenden Stimmen von Dexter, weil er im G:B nicht angemeldet ist. Also keine Morddrohungen an mich bitte...

[seed]

@krazyivan: coole idee, den schlüssel nur aus teilen der datei zu machen, sollte auch leicht zu implementieren sein aber man sollte trotzdem die gesammtdateigröße mit angeben, falls mans reuppen möchte und dabei noch bytes ans ende anfügen möchte... so werden die daten am ende nicht korrumpiert, denn man kann die gepaddeten bytes dann wieder abziehen...


@Blad€: die neuen ccf sind super leicht zu entschlüsseln, wobei man dabei noch cl benötigt, denn es gibt ne wunderschöne schwachstelle in cl, die meiner meinung nach auch gar nicht so einfach behoben werden kann...

[Ridcully]

ups ja .. war bestimmt wieder der tastaturvirus .. loool

[Xeton]

Zitat von seed

@Blad€: die neuen ccf sind super leicht zu entschlüsseln, wobei man dabei noch cl benötigt, denn es gibt ne wunderschöne schwachstelle in cl, die meiner meinung nach auch gar nicht so einfach behoben werden kann...

hmm, dann könnte man ja wieder ein Programm schreiben, oder?

[h264]

die Idee von krazyivan mit zufällige string als Key ist auch sehr gut, da es schneller geht als hash von 100MB Datei zu berechnen. Und die Methode von seed hat den grossen vorteil das man nur das verpetzte teil reuppen muss. Ich überbearbeite das schema nach den Ideen von seed und krazyivan so:

Uppen:
1. DAT-files vorbereiten
part01.rar + [256 zufall bytes] -> part01.rar.dat
part02.rar + [256 zufall bytes] -> part02.rar.dat
...
2. upload dat-files mit beliebigen uploader
3. links container file erstellen:

[http://.../part02.rar.dat] + [letzte 32-bytes von part01.rar als key] --> verschlüsselte link für part02
[http://.../part03.rar.dat] + [letzte 32-bytes von part02.rar als key] --> verschlüsselte link für part03
...

Das links container file sieht dann so aus:

# comments, NFOs
part01.rar|100000000|none|http://.../part01.rar.dat
part02.rar|100000000|part01.rar|verschlüsselte link für part02
part03.rar|100000000|part02.rar|verschlüsselte link für part03
und so weiter nach dem schema
<filename>|<originalsize>|<keyholder-filename>|<encrypted-link>

Downloaden:

http://.../part01.rar.dat downloaden
letzte 256 bytes wegschneiden --> original part01.rar
[letzte 32-bytes von part01.rar als entschlüsselnkey] + verschlüsselte link für part02 --> http://.../part02.rar.dat
letzte 256 bytes wegschneiden --> original part02.rar usw.

Reupp: beispiel part50 ist verpetzt

1. part50.rar + [256 zufall bytes] -> neues part50.rar.dat (part50.rar bleibt unverändert!)
2. part50.rar.dat reuppen, bekommen wir neuen link http://.../part50.rar.dat
3. links container file re-generieren und wieder veröffentlichen
[letzte 32-bytes von part49.rar] + [http://.../part50.rar.dat] --> verschlüsselte link für part50 (neu)
Der downloader überspringt 49 teile die bereits auf Festplatte liegen und lädt von dieser stelle weiter.

- das padden ein zufallsblock hinter rar-teil ist einfacher als doppelt verpacken. Beim doppelten verpacken müssen wir sowieso irgendetwas, zufallsdaten, datum etc., dazu packen damit ein reupp klappt. Das padden/wegschneiden ist viel einfacher und resourceschonender als pack/unpack (nur einfach fseek(f,filesize(f)-256)); truncate(f); )
- warum nehme ich letzte bytes als key: 1. petze muss datei komplett laden, 2. dieses teil unterscheidet sich meistens von file zu file (im gegensatz zu header). Und 32 bytes also 256 bit sind genug. Der Petze lohnt es sich nicht via bruteforce zu knacken
- die cumulative verschlüsselung durch alle bisher geladene teile macht zwar etwas sicherer. Die petze hat aber schon diese teile, weil sonst wie ist sie zu diesem teil gekommen
- man kann beliebigen Upload Prog nehmen, aber es ist bequemer mit einem einfachen upload tool, der beim uppen dat-file on-the-fly erstellt (spart man zeit und platz)
- ich nehme rar und rapidshare als beispiel, ist ja das verbreiteste, muss aber nicht. Also hoster und file format unabhängig. Download progies müssen sowieso erweitern und nach einem standard halten

Ein Nachteil bei diesen kettenmethoden: man kann nicht vor dem download alle links checken. Es hilft eine webseite die die links on-the-fly prüft und gibt als Statusbild zurück. Es ist schön wenn dieses Statusbild direkt in G:B gezeigt wird. Die Links muss der Upper dem webserver mitteilen und werden dort sicher gespeichert.

EDIT. Das Statusbild belastet nur den server. Also reicht es ein Link zum checken der prüft und sagt welche Dateien verpetzt sind

EDIT2. Ich gebe zu dass es mit Dateigröße angabe sicherer ist

[schneewiesel]

Zitat von Blad€

hmm, dann könnte man ja wieder ein Programm schreiben, oder?

Ich arbeite zzt. an einem, ccf zu rsdf konverter, damit ist es möglich die ccf Links mit dem RSD zu laden

[krazyivan]

@h264:
bei deiner version ist es wieder so dass sich die keys nach einem reup nicht ändern, dh. eine petze die einmal alle keys hat kann sofort wieder petzen ohne sich die ganzen parts aufheben zu müssen.

so wie ich das meine ändern sich sämtliche keys bei jedem reup und nur wer die kompletten parts hat kann die gereupte version auch entschlüsseln, es genügt eben nicht nur die keys aufzuheben.

....Und die Methode von seed hat den grossen vorteil das man nur das verpetzte teil reuppen muss.....

wieso sollte das bei meiner version nicht gehen?

[h264]

@krazyivan: natürlich geht es mit deiner version. Sie basiert doch auf seed-methode oder?
Zu dem petzen: die keys liegen ja in den vorherigen parts. Wenn die petze die parts einmal runtergeladen hat damit sie petzen kann, ist sie auch in der lage das neu reuppte part zu entschlüsseln. Das regenerierte container file muss man doch wieder veröffentlichen oder? Es sei denn wir packen alle neu und reuppen.
Das system hindert nämlich das erste petzen, weil der Aufwand alle teile zu petzen ist enorm im vgl zu CCF. Hat die petze das letzte teil petzen können, hilft es nur ein kompletter reupp