3. char* zu unsigned char*

char* zu unsigned char*

  • T

    hallo,

    bei meiner funktion (openssl-verschlüsselung) gibt es probleme bei der umwandlung von char* zu unsigned char*

    string CRYPT::encrypt(char *key, char *iv) {
 	EVP_CIPHER_CTX *ctx;

  	/* This uses the OpenSSL PRNG .  See Recipe  11.9 */
  	RAND_bytes(reinterpret_cast<unsigned char*>(key), EVP_MAX_KEY_LENGTH);
  	RAND_bytes(reinterpret_cast<unsigned char*>(iv), EVP_MAX_IV_LENGTH);
  	if (!(ctx = (EVP_CIPHER_CTX *)malloc(sizeof(EVP_CIPHER_CTX)))) exit(1);
  	EVP_CIPHER_CTX_init(ctx);
  	EVP_EncryptInit_ex(ctx, EVP_aes_128_cbc(), 0, reinterpret_cast<unsigned char*>(key), reinterpret_cast<unsigned char*>(iv));
}

    wie stell ich es denn geschickter an, ohne reinterpret_cast welches einen segmentation fault verursacht. 😕 THX

    0
  • P

    wenn du nicht gerade auf exakt dieses Interface fuer diene Methode angewiesen bist, wuerde ich ihr einfach auch unsigned char* parameter geben, so dass die ganzen casts nicht mehr noetig sind, bzw. nur einmalig vom Aufrufer.
    Die Methode arbeitet nunmal mit Daten, die "eigentlich" unsigned char* sein sollen, dann sollte sie auch solche verlangen. Die Aufgabe der Methode ist schliesslich nicht das Umwandeln sondern das Verarbeiten der Daten.

    0
  • T

    bleibt aber immer noch das problem der umwandlung... egal ob ich es nun innerhalb oder außerhalb der methode mache!

    0
  • C

    Die einfachste Lösung ist's da wohl, komplett mit unsigned char's zu arbeiten.

    PS: Übrigens ist nicht der Cast für deine Speicherfehler verantwortlich - die treten vermutlich in deiner Funktion auf, weil du über das Ende deiner Eingabedaten hinausliest (oder vor dem Aufruf nicht genug Platz angefordert hast).

    0
  • S

    HI,

    also ich muss hier mal ts0 mal beipflichten: Das ist in C (und wohl in C++ nicht anders) total beknackt !!!
    (jetzt kommt C-Frust aus meinem täglichen Umfeld)
    Da muss man evtl. irgendwo den Text verschlüsseln und schon muss das gesamte Programm mit "unsigned char" arbeiten ? Oder wild durch die Gegend cast-en ?
    IMO ist das ein Datentypproblem bei C, dass "char" zwar suggeriert (und auch fast immer dafür verwendet wird), zum Speichern von "Buchstaben" ("character") da zu sein, aber in Wirklichkeit eine Zahlvariable darstellt.
    Da hätte es den C-Designer gut angestanden, das zu trennen ... und am Besten "hierarchisch mit unsigned char" (oder besser "byte") zu koppeln.
    Bei Aufgaben, bei denen es nur darauf ankommt, eine Variable im Speicher aussieht (wie hier: Verschlüsseln), sollte das ohne Murren klappen - und ohne, dass ich mir dann andere Funktionen (wie str...()) "abschneide".

    Gruß,

    Simon2.

    0
Anmelden zum Antworten