Abo
  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?

  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.

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

  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.

  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.

  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

  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

  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

  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.

  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.

  11. Re: encryption vs de-duplication

    Autor: Chatlog 22.01.13 - 10:49

    Blocklevel Deduplication.

    Dabei spielen Dateien, Dateiformate und Verschluesselungen keinerlei Rolle.

  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:
    https://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.

  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.

  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.

  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.

  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

  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!

  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.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. Robert Bosch GmbH, Leonberg
  2. Schaeffler Automotive Aftermarket GmbH & Co. KG, Langen
  3. A.M.P.E.R.E. Deutschland GmbH, Dietzenbach
  4. Hochschule Ostwestfalen-Lippe, Lemgo

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 7,99€
  2. 109,99€ mit Vorbesteller-Preisgarantie
  3. 23,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Creoqode 2048 im Test: Wir programmieren die größte portable Spielkonsole der Welt
Creoqode 2048 im Test
Wir programmieren die größte portable Spielkonsole der Welt
  1. Arduino 101 Intel stellt auch das letzte Bastler-Board ein
  2. 1Sheeld für Arduino angetestet Sensor-Platine hat keine Sensoren und liefert doch Daten
  3. Calliope Mini im Test Neuland lernt programmieren

Ikea Trådfri im Test: Drahtlos (und sicher) auf Schwedisch
Ikea Trådfri im Test
Drahtlos (und sicher) auf Schwedisch
  1. Die Woche im Video Kündigungen, Kernaussagen und KI-Fahrer
  2. Augmented Reality Ikea will mit iOS 11 Wohnungen virtuell einrichten
  3. Space10 Ikea-Forschungslab untersucht Umgang mit KI

Microsoft Surface Pro im Test: Dieses Tablet kann lange
Microsoft Surface Pro im Test
Dieses Tablet kann lange
  1. Microsoft Neues Surface Pro fährt sich ohne Grund selbst herunter
  2. iFixit-Teardown Surface Laptop ist fast nicht reparabel
  3. Surface Studio Microsofts Grafikerstation kommt nach Deutschland

  1. Chipping: Firma versieht Mitarbeiter mit Microchips
    Chipping
    Firma versieht Mitarbeiter mit Microchips

    Am 1. August ist Chipping-Party bei Three Square Market (32M). Das Unternehmen bietet allen Mitarbeitern an, sich einen Chip implantieren zu lassen, um Türen zu öffnen, sich am Rechner einzuloggen, in der Cafeteria einzukaufen und den Kopierer zu nutzen.

  2. Elektroautos: Bayern startet Förderprogramm für Ladesäulen
    Elektroautos
    Bayern startet Förderprogramm für Ladesäulen

    Bayern führt ein eigenes Förderprogramm für Ladesäulen ein, mit denen Elektrofahrzeuge abseits der eigenen Garage aufgeladen werden können. Bayerns Wirtschaftsministerin Ilse Aigner (CSU) spricht von geplanten 7.000 Säulen.

  3. Elektrorennserie: Mercedes Benz steigt in die Formel E ein
    Elektrorennserie
    Mercedes Benz steigt in die Formel E ein

    Mercedes-Benz nimmt ab 2019 an den Rennen der Formel E teil. Mit Siegen soll die Leistungsfähigkeit im elektromobilen Bereich demonstriert werden. Auch Technologietransfer ist dabei wichtig.


  1. 08:47

  2. 08:05

  3. 07:29

  4. 23:54

  5. 22:48

  6. 16:37

  7. 16:20

  8. 15:50