Strategie um WAV-Dateien zu schützen? Ist das gut?

[philo]

Hallo,

ich suche einen möglichst wenig CPU intensiven Weg um WAV-Dateien nicht einfach dem Programm beilegen zu muessen.
Es muss nicht hyper sicher sein, mann soll einfach nur nicht die WAV Dateien einfach von der Festplatte abspielen koennen. Ich dachte mir die Dateien (einzelen BITS des Streams) (alle ca. 1 Sekunde lang) einfach zu negieren. Dass muesste ja schnell rueckgängig machbar sein.

Was denkt ihr?
Danke und Gruss
philo

 

[Koravel]

Ich wüsste nicht, was dagegen spricht, eine einfache Negation ist leicht zu machen, und auch relativ schnell (schätze ich jetzt, nie ausprobiert)
Du könntest natürlich auch einfach eine feste anzahl 0'en vor die Datei setzen, und beim Abspielen dann vorher überspringen, oder irre ich mich da?

 

[Bleiglanz]

warum nicht gleich mit einem festen Zufallswert XORen, sollte noch undurchschaubarer sein und ist wahrscheinlich auch nicht langsamer...

 

[stev.glasow]

Nur wenn ich es weiß ist der Schutz doch hin. Oder muss das jetzt nicht soo sicher sein?

 

[Bleiglanz]

von "Schutz" kannst du hier eh nicht reden

 

[stev.glasow]

Nagut ich dachte halt nur dran, weil ja die Rede von 'Schutzstrategieen' war

 

[Illuvatar]

warum nicht gleich mit einem festen Zufallswert XORen, sollte noch undurchschaubarer sein und ist wahrscheinlich auch nicht langsamer...

Wo wir schon dabei sind: bei einem festgelegten Wert anfangen, diesen hochzählen und immer mit diesem Wert XORen (das hab ich schonmal zum Spaß gemacht, geht relativ flott:

class SaveFileWriter extends FileWriter
    {
      private int xor = 60;
      /**
       *Neuer SaveFileWriter in die Datei filename
       */
      protected SaveFileWriter (String filename)
      throws IOException
      {
        super (new File (filename));
      }
      public void write (int c)
      throws IOException
      {
        xor++;
        if (xor == 71){
          xor = 60;
        }
        super.write (c ^ xor);
      }
    }

 

[0xdeadbeef]

Ich bitte zu bedenken, daß man Java wunderbar decompilieren kann. Dann liegt jeder noch so ausgefuchste (und nach kryptografischen Maßgabenvermutlich eh unsichere) Algorithmus offen. Selbst mit großen Kalibern wie RSA verhält sich das leider so: Der public key muß mitgeliefert werden, um die Daten zu entschlüsseln, also kann jeder mäßig begabte Programmierer die Dateien entschlüsseln.
Es ist also wohl zwecklos, allzuviel Energie in die Verschlüsselung der Dateien zu investieren.

 

[stev.glasow]

Den Key im Programm mit zu liefern scheint nie so viel Sinn zumachen, auch bei anderen Sprachen nicht.
Aber man könnte es ja so machen das der Nutzer sich den Key anfordern lassen kann, per Registierung über eine Seite oder so, dann könnten theoretisch nur registrierte Nutzer die Dateien lesen, is nur so ne Idee, weiß ja gar nicht was du überhaupt machen willst..
[edit]

Der public key muß mitgeliefert werden, um die Daten zu entschlüsseln, also kann jeder mäßig begabte Programmierer die Dateien entschlüsseln.

Wieso das? war RSA nicht so dass den public key jeder kennen darf und nur den Private Key nicht, denn nur wenn man beide hat kann man das auch entschlüsseln. Sprich der public key kann ruhig im Code stehen und den privaten läßt man anfordern.

 

[Beni]

Na gut, dann fordert der erste Benutzer mal einen Key an... und dann kann er diesen Key mit dem Progi weiterreichen, oder den Algorithmus angucken und die Dateien kurz entschlüsseln und weiterreichen...

 

[stev.glasow]

Ich würd sagen das hängt von der Situation ab, sprich was da geschützt werden soll - wenn es nämlich irgendwelche Benutzerspezifischendaten sind und der Sinn der Verschlüssung ist diese auch nur dem Nutzer zugänglich zu machen, kann er seinen Key (bzw die entschlüsselten Daten) ja ruhig weiter geben, dann will er es ja. Und wenn er es nicht will sind die Daten halt sicher und jeder ist zufrieden - außer der böse Bubi der an die Daten will

 

[Illuvatar]

Es ging ihm ja glaube ich auch nur darum, dass nicht Otto Normaluser nicht einfach bloß auf die Datei zu klicken braucht, und sie abspielen kann.

 

[stev.glasow]

Nagut, wollt ja nur wichtig tun und stand auch nix da :bae:

 

[0xdeadbeef]

Den Key im Programm mit zu liefern scheint nie so viel Sinn zumachen, auch bei anderen Sprachen nicht.

So funktioniert aber Authentifizierung. Geht auch nicht anders. Deshalb werden Public Keys ja auch immer schnell geknackt. Damit hat man aber immer noch nicht den Private Key, mit dem z.B. X-Box-Spiele signiert werden usw.
Nur geht es ja hier nicht um das Signieren/Authentifizieren, sondern um das Entschlüsseln und dazu reicht der Public Key natürlich-

Aber man könnte es ja so machen das der Nutzer sich den Key anfordern lassen kann, per Registierung über eine Seite oder so, dann könnten theoretisch nur registrierte Nutzer die Dateien lesen, is nur so ne Idee, weiß ja gar nicht was du überhaupt machen willst..

Auch zwecklos. Sobald der Schlüssel bekannt ist, kann man die Dateien entschlüsseln und beliebig verteilen.

Wieso das? war RSA nicht so dass den public key jeder kennen darf und nur den Private Key nicht, denn nur wenn man beide hat kann man das auch entschlüsseln. Sprich der public key kann ruhig im Code stehen und den privaten läßt man anfordern.

Nein! Mit dem Private Key verschlüsselt man, mit dem Public Key entschlüsselt man. Damit kann niemand die Dateien selber für diesen Public Key verschlüsseln, ohne den Private Key zu kennen. Aber jeder mit dem Public Key kann sie entschlüsseln.

Die Crux ist immer und bleibt immer, daß man die Daten ja auf dem lokalen Rechner entschlüsseln muß. Dazu muß sowohl der Algorithmus als auch der Schlüssel lokal bekannt sein und beide sind somit leicht angreifbar.
Sebst wenn man den Algorithmus und den Schlüssel auf einen Server auslagern würde, also weder Algorithmus noch Quellcode lokal liegen würden, müßten doch die entschlüsselten Daten lokal liegen. Dann könnte man einfach ein manipuliertes Programm aus dem dekompilierten Code erzeugen, daß die entschlüsselten Daten als Dateien abspeichert.

 

[abollm]

Ich bitte zu bedenken, daß man Java wunderbar decompilieren kann. Dann liegt jeder noch so ausgefuchste (und nach kryptografischen Maßgabenvermutlich eh unsichere) Algorithmus offen. Selbst mit großen Kalibern wie RSA verhält sich das leider so: Der public key muß mitgeliefert werden, um die Daten zu entschlüsseln, also kann jeder mäßig begabte Programmierer die Dateien entschlüsseln.
Es ist also wohl zwecklos, allzuviel Energie in die Verschlüsselung der Dateien zu investieren.

Das mag ja stimmen, aber ich denke es hängt auch immer von der Applikation (Einsatzzweck) und dem Verhältnis Nutzen zu Aufwand ab.

Wie oft habe ich in beruflicher Hinsicht mit kleineren Verschlüsselungen zu tun, bei denen sich bisher kein (0815-) Anwender die von dir skizzierte Mühe des Knackens gemacht hat, gleichwohl das mit ein wenig "Knoff-Hoff" leicht zu machen wäre.

Vordergründig geht es bei vielen einfchen Verschlüsselungen um die Abschreckung der typischen Anwender. Es geht sicherlich nicht darum ausgefuchste programmiererprobte Anwender oder gar Hacker abzuschrecken, zumal derartige Verschlüsselungen solchen Leuten wohl gerade einmal ein müdes Lächeln abringen würden.

Aber vielleicht einmal eine Frage zum Thema:

Ich knobel schon seit einiger Zeit an einem ein wenig komplexeren Verschlüsselungsprinzip für die folgende Aufgabe herum:

Es soll eine relativ einfache, datenbankgestützte Import-Applikation zusammen mit der Datendatei an Kunden ausgeliefert werden. Um Kosten zusparen und sich das Leben auch einfacher zu machen, soll sowohl die Applikation als auch die Datendatei elektronisch versandt werden können, damit der Endanwender den Import selbst ausführen kann.

Allerdings soll bzw. darf der Import nur zusammen mit der gelieferten Importdatei funktionieren. Bei jeder anderen Importdatei muss er den Import verweigern.

Wie würdet ihr das prinzipiell machen?

Ich hatte an einen MD5-Verschlüsselungscode der Datendatei gedacht, der zusammen mit einem Public Key-Code an den Endanwender gesandt wird. Das oben skizzierte grundsätzliche Problem löse ich damit aber auch nicht.

 

[stev.glasow]

OK das mit dem Public Key und Private Key hatte ich verwechelt, aber um Benutzerdaten(Daten die nicht vor dem Benutzer geschütz werden sondern den Benutzer schützen sollen) zu verschlüsseln ist solch ein Verfahren gut. Dort reicht evtl. so gar ein Verfahren was nur einen Schlüssel nutzt. Oder habe ich was übersehen?

 

[stev.glasow]

Aber vielleicht einmal eine Frage zum Thema:

Ich knobel schon seit einiger Zeit an einem ein wenig komplexeren Verschlüsselungsprinzip für die folgende Aufgabe herum:

Es soll eine relativ einfache, datenbankgestützte Import-Applikation zusammen mit der Datendatei an Kunden ausgeliefert werden. Um Kosten zusparen und sich das Leben auch einfacher zu machen, soll sowohl die Applikation als auch die Datendatei elektronisch versandt werden können, damit der Endanwender den Import selbst ausführen kann.

Allerdings soll bzw. darf der Import nur zusammen mit der gelieferten Importdatei funktionieren. Bei jeder anderen Importdatei muss er den Import verweigern.

Wie würdet ihr das prinzipiell machen?

Ich hatte an einen MD5-Verschlüsselungscode der Datendatei gedacht, der zusammen mit einem Public Key-Code an den Endanwender gesandt wird. Das oben skizzierte grundsätzliche Problem löse ich damit aber auch nicht.

Wieso nicht? Bei jedem neuen Import gibt es einen neuen Key und fertig ist's. Ohne Key kein Import.