News Sicherheitsexperten kritisieren diverse Mängel bei Mega

[luschi7]

Wenn sich raus stellt das die Verschlüssellung so leicht auszuheblen ist, dass selbst die wahrer der Urheberrechte das problemlos können, wird die Ausrede das Mega nicht wissen kann was die Nutzer da hochladen nicht all zu lange greifen.

 

[AramisCortess]

@AramisCortess
"Wenn er sagt er arbeite dran und wird es beheben, dann glaube ich ihm das."

worauf beruht dein glaube?

mein glaube beruht auf meiner einschätzung dotcoms als macher.
Er haette nicht ein solches projekt angepackt nachdem sein erstes beendet wurde, wenn er nicht vor haette es richtig zu machen.
Meine einschätzung der lage

 

[Elcrian]

Ich verstehe ohnehin nicht, warum RSA und die Bindung an das Account-PW. Extrem unperformant und solange niemand anders vor hat, die Daten zu öffnen sehe ich keinen Vorteil in symmetrischer Kryptologie. AES o.Ä. lassen sich wohl auch via JS integrieren, das Passwort kann man beim Hochladen vergeben. Ist selbiges >256bit mächtig kann es gesalted werden (oder man erzwingt es).

 

[Lagerhaus_Jonny]

Ich sehe diesen angesprochenen "Mangel" nicht als Problematik an, sondern als einen weiteren Plus-Punkt in Richtung Vertrauen in die Sicherheit dieses Services. Denn der Aufschrei wäre entsprechend groß, wenn man bei einem verlorenen TrueCrypt Passwort einfach eine email an truecrypt.org schicken könnte, und die dann einem ein Passwort per Postkarte (Email) zuschicken würden.

Exakt!
In TrueCrypt kann ich auch sog. Keyfiles verwenden, beliebige Dateien mit beliebigen Inhalt die als "Passwort" für den Zugang zu meinen verschlüsselten Daten dienen.
Wenn nun auch nur 1 bit an dieser Datei geändert wird, erlange ich keinen Zugriff mehr auf meine Dateien.
Wo ist da der Aufschrei der Sicherheitsexperten?
Es kann doch nicht sein, das ich an sensible und verschlüsselten Daten nicht mehr drankomme, wenn ich mein Passwort nicht mehr weiß oder mein Keyfile aus versehen geändert wurde!!!

Was für ein Bullshit.
Die Sache mit Javascript sehe ich noch eher als eine Schwachstelle. Besonders hervorzuheben ist diese allerdings sicher nicht, weil viele andere Seiten ebenfalls JS verwenden. Wenn das Ganze über einen Browser funktionieren soll, ist die Auswahl an Möglichkeiten da auch sehr schmal.
Es soll ja auch einfach sein, für die User.

Und denjenige, der mal eben so einen 2048bit RSA Schlüssel errät, weil es teilweise vorhersagbare Zahlen im Random-Generator von Javascript gibt, solle bitte vortreten.
Bis man sich dafür entsprechende Tools gebastelt und ggf. die nötige Hardware zusammen hat, ist Weihnachten.

Ich denke Meinungen von Sicherheitsexperten gibt es bei so populären Projekten wie Mega sicherlich immer.
Die Frage die man sich hier stellen sollte ist allerdings, ob diese immer auch so krass pupliziert wird, wie in diesem Fall.
Das ist doch nur ein Versuch politisch gefärbter und von Lobbyismus geprägter Meinungsmacher die möglichen User abzuschrecken. Mehr ist das nicht.

 

[MTR]

Ein bisschen mehr Recherche was Deduplizierung ist, hätte dem Artikel keinen Abbruch getan. Da ich irgendwie das Gefühl habe, man möchte Mega unterstellen doch die Daten analysieren/einlesen/identifizieren zu können.

Deduplizierung findet auf Byte-Ebene statt. Heißt im Klartext, das System schneidet alle Daten in gleichgroße Stücke (Bit-Folgen) und löscht alle die doppelt sind, bis auf eine. Die eine Bit-Folge wird dann in alle anderen Daten als Referenz benutzt. Solange also die Bit-Folge um einiges größer als eine Referenz ist, kann man so einiges an Speicherplatz einsparen. Eine komplette DvD könnte so also nur aus Referenzen bestehen. Hier ein Wikipedia-Auszug:

Deduplizierungs-Systeme arbeiten anders als klassische Kompressionsverfahren, die nur wenige Vergleichsmuster benutzen, auf dem sogenannten "Blocklevel", d.h. die Dateien werden als in eine Anzahl Blöcke gleicher Größe (meist Zweierpotenzen) zerlegt betrachtet. Hierin liegt auch die Abgrenzung zum Single Instance Storage (SIS), das identische Dateien eliminieren soll (siehe auch inhaltsadressierte Speichersysteme, CAS). Eine wichtige Funktion der Deduplizierung ist das "Fingerprinting". Hier werden Dateien in Segmente unterschiedlichster Größe (Chunks) zerlegt. Auf Byte-Ebene wird dann analysiert, welche Segmente die höchste Wiederholrate bieten, um durch Referenzierung (Pointer) auf das Ursprungselement größtmögliche Datenreduzierungen zu bieten.

 

[cbacc32]

@MTR
Ich hab jetzt nicht so die Ahnung von Verschlüsselung, aber wenn jeder einen anderen private key hat, dann sind hochgeladene gleiche Daten am Server doch trotzdem unterschiedlich?!

 

[SeeD]

Trotzdem könnten ja theor. gesehen gleiche Teilstücke auftreten. Gerade bei den Datenmengen mit denen dort gearbeitet wird. Ob diese Teilstücke dann mit verschiedenen Passwörtern entschlüsselt auch unterschiedliche Datensätze am Ende ergeben, ist ja unerheblich.

 

[MTR]

@cbacc32
Wie SeeD schon richtig gesagt hat, verschlüsselt oder nicht, alle digitalen Daten sind am Ende nur Nullen und Einsen, und bei großen Datenmengen werden sich große Folgen von Nullen und Einsen oft wiederholen. Das nutzt man aus, um Platz zu sparen. Sagen wir eine Datei besteht aus der Folge 001011101001, dann kann man die Folge 01 schon viermal in der Datei durch eine Referenz ersetzen und damit den Speicherplatz sparen.

Die eingesetzten Algorithmen können aber viel viel größere Bit-Folgen erkennen und meist auch die Folgen, bei denen die Deduplizierung am meisten Speicherplatz spart. Wie schon in dem Wikipedia-Artikel gesagt, kann man den Speicherplatzverbrauch so um 1:12 (Wikipedia), bestenfalls, reduzieren. So werden aus knapp 50.000 GB nur noch 4166 GB. Dass das wirtschaftlich Sinn macht muss ich ja wohl niemandem erzählen.

 

[Jaytie]

Schon lustig, jeden Tag tauchen neue "erschütternde" Meldungen zum neuen Superhoster "Mega" auf. Das ganze wird mir schon wieder ein bisschen zu heftig gehypted ... naja Mega freut sich über gratis PR.

 

[unknown7]

Das ist der neue Plan der USA, bzw. generell das Vorgehen der Politik:

1 Phase: den Feind schlecht machen
2 Phase: für Zwischenfälle sorgen und in den Zeitungen verbreiten (z.B. jemanden trotz Verschlüsselung erwischen)
3 Phase: für Klagen sorgen, über die man Server Zugriff bekommt
4 Phase: Kim anklagen wegen Grund x
5 Phase: Dieses mal sein eigenes illegales Vorgehen besser vertuschen

Doch eines vergessen sie dabei immer:

Warum die Leute auf der Seite von Mega stehen und wie lange ihr tolles System noch bestehen kann, wenn die allgemeine Meinung über die Industrie jetzt schon sehr schlecht ist.

Generell sollte man sich an Gesetze halten... aber wie du gut erkannt hast machen das die Obersten Politiker nicht... demnach...
Ich glaub es ist verboten Straftaten zu beschönigen (falls es denn überhaupt welche waren/sind), daher sage ich nur...

schön Kim... weiter so... Ich nutze so etwas nicht, da es mir zu heiß ist... aber freut mich zu sehen, wie die Politischen Betrüger mal an der Nase herum geführt werden. Und des weiteren, denkt der ein oder andere vielleicht mal über Politik nach!

 

[cbacc32]

@SeeD/MTR
Achso ja, das stimmt natürlich...

 

[ice-breaker]

Und denjenige, der mal eben so einen 2048bit RSA Schlüssel errät, weil es teilweise vorhersagbare Zahlen im Random-Generator von Javascript gibt, solle bitte vortreten.

Teilweise hervorsehbar ist eine blanke Untertreibung. Es ist hinlänglich bekannt dass der JavaScript Random-Generator in den Browser-Implementierung wirklich grottig ist. Der reicht für kleine Memory-Spielchen und co, aber nicht für Kryptographie. In einigen Browsern stecken nur Kongruenzgeneratoren [1]. Bei Recherchen, die ich vor wenigen Jahren aus ähnlichen Gründen in dem Bereich gemacht habe, habe ich dann sogar herausgefunden, dass der Random-Generator in einigen Browsern nur zum Zeitpunkt des Startens des Browsers oder noch schlimmer zum Start des Page-Rendering der Seite anhand der Uhrzeit initialisiert wurde.
Math.random() ist weit weg von einigermaßen sicheren Zufallszahlen, nicht ohne Grund gibt es in HTML5 den Crypto-API Entwurf.


[1] Symmetric Cryptography in Javascript (Emily Stark, Michael Hamburg, Dan Boneh)

 

[Blutschlumpf]

Wie schon in dem Wikipedia-Artikel gesagt, kann man den Speicherplatzverbrauch so um 1:12 reduzieren. So werden aus knapp 50.000 GB nur noch 4166 GB. Dass das wirtschaftlich Sinn macht muss ich ja wohl niemandem erzählen.

Dein Post klingt nach Marketing-Märchenonkel, der Winzip bewirbt und seine Word-Dokumente als Referenz nennt.
1:12 wird aber nur bei unkomprimierten und unverschlüsselten Daten funktionieren. Sprich wenn du in der Firma die Dateifreigabe mit den Textdateien nimmst.
Wenn da einer seine Filme draufpackt, bringt das praktisch nichts, da die Daten hier ja angeblich verschlüsselt gelagert werden, werden die da auch nicht nennenswert Platz einsparen.

 

[MTR]

Ob eine Bit-Folge eine Datei oder eine schon verschlüsselte Datei repräsentiert ist doch völlig egal, wenn man einzig und alleine die Bit-Folge dedupliziert. Sofern meine verschlüsselte Datei bis auf das bit genau wieder bei mir ankommt, kann mein Decrypter doch die eigentliche Datei wiederherstellen? Also ich bin kein Experte, aber das klingt doch einfach logisch.
Man ändert doch rein gar nichts an der Datei selbst, egal ob unverschlüsselt oder verschlüsselt.

Aber wenn du mir erklären kannst, wo mein Denkfehler liegt, würde ich mich sehr darüber freuen.
Und ich hab auch keine Ahnung was du jetzt mit WinZip und Word-Dokumenten meinst?

Habe nur versucht zu erklären wie Deduplizierung funktioniert, das hat nichts mit "Marketing-Märchenonkel" zu tun. Wenn ich einen Fehler gemacht habe, dann klär mich und den Rest hier auf. Ich lerne gerne dazu.

 

[RangnaR]

Ein bisschen mehr Recherche was Deduplizierung ist, hätte dem Artikel keinen Abbruch getan. Da ich irgendwie das Gefühl habe, man möchte Mega unterstellen doch die Daten analysieren/einlesen/identifizieren zu können.

Deduplizierung findet auf Byte-Ebene statt. Heißt im Klartext, das System schneidet alle Daten in gleichgroße Stücke (Bit-Folgen) und löscht alle die doppelt sind, bis auf eine. Die eine Bit-Folge wird dann in alle anderen Daten als Referenz benutzt. Solange also die Bit-Folge um einiges größer als eine Referenz ist, kann man so einiges an Speicherplatz einsparen. Eine komplette DvD könnte so also nur aus Referenzen bestehen. Hier ein Wikipedia-Auszug:

Ebenfalls aus wikipedia zum Thema Deduplizierung:

Deduplizierung ist jedoch die derzeit effizienteste Art, Daten zu reduzieren, bei denen eine Mustererkennung möglich ist (unverschlüsselte Daten).

Hervorhebung durch mich.

Nehme ein x-beliebiges MP3 Stück, kopiere es auf den Rechner deines Freundes. Und nun laßt beide die gleiche Verschlüsselung mit verschiedenen Passwörtern laufen. Ein und dasselbe Stück müssen sich genau dann auf dem selben Byte unterscheiden, in dem Moment in der die Verschlüsselung brauchbar ist. Verschlüsselung ist dann gut, wenn die Zahlenabfolge nicht von einer Zufälligen Abfolge unterschieden werden kann. Selbst leere Blöcke die verschlüsselt sind, unterscheiden sich bei verschiedenen Passwörtern.

Wie soll "Deduplizierung" funktionieren, wenn die Daten ausssehen, als kämen diese aus dem Zufallsgenerator. Da ist der Versuch Duplikate zu finden bereits widersinnig. Deduplizierung ist ja an sich sinnvoll, funktioniert auch weiterhin nur, wenn die Daten unverschlüsselt bei MEGA vorliegen. Punkt.

 

[ice-breaker]

Die Deduplizierung, die MTR beschreibt, bezieht sich nicht auf die Anwendung von Mega. Also nicht das Mega sieht Encoded(SongA) = Encoded(SongA). Sondern wenn eine Datei verschlüsselt wird besteht sie auf tausenden Chunks - sagen wir mal 4KB (eventuell nimmt man für ein Filesystem da auch weniger). Wenn nun der Chunk 533 des verschlüsselten Urlaubsfotos von Nutzer A identisch zum Chunk 78965 von Nutzer B ist, der den neuesten Kinofilm verschlüsselt hat, müsste man nicht mehr die beiden Chunks jeweils doppelt auf der Festplatte speichern, sondern könnte den Chunk nur einmal speichern und beide verschlüsselte Dateien nutzen diesen.

Hier tritt natürlich das Problem auf, dass es bei 4KB Blockgrößen immernoch mehr als genug mögliche Permutationen gibt und beim Lesen nachher eventuell der Lesekopf der HDD sehr oft springen muss, wenn die Deduplizierung wirklich gut funktioniert hat. Aus diesem Grund ist das kein triviales Thema und wird nur von wenigen Dateisystemen genutzt. ZFS, das wohl aktuell mächtigste Dateisystem, in ganz seltenen Fällen kann da auch eine Speicherreduzierung von 10x erreicht werden, genauso gut aber auch kein Gewinn. Nach dem was man so liest werden aber i.R. schon so > 20% gespart, natürlich weit von den 1000% von MTR entfernt, aber diese sind auch möglich, es hängt von den Daten ab. Da die Bitfolgen von verschlüsselten Dateien ziemlich "zufällig" sind, würde ich da aber mit keinerlei Einsparung rechnen, da man ja auch den Vorteil verliert dass 2 gleiche Dateien nur einmal gespeichert werden
müssten (durch die Verschlüsselung sind sie ja versch.).




Ich nehme mal stark an, dass dieser Punkt mit der Deduplizierung einfach nicht stimmt und noch aus seinem alten Portal übernommen wurde.

 

[Smagjus]

Ich verstehe deine Ausführungen nicht, RangnaR.

Wieso sollte es einen Unterschied machen, ob die Datei verschlüsselt ist? Wir reden schließlich nicht von gleichen oder teilweise gleichen Dateien, sondern von verschiedenen Dateien auf Byteebene. Soviele Kombinationsmöglichkeiten gibt es nicht für Bytes. Es ist also bei dem Datenvolumen durchaus denkbar, dass man verschiedene Dateien mit identischen Bytefolgen findet.

 

[MTR]

@RangnaR
Okay okay, dann muss ich mir das nochmal genauer anschauen. Aber es klingt für mich unlogisch, da ich ja häufig auftretende Bit-Folgen referenziere. Also wenn man alle! Daten auf Mega als ByteStream betrachtet werden einige Bit-Folgen wie z.B 0110101100010100011110101010000111010011010 öfters vorkommen. Diese kann man dann durch ne Referenz ersetzen und Platz sparen. Es geht hier nicht um redundante Dateien, die man nur einmal Abspeichern will, sondern häufig auftretende ByteStreams.

Aber ich werde nochmal ein bisschen darüber lesen wenn ich mehr Zeit an der Hand habe und meinen Poste korrigieren/bearbeiten, falls es komplett falsch sein soll.

 

[ice-breaker]

Wie soll "Deduplizierung" funktionieren, wenn die Daten ausssehen, als kämen diese aus dem Zufallsgenerator. Da ist der Versuch Duplikate zu finden bereits widersinnig. Deduplizierung ist ja an sich sinnvoll, funktioniert auch weiterhin nur, wenn die Daten unverschlüsselt bei MEGA vorliegen. Punkt.

Nein, die Deduplizierung bei Mega wäre nicht sinnlos, weil die Daten verschlüsselt sind, sondern weil es durch die Verschlüsselung kaum noch gleiche Teile gibt (Prämisse der Aussage ist falsch).
Der Deduplizierung ist egal, ob die Daten verschlüsselt wurden oder nicht, aber wenn (wie korrekt von dir genannt) die Daten alle unterschiedlich aussehen - da scheinbar zufällig zusammengewürfelt - ist es für die Deduplizierung eben sehr schwierig gleiche Blocke zu finden. Es wird dann also im Endeffekt so aussehen, dass die Deduplizierung zwar aktiviert ist und läuft, aber kaum gleiche Blöcke findet.

 

[etheReal]

Teilweise hervorsehbar ist eine blanke Untertreibung. Es ist hinlänglich bekannt dass der JavaScript Random-Generator in den Browser-Implementierung wirklich grottig ist. Der reicht für kleine Memory-Spielchen und co, aber nicht für Kryptographie.

Man kann sich das ungefähr so vorstellen: http://xkcd.com/221/