Ver- und Entschlüsselung mit OPENSSL in C

[Robert B. (rsb89)]

Hallo zusammen,

ich möchte einige versuche bezüglich Ver- und Entschlüsselung machen und 
benutze dafür den OPENSSL-Stack. Einige Sachen habe ich auch schon 
hinbekommen, aber es gibt so Ecken bei denen es hakt und ich hoffe, dass 
mir hier jemand helfen kann.

Ich versuche gerade mit der Funktion

void AES_cbc_encrypt(const unsigned char *in, unsigned char *out, size_t length, const AES_KEY *key, unsigned char *ivec, const int enc);

etwas zu verschlüsseln, nur ist mir die Bedeutung der letzten beiden 
Parameter nicht klar. Mit AES_encrypt() und AES_decrypt() läuft es 
bereits, aber welcher Modus wird da verwendet?

[Εrnst B. (ernst)]

"enc" ist ein Flag, AES_DECRYPT oder AES_ENCRYPT, dass sagt, was gemacht 
werden soll.

"ivec" ist der initialization vector. (16 Byte IIRC). Beim ersten Aufruf 
(beliebig, aber für En- und Decrypt gleich) initialisieren.

[Robert B. (rsb89)]

Danke für die schnelle Antwort!

Εrnst B✶ schrieb:
> "ivec" ist der initialization vector. (16 Byte IIRC). Beim ersten Aufruf
> (beliebig, aber für En- und Decrypt gleich) initialisieren.

Was wird denn initialisiert? Gebe ich da eine beliebige Zeichenfolge 
(mit länge des Schlüssels nehme ich an) an? So richtig steig ich da noch 
nicht hinter :-/

[ConverstQuestionsToAnswers (Gast)]

"CBC" ist der Cipher Block Chaining Modus.

In ihm wird der jeweils vorhergehende chiffrierte Block mit dem 
aktuellen Klartext XOder-Verknüpft und der enstehende Block 
chiffrieriert.

Dabei entsteht das Problem, womit denn der erster Block des Klartextes 
XOder-Verknüpft wird. Dafür nimmt man einen Initialisierungsvektor.
Im allgemeinen ist das eine zufällige Zahl oder ein Zeitstempel. Schau 
mal selbst wie das bei SSL (neuer Begriff "TLS") ist.

Ein Diagramm (nebst einer Erklärung) siehst Du hier: 
http://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode

[Robert B. (rsb89)]

Danke, das Diagramm ist super! Jetzt wird mir einiges klarer.

[Stefan R. (srand)]

Εrnst B✶ schrieb:
> Beim ersten Aufruf
> (beliebig, aber für En- und Decrypt gleich) initialisieren.

Nein. Zufällig, nicht beliebig.

Wenns nicht nur Spielerei ist, sondern was ernsthaftes, sollte der OP 
aber tunlichst die Finger von OpenSSL lassen und NaCL, Keyczar oder 
cryptlib verwenden.

[Robert B. (rsb89)]

Stefan Rand schrieb:
> Wenns nicht nur Spielerei ist, sondern was ernsthaftes, sollte der OP
> aber tunlichst die Finger von OpenSSL lassen und NaCL, Keyczar oder
> cryptlib verwenden.

Danke für den Tip, es ist aber nichts ernsthaftes. Aber vielleicht 
kannst du noch sagen warum man eher die anderen nehmen sollte?

[ConvertsQuestionsToAnswers (Gast)]

> ...warum man eher die anderen nehmen sollte?

Das lässt sich in Kürze nicht so leicht beantworten wenn man 
gleichzeitig die Begründungen dafür verständlich darstellen will. Ich 
selbst bin eigentlich nur in der Lage gewisse Grundlagen darzustellen.

Einfacher ist natürlich die Behauptung XYZ sei besser als ABC. Ob Du 
Dich dann auf den, der diese Behauptung aufstellt, verlassen kannst ist 
dann eine weitere Frage.

Eine allgemeine Antwort wird darauf hinauslaufen, das sich die 
Benutzbarkeit, vor allem aber die Sicherheit der Bibliothek selbst 
voneinander unterscheiden. Letzteres ist wesentlich, denn was nützt Dir 
die schönste Verschlüsselung am Netz, wenn der Code selbst angreifbar 
ist (sagen wir wegen Pufferüberläufen)?

Falls Du das ernsthaft selbst wissen willst, empfehle ich Dir die Namen 
der genannten Bibliotheken als Suchworte zu benutzen und auf den 
Projektseiten die Selbstdarstellungen zu lesen.


Es gibt dabei drei elementare Schwierigkeiten:

1. Es ist fast unvermeidbar, dass Du einigermaßen gut Englisch kannst 
oder willens bist es zu lernen. Das ist eine gute Gelegenheit dazu, wenn 
auch nicht die allerbeste da noch die zweite Schwierigkeit hinzukommt.

2. Du solltest schon weitreichendere Kenntnisse in Mathematik 
(insbesondere der Zahlentheorie und der Gruppen und Körper) haben oder 
willens sein, Dir sie anzueignen. Das ist der steinige Teil. Ein gut 
Teil der Mathematik in der Kryptografie hält sich weit jenseits der 
Schulmathematik auf, selbst der in der 13. Klasse des Gymnasiums 
gelehrten.

3. Deine Kenntnisse der Programmierung, insbesondere von Datenstrukturen 
und Algorithmen sollte deutlich über Anfängerniveau hinausgehen oder Du 
solltest willens sein sie zu erwerben. Eine Erfahrung von mehr als drei 
Jahren beim Schreiben von realen Anwendungen währe meiner Ansicht nach 
die Richtschnur.

Ich will damit sagen, das Du Dich entscheiden musst, ob Du in das Thema 
einsteigst oder nicht. Wenn ja, dann mache Dich auf eine längere Reise 
gefasst. Willst Du nur mal ein bisschen spielen aber keine echte 
Anwendung im Netz haben, dann reicht die Spielerei mit irgendeiner 
Bibliothek.

Du wirst HIER nur zufällig jemanden finden, der bereit ist, Dir eine 
komplette aber kurze und dennoch nachvollziehbaren Vergleich der 
Bibliotheken zu geben. Das würde in eine ziemliche Arbeit ausarten.


Ein Mittelweg wäre die suche nach einem Forum, das sich speziell mit 
Kryptographie beschäftigt. Ein Ansatz wäre mal die Suche in den yahoo- 
oder google-Gruppen.

[Stefan R. (srand)]

Robert B. schrieb:
> Stefan Rand schrieb:
>> Wenns nicht nur Spielerei ist, sondern was ernsthaftes, sollte der OP
>> aber tunlichst die Finger von OpenSSL lassen und NaCL, Keyczar oder
>> cryptlib verwenden.
>
> Danke für den Tip, es ist aber nichts ernsthaftes. Aber vielleicht
> kannst du noch sagen warum man eher die anderen nehmen sollte?

Weil du die Kryptoprimitiven aus Low-Level-Bibliotheken wie OpenSSL mit 
an Sicherheit grenzender Wahrscheinlichkeit nicht korrekt zu einem 
sicheren System zusammengebaut bekommst.

Ich übrigens auch nicht. Und auch sonst niemand, der hier mitliest.

Deswegen verwendet man als normaler Entwickler High-Level-Bibliotheken, 
die grob gesagt nur "encrypt" und "decrypt" anbieten, ohne daß du bei 
Auswahl des IV, Nonce, Verschlüsselungsmodus oder an drei Millionen 
anderen Stellen ein kleines Detail falsch machst, woraufhin dein 
"AES-256-gesichertes System" mittels einer Skriptsprache und dreißig 
Sekunden Rechenzeit vollständig gebrochen wird.

cryptlib von Peter Gutmann ist uralt und hat einen exzellenten Ruf.

Keyczar von Google hat den Charme, für Java und Python verfügbar zu 
sein, hatte kürzlich eine wirklich peinliche Timing-Attacke gegen sich, 
aber die Leute da sind trotzdem absolut kompetent.

Und NaCL von djb ist... halt djb. Ungewöhnliche Algorithmen, Liebe zum 
Detail. Bizarr, aber gut.

[Stefan R. (srand)]

Und falls jemand mal sehen will, was bei der Implementierung so in die 
Hose gehen kann, sollte er das hier mitmachen. Highly recommended!

http://www.matasano.com/articles/crypto-challenges/

[Stefan R. (srand)]

Stefan Rand schrieb:
> hatte kürzlich eine wirklich peinliche Timing-Attacke gegen sich

Die ist übrigens sehr erhellend und leicht zu begreifen.

Hand aufs Herz: wer hätte spontan gewußt, daß ein simpler Vergleich 
zweier Bytestrings so falsch gemacht werden kann, daß das System 
anschließend komplett gebrochen ist?

Und dummerweise ist diese katastrophal falsche Art genau die simple Art, 
die jeder zuerst programmieren würde:

    return self.Sign(msg) == sig_bytes

Und der Fix war dann...

    correctMac = self.Sign(msg)
    if len(correctMac) != len(sig_bytes):
        return False
    result = 0
    for x, y in zip(correctMac, sig_bytes):
        result |= ord(x) ^ ord(y)
    return result == 0

Autsch!

[Robert B. (rsb89)]

Danke Stefan, das leuchtet natürlich ein!

Ich hänge nun bei den publickey-Verfahren, und zwar bei RSA.

//seed Random-Number-Generator
  err = RAND_poll(); 

  rsa = RSA_new();
  bn = BN_new();
  BN_dec2bn(&bn, EXPONENT);

  err = RSA_generate_key_ex(rsa, KEYSIZE, bn, NULL);

  encdata = (char *)malloc(datasize+(KEYSIZE/8)+1);
  decdata = (char *)malloc(datasize+1);

  err = RSA_private_encrypt(datasize+1, (unsigned char *)plaindata, (unsigned char *)encdata, rsa, RSA_NO_PADDING);
  err = RSA_public_decrypt(datasize+(KEYSIZE/8)+1, (unsigned char *)encdata, (unsigned char *)decdata, rsa, RSA_NO_PADDING);

Die Encryption-(und Decryption-)Funktion geben beide -1 zurück. Was 
mache ich nur falsch? :-/

[Robert B. (rsb89)]

Habe es nun hinbekommen und die Lösung gleich posten! Muss erstmal alles 
sortieren ;)

[Robert B. (rsb89)]

Falls es jemandem hilft:

  rsa = RSA_new();
  bn = BN_new();
  BN_dec2bn(&bn, EXPONENT);

  err = RSA_generate_key_ex(rsa, KEYSIZE, bn, NULL);

  encdata = (char *)malloc(RSA_size(rsa));
  decdata = (char *)malloc(datasize+1);

  err = RSA_public_encrypt(strlen(plaindata), (unsigned char *)plaindata, (unsigned char *)encdata, rsa,  RSA_PKCS1_OAEP_PADDING);
  err = RSA_private_decrypt(KEYSIZE/8, (unsigned char *)encdata, (unsigned char *)decdata, rsa, RSA_PKCS1_OAEP_PADDING);

Der Fehler lag im letzten Parameter der encryption bzw decryption-Fkt.

[Robert B. (rsb89)]

Erstmal ein frohes und gesundes neues Jahr an alle hier im Forum!

Ich war mir ehrlich gesagt unsicher ob ich einen neuen Thread hierfür 
aufmachen soll, aber eigentlich passt mein Problem noch unter den Titel.

Also ich versuche mich nun mit "Elliptic Curve Diffie Hellman" bei 
OpenSSL, hänge aber auch hier wieder etwas.

Ich orientiere mich an folgendem Beispiel:

unsigned char *ecdh_low(size_t *secret_len)
{
  EC_KEY *key, *peerkey;
  int field_size;
  unsigned char *secret;

  /* Create an Elliptic Curve Key object and set it up to use the ANSI X9.62 Prime 256v1 curve */
  if(NULL == (key = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1))) handleErrors();

  /* Generate the private and public key */
  if(1 != EC_KEY_generate_key(key)) handleErrors();

  /* Get the peer's public key, and provide the peer with our public key -
   * how this is done will be specific to your circumstances */
  peerkey = get_peerkey_low(key);

  /* Calculate the size of the buffer for the shared secret */
  field_size = EC_GROUP_get_degree(EC_KEY_get0_group(key));
  *secret_len = (field_size+7)/8;

  /* Allocate the memory for the shared secret */
  if(NULL == (secret = OPENSSL_malloc(*secret_len))) handleErrors();

  /* Derive the shared secret */
  *secret_len = ECDH_compute_key(secret, *secret_len, EC_KEY_get0_public_key(peerkey),
            key, NULL);

  /* Clean up */
  EC_KEY_free(key);
  EC_KEY_free(peerkey);

  if(*secret_len <= 0)
  {
    OPENSSL_free(secret);
    return NULL;
  }

  return secret;
}

Bis zu der Stelle wo "peerkey" auftaucht ist mir die Sache klar. Aber 
was ist nun dieser Peerkey? Man möchte mit ECDH ja etwas erzeugen, 
woraus der Partner dann einen Schlüssel generieren kann. Dieses "etwas" 
ist, wenn ich das richtig verstanden habe die Variable "secret", die am 
ende zurück gegeben wird. "key" ist der nur mir bekannte Schlüssel. Aber 
was ist dann der Peerkey in diesem Beispiel?

[Hans Ulli K. (Gast)]

Robert B. schrieb:
> Bis zu der Stelle wo "peerkey" auftaucht ist mir die Sache klar. Aber
> was ist nun dieser Peerkey? Man möchte mit ECDH ja etwas erzeugen,
> woraus der Partner dann einen Schlüssel generieren kann. Dieses "etwas"
> ist, wenn ich das richtig verstanden habe die Variable "secret", die am
> ende zurück gegeben wird. "key" ist der nur mir bekannte Schlüssel. Aber
> was ist dann der Peerkey in diesem Beispiel?

Steht doch schon da

>   /* Get the peer's public key, and provide the peer with our public key
> -
>    * how this is done will be specific to your circumstances */
>   peerkey = get_peerkey_low(key);

Hier passiert der Schlüsseltausch.
Entweder Diffie Hellmann oder RSA.

peerkey ist der öffentliche Schlüssel von deinem Gegenüber und der will 
ja deinen öffentlichen Schlüsssel haben.

Der Rest ist im Web zu finden

[Robert B. (rsb89)]

Danke! Da stand ich ganz schön auf dem Schlauch...

[Hans Ulli K. (Gast)]

Hier mal der Crypto Talk vom letzten CCC Treffen in Hamburg.

www.youtube.com/watch?v=HJB1mYEZPPA

Beachte mal die Sache mit Lavabit aka Snoden Mailserver, so ab der 19 
Minute.

Versuche das mal zu verstehen. Mir ist danach die Kinnlade 
heruntergefallen. ;-)

Link vergessen