Dateien/Ordner verschlüsseln

  • Dateien/Ordner verschlüsseln

    Hallo,

    ich würde gerne als Feature anbieten, dass Dateien, die durch mein Programm erzeugt wurden, verschlüsselt bzw. passwortgeschützt auf der Festplatte abgelegt werden können.
    Mein erster Gedanke war über hdiutil verschlüsselte bzw. passwortgeschützte Images zu erzeugen, leider funktioniert das in der MAS Sandbox nicht.
    Es muss die Möglichkeit bestehen ganze Ordner zu sichern. Schön wäre es, wenn man die Dateien auch auf anderen Betriebssystemen als OS X öffnen kann, vorausgesetzt man kennt das Passwort.

    Ich habe schon im Internet gesucht, bin aber leider nicht fündig geworden. Mir fehlt zum einen grober Überblick über die Verfahren, die es gibt, zum anderen muss ich das Verfahren/Framework ja auch in den MAS bringen können (Lizenzierung, Sandbox).
    Ich habe gerade mal nach "zip password" gegoogelt und gleich der erste Eintrag ist eine Anleitung, wie man diese Dateien ohne Passwort entpacken kann, also genau das was ich suche ;)

    Über Hinweise und Tipps wäre ich dankbar.

    Viele Grüße

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von jopjip ()

  • jopjip schrieb:

    Mir fehlt zum einen grober Überblick über die Verfahren,
    Wenn Dir für sowas das Wissen/Erfahrung fehlt, wäre es vielleicht ein guter Gedanke, dass eben gerade nicht in Deiner Anwendung anzubieten. Kryptographie ist ein Thema da kann man sehr viel falsch machen und damit dem Benutzer eine Sicherheit vorgaukeln, die gar nicht existiert.

    Nur mal so als Gedankenanregung.

  • macmoonshine schrieb:

    Wenn du nur verhindern willst, dass mal eben ein Unbefugter in die Dateien reinschaut, kannst du auch passwortgeschützte ZIP-Dateien verwenden. Das ist zwar nicht so sonderlich sicher, dafür gibt's aber auf (fast) jeder Plattform ein Tool zum Auspacken.
    dazu hat er ja schon angemerkt dass bei google der erste treffer bereits ein tool zum auslesen ohne passwort gibt...

  • gandhi schrieb:

    jopjip schrieb:

    Mir fehlt zum einen grober Überblick über die Verfahren,
    Wenn Dir für sowas das Wissen/Erfahrung fehlt, wäre es vielleicht ein guter Gedanke, dass eben gerade nicht in Deiner Anwendung anzubieten. Kryptographie ist ein Thema da kann man sehr viel falsch machen und damit dem Benutzer eine Sicherheit vorgaukeln, die gar nicht existiert.
    Nur mal so als Gedankenanregung.
    Es ist noch kein Meister vom Himmel gefallen. Ich will ja auch kein eigenes Kryptoverfahren schreiben, sondern suche nach einem, das ich anwenden kann. Das man da immer noch viel falsch machen kann ist mir bewusst, aber AES auf ein NSData-Objekt anzuwenden ist kein Hexenwerk.

    macmoonshine schrieb:

    Hier gibt's ein Open-Source-Tool, dass auf AES aufsetzt und Clients für verschiedene Betriebssysteme hat. Aus den Sourcen für den OSX-Client kannst du dir vielleicht die benötigten Sachen ziehen.

    Danke für den Tipp schaue ich mir an. Ich finde folgendes Vorgehen aber eleganter: Ich zippe die Dateien, verschlüssele das Paket (bzw. ein NSData-Objekt) und mit meinem Programm, das diese Dateien erstellt, kann man die ganze dann wieder entschlüsseln. Die Plattformunabhängigkeit geht damit verloren.

    Gibt es Bedenken bei diesem Vorgehen?

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von jopjip ()

  • jopjip schrieb:

    Danke für den Tipp schaue ich mir an. Ich finde folgendes Vorgehen aber eleganter: Ich zippe die Dateien, verschlüssele das Paket (bzw. ein
    Zippen solltest / kannst du ja in jedem Fall. Das schließt ja mein Vorschlag nicht aus. Wenn du die ZIP-Datei aber so verpackst, wie es das Tool macht, dann bekommst du die Plattformunabhängigkeit geschenkt.
    „Meine Komplikation hatte eine Komplikation.“

  • jopjip schrieb:

    gandhi schrieb:

    jopjip schrieb:

    Mir fehlt zum einen grober Überblick über die Verfahren,
    Wenn Dir für sowas das Wissen/Erfahrung fehlt, wäre es vielleicht ein guter Gedanke, dass eben gerade nicht in Deiner Anwendung anzubieten. Kryptographie ist ein Thema da kann man sehr viel falsch machen und damit dem Benutzer eine Sicherheit vorgaukeln, die gar nicht existiert.Nur mal so als Gedankenanregung.
    Es ist noch kein Meister vom Himmel gefallen. Ich will ja auch kein eigenes Kryptoverfahren schreiben, sondern suche nach einem, das ich anwenden kann. Das man da immer noch viel falsch machen kann ist mir bewusst, aber AES auf ein NSData-Objekt anzuwenden ist kein Hexenwerk.
    Da muss ich Dir erstmal wiedersprechen. Kryptographie ist prinzipiell schwer. Tonnenschwer! Und Kryptographie verzeiht keine Fehler. Gerade nicht die vermeintlich "Kleinen". Und es gibt nur ganz wenige echte Experten. Selbst die wohlbezahlten Koryphäen bei Apple sind nicht vor essentiellen Fehlern gefeilt.
    Das Resultat: Diejenigen die Kryptographie benutzen (Programmierer und Anwender) wissen meist nicht was sie tun. Das führt dazu, dass sich ganz viele mit der Einstellung "Ich will ja auch kein eigenes Kryptoverfahren schreiben, sondern suche nach einem, das ich anwenden kann.", den Murks den Apple verzapft hat 1:1 in ihre Apps übernommen haben. Das ist die traurige Ausgangslage.

    Die gute Nachricht: Es gibt einen erfahrenen und bekannten Mathematiker, Kryptologen & Programmierer, der sich genau über das Problem (Programmierer != Kryptologen) den Kopf zerbrochen hat und eine Library entwickelt die dieses Problem angeht. Die libNaCl.
    Dort wurden die Grundpararmeter so gewählt, das sie per default sicher sind und den Programmierer nicht Entscheidungen abzuzwingen deren Auswirkungen er gar nicht einschätzen kann. Mit einem möglichst geradlinigem API. Bei Verzicht von Verfahren/Optionen die potentielle Unsicherheit bedeuten könnten. Und unter bewusstem Bruch mit der Kompatibilität zugunsten der Sicherheit. Davon gibt es auch gebrauchsfertige Ableger u.a. für Objective-C, Swift und fast jede andere Sprache. (LibSodium)
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von NSObject ()

  • @NSObject Ich weiß, dass es keine 100%ige Sicherheit gibt. Mein Gedanke war: Ich nutze etwas, das ein Konzern wie Apple entwickelt hat und fahre damit relativ sicher. Jetzt ist zum einen die Frage was denn Apple denn für ein Konzern ist (NSA, etc. pp.) und was 'relativ' in diesem Fall bedeutet.

    Insgesamt kann ich dir nur Recht geben und vielen Dank für den Hinweis. :)

    Edit: Ich sehe gerade, dass es das auch eine Javascript-Bibliothek gibt. Die Plattformunabhängigkeit könnte ich dann durch eine Website erreichen, die die Dateien lokal (ohne sie an den Server zu schicken) über Javascript entschlüsselt. Das funktioniert dann auf allen Plattformen mit entsprechendem Browser. Solange man diese Website über SSL ausliefert, er ist die Gefahr minimiert. So ganz sicher bin ich aber nicht, ob das wirklich eine gute Idee ist ?(

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von jopjip ()

  • jopjip schrieb:

    @NSObject Ich weiß, dass es keine 100%ige Sicherheit gibt. Mein Gedanke war: Ich nutze etwas, das ein Konzern wie Apple entwickelt hat und fahre damit relativ sicher.
    Die Strategie ist klar.

    Und hier ist die "Rote Pille": The Apple Idioten Vektor (IV)

    jopjip schrieb:

    Edit: Ich sehe gerade, dass es das auch eine Javascript-Bibliothek gibt. Die Plattformunabhängigkeit könnte ich dann durch eine Website erreichen, die die Dateien lokal (ohne sie an den Server zu schicken) über Javascript entschlüsselt. Das funktioniert dann auf allen Plattformen mit entsprechendem Browser. Solange man diese Website über SSL ausliefert, er ist die Gefahr minimiert. So ganz sicher bin ich aber nicht, ob das wirklich eine gute Idee ist ?(
    Ich kann Dir nicht ganz folgen. - Aber einen Webserver korrekt abzusichern und zu prüfen, ist bei allen "Crypto-im-Browser"-Geschichten existentielle Grundvoraussetzung. Und auch das ist nicht direkt einfach. TLS 1.2, PFS, HSTS, XSS, STS, CSP, PKP, etc.
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von NSObject ()

  • jopjip schrieb:

    Ich habe nur (zu) laut gedacht. Die Frage war auch eher, ob man so ein Entschlüsselungstool überhaupt über das www auf diese Weise verteilen sollte.
    Da streiten sich die Geister. Es ist prinzipiell nicht schlecht, weil vieles nur noch im Browser erledigt wird. - Aber meine Meinung (und da bin ich nicht allein): Nur im Notfall.

    jopjip schrieb:

    Dass SSL bereits Standard ist / sein sollte ist auch bei mir angekommen.
    Viele haben auch da eine falsche Vorstellung. SSL-Zertifikat installieren und fertig. - Falsch. Dann beginnt erst eigentliche die Arbeit. Bzw. damit wird man nie fertig. ^^
    * Kann Spuren von Erdnüssen enthalten.

  • gandhi schrieb:

    NSObject schrieb:

    Und hier ist die "Rote Pille": The Apple Idioten Vektor (IV)
    Der IV in den Apple-Beispielen ist mir da auch spontan eingefallen. Möchte nicht wissen, in wie vielen Anwendungen der Code genau so übernommen wurde.
    Ja. Da kann man ganz leicht erahnen, bei wie viel Prozent aller Anwendungen, die angepriesene Verschlüsselung nicht mehr als zu Marketing-Bullshit taugt.

    ...und willst Du mal weinen? Dann sieh mal in die aktuellen Header. - (TIP - Suchbegriff: zeroes)
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von NSObject ()

  • tsunamix schrieb:

    Nur, was macht man in der Praxis als durchschnittlich begabter Entwickler? Komplett auf Krypto verzichten und gleich ne Postkarte schicken? Scheint mir auch nicht so das Wahre zu sein.
    Erstmal: Doch. Man muss sich bewusst machen, dass man mit dem Einsatz von Kryptographie so etwas wie eine ungesicherte und scharfe Zeitbombe benutzt bzw. erschafft, die man nicht kontrollieren kann, und dennoch sichern muss.

    Wenn man das also aus zwingenden Umständen dennoch erforderlich ist, bleiben einem die Möglichkeiten:
    * Man holt Fachleute dazu, welche über die Fachkenntnisse verfügen und lässt diese den Part umsetzen und pflegen.
    * Wenn das nicht geht, dann sollte das Resultat der eigenen Bemühungen in einem externem Review Fachleuten vorlegen und überprüfen lassen. - Hinweis: Das tun auch die echten Fachleute.
    * Letzte Option: Man lernt die Grundkenntnisse, und nimmt die Lösung mit der vermutlich geringsten Angriffsfläche. (Imho: LibNaCl, libSodium) - Und zudem einen Public Review.

    Ansonsten bleibt bloß noch: Drauf verzichten.


    Wenn man soweit ist, dass man die Metapher mit der Bombe wirklich begriffen und verinnerlicht hat, weiss man auch, das man besser drauf verzichtet, als andere durch die eigene Unkenntnis zu gefährden. - Man hat das wissen, dass man weiss, dass man nichts weiss.


    P.S. Schöne Zitate gefunden:

    Frank Denis schrieb:

    ...the cipher is rarely the weakest link in an application using cryptography. No matter how secure a function is, its security can be totally destroyed by a tiny weakness in its implementation or by using it incorrectly. And an application using cryptography has to do way more than picking a decently secure set of primitives.
    ...
    Is encryption all it takes to provide integrity? Is the key length the best indicator of how secure a cipher is? How should random numbers be generated? What are these “modes”? Is opting for the fastest one, like ECB, the best way to go? Why not just use SHA1(secret | message) instead of a HMAC?
    ...
    Frequently, developers make arbitrary choices in response to the above questions, leading to security disasters. Worse, this happens most frequently when the intent was to achieve a very common operation.

    Drei Mal täglich aufsagen:

    Frank Denis schrieb:

    Cryptography is hard. Hard to design, hard to implement, hard to use, and hard to get right.
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von NSObject ()