C- bei Bedarf Speicher in der Funktion anlegen

C

Crymes

Guest
Ich bin gerade auf ein seltsames Problem in C gestoßen: Die ganzen if-Blöcke haben ja alle solche Klammern : {} .
Ich wollte eigentlich so etwas realisieren:
Code:
void Aes_xcryptBlock(void *key, unsigned short keylength, void *block, size_t size, void *iv)
{
	//Check if iv must be generated
	if(iv == NULL)
	{
		uint8_t i[16];
		Aes_generateIV(key, keylength, block, size, &i);
		iv = &i;
	}
Das Array wird aber nach dem if-Block wieder gelöscht, oder?
Kann man so etwas überhaupt in C ohne malloc realisieren?
 
Du könntest das Array vor der if-Bedingung anlegen. Aber ja klar, es wird nach dem { } scope wieder "gelöscht". Aber das ist beabsichtigt und gewollt, da es total logisch ist. Man braucht Dinge meist nur in einem bestimmten Scope.
 
Die Frage ist, was du erreichen willst. Willst du das Array nach dem if weiterbenutzen, aber nicht nach dem Ende des Funktionsaufrufs? Sollte das der Fall sein, mache es wie Crysis nerd sagt und deklariere das Array vor dem if-Block. Falls das Array auch nach dem Ende des erzeugenden Funktionsaufrufs weiterexistieren muss, wäre zumindest in diesem Fall möglicherweise eine Kopie das Mittel der Wahl - 16 Bytes passen in ein einzeles CPU-Register, und wenn der Compiler darauf hin optimiert, kostet das weitaus weniger Zeit (und Speicher) als dynamische Allokation mit malloc. Kommt aber natürlich darauf an, was du mit dem Array machen willst.
 
Also iv sind 16 byte die im ofb Modus ganz normal mit AES verschlüsselt werden.
Ich will am Anfang das iv Array erzeugen, wenn es das eben noch nicht gibt.
Davon soll aber der Rest der Funktion nichts mitbekommen.
Angenommen ich bin knausrig mit dem Speicher: entweder die 16 byte sind vor dem Funktionsaufruf hinter iv allokiert worden oder sie werden innerhalb der Funktion allokiert, für beides zusammen würde der Speicher nicht reichen.
Das funktionier dann nur mit malloc, oder ?
 
Ohne malloc könnte man es so machen:
Code:
//Check if iv must be generated
if(iv == NULL)
{
    static uint8_t i[16];
    Aes_generateIV(key, keylength, block, size, &i);
    iv = &i;
}
Static Variablen in einer Funktion bleiben über den Funktionsaufruf erhalten und theoretisch könntest du den Pointer auch außerhalb der Funktion nutzen. Besonders elegant ist das aber auch nicht, da die Funktion so nicht mehr von mehreren Threads gleichzeitig aufgerufen werden kann. Außerdem wird so direkt zum Start des Programms Speicher für die statische Variable reserviert.

Was spricht denn gegen die malloc Variante oder einfach zu fordern, dass iv nicht NULL sein darf? Bei jedem Block den IV neu zu berechnen ist auch nicht gerade effizient. Wobei ich am ehesten zu der Variante tendieren würde, bei der das Array normal vor dem if-Block angelegt wird. Die 16 Byte auf dem Stack sollten kein Problem sein oder für welche Platform entwickelst du dein Programm?
 
Also das Aes soll erstmal in eine Ansammlung von nützlichem Code, den ich vll. irgendwann mal brauchen könnte (soll mit auch beim besseren Verständnis von C helfen).
Ich glaube alloca wäre das gewesen was ich gesucht hab, ist aber nicht im C Standard :( .
Ich hab mich jetzt dazu entschieden, einen AES Context zu verwenden, den unfertigen Code könnt ihr euch hier ansehen ( aes.c und aes.h ) :
https://github.com/Crymes/CStructures

Edit: der IV soll später mal aus dem Hash der zu verschlüsselnden Daten und dem Key entstehen, sodass man den nicht auch noch weitergeben muss.

Also x = hash von Daten, y= Hash von Key, z= Hash von x und y und wird auf die 128 bit des iv zugeschnitten.
 
Edit: der IV soll später mal aus dem Hash der zu verschlüsselnden Daten und dem Key entstehen, sodass man den nicht auch noch weitergeben muss.
Wie soll das denn funktionieren? Beim Entschlüsseln kennt man ja noch nicht die entschlüsselten Daten und kann daher auch keinen Hash berechnen. Umgekehrt kennt man beim Verschlüsseln auch noch nicht den Hash der verschlüsselten Daten. Also eignen sich weder die verschlüsselten, noch die unverschlüsstelten Daten um einen IV zu generieren.
 
Du hast Recht, daran hatte ich garnicht gedacht :what::lol::hail:
Dann wird die Funktion generateIV eben doch den Zufallszahlengenerator anzapfen :(
 
Zurück