MEGA - Pro und Contra

[misterunknown]

Moin,

ich habe mich heute bisschen über den neuen Dienst MEGA informiert. Die Meinungen der Internetcommunity könnten verschiedener nicht sein: von "schlecht, werde ich nie nutzen, schon aus Prinzip nicht" bis "geil, darauf hat die Welt gewartet" ist alles dabei.
Mich würde mal interessieren, was ihr dazu sagt, also Leute, von denen ich größtenteils weiß, dass sie Experten sind. Oder zumindest, dass sie nicht auf irgendeine aufgeschwatzte Meinung setzen.

Ein speziell interessanter Punkt ist die End-to-End-Verschlüsselung der Dateien. Meines Wissens funktioniert diese bei MEGA mit RSA-2048. Ich bin kein Kryptoexperte, aber meiner Meinung nach ist das ja eine sehr sichere Variante. Wird der Dienst damit ein ernst zu nehmender Konkurrent zu Google Drive oder Dropbox? Oder ist er das schon allein wegen des großen Speichers?

Fragen über Fragen... :)

Grüße Marco

[suit]

Wird der Dienst damit ein ernst zu nehmender Konkurrent zu Google Drive oder Dropbox? Oder ist er das schon allein wegen des großen Speichers?

RSA mit 2048-Bit-Schlüsseln sind sicher noch für die nächsten paar Jahre ausreichend - der Speicherplatz selbst ist nicht wirklich ein Argument, das haben ander auch.

Was an MEGA interessant ist, ist die Tatsache dass der Hoster nichts von den Daten weiß und de facto allos in der Hand des Users liegt.

Das was in der Offline-Welt schon lange funktioniert, sollte damit auch in der Online-Welt möglich sein: der Überbringer trägt keine Schuld. Die Post wird auch nicht dafür verantwortlich gemacht, wenn jemand eine Briefbombe verschickt - warum also sollte man einen ISP dafür verantworlich machen, wenn jemand das Internet oder einen File-Hoster zum Tauschen nicht lizenzierter Werke verwendet (was in der Praxis ja leider getan wird).

[suit]

Was an MEGA interessant ist, ist die Tatsache dass der Hoster nichts von den Daten weiß und de facto allos in der Hand des Users liegt.

Wie hier von Jens gepostet trifft das offenbar nicht zu - also aus der Traum.

[Jens Holzkämper]

Tach,

ich habe mich heute bisschen über den neuen Dienst MEGA informiert. Die Meinungen der Internetcommunity könnten verschiedener nicht sein: von "schlecht, werde ich nie nutzen, schon aus Prinzip nicht" bis "geil, darauf hat die Welt gewartet" ist alles dabei.
Mich würde mal interessieren, was ihr dazu sagt, also Leute, von denen ich größtenteils weiß, dass sie Experten sind. Oder zumindest, dass sie nicht auf irgendeine aufgeschwatzte Meinung setzen.

http://www.metronaut.de/2013/01/fragen-und-antworten-zu-mega-was-kann-der-neue-cloud-dienst/

Ich persönlich würde nichts anfassen, wo Kimble seine Finger drin hat.

Ein speziell interessanter Punkt ist die End-to-End-Verschlüsselung der Dateien. Meines Wissens funktioniert diese bei MEGA mit RSA-2048. Ich bin kein Kryptoexperte, aber meiner Meinung nach ist das ja eine sehr sichere Variante. Wird der Dienst damit ein ernst zu nehmender Konkurrent zu Google Drive oder Dropbox? Oder ist er das schon allein wegen des großen Speichers?

Laut http://arstechnica.com/business/2013/01/megabad-a-quick-look-at-the-state-of-megas-encryption/ kann Mega vermutlich auf die Daten zugreifen, die Daten wereden also nicht sicher abgelegt, aber das würde ich von einem Cloud-Service eh nicht erwarten: private Daten haben in der Cloud nichts verloren!

mfg
Woodfighter

[Jens Holzkämper]

Tach,

Laut http://arstechnica.com/business/2013/01/megabad-a-quick-look-at-the-state-of-megas-encryption/ kann Mega vermutlich auf die Daten zugreifen,

äh, man streiche beim lesen das vermutlich.

mfg
Woodfighter

[suit]

http://www.metronaut.de/2013/01/fragen-und-antworten-zu-mega-was-kann-der-neue-cloud-dienst/

Ich persönlich würde nichts anfassen, wo Kimble seine Finger drin hat.

Das ist wohl richtig.

Laut http://arstechnica.com/business/2013/01/megabad-a-quick-look-at-the-state-of-megas-encryption/ kann Mega vermutlich auf die Daten zugreifen, die Daten wereden also nicht sicher abgelegt,

Das ist hart und ein klares K.O.-Kriterium

aber das würde ich von einem Cloud-Service eh nicht erwarten: private Daten haben in der Cloud nichts verloren!

Ich würde nichtmal Unternehmensdaten auf einen Cloud Service auslagern.

[Jens Holzkämper]

Tach,

aber das würde ich von einem Cloud-Service eh nicht erwarten: private Daten haben in der Cloud nichts verloren!

Ich würde nichtmal Unternehmensdaten auf einen Cloud Service auslagern.

ach, ein false friend und dann auch noch in die falsche Richtung, hier war das englische private im Sinne von nicht öffentlich gemeint.

mfg
Woodfighter

[Jens Holzkämper]

Tach,

und die Cryptoanalyse beginnt: http://fail0verflow.com/blog/2013/megafail.html

mfg
Woodfighter

[Jost]

... aber der Typ ist echt ne verteufelt coole Socke.

Sicher mit ner menge krimineller Energie und auch ner deftigen Klatsche.

Aber ne coole Socke ist er trotzdem!

Und irgendwie verdammen ihn, so glaube ich, viele hier und woanders), die auch ein ganz klein bißchen neidisch sind.

Schriller Typ, bißchen eins an der Waffel, aber auch durchaus cool.

Mir lieber als so mancher "Rockstar" oder sonstige Luftpumpen.
Jost

[Jens Holzkämper]

Tach,

Und irgendwie verdammen ihn, so glaube ich, viele hier und woanders), die auch ein ganz klein bißchen neidisch sind.

Schriller Typ, bißchen eins an der Waffel, aber auch durchaus cool.

och, jemandem zu vertrauen, der schon in den 90ern seine "Kunden" verraten und deren Daten an die Staatsanwaltschaft und den berüchtigten Günni gegeben hat, um seinen Arsch zu retten, ist sicher eine gute Idee (http://www.gulli.com/news/12565-nachruf-guenter-freiherr-von-gravenreuth-2010-02-22).

mfg
Woodfighter

[Fred Furunkelstein 2013]

och, jemandem zu vertrauen, der schon in den 90ern seine "Kunden" verraten und deren Daten an die Staatsanwaltschaft und den berüchtigten Günni gegeben hat, um seinen Arsch zu retten, ist sicher eine gute Idee (http://www.gulli.com/news/12565-nachruf-guenter-freiherr-von-gravenreuth-2010-02-22).

Ich hätte scherste Bedenken, dass auch diese Server von einer Staatsanwaltschaft abgeschaltet werden.

Konsequenz daraus: Der Dienst ist wegen der Person des Betreibers unbrauchbar.

[micha2013]

Moin,

oh, 2010 ... ich hab's irgendwie gar nicht mitbekommen, dass der nicht mehr lebt.

[Der Martin]

Hallo,

oh, 2010 ... ich hab's irgendwie gar nicht mitbekommen, dass der [Gravenreuth] nicht mehr lebt.

dabei ging das damals in der Presse rauf und runter. Viele haben unverhohlen-befriedigt gegrinst, andere haben in pflichtbewusst gespielter Betroffenheit den virtuellen Blick gesenkt - aber letztendlich waren die meisten wohl doch der Ansicht, dass ausnahmsweise mal wieder Anstand und Gerechtigkeit einen Punktesieg erzielt hatten.

Ciao,
 Martin

[Bernd]

andere haben in pflichtbewusst gespielter Betroffenheit den virtuellen Blick gesenkt

Mal unabhängig vom Anlass.

Ich liebe solche Wortspielformulierungen :-D

Sollte einer in die Zitatesammlung schieben :-D

[Gunnar Bittersmann]

@@Bernd:

nuqneH

Sollte einer in die Zitatesammlung schieben :-D

Der war gut. :-(

Qapla'

[Christian Kruse]

Moin Jost,

... aber der Typ ist echt ne verteufelt coole Socke.

Egozentriker, Krimineller, Verräter. Ja, total cool.

LG,
 CK

[Jost]

Egozentriker, Krimineller, Verräter. Ja, total cool.

In einem Wort, er ist "Politiker"? ;-)

[Christian Kruse]

Moin Jost,

Egozentriker, Krimineller, Verräter. Ja, total cool.
In einem Wort, er ist "Politiker"? ;-)

Hehe, auffällige Gemeinsamkeiten, in der Tat ;-)

LG,
 CK

[molily]

Egozentriker, Krimineller, Verräter.

Wen oder was hat er verraten?

Mathias

[Fred Furunkelstein 2013]

Wen oder was hat er verraten?

http://www.gulli.com/news/12565-nachruf-guenter-freiherr-von-gravenreuth-2010-02-22

Zitat:

"Doch damit nicht genug. Kim Schmitz trat der zumeist britischen Amiga-Gruppe Loons bei, die zu diesem Zeitpunkt einige größere Spiele über mehrere Disketten illegal in Umlauf brachte. Die Amiga-Spiele waren letztlich auch der Schlüssel für Kim Schmitz, um sich Zugang zu rund einhundert illegalen Mailboxen in ganz Deutschland zu verschaffen. Es sprach sich schnell herum, dass er in der Szene angekommen war und die neuen illegalen Veröffentlichungen zeitnah hochladen konnte. Für viele Betreiber Grund genug, ihr Misstrauen über Bord zu werfen und ihn in ihr System zu lassen. Schmitz lud hoch & 'runter und machte Mitschnitte aller Dateien, die dort verfügbar waren. Mit den Captures ging er zu Gravenreuth, der Schmitz wiederum pro Bust bezahlt haben soll."

Wer DEM jetzt auch noch irgendwelche Daten anvertraut, der hat gewaltig einen an der Waffel. Zumal ja die Behauptung, die Daten würden verschlüsselt gespeichert, einige Haken hat.

[Jens Holzkämper]

Tach,

Egozentriker, Krimineller, Verräter.

Wen oder was hat er verraten?

http://pastebin.com/xdTdsgAe

mfg
Woodfighter

[molily]

http://pastebin.com/xdTdsgAe

Ich verstehe diesen Text nicht wirklich.

Er wusste, dass Carpathia durchsucht werden wird (?) und verschwieg es, weil er dachte, er sei nicht betroffen und komme fein raus, solange er Carpathia »opfert«? (Letztlich waren sie ja hinter ihm her.)

Okay, nichts anderes hätte ich von Kim erwartet. Er ist Geschäftsmann. Dass er seinen Geschäftspartner Carpathia über die Klippe springen lässt, solange sein Laden unangetastet bleibt: That’s Business.

Dass er die rechtliche Verfolgung von Konkurrenten wie NinjaVideo unterstützt, obwohl MegaUpload nicht legaler war: Ist das jetzt ein Spezifikum von Kim?

Überhaupt: Sich über Moral unter Ganoven zu streiten (»pirate code«, man hat sich gefälligst nicht zu verraten), finde ich ziemlich lächerlich. Alle Beteiligten wussten, was sie machen und wussten, dass sie rechtlich verfolgt werden. Keiner macht das aus einem anderen Grund als Eigennutz, keiner wird irgendwen anders schützen, nur weil der genauso kriminell ist.

Mathias

[Jens Holzkämper]

Tach,

Okay, nichts anderes hätte ich von Kim erwartet. Er ist Geschäftsmann. Dass er seinen Geschäftspartner Carpathia über die Klippe springen lässt, solange sein Laden unangetastet bleibt: That’s Business.

ok, andere Läden gehen halt vor Gericht, um geheime Durchsuchungsbeschlüsse anzufechten oder zumindest öffentlich machen zu können: https://en.wikipedia.org/wiki/Wikileaks_related_Twitter_subpoenas

Dass er die rechtliche Verfolgung von Konkurrenten wie NinjaVideo unterstützt, obwohl MegaUpload nicht legaler war: Ist das jetzt ein Spezifikum von Kim?

Nein, aber es ging hier auch nicht darum, dass kimble der einzige ist, der das tut.

Überhaupt: Sich über Moral unter Ganoven zu streiten (»pirate code«, man hat sich gefälligst nicht zu verraten), finde ich ziemlich lächerlich. Alle Beteiligten wussten, was sie machen und wussten, dass sie rechtlich verfolgt werden. Keiner macht das aus einem anderen Grund als Eigennutz, keiner wird irgendwen anders schützen, nur weil der genauso kriminell ist.

Wenn jemand, der sowas macht, sich aber hinterher versucht als Held für den kleinen Filesharer („We wrote 50,000 lines of code to empower people.“) hinzustellen, dann sollte man das doch durchaus angreifen können und Leute warnen.

mfg
Woodfighter

[molily]

Hallo,

ok, andere Läden gehen halt vor Gericht, um geheime Durchsuchungsbeschlüsse anzufechten oder zumindest öffentlich machen zu können: https://en.wikipedia.org/wiki/Wikileaks_related_Twitter_subpoenas

Wenn es ihnen nutzt, ja. Twitter würde sonst rechtlich in eine ungünstige Lage geraten und seinem Image schaden. Twitter will sich auf Seiten von Bürgerrechten und konkret auf Seiten einflussreicher Nutzer positionieren. Twitter profitiert enorm davon, dass soziale Bewegungen und Initiativen wie WikiLeaks das Medium nutzen. Hier ging es auch darum, einen Präzedenzfall zu schaffen, der Twitter gegen weitere solcher rechtlichen Auskünfte soweit es geht schützt. Nicht weil Twitter ein inhärentes Interesse daran hat, Whistleblowing zu verteidigen bzw. irgendwelchen Nutzern beizustehen, sondern damit es in solche Streitigkeiten nicht verwickelt wird, die der Nutzerbasis und damit ihm selbst schaden.

Anderen Unternehmen verhalten sich opportunistisch, weil sie entweder kein Pferd in diesem Rennen haben oder sogar davon profitieren, wenn es gegen bestimmte Nutzer geht.

Dass er die rechtliche Verfolgung von Konkurrenten wie NinjaVideo unterstützt, obwohl MegaUpload nicht legaler war: Ist das jetzt ein Spezifikum von Kim?

Nein, aber es ging hier auch nicht darum, dass kimble der einzige ist, der das tut.

Hier vielleicht nicht, aber der verlinkte Text unterscheidet stark zwischen den guten Copyright-Piraten, die keinen anderen Piraten an die Justiz ausliefern, und den »Verrätern«, die bloß ihre eigenen Interessen verfolgen.

Wenn jemand, der sowas macht, sich aber hinterher versucht als Held für den kleinen Filesharer („We wrote 50,000 lines of code to empower people.“) hinzustellen, dann sollte man das doch durchaus angreifen können und Leute warnen.

Sollte noch nicht klar sein, dass Kim nicht aus Menschenliebe handelt, sondern stets nur seinem Kontostand verpflichtet war – man kann nicht müde werden, darauf hinzuweisen.

Jede Geschäftsidee, sei sie harmlos oder zweifelhaft, legal oder rechtlich angreifbar, wird mit irgendeiner Moral vermarktet, die oftmals verlogen ist. Kim hat das nicht erfunden, schon gar nicht unter Filesharing-Diensten. The Pirate Bay etwa hat es viel effektiver geschafft, durch Urheberrechtsverletzungen Millionen zu verdienen und gleichzeitig als Freiheitskämpfer und ernstzunehmende Kritiker der bösen Unterhaltungsindustrie dazustehen. Es gibt sogar einen politischen Arm und Leute, die immer noch daran verdienen, obwohl die Gründer längst im Gefängnis sitzen.

Mathias

[ichbinich]

Hallo,

Zitat aus der Privacy Policy:

Your information we collect
[...]

• Any personal information included in data uploaded to our system including but not limited to registration information.

Noch Fragen?

vg ichbinich

[Christian Kruse]

Moin ichbinich,

Your information we collect
[...]

• Any personal information included in data uploaded to our system including but not limited to registration information.

Soviel zur End-to-end-Verschlüsselung…

LG,
 CK

[Siri]

Hallo,

wie würde das richtige Konzept dazu ausschauen (grob skizziert)? Man benötigt einen Schlüssel. Wo sollte der abgelegt werden. Sinnigerweise doch beim User, oder? Aber wie soll das gehen im Webumfeld und wenn jemand verschiedene Endgeräte benutzt?

Und wie wäre es dann möglich, jemand anderem z.B. eine Datei zugänglich zu machen, ohne ihm den Schlüssel zu verraten?

Viele Grüße
Siri

[Christian Kruse]

Moin Siri,

wie würde das richtige Konzept dazu ausschauen (grob skizziert)? Man benötigt einen Schlüssel. Wo sollte der abgelegt werden. Sinnigerweise doch beim User, oder? Aber wie soll das gehen im Webumfeld und wenn jemand verschiedene Endgeräte benutzt?

Es gibt da überlicherweise zwei Ansätze. Entweder, der Schlüssel ist ein Passwort oder eine Passphrase, die der User eingeben muss oder der Schlüssel wird verschlüsselt mit einem Passwort oder einer Passphrase des Users gespeichert in einer Datenbank abgelegt.

Und wie wäre es dann möglich, jemand anderem z.B. eine Datei zugänglich zu machen, ohne ihm den Schlüssel zu verraten?

Jetzt muss man umsteigen auf Private-Public-Key-Verfahren. Bei diesem Verschlüsselungsverfahren besitzt ein User ein Schlüsselpaar: einen privaten Schlüssel und einen öffentlichen Schlüssel. Der öffentliche Schlüssel ist bekannt, man lädt ihn einfach irgendwo im Internet hoch (für GPG gibt es dafür sogar Schlüsselserver). Der wird benutzt, um Nachrichten an dich zu verschlüsseln. Der private Schlüssel ist geheim und nur dir bekannt. Mit dem kannst du Dateien entschlüsseln, die mit deinem öffentlichen Schlüssel verschlüsselt wurden.

Man würde also die Datei, die du weitergeben willst, entschlüsseln, eine Kopie der Datei erstellen und mit dem Public Key des Users, dem man die Datei zukommen lassen will, verschlüsseln. Der User kann sie dann wieder entschlüsseln mit seinem Private Key.

Oft kannst du aber an dieser Funktionalität erkennen, dass der Betreiber lügt.

LG,
 CK

[Siri]

Hallo,

Es gibt da überlicherweise zwei Ansätze. Entweder, der Schlüssel ist ein Passwort oder eine Passphrase, die der User eingeben muss oder der Schlüssel wird verschlüsselt mit einem Passwort oder einer Passphrase des Users gespeichert in einer Datenbank abgelegt.

Wenn ich das richtig verstanden habe, ist das einer der Kritikansätze an Mega. Vergisst man das Passwort, sind die Daten nicht mehr zugänglich oder es wird beides in einer DB abgelegt, dann hat derjenige Zugriff, der die DB knackt, richtig?

Jetzt muss man umsteigen auf Private-Public-Key-Verfahren. Bei diesem Verschlüsselungsverfahren besitzt ein User ein Schlüsselpaar: einen privaten Schlüssel und einen öffentlichen Schlüssel. Der öffentliche Schlüssel ist bekannt, man lädt ihn einfach irgendwo im Internet hoch (für GPG gibt es dafür sogar Schlüsselserver). Der wird benutzt, um Nachrichten an dich zu verschlüsseln. Der private Schlüssel ist geheim und nur dir bekannt. Mit dem kannst du Dateien entschlüsseln, die mit deinem öffentlichen Schlüssel verschlüsselt wurden.

Man würde also die Datei, die du weitergeben willst, entschlüsseln, eine Kopie der Datei erstellen und mit dem Public Key des Users, dem man die Datei zukommen lassen will, verschlüsseln. Der User kann sie dann wieder entschlüsseln mit seinem Private Key.

Interessant! Das bedeuted aber auch, das beide -Sender und Empfänger- im gleichen Kontext stehen müssen (also z.B. Mega) oder anders ausgedrückt: Der Empfänger benötigt einen Mega_Account für seinen private key. Einfach einen Key generieren, den Link in eine Standard-Mail kopieren reichtdann wohl nicht...

Viele Grüße
Siri

[Christian Kruse]

Moin Siri,

Es gibt da überlicherweise zwei Ansätze. Entweder, der Schlüssel ist ein Passwort oder eine Passphrase, die der User eingeben muss oder der Schlüssel wird verschlüsselt mit einem Passwort oder einer Passphrase des Users gespeichert in einer Datenbank abgelegt.

Wenn ich das richtig verstanden habe, ist das einer der Kritikansätze an Mega. Vergisst man das Passwort, sind die Daten nicht mehr zugänglich […]

Naja, kommt drauf an. Wenn das bedeutet, dass der Schlüssel bei dir lokal liegt, wäre das ja das richtige und gute Vorgehen. Sicherheit ist halt nicht unbedingt bequem ;)

[…] oder es wird beides in einer DB abgelegt, dann hat derjenige Zugriff, der die DB knackt, richtig?

Naja, bei Mega läuft das etwas anders. Wenn wir die technischen Schwächen und den Idioten Kim mal beiseite lassen, haben sie das gar nicht so schlecht gemacht. Der Schlüssel mit deinem Passwort verschlüsselt bei denen abgelegt. Das ist nicht optimal, aber ich kann nachvollziehen, warum sie das machen: es muss ja auch für den DAU benutzbar bleiben. Zusätzlich zu deinem symmetrischen Schlüssel gibt es noch ein je 2048 Bit grosses RSA Schlüsselpaar für exakt das Verfahren, dass ich unten beschrieben habe. Der private Schlüssel wird scheinbar (so richtig weiss man es nicht, weil die Doku unklar ist) mit deinem symmetrischen Schlüssel verschlüsselt gespeichert.

Der reine Datenbank-Zugriff nützt dir also nichts, du benötigst immer noch das Passwort des Users.

Allerdings kommen hier zwei Sachen zum tragen:

1. Die Privacy Terms von Mega:

Your information we collect
[...]

• Any personal information included in data uploaded to our system including but not limited to registration information.

Das legt nahe, dass sie lügen.

2. Technische Schwächen in der Implementation. Schlechter Zufall, kaputtes Hashing, Unicode-Bugs, etc

Das legt nahe, dass die Verschlüsselung angreifbar ist.

Man sollte Mega also nicht trauen.

[… asymmetrische Verschlüsselung …]
Interessant! Das bedeuted aber auch, das beide -Sender und Empfänger- im gleichen Kontext stehen müssen (also z.B. Mega) oder anders ausgedrückt: Der Empfänger benötigt einen Mega_Account für seinen private key. Einfach einen Key generieren, den Link in eine Standard-Mail kopieren reichtdann wohl nicht...

Das ist so, ja.

LG,
 CK

[Siri]

Hallo,

vielen Dank für Deine Erläuterungen! Eine Frage noch!

[…] oder es wird beides in einer DB abgelegt, dann hat derjenige Zugriff, der die DB knackt, richtig?
...
Der reine Datenbank-Zugriff nützt dir also nichts, du benötigst immer noch das Passwort des Users.

Aber es muss doch eine Querverbindung zu den Schlüsselpaaren und dem User(password) geben?

Viele Grüße
Siri

[Christian Kruse]

Moin Siri,

Der reine Datenbank-Zugriff nützt dir also nichts, du benötigst immer noch das Passwort des Users.

Aber es muss doch eine Querverbindung zu den Schlüsselpaaren und dem User(password) geben?

Es ist bekannt, wem der Schlüssel gehört, ja. Aber das heisst ja nicht, dass du den Schlüssel benutzen kannst: er ist ja verschlüsselt mit deinem Passwort. Du kannst also nur in Verbindung mit deinem Passwort auf den unverschlüsselten Key zgreifen.

Und das Passwort liegt nicht im Klartext bei Mega vor, sondern nur als nicht reversibler Hash (das will ich zumindest hoffen – das wäre sonst ein echter Anfängerfehler).

LG,
 CK

[Jens Holzkämper]

Tach,

Und das Passwort liegt nicht im Klartext bei Mega vor, sondern nur als nicht reversibler Hash (das will ich zumindest hoffen – das wäre sonst ein echter Anfängerfehler).

das ist im Prinzip auch der nie auszuschließende Angriffsvektor für die Zukunft, wo man dem Anbieter vertrauen muss: Selbst wenn Mega alles korrekt implementiert hat und alles so funktioniert, wie CK beschreibt, können sie im Prinzip bei jedem Login, ohne dass es der User bemerken kann, statt dem Hash das Passwort direkt übertragen und haben dann Zugriff auf die Daten.

mfg
Woodfighter

[Siri]

Hallo,

ich hab unten stehendes Beispiel gefunden, habe aber das Gesamtkonzept nicht ganz verstanden...

1. erzeugt wird wohl ein KeyPair, das zwingend zusammengehört.
2. Mit dem publicKey wird verschlüsselt, mit dem privateKey entschlüsselt.
3. Wenn das Dokument verschlüsselt ist, kann es also nur noch mit dem privateKey entschlüsselt werden.

Wenn man jetzt sharen will, was nützt es dann, dem empfänger den publicKey zukommen zulassen? Damit kann er nichts anfangen. Ist der publicKey einaml verwendet, dann ist er (in unten stehendem Beispiel) doch nutzlos!
Under der privateKey sollte ja private bleiben...

Viele Grüße
Siri

  
public class EncryptionTest2 {  
  
    /**  
     * Zwischengespeichertes Schluesselpaar  
     */  
    private static KeyPair keyPair;  
  
    /**  
     * Erzeugt ein RSA Schluesselpaar  
     */  
    public static KeyPair getKeyPair() throws Exception {  
        if (keyPair == null) {  
            KeyPairGenerator kpg;  
            try {  
                kpg = KeyPairGenerator.getInstance("RSA");  
                kpg.initialize(2048);  
                keyPair = kpg.generateKeyPair();  
            } catch (NoSuchAlgorithmException e) {  
                throw new Exception(  "Fehler beim Erzeugen des Schluesselpaars: " + e.getMessage());  
            }  
        }  
  
        return keyPair;  
    }  
  
    /**  
     * Wrapped einen OutputStream in einen verschlüsselnden CipherOutputStream  
    */  
    public static OutputStream encryptOutputStream(OutputStream os)  throws Exception {  
        try {  
            // temporaeren AES Key erzeugen  
            KeyGenerator keygen = KeyGenerator.getInstance("AES");  
            SecureRandom random = new SecureRandom();  
            keygen.init(random);  
            SecretKey key = keygen.generateKey();  
  
            // mit RSA verschluesseln und an Empfaenger senden  
            Cipher cipher = Cipher.getInstance("RSA");  
            cipher.init(Cipher.WRAP_MODE, getKeyPair().getPublic());  
            byte[] encryptedAesKey = cipher.wrap(key);  
            os.write(encryptedAesKey);  
  
            // eigentliche Nachricht mit AES verschluesseln  
            cipher = Cipher.getInstance("AES");  
			cipher.init(Cipher.ENCRYPT_MODE, key);  
            os = new CipherOutputStream(os, cipher);  
        } catch (Exception e) {  
            throw new Exception("Fehler beim Verschluesseln: " + e.getMessage());  
        }  
  
        return os;  
    }  
  
    /**  
     * Liest den Inhalt einer Datei aus.  
     */  
    public static String readFile(String file) throws Exception {  
        InputStream is = new FileInputStream(file);  
        InputStreamReader isr = new InputStreamReader(is);  
        BufferedReader isrb = new BufferedReader(isr);  
        return isrb.readLine();  
    }  
  
    /**  
     * Wrapped einen InputStream in einen entschlüsselnden CipherInputStream  
     */  
    public static InputStream decryptInputStream(InputStream is)   throws Exception {  
        try {  
            // AES Key lesen  
            byte[] wrappedKey = new byte[256];  
            is.read(wrappedKey, 0, 256);  
  
            // AES Key mit RSA entschluesseln  
            Cipher cipher = Cipher.getInstance("RSA");  
            cipher.init(Cipher.UNWRAP_MODE, getKeyPair().getPrivate());  
            Key key = cipher.unwrap(wrappedKey, "AES", Cipher.SECRET_KEY);  
  
            // Daten mit AES entschluesseln  
            cipher = Cipher.getInstance("AES");  
            cipher.init(Cipher.DECRYPT_MODE, key);  
  
            is = new CipherInputStream(is, cipher);  
        } catch (Exception e) {  
            throw new Exception("Fehler beim Entschluesseln: " + e.getMessage());  
        }  
  
        return is;  
    }  
  
    /**  
     * Beispiel für Verschlüsselung mit CipherInputStream und CipherOutputStream  
     */  
    public static void main(String... args) {  
        try {  
  
            String file = "c:/temp/test.txt";  
            String plain = "Blubb Bla Blubb";  
            System.out.println("Klartext: " + plain);  
  
            // verschlüsseln  
            OutputStream os = new FileOutputStream(file);  
            os = encryptOutputStream(os);  
            OutputStreamWriter osw = new OutputStreamWriter(os);  
            osw.write(plain);  
            osw.close();  
  
            // verschlüsselten Text ausgeben  
            String secret = readFile(file);  
            System.out.println("verschluesselter Text: " + secret);  
  
            // entschlüsseln  
            InputStream is = new FileInputStream(file);  
            is = decryptInputStream(is);  
            InputStreamReader isr = new InputStreamReader(is);  
            BufferedReader isrb = new BufferedReader(isr);  
            String decryptedPlain = isrb.readLine();  
            isrb.close();  
            System.out.println("entschluesselter Text: " + decryptedPlain);  
  
        } catch (Exception e) {  
            System.err.println(e.getMessage());  
        }  
  
    }  
  
}

[Jens Holzkämper]

Tach,

Wenn man jetzt sharen will, was nützt es dann, dem empfänger den publicKey zukommen zulassen? Damit kann er nichts anfangen. Ist der publicKey einaml verwendet, dann ist er (in unten stehendem Beispiel) doch nutzlos!

man nutzt den Public Key des Empfängers um die Daten zu verschlüsseln (und potentiell den eigenen Private Key um zu signieren).

mfg
Woodfighter

[Siri]

Hallo,

man nutzt den Public Key des Empfängers um die Daten zu verschlüsseln (und potentiell den eigenen Private Key um zu signieren).

Das bedeute, für jeden User wird einamlig ein keyPair erzeugt und dieses wiederum mit der verschlüsselten ID des Users verknüpft, sonst ist ja eine Zuordnung bzw. das anfordern des publicKey des Empfängers nicht möglich, oder?

Viele Grüße
Siri

[Jens Holzkämper]

Tach,

Das bedeute, für jeden User wird einamlig ein keyPair erzeugt und dieses wiederum mit der verschlüsselten ID des Users verknüpft, sonst ist ja eine Zuordnung bzw. das anfordern des publicKey des Empfängers nicht möglich, oder?

was meinst du mit "verschlüsselte ID des Users"? Den Public Key wird man vermutlich einfach mit dem Benutzernamen verknüpft ablegen.

mfg
Woodfighter

[Siri]

Hallo,

was meinst du mit "verschlüsselte ID des Users"?

Falscher Gedanke... Mir schwirrt noch ein wenig der Kopf, weil ich mich noch nie mit dem Thema auseinandergesetzt habe und alles -was ich seit gestern dazu gelesen habe- sich noch nicht richtig "gesetzt" hat.

Viele Grüße
Siri