AES256: iOS und PHP mögens irgendwie anders

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

  • AES256: iOS und PHP mögens irgendwie anders

    Hallo Leute,
    ich hab da ein AES256 Problem. Um das Problem kurz zu beschreiben:
    Folgende Szenario: PHP krypted-->sendet an App-->Xcode (App) will dekrypten. (key bei beiden natürlich identisch).
    Ohne Sonderzeichen gab Xcode mir nur 16 Bytes aus, also immer nur die ersten 16 Zeichen. Habe ich aber in PHP gekrypted und wieder dekrypted hab ich genau das gleiche String (also in voller Länge) natürlich wieder zurückbekommen (mit oder Sonderzeichen war egal). DAs gleiche gilt aber auch für mein Framework im App (Xcode). Auch da wenn ich ein String krypte und wieder dekrypte bekomme ich mein String (auch das waren Sonderzeichen egal). Obwohl Xcode was anderes krypted als wie PHP, können sie also beim dekrypten das gleiche String wiederherstellen, aber mit dem vom jeweils anderen nur 16 Bytes, wenn es keine Sonderzeichen beinhaltet, null wenn doch. Bin ziemlich stark am rätseln...

    Bevor mich da einer niederschlägt: Ich hab ecbstatt cbc genommen, aus dem ganz einfachen Grund weil die Daten nicht allzu wichtig sind, und um die Wahrheit zu sagen, ich nicht die Welt an Zeit habe/hatte um mich in Kryptografie einzuarbeiten.

    Hier nun etwas Code (PHP):

    PHP-Quellcode

    1. function mc_encrypt($str, $key = "12345678901234567890123456789012")
    2. {
    3. $arr = array("apple","boss","car");
    4. $teststr = (json_encode($arr,JSON_HEX_TAG|JSON_HEX_APOS|JSON_HEX_QUOT|JSON_HEX_AMP));
    5. $block = mcrypt_get_block_size('rijndael-128', 'ecb');
    6. $pad = $block - (strlen($str) % $block);
    7. $str .= str_repeat(chr($pad), $pad);
    8. $encoded = base64_encode(mcrypt_encrypt('rijndael-128', $key, $str, 'ecb'));
    9. $decoded = mc_decrypt($encoded, $key);
    10. return $encoded;
    11. }
    Alles anzeigen


    Hier aus'm Framework (Obj-C):

    Quellcode

    1. + (NSData*)decryptData:(NSData*)data key:(NSData*)key iv:(NSData*)iv;
    2. {
    3. NSData* result = nil;
    4. // setup key
    5. unsigned char cKey[FBENCRYPT_KEY_SIZE];
    6. bzero(cKey, sizeof(cKey));
    7. [key getBytes:cKey length:FBENCRYPT_KEY_SIZE];
    8. // setup iv
    9. char cIv[FBENCRYPT_BLOCK_SIZE];
    10. bzero(cIv, FBENCRYPT_BLOCK_SIZE);
    11. if (iv) {
    12. [iv getBytes:cIv length:FBENCRYPT_BLOCK_SIZE];
    13. }
    14. // setup output buffer
    15. size_t bufferSize = [data length] + FBENCRYPT_BLOCK_SIZE;
    16. void *buffer = malloc(bufferSize);
    17. // do decrypt
    18. size_t decryptedSize = 0;
    19. CCCryptorStatus cryptStatus = CCCrypt(kCCDecrypt,
    20. FBENCRYPT_ALGORITHM,
    21. kCCOptionPKCS7Padding,
    22. cKey,
    23. FBENCRYPT_KEY_SIZE,
    24. cIv,
    25. [data bytes],
    26. [data length],
    27. buffer,
    28. bufferSize,
    29. &decryptedSize);
    30. if (cryptStatus == kCCSuccess) {
    31. result = [NSData dataWithBytesNoCopy:buffer length:decryptedSize];
    32. } else {
    33. free(buffer);
    34. NSLog(@"[ERROR] failed to decrypt| CCCryptoStatus: %d", cryptStatus);
    35. }
    36. return result;
    37. }
    Alles anzeigen


    Falls jemand Erfahrung oder eine Idee hat, wär's super. 8)

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

  • Ein sehr ähnliches Thema wurde hier im Forum schon einmal diskutiert, such am besten mal (evtl mit Google und site:osxentwicklerforum.de)

    acidayi schrieb:

    Bevor mich da einer niederschlägt: Ich hab ecbstatt cbc genommen, aus dem ganz einfachen Grund weil die Daten nicht allzu wichtig sind, und um die Wahrheit zu sagen, ich nicht die Welt an Zeit habe/hatte um mich in Kryptografie einzuarbeiten.

    ECB is sehr sinnlos. Wenn Du keine Zeit hast, Dich auch nur annähernd in das Thema einzuarbeiten, warum will Du Dich dann damit überhaupt beschäftigen? Wenn Du ohnehin nur eine Lösung brauchst, nimm halt SSL. Ich habe auch nicht die Welt an Zeit, um Dir das jetzt genauer darzulegen :P
    C++
  • Problem ist gelöst. Falls jemand seine Daten zuverlässig verschlüsseln möchte, hier, so gehts (sogar mit CBC (aber ohne IV)):

    1. Nutze für die Ver- und Entschlüsselung in deiner APP DIESES FRAMEWORK (es gibt aber auch andere tolle alternativen).
    2. Nutze den Code unten und werde glücklich :D :D :D

    Den decrypter (uncypheraes128) hab ich zu dieser Sekunde noch nicht getestet, sollte aber ebenfalls einwandfrei funktionieren.

    PHP-Quellcode

    1. //PHP Code:
    2. function cypherAES128($plaintext, $key = "12345678901234567890123456789012")
    3. {
    4. $block = @mcrypt_get_block_size('rijndael-128', 'cbc');
    5. $pad = $block - (strlen($plaintext) % $block);
    6. $plaintext .= str_repeat(chr($pad), $pad);
    7. $ciphertext = @mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $plaintext, MCRYPT_MODE_CBC/*, $iv*/);
    8. $ciphertext = base64_encode($ciphertext);
    9. return $ciphertext;
    10. }
    11. function uncypherAES128($ciphertext, $key)
    12. {
    13. $ciphertext = base64_decode($ciphertext);
    14. $plaintext = @mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $key, $ciphertext, MCRYPT_MODE_CBC/*, $iv*/);
    15. $block = @mcrypt_get_block_size('rijndael-128', 'cbc');
    16. $pad = ord($str[($len = strlen($str)) - 1]);
    17. return substr($str, 0, strlen($str) - $pad);
    18. }
    Alles anzeigen


    Schöne Grüße 8)
  • zu behaupten ecb wäre sinnlos..hmm..seh ich nicht so obwohl ichs nicht nutze.
    Hier paar Infos mal: de.wikipedia.org/wiki/Blockver…0.93_Electronic_Code_Book

    Unabhängig davon hängts davon ab inwieweit man es nutzt. Man greift eben logischerweise nur auf das sicherste (je nach Betrachtung) weil die herangehensweise rein aus der Programmiereransicht bezogen auf den Aufwand, identisch ist. Zumindest in PHP.
  • ECB erlaubt mir in der Regel mit hoher Wahrscheinlichkeit einen echt zufälligen Bytestrom von einem ECB encrypted Bytestrome zu unterscheiden. Ich denke, dass darf man "sinnlos" nennen.
    Drei Klicks weiter schreibt auch Wikipedia
    In some senses, it doesn't provide serious message confidentiality, and it is not recommended for use in cryptographic protocols at all.


    Es ist ja nicht einmal mehr Aufwand, wie Du inzwischen festgestellt hast, CBC zu verwenden, von daher verstehe ich nicht, warum überhaupt immer wieder leute ECB in Betracht ziehen. Wahrscheinlich macht das irgendein PHP "Tut" so, was ganz oben bei Google erscheint, wenn man "PHP AES" such.
    C++
  • acidayi schrieb:

    zu behaupten ecb wäre sinnlos..hmm..seh ich nicht so obwohl ichs nicht nutze.
    Hier paar Infos mal: de.wikipedia.org/wiki/Blockver…0.93_Electronic_Code_Book

    Sinnlos ist imho der falsche Begriff. Schädlich ist deutlich passender. Ich denke Du bist nicht in der Lage das zu beurteilen. Daher zitiere ich hier auch mal aus der Wikipedia:

    Die Implementierung und Anwendung des unsicheren ECB-Modus erfolgt von Entwicklern meist aus Unkenntnis der Zusammenhänge und eröffnet so Sicherheitsschwachstellen, welche leicht vermeidbar wären.
    * Kann Spuren von Erdnüssen enthalten.

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

  • acidayi schrieb:

    Problem ist gelöst. Falls jemand seine Daten zuverlässig verschlüsseln möchte, hier, so gehts (sogar mit CBC (aber ohne IV)):

    Au weia! Da rate ich gleich davon ab, denn "If CBC mode is selected (...) and no IV is present, a NULL (all zeroes) IV will be used.". (Zitat man-Page) *Applaus*

    P.S.: Der Vollständigkeit wegen noch ein Zitat der Wikipedia für Dich: "A basic requirement is uniqueness, which means that no IV may be reused under the same key."

    2. P.S.: For block ciphers, repeated IV values devolve the encryption scheme into electronic codebook mode....
    * Kann Spuren von Erdnüssen enthalten.

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

  • NSObject schrieb:

    Sinnlos ist imho der falsche Begriff

    Sinnlos, weil man Zyklen und Strom verschwendet, für etwas, was man billiger haben könnte :P

    NSObject schrieb:

    Au weia! Da rate ich gleich davon ab, denn "If CBC mode is selected (...) and no IV is present, a NULL (all zeroes) IV will be used.". (Zitat man-Page) *Applaus*

    Es bringt hier wenig, weitere Hinweise zu geben, denk ich. Er hat ja nicht alle Welt der Zeit.....

    EDIT: Ansonsten wäre der Weg ja auch nicht weit gewesen, mal hier zu schauen, wie ich es geraten hatte: AES verschlüsselten String (PHP-seitig) via HTTP Request an iPhone App senden und entschlüsseln
    C++
  • Diese unscheinbare Überheblichkeit echt genial, aber gut.

    @zerm: du wirst es nicht glauben, ich hatte dein LInk bereits davor schon gelesen, und daraufhin erst einen neuen Eintrag gemacht. Dies resultiert wohl daraus dass es bei mir nicht geklappt hat.

    @nsobject: Was für ein genialer Einfall, mir klar zu machen dass ohne ein tatsächliches IV das ganze "geschwächt" ist. Toll! thumps up! Darauf wäre ich nie im Leben selbst gekommen. Ach ja, die Wiki LInks in diesem Thread sind wieder einmal mehr der Beweis, dass in Wikipedia zwar viel steht, aber wenns interessant wird man nicht wirklich weiß ob das richtig ist. Jetzt könnte ich konternt haufen andere Links hier reinstellen und sagen: "guck da stehts, alles okey", aber wofür :)
    Die interessante Frage wäre ganz einfach: Wenn ihr beide Spezis der Meinung seit dass das "gar nicht toll" ist- wieso steht es dann auf diversen Webseiten bzw. Büchern als eine Alternative. Was Alternative bedeutet muss ich ja jetzt nicht erklären.

    Anbei an alle anderen die sich nicht mit kryptografie beschäftigen wollen: Nimmt es nutzt es, es funktioniert wunderbar und wägt immer ab inwiefern und wie lange diese Daten die Ihr überträgt sicher sein müssen.
    Werden sehr sehr wichtige Daten über ein sehr langen Zeitraum immer wieder übertragen, solltet ihr versuchen ein IV (siehe oben mein Code) immer mit unterzubringen (und natürlich immer variabel). Die Prioriät eurer Daten ist hierbei sehr entscheidend.
    Und: nicht alles was Leute schreiben und behaupten, bedeutet dass Sie davon Ahnung haben.

    ps: bitte jetzt das ganze nicht ausweiten.
  • @ acidayi : Das ist diese ewige Diskussion und immer wieder trifft man die selben Typen.
    Wenn Du ein PHP-Problem hast, tue Dir nen Gefallen und frag woanders. Hier hat es einfach keinen Sinn. Sobald manche auch nur PHP riechen, kommen sie hervor gekrochen und bashen alles nieder. Widerlich.
    Und Code posten: Bitte nie nie nie nie NIE Code posten. Dann kommen sie wieder aus ihren Löchern gekrochen und bashen wieder auf Dich nieder. Auch wenn es gut gemeint ist, nimm aus diesem Forum mit was Du kannst aber hinterlass so wenig wie möglich.
    Das ist es einfach nicht wert.

    Hab schon ganz andere Foren steigen und wieder fallen sehen wegen ein paar Psychos die vom hohen Tron nicht mehr herab gesehen haben. Bäh. Pfui Teufel.

    (und damit wieder 2 auf meiner Ignore-Liste damit ich solch ne Darmentleerung nicht mehr lesen muss)
    _____________________________
    Alle Angaben ohne Gewähr :)

    On the internet you can be anything you want. It's strange that so many people choose to be stupid.


    Superbientem animus prosternet
  • Zumindest haben diese Standardantworten wie "Bäh, Du hast nen memleak" ein Ende dank ARC. Gott sei gedankt. Konnte die Meldung auch nicht mehr lesen.
    _____________________________
    Alle Angaben ohne Gewähr :)

    On the internet you can be anything you want. It's strange that so many people choose to be stupid.


    Superbientem animus prosternet
  • Es geht nicht um 'Ieh, der nutzt PHP!' oder 'Ieh, der postet Code!' sondern darum, auf gravierende Fehler hinzuweisen.

    Vor Allem im Punkt Verschlüsselung gilt nach wie vor:
    keine Verschlüsselung ist besser als schlechte Verschlüsselung.

    Wirft die App einen Hinweis 'Übrigens, was immer du eingibst wird im Klartext übertragen und kann von jedem Schwanz gelesen werden.' ist er User in der Verantwortung sinnvoll mit seinen Daten umzugehen und eigenmächtig herauszufiltern, was er übertragen möchte.
    Das gibt dann höchstens schlechte Bewertungen, weil man nicht bereit war Zeit in Verschlüsselungsverfahren zu investieren.

    Fühlt sich der User aber durch eine Verschlüsselung sicher, die idealerweise auch noch als solche angekündigt wird, und werden dann auf Grund der zu wenig investierten Zeit die verschlüsselten Daten geknackt, wird es für den Entwickler teuer.

    Auf nichts anderes wollten zerm und NSObject hinaus.
    Das obligatorische 'Nutz die Suche' hat übrigens nach wie vor seine Berechtigung, egal wie viele dagegen stänkern.
    Schließlich haben zu haargenau demselben Problem bereits Leute Hirnschmalz und Zeit investiert.
    Wenn du das alles schon gesehen und durchgearbeitet hast, warum weist du darauf dann nicht in deinem Post hin?

    Fragen richtig zu stellen wird offenbar immer unwichtiger.

    Alex:
    Ich bezweifle, dass deinetwegen oder deinesgleichen dieses Forum fallen wird.
    Mit deiner Einstellung ("nimm mit und hinterlass nix") hast du dich ja mal ausgesprochen disqualifiziert.

    Wenn du Hinweise wie 'Da ist ein MemLeak' als 'Gebashe' ansiehst wundert es mich nicht, dass jeder deine geposteten Codes auseinandernimmt.
    Da kann dann ja nix Sinnvolles bei rum kommen.

    Spannend: zum Thema Verschlüsselung selbst hast du in zwei Postings nicht im Entferntesten irgendetwas beigetragen.
    Geh gefälligst woanders trollen.
    (Spannend, wie viele User ihrem Signaturspruch entsprechen - nur nicht unbedingt so, wie sie es vor hatten.)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P