1. Foren
  2. Kommentare
  3. Politik/Recht
  4. Alle Kommentare zum Artikel
  5. › Rechtsanwalt: Filmindustrie wird…

encryption vs de-duplication

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. encryption vs de-duplication

    Autor zZz 21.01.13 - 20:18

    hmm, mega verspricht sowohl verschlüsselung durch den user als auch de-duplication. geht das überhaupt, wie geht das?

    Benutzer wird von Ihnen ignoriert. Anzeigen

  2. Re: encryption vs de-duplication

    Autor blub1991 21.01.13 - 20:42

    du könntest ne checksumme vorher bilden und abfragen ob diese datei schon mal hochgeladen wurde... dann hast du aber ein problem, das du nicht weißt wie die andere datei verschlüsselt wurde, da mega ja angeblich die keys nicht hat.
    eine andere möglichkeit währe ein eigenes FS, bei dem dedublication auf einer lowlevel betrieben wird, also ein speichersektor von vieleicht 4k zu mehrern dateien gehört. das ist ziemlich aufwendig und mann muss mal ausprobieren ob die filetable vieleicht mehr speicher braucht als das system spart, aber es währe möglich.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  3. Re: encryption vs de-duplication

    Autor NobodzZ 21.01.13 - 21:29

    blub1991 schrieb:
    --------------------------------------------------------------------------------
    > du könntest ne checksumme vorher bilden und abfragen ob diese datei schon
    > mal hochgeladen wurde... dann hast du aber ein problem, das du nicht weißt
    > wie die andere datei verschlüsselt wurde, da mega ja angeblich die keys
    > nicht hat.
    angeblich ja nicht...
    > eine andere möglichkeit währe ein eigenes FS, bei dem dedublication auf
    > einer lowlevel betrieben wird, also ein speichersektor von vieleicht 4k zu
    > mehrern dateien gehört. das ist ziemlich aufwendig und mann muss mal
    > ausprobieren ob die filetable vieleicht mehr speicher braucht als das
    > system spart, aber es währe möglich.
    wenn daten verschlüsselt ist, funktioniert auch das nicht wirklich, anonsten wäre der Verschlüsselung angreifbar...

    Benutzer wird von Ihnen ignoriert. Anzeigen

  4. Re: encryption vs de-duplication

    Autor Geistesgegenwart 21.01.13 - 22:34

    blub1991 schrieb:
    --------------------------------------------------------------------------------
    > du könntest ne checksumme vorher bilden und abfragen ob diese datei schon
    > mal hochgeladen wurde... dann hast du aber ein problem, das du nicht weißt
    > wie die andere datei verschlüsselt wurde, da mega ja angeblich die keys
    > nicht hat.

    Richtig. Deswegen geht de-duplication bei MEGA nicht.

    > eine andere möglichkeit währe ein eigenes FS, bei dem dedublication auf
    > einer lowlevel betrieben wird, also ein speichersektor von vieleicht 4k zu
    > mehrern dateien gehört. das ist ziemlich aufwendig und mann muss mal
    > ausprobieren ob die filetable vieleicht mehr speicher braucht als das
    > system spart, aber es währe möglich.

    Braucht man nicht ausprobieren, dazu reicht Deduktion: Wenn du eine Blocklänge von 4k Byte hast, wird sich im Schnitt erst nach (2^(8*4096)-1) beschriebenen Blöcken ein Block wiederholen. Selbst alle Festplatten der Welt zusammengenommen könnten nichtmal ein Bruchteil dieser Datenmenge speichern.

    Das es nicht funktionieren kann liegt daran, dass bei wirkungsvoller Verschlüsselung ein 4k Block verschlüsselter Daten sich nicht erkennbar von einem 4k Block zufällig generier Daten unterscheidet. Aus dem selben Grund kannst du verschlüsselte Daten auch nicht komprimieren, da eben maximale Entropie vorliegt.

    Wäre dies nicht der Fall, also eine doppelter Block bei unterschiedlichen Eingabedaten gegeben und vergleichsweiser geringer Anzahl an vorhanden Blöcken, wäre deine Verschlüsselung angreifbar, und damit nicht sicher.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  5. Re: encryption vs de-duplication

    Autor LH 21.01.13 - 22:43

    Allerdings kennt Mega laut ihrer Doku sehr wohl die Keys, sie haben also Zugriff auf den Inhalt der Dateien.
    Die Dateien sind einzeln mit Keys versehen. Es wäre problemlos möglich beim auftauchen einer identischen Quelldatei diese nicht erneut zu speichern, sondern schlicht den bereits bekannten Keys beim neuen User einzutragen und die Datei beim User zu registrieren.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  6. Re: encryption vs de-duplication

    Autor scinaty 21.01.13 - 23:48

    LH schrieb:
    --------------------------------------------------------------------------------
    > Allerdings kennt Mega laut ihrer Doku sehr wohl die Keys, sie haben also
    > Zugriff auf den Inhalt der Dateien.
    > Die Dateien sind einzeln mit Keys versehen. Es wäre problemlos möglich
    > beim auftauchen einer identischen Quelldatei diese nicht erneut zu
    > speichern, sondern schlicht den bereits bekannten Keys beim neuen User
    > einzutragen und die Datei beim User zu registrieren.

    Quelle bitte

    Benutzer wird von Ihnen ignoriert. Anzeigen

  7. Re: encryption vs de-duplication

    Autor Fraggl 22.01.13 - 00:00

    schlichtweg falsch...Datei-Keys werden nur beim Sharen generiert, und existieren sonst nicht

    Benutzer wird von Ihnen ignoriert. Anzeigen

  8. Re: encryption vs de-duplication

    Autor rangnar 22.01.13 - 10:13

    zZz schrieb:
    --------------------------------------------------------------------------------
    > hmm, mega verspricht sowohl verschlüsselung durch den user als auch
    > de-duplication. geht das überhaupt, wie geht das?


    Kryptographie ist keine Hexerei. Wenn es stimmt, das De-Duplication funktioniert, dann hat das zwei Implikationen:

    MEGA ist nicht für normale, private Daten & Dokumente gedacht. Dein Brief an Frau von Leyen dürfte sich signifikant von den Anderen an Nutzern unterscheiden, da lohnt sich De-Duplikation nicht.

    De-Duplikation lohnt sich nur, wenn man mit hoher Wahrscheinlichkeit mehr als ein mal die selben Daten hat. Das sind in der Regel Musik-Dateien und Filme, Installations-Dateien, Source-Code, Dokumente für Wikileaks, Geheimakten über dich ...

    Die zweite Implikation: Den Schlüssel den du hast, das ist der Public-Schlüssel. Mit dem kannst du zwar die Dateien entschlüsseln, mit dem Schlüssel wurden die Daten aber nicht _verschlüsselt_. Den "geheimen", privaten Schlüssel hat Kim Dotcom. Und kann damit deine Daten auf seiner Festplatte entschlüsseln. Und dann funktioniert De-Duplication wunderbar, denn die Daten werden bei deinem Zugriff on-the-fly wieder mit dem privaten Schlüssel, passend zu deinem öffentlichen Schlüssel, verschlüsselt.

    Nein, verschlüsselte Dateien unterscheiden sich grundsätzlich. Ansonsten ist das Verfahren angreifbar. Es ist nur dann gut, wenn die Änderung eines Bits im Schlüssel dazu führt, das die neue verschlüsselte Datei gegenüber dem Ursprung und gegenüber jeder Verschlüsselung mit einem anderen Schlüssel ein völlig anderes, scheinbar zufälliges Muster hat. Da funktioniert keine De-Duplication. Auch nicht mit vorher bekanntem Hash. Denn solange du den "privaten" Schlüssel hast, kann Kim die Daten nicht mehr neu verschlüsseln. Er kann die Daten nur dann verschlüsseln, wenn er, wenn Kim Dotcom, den geheimen, privaten Schlüssel hat. Und dann kann er auch entschlüsseln.

    Sprich: Wenn die Dateien verschlüsselt sind und Kim Dotcom De-Duplication nutzt, dann hat er den geheimen Schlüssel, dann könnte er ganz genau wissen, welche Daten vor liegen, dann kann er ganz genau prüfen, ob die Daten andere Urheberrechte verletzen. ... Oder kurz: Fail

    Benutzer wird von Ihnen ignoriert. Anzeigen

  9. Re: encryption vs de-duplication

    Autor rangnar 22.01.13 - 10:18

    Fraggl schrieb:
    --------------------------------------------------------------------------------
    > schlichtweg falsch...Datei-Keys werden nur beim Sharen generiert, und
    > existieren sonst nicht

    Unfug. der öffentliche Schlüssel ist genau seit ab denn Zeitpunkt bekannt und existiert, als der geheime Schlüssel generiert wurde. Unveränderlich, solange das Schlüsselpaar genutz wird. Würde der Key nur "beim sharen" generiert werden, müsstest du bei jedem Vorgang einen neuen Schlüssel erhalten.

    Wenn du sagst, dass der Schlüssel nur dann existiert, wenn Daten übertragen werden (beim Sharen), heißt dass, das die Daten bei Kim Dotcom unverschlüsselt vorliegen? Das heißt, dass nur Kim Dotcom den geheimen Schlüssel hat, du nur den öffentlichen Schlüssel.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  10. Re: encryption vs de-duplication

    Autor Geistesgegenwart 22.01.13 - 10:28

    rangnar schrieb:
    --------------------------------------------------------------------------------
    > zZz schrieb:
    > ---------------------------------------------------------------------------
    > Kryptographie ist keine Hexerei. Wenn es stimmt, das De-Duplication
    > funktioniert, dann hat das zwei Implikationen:

    Scheinbar schon, denn du hast die Basics nicht verstanden.

    > Die zweite Implikation: Den Schlüssel den du hast, das ist der
    > Public-Schlüssel. Mit dem kannst du zwar die Dateien entschlüsseln, mit dem
    > Schlüssel wurden die Daten aber nicht _verschlüsselt_.

    Wenn du mal nen Blick in die Developer API Docs von MEGA wirfst, würde dir schnell klar werden, das zur Dateiverschlüsselung ausschleisslich das symetrische AES128 eingesetzt wird. Es gibt also kein Public/Private Keypair für die *Verschlüsselung*. Der einzige Grund warum doch ein RSA schlüsselpaar erzeugt wird, ist für private Nachrichten und Schlüsselaustausch mit anderen Usern, das hat aber nichts mit der Dateiverschlüsselung zu tun und du kannst MEGA auch ohne die Nachrichtenfunktion zum verschlüsseln verwenden

    > Den "geheimen",
    > privaten Schlüssel hat Kim Dotcom. Und kann damit deine Daten auf seiner
    > Festplatte entschlüsseln.

    Bullshit. Dein Browser erzeugt FÜR JEDE DATEI einen neuen AES128 Key, mit dem die Datei verschlüsselt wird bevor Sie hochgeladen wird. Kim sieht diesen AES128 Key nicht. Ein Blick in die Developer Docs helfen. Damit du nicht diese Unmenge an Keys lokal speichern musst, werden diese mit deinem Passwort als Schlüssel (bzw. ein Hash davon) wiederrum AES verschlüsselt und bei MEGA hochgeladen. Aber niemand kann mit den Filekeys was anfangen, solange er nicht dein Passwort kennt. Und NEIN, MEGA kennt dein PAsswort nicht. Zur Authentifizierung und Filekey-Verschlüsselung werden zwei verschiedene Salts verwendet und dann gehasht, sodass die Kenntniss des Passwort-Hashes mit dem du dich bei MEGA authentifizierst keinerlei Rückschlüsse auf dein Masterkey (=Passwort) ermöglicht.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  11. Re: encryption vs de-duplication

    Autor Chatlog 22.01.13 - 10:49

    Blocklevel Deduplication.

    Dabei spielen Dateien, Dateiformate und Verschluesselungen keinerlei Rolle.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  12. Re: encryption vs de-duplication

    Autor muhzilla 22.01.13 - 11:43

    Mal nicht so dick auftragen, wenn DU dich noch nicht richtig damit beschäftigt hast, wie man sehen kann:

    Die RSA-Keys haben nichts mit der Verschlüsselung der Dateien zu tun. Man lernt auch relativ früh, dass sich asymmetrische Verschlüsselung nicht dafür eignet große Datenmengen zu verschlüsseln, weil zu langsam. Aus der Doku geht hervor, dass sämtliche Dateiverschlüsselungsoperationen über AES durchgeführt werden. Das Keypair für deinen Account dient vermutlich eher für andere Zwecke, z.B. um die Keys zum Entschlüsseln der Files mit anderen usern zu teilen...

    Edit: Siehe auch hier im Beitrag von Geistesgegenwart:
    http://forum.golem.de/kommentare/politik-recht/rechtsanwalt-filmindustrie-wird-es-mit-mega-schwer-haben/encryption-vs-de-duplication/70216,3234937,3235603,read.html#msg-body



    1 mal bearbeitet, zuletzt am 22.01.13 11:44 durch muhzilla.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  13. Re: encryption vs de-duplication

    Autor zZz 22.01.13 - 16:38

    wenn man sich mit damit ein bisschen auseinandersetzt, wird man schnell zweifel bekommen, dass das bei mega eingesetzt wird. eines der beiden versprechen ist wohl falsch, mega verspricht laut docs aber sowohl verschlüsselung als auch de-duplication. beim hochladen deutet nichts auf das hashen einer datei hin, da wäre selbst bei einer vcd eine deutliche verzögerung vor beginn des uploads spürbar.

    wen's interessiert, hier ein artikel zum secure data de-duplication:
    http://www.ssrc.ucsc.edu/Papers/storer-storagess08.pdf



    3 mal bearbeitet, zuletzt am 22.01.13 16:48 durch zZz.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  14. Re: encryption vs de-duplication

    Autor LH 22.01.13 - 17:08

    scinaty schrieb:
    --------------------------------------------------------------------------------
    > LH schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Allerdings kennt Mega laut ihrer Doku sehr wohl die Keys, sie haben also
    > > Zugriff auf den Inhalt der Dateien.
    > > Die Dateien sind einzeln mit Keys versehen. Es wäre problemlos möglich
    > > beim auftauchen einer identischen Quelldatei diese nicht erneut zu
    > > speichern, sondern schlicht den bereits bekannten Keys beim neuen User
    > > einzutragen und die Datei beim User zu registrieren.
    >
    > Quelle bitte

    Die Doku ist die Quelle.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  15. Re: encryption vs de-duplication

    Autor LH 22.01.13 - 17:11

    zZz schrieb:
    --------------------------------------------------------------------------------
    > wenn man sich mit damit ein bisschen auseinandersetzt, wird man schnell
    > zweifel bekommen, dass das bei mega eingesetzt wird. eines der beiden
    > versprechen ist wohl falsch, mega verspricht laut docs aber sowohl
    > verschlüsselung als auch de-duplication. beim hochladen deutet nichts auf
    > das hashen einer datei hin, da wäre selbst bei einer vcd eine deutliche
    > verzögerung vor beginn des uploads spürbar.

    Bei einer anderen Seite (Link leider nicht mehr zur Hand :/ ) wurde vermutet das es durchaus ein Hash ist, dieser dient auch als Schlüssel.

    Das wäre logisch, denn damit würde jeder Upload immer den gleichen Key (basierend auf dem Hash) erzeugen. Dies würde immer zur identischen Verschlüsselung führen und damit ein depulizieren erlauben. Ohne eine Originaldatei oder wenigstens den Hash kann man jedoch trotz dessen nicht wissen, was in der Datei steckt.
    Diese Methode wird wohl auch bereits bei einigen Krypto-Filehostern eingesetzt. Allerdings kann ich nicht sagen ob das stimmt. Logisch erscheint es mir aber.

    Bezüglich des Hashens: Zumindest bei mir gibt es durchaus eine starke Verzögerung vor einem Upload großer Dateien, ein hashen scheint mir hier möglich.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  16. Re: encryption vs de-duplication

    Autor nightfire2xs 22.01.13 - 18:59

    Wenn man nicht weiss, wie Deduplizierung genau funktioniert, dann am besten den Nuhr machen.
    Datei-Deduplizierung ist was aus dem letzten Jahrtausend. Inzwischen macht man sowas auf Blockbasis und da ist es vollkommen egal, zu welcher Datei der Block gehört und ob die Datei selbst verschlüsselt ist oder nicht.
    Ein Block von Grösse X besteht aus 0 und 1 und wird sich, auf die gesamte Menge aller Blöcke des gesamten Dateisystems öfters wiederholen, somit speichert man den Block 1x und biegt dann die Pointer im Dateisystem so hin, dass die unterschiedlichsten Dateien eben auf diesen einen Block deuten.

    Problem solved... Dateien verschlüsselt, trotzdem dedupliziert.

    NF2XS

    Benutzer wird von Ihnen ignoriert. Anzeigen

  17. Re: encryption vs de-duplication

    Autor Epaminaidos 22.01.13 - 20:34

    zZz schrieb:
    --------------------------------------------------------------------------------
    > wen's interessiert, hier ein artikel zum secure data de-duplication:
    > www.ssrc.ucsc.edu

    Habe kurz das Abstract überflogen. Das genügt eigentlich, um zu verstehen, wie das konzeptionell gelöst wird.
    Gute Erklärung!

    Benutzer wird von Ihnen ignoriert. Anzeigen

  18. Re: encryption vs de-duplication

    Autor zZz 23.01.13 - 13:15

    LH schrieb:
    --------------------------------------------------------------------------------

    > Bezüglich des Hashens: Zumindest bei mir gibt es durchaus eine starke
    > Verzögerung vor einem Upload großer Dateien, ein hashen scheint mir hier
    > möglich.

    hast du's mal mit der zeit verglichen, die es dauert einen hash lokal zu errechnen? bei einem 8gb hd-film hat das ein paar minuten gedauert (sowohl md5, als auch sha-1). das einzige was im source der mega seite auf hashing hindeuten könnte, ist ein eingebundenes base64 javascript. zwar gab es eine kurze verzögerung vor beginn meines uploads (ca. 5-10sekunden), aber ich glaube nicht, dass sich in der zeit ein hash hätte berechnen lassen können - erst recht nicht per javascript.

    wie auch immer, machbar ist es verschlüsselung mit deduplikation zu kombinieren. ob mega das -wie behauptet- tut darf bezweifelt werden, aber das hat man bei einem wie herrn schmitz vielleicht auch erwarten können.

    Benutzer wird von Ihnen ignoriert. Anzeigen

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige

Haben wir etwas übersehen?

E-Mail an news@golem.de


Sony RX100 Mark III im Test: Klein, super, teuer
Sony RX100 Mark III im Test
Klein, super, teuer
  1. Custom ROM Sonys Bootloader einfacher zu entsperren
  2. Sony Xperia T3 kommt als Xperia Style für 350 Euro
  3. Auge als Vorbild Sony entwickelt gekrümmte Kamerasensoren

Oneplus One im Test: Unerreichbar gut
Oneplus One im Test
Unerreichbar gut
  1. Oneplus One Eigenes ROM mit Stock Android 4.4.4 vorgestellt
  2. Oneplus One-Update macht verkürzte Akkulaufzeit rückgängig
  3. Oneplus One könnte ab dem dritten Quartal vorbestellbar sein

Luftfahrt: Die Rückkehr der Überschallflieger
Luftfahrt
Die Rückkehr der Überschallflieger
  1. Verkehr FBI sorgt sich um autonome Autos als "tödliche Waffen"
  2. Steampunk High Tech trifft auf Dampfmaschine
  3. Aerovelo Eta Kanadier wollen mit 134-km/h-Fahrrad Weltrekord aufstellen

  1. iFixit: Amazon Fire Phone ist nur schlecht zu reparieren
    iFixit
    Amazon Fire Phone ist nur schlecht zu reparieren

    Die Profibastler von iFixit haben sich Amazons Fire Phone vorgenommen und das mit vier Infrarot-Sensoren und sechs Kameras bestückte Smartphone auseinandergenommen. Leicht zu reparieren ist es nicht, obwohl auf Standardschrauben gesetzt wurde.

  2. Entwicklerstudio: Crytek räumt finanzielle Probleme ein
    Entwicklerstudio
    Crytek räumt finanzielle Probleme ein

    Seit Wochen gibt es Gerüchte über nicht ausbezahlte Löhne, Massenkündigungen und Arbeitsniederlegungen. Jetzt äußert sich Crytek erstmals ausführlich und räumt gewisse Probleme ein - die jetzt aber behoben seien.

  3. M-net: Über 390 Kilometer Glasfaserkabel verlegt
    M-net
    Über 390 Kilometer Glasfaserkabel verlegt

    Ein Großprojekt zum Glasfaserausbau im hessischen Main-Kinzig-Kreis ist zur Hälfte abgeschlossen. Einige Unternehmen wurden von M-net auch mit FTTH-Anschlüssen ausgestattet, die bis zu 1 GBit/s und mehr ermöglichen.


  1. 19:06

  2. 18:54

  3. 18:05

  4. 16:19

  5. 16:08

  6. 16:04

  7. 15:48

  8. 15:21