Frage zum RNCryptor

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Frage zum RNCryptor

    Hallo

    Ich möchte einen NSString sehr stark verschlüsseln. Dazu habe ich das Framework RNCryptor gefunden. Ich nutze zum testen das Beispiel von Github. Wenn ich den NSString crypte bekomme ich
    ein NSData. Das kann ich aber nicht in einer Datenbank speichern.

    Wenn ich versuche den NSData mit UTF8 zu konvertieren, ist die Ausgabe (null). Also scheint das NSData nicht im UTF8 encoded zu sein.
    Ich habe schon versucht mit anderen encodings den NSString zu bekommen. Leider bekomme ich kein Ergebnis. Die Ausgabe ist immer (null)

    Kann mir bitte jemand sagen wie ich den NSData vom RNCrytor in einen NSString bekomme?
    Oder gibt es bessere Verschlüsslungen die noch stärker Crypten als RNCryptor?

    Hier ist der Code den ich verwende:

    Quellcode

    1. NSString *secretPass = @"adv4F3zb4*!fdegr";
    2. NSString *plainText = @"Dies ist nur ein kleiner Test";
    3. NSData *data = [plainText dataUsingEncoding:NSUTF8StringEncoding];
    4. NSError *error;
    5. NSData *encryptedData = [RNEncryptor encryptData:data
    6. withSettings:kRNCryptorAES256Settings
    7. password:secretPass
    8. error:&error];
    9. NSString* cryptedString = [[NSString alloc] initWithData:encryptedData
    10. encoding:NSUTF8StringEncoding];
    11. NSLog(@"crypted string:%@",cryptedString);
    12. NSData *decryptedData = [RNDecryptor decryptData:encryptedData
    13. withPassword:secretPass
    14. error:&error];
    15. NSString* decryptedString = [[NSString alloc] initWithData:decryptedData
    16. encoding:NSUTF8StringEncoding];
    17. NSLog(@"decrypted string:%@",decryptedString);
    Alles anzeigen


    und hier die Ausgabe:

    2014-08-16 16:32:21.758 RNCrypt[411:70b] crypted string:(null)

    2014-08-16 16:32:21.800 RNCrypt[411:70b] decrypted string:Dies ist nur ein kleiner Test
  • Mal davon abgesehen, dass ich Dir das Apple Security Framework vorschlagen würde, musst Du die verschlüsselten Daten wohl base64 kodieren.
    Eine Verschlüsselung liefert keine String Objekte sondern erstmal "Bytes am Stück".
  • macmoonshine schrieb:


    BTW: Übrigens verwendet RNCryptor unter Anderem eine AES-256-Verschlüsselung. Die kannst Du auch mit Common-Crypto selber bauen.


    Richtig, aber: CC verlangt zumindest kryptographisches Basiswissen (und das scheint beim OP nicht vorhanden zu sein). Da kann man noch einiges falsch machen. Gerne wird z.B. der IV ignoriert. Oder die Frage wie aus dem Passwort des Benutzers der Schlüssel generiert wird. RNCryptor macht da schon vieles richtig, und damit kann man es nicht mehr falsch machen.

    schönen Gruß

    gandhi
  • gandhi schrieb:

    macmoonshine schrieb:


    BTW: Übrigens verwendet RNCryptor unter Anderem eine AES-256-Verschlüsselung. Die kannst Du auch mit Common-Crypto selber bauen.


    Richtig, aber: CC verlangt zumindest kryptographisches Basiswissen (und das scheint beim OP nicht vorhanden zu sein). Da kann man noch einiges falsch machen. Gerne wird z.B. der IV ignoriert. Oder die Frage wie aus dem Passwort des Benutzers der Schlüssel generiert wird. RNCryptor macht da schon vieles richtig, und damit kann man es nicht mehr falsch machen.

    schönen Gruß

    gandhi


    und von was träumst du nachts?

    wenn man sich damit nicht befasst kannst du sicher sein dass das passwort direkt als string im quellcode steht...
    irgendwelche fremden frameworks verwenden wenn man sicherheit will ist auch so eine sache... :(
  • gritsch schrieb:

    und von was träumst du nachts?

    Willst Du nicht wissen 8)

    ​irgendwelche fremden frameworks verwenden wenn man sicherheit will ist auch so eine sache..


    Wenn Du CC verwendest, verwendest Du auch ein fremdes Framework. Oder hast Du Dir die Implementierung von AES oder RSA in CC angesehen und auf potentielle Fehler überprüft? Wohl kaum...

    Es ist tausendmal besser ein bekanntes, fremdes Framework (*) zu verwenden als sich ohne das entsprechende Wissen etwas eigenes zu basteln. Und wie gesagt, RNCryptor ist in der Hinsicht nicht schlecht. Noch schlimmer ist es allerdings, wenn man anfängt eigene kryptographische Algorithmen zu verwenden. Da lauern die Sicherheitsgruben (Löcher sind's dann nicht mehr)...

    schönen Gruß

    gandhi

    (*) Wenn's viele Leute verwenden ist das Wahrscheinlichkeit für unentdeckte Sicherheitslöcher nunmal deutlich geringer
  • CC ist aber von apple. wenn du apple nicht traust dann bringt dir alles nix denn das system ist ja von ihnen also sitzen sie immer den längeren hebel.

    naja, was muss man da groß machen? 2 funktionen aufrufen. so weit sollte man sich doch informieren oder? und ob man RC4 oder AES verwendet ist in so einem fall ja komplett egal denn an den key kommt man immer (debugger attachen, breakpoint setzen, key ausgeben lassen. fertig).
  • gritsch schrieb:


    naja, was muss man da groß machen? 2 funktionen aufrufen. so weit sollte man sich doch informieren oder? und ob man RC4 oder AES verwendet ist in so einem fall ja komplett egal denn an den key kommt man immer (debugger attachen, breakpoint setzen, key ausgeben lassen. fertig).


    Wie schon erwähnt, auch da kann man eine Menge falsch machen: Zufallszahlen, Schlüsselerzeugung aus Passwort, Verwendung IV, Schlüssellängen. Wenn's jetzt ein Framework gibt, was sich da gut drum kümmert, warum das nicht verwenden? Es spricht m.E. nichts gegen die Verwendung von RNCryptor...

    Was noch dazukommt: Das API von RNCryptor ist einfacher als das von CommonCrypto (von OpenSSL mal ganz abgesehen, <X ). Und "einfaches API" heißt auch weniger Möglichkeiten Fehler zu machen.

    ciao

    gandhi
  • gandhi schrieb:

    gritsch schrieb:


    naja, was muss man da groß machen? 2 funktionen aufrufen. so weit sollte man sich doch informieren oder? und ob man RC4 oder AES verwendet ist in so einem fall ja komplett egal denn an den key kommt man immer (debugger attachen, breakpoint setzen, key ausgeben lassen. fertig).


    Wie schon erwähnt, auch da kann man eine Menge falsch machen: Zufallszahlen, Schlüsselerzeugung aus Passwort, Verwendung IV, Schlüssellängen. Wenn's jetzt ein Framework gibt, was sich da gut drum kümmert, warum das nicht verwenden? Es spricht m.E. nichts gegen die Verwendung von RNCryptor...

    Was noch dazukommt: Das API von RNCryptor ist einfacher als das von CommonCrypto (von OpenSSL mal ganz abgesehen, <X ). Und "einfaches API" heißt auch weniger Möglichkeiten Fehler zu machen.

    ciao

    gandhi


    wie schon gesagt: das ist alles komplett egal denn wenn man an die daten will schafft man das in einer minute. für alle anderen reicht eigentlich schon rot13 ;)
  • gritsch schrieb:

    wie schon gesagt: das ist alles komplett egal denn wenn man an die daten will schafft man das in einer minute.


    Was ist denn das für ein Argument? Nur weil's irgendjemand schaffen könnte, die Verschlüsselung zu knacken, soll ich darauf verzichten? Mit dem Argument kannste ja gleich alle Deine Daten an die NSA und/oder BND schicken. Erstens hast Du nix zu verbergen und zweitens können die's ja eh entschlüsseln...

    Du kennst außerdem das Szenario des OPs gar nicht und evtl. ergibt die AES-Verschlüsselung der Daten dort viel Sinn. Z.B. Benutzer gibt Passwort ein, Daten werden verschlüsselt und so an dann einen Mailaccount des Benutzers geschickt, der sie dann wieder mit seinem PW entschlüsseln kann. Oder was weiß ich.

    schönen Gruß

    gandhi
  • pmau schrieb:

    (Psst. Habt ihr gemerkt, dass der Fragesteller schon lange weg ist.)
    Was soll Eure Diskussion bringen?


    ich möchte darauf hinweisen dass ich es nicht schlau finde für jeden furz ein fremd-framework zu verwenden: was zu verschlüsseln ein framework, für sqlite ein framework für xml ein framework etc...

    allen schon RNCryptor verwendet 3 verschiedene lizenzen die man alle beachten muss. ich glaube nicht dass der fragesteller dessen pflichten kennt und die lizenzen auch im bundle mitzuliefern, in die dokumentation zu packen und falls (wie oft) gefordert auch an prominenter stelle im app selbst present sein muss (about-screen zb).

    also einfach einige minuten sich in die materie einarbeiten dann hat man a) was gelernt und b) sich viel ärger mit fremdem code, lizenzen etc gespart ;)
  • Hallo gritsch

    Du hast mich ein bisschen missverstanden.
    Der Fragesteller hatte schon nicht begriffen das seine Verschlüsselung keine Strings zurückliefert.
    Er hat das Framework gerade mal im Internet gefunden.

    Daraus eine Grundsatzdiskussion zu machen, welche oder ob man überhaupt ein Third-Party Framework verwenden sollte ist halt overkill.
    Man hat doch schon an den Zeilen im Code gesehen, dass er gerade mal versucht hat einen String mit einer konstanten Secret zu verschlüsseln...

    Über alles andere kann man natürlich diskutieren, aber das bringt bei diesem konkreten Thema recht wenig.
    Mehr wollte ich gar nicht anmerken.
  • pmau schrieb:

    Hallo gritsch

    Du hast mich ein bisschen missverstanden.
    Der Fragesteller hatte schon nicht begriffen das seine Verschlüsselung keine Strings zurückliefert.
    Er hat das Framework gerade mal im Internet gefunden.

    Daraus eine Grundsatzdiskussion zu machen, welche oder ob man überhaupt ein Third-Party Framework verwenden sollte ist halt overkill.
    Man hat doch schon an den Zeilen im Code gesehen, dass er gerade mal versucht hat einen String mit einer konstanten Secret zu verschlüsseln...

    Über alles andere kann man natürlich diskutieren, aber das bringt bei diesem konkreten Thema recht wenig.
    Mehr wollte ich gar nicht anmerken.


    aber ganz ehrlich: so jemand sollte NICHTS mit sicherheit/verschlüsselung zu tun haben. zuerst mal etwas studiom zum thema bitte. und nachher braucht man kein framework mehr da tuts ein funktionsaufruf oder eben 2 ;)
  • gandhi schrieb:

    Wie schon erwähnt, auch da kann man eine Menge falsch machen: Zufallszahlen, Schlüsselerzeugung aus Passwort, Verwendung IV, Schlüssellängen. Wenn's jetzt ein Framework gibt, was sich da gut drum kümmert, warum das nicht verwenden?


    Klar, kann man machen. Wenn es gute Standards von Experten gibt, sollte man sich daran halten.

    gandhi schrieb:

    Es spricht m.E. nichts gegen die Verwendung von RNCryptor...


    Doch: Der gute Junge will autorisierte Verschlüsselung machen, hat aber selber keine Ahnung, liest sich deshalb was im Internet zusammen (Colin Percival meint...) und bastelt sich aus eigentlich guten Algorithmen ein eigenes Format. Das ist der Standardfehler, und wie immer machen alle mit.

    Das Gericht enthält Biofleisch, Biosalz und Biosahne. Muss ja schmecken.

    Welches Sicherheitsniveau hat sein Format? Weißt Du nicht? Er auch nicht. Aber „sehr sicher“. Eben „genug“.

    Was stimmt: Wer diese Bibliothek verwendet, für den reicht es auch.

    gritsch schrieb:

    ich möchte darauf hinweisen dass ich es nicht schlau finde für jeden furz ein fremd-framework zu verwenden: was zu verschlüsseln ein framework, für sqlite ein framework für xml ein framework etc...


    Ist klar, Du kannst das alles viel besser. Wer braucht schon Frameworks für SQLite und XML? SQLite habe ich schnell selber implementiert und XML ist ja nur Text, da reicht printf und scanf.

    gritsch schrieb:

    also einfach einige minuten sich in die materie einarbeiten dann hat man a) was gelernt und b) sich viel ärger mit fremdem code, lizenzen etc gespart ;)


    Ist ein ein paar Minuten erledigt. Andere mögen sich fragen warum sie ein paar Jahre auf der Universität verbracht haben, aber es kann ja nicht jeder intelligent sein - einige brauchen eben etwas länger ;)
  • SteveJ schrieb:

    gandhi schrieb:

    Wie schon erwähnt, auch da kann man eine Menge falsch machen: Zufallszahlen, Schlüsselerzeugung aus Passwort, Verwendung IV, Schlüssellängen. Wenn's jetzt ein Framework gibt, was sich da gut drum kümmert, warum das nicht verwenden?


    Klar, kann man machen. Wenn es gute Standards von Experten gibt, sollte man sich daran halten.

    gandhi schrieb:

    Es spricht m.E. nichts gegen die Verwendung von RNCryptor...


    Doch: Der gute Junge will autorisierte Verschlüsselung machen, hat aber selber keine Ahnung, liest sich deshalb was im Internet zusammen (Colin Percival meint...) und bastelt sich aus eigentlich guten Algorithmen ein eigenes Format. Das ist der Standardfehler, und wie immer machen alle mit.

    Das Gericht enthält Biofleisch, Biosalz und Biosahne. Muss ja schmecken.

    Welches Sicherheitsniveau hat sein Format? Weißt Du nicht? Er auch nicht. Aber „sehr sicher“. Eben „genug“.

    Was stimmt: Wer diese Bibliothek verwendet, für den reicht es auch.

    gritsch schrieb:

    ich möchte darauf hinweisen dass ich es nicht schlau finde für jeden furz ein fremd-framework zu verwenden: was zu verschlüsseln ein framework, für sqlite ein framework für xml ein framework etc...


    Ist klar, Du kannst das alles viel besser. Wer braucht schon Frameworks für SQLite und XML? SQLite habe ich schnell selber implementiert und XML ist ja nur Text, da reicht printf und scanf.

    gritsch schrieb:

    also einfach einige minuten sich in die materie einarbeiten dann hat man a) was gelernt und b) sich viel ärger mit fremdem code, lizenzen etc gespart ;)


    Ist ein ein paar Minuten erledigt. Andere mögen sich fragen warum sie ein paar Jahre auf der Universität verbracht haben, aber es kann ja nicht jeder intelligent sein - einige brauchen eben etwas länger ;)


    du musst das nicht alles per hand machen. für SQLite gibts eine C-API und auch für xml gibts die perfekte lib bereits im system: libxml(2)
  • gritsch schrieb:

    du musst das nicht alles per hand machen. für SQLite gibts eine C-API und auch für xml gibts die perfekte lib bereits im system: libxml(2)


    Ach so. Und Deine SQLite-Library ist kein „Framework“ in Deinem Sinne? Falls nicht: RNCryptor ist auch nur eine statische Bibliothek...

    Und mit der „perfekten“ libxml kann man alles machen was man mit XML machen kann?

    Ich frage mich warum Apple so ein Gedöns mit GCD macht. Alles unnötiges Zeug, es gibt doch die perfekten Pthreads.

    Das Argument gegen RNCryptor ist nicht, dass es „noch eine Bibliothek“ ist. Das Argument ist, das jemand Einzelteile zusammengeschraubt hat ohne zu wissen was er tut. Was wahrscheinlich auch die meisten Leute machen würden wenn sie sich „einige Minuten in die Materie einarbeiteten“.
  • es ist nicht MEINE SQLite-library sondern jene die apple ins system packt und dass wir apple vertrauen haben wir ja anfangs schon definiert.
    wenn du irgendwas mit xml machen musst/willst das libxml nicht kann, dann solltest du dich wirklich mit der thematik beschäftigen und nicht irgend ein framework verwenden. genauso eben bei sicherheit.

    hab mir mal exemplarisch ein cocoa-framework für SQLite angeschaut und war schockiert.
    ich konnte mir die unterirdische qualität nur damit erklären dass solche frameworks nur von leuten gemacht werden die sich mit C nicht auskennen (sonst würden sie ja kein eigenens cocoa-framework brauchen). und genau die wursteln sich dann irgendwie durch und produzieren den größten müll.
    dass es in dem fall von RNCryptor nicht so ist glaube ich dir gerne - da scheint sich schon jemand gedanken gemacht zu haben und zu wissen was er tut - doch spreche ich hier GENERELL von dritt-frameworks...