Botan: serialisiert ECDH private Schlüssel

ich ein neues Schlüsselpaar erstellt mitBotan: serialisiert ECDH private Schlüssel

Botan::EC_Group ecgroup("brainpool512r1"); 
    Botan::ECDH_PrivateKey privKey(CBotanInitEx::RNG(), ecgroup);

Dem Versuch, es zu serialisieren PKCS # 8, gemäß Empfehlungen hier mit (im Vergleich zu RSA, das war schnell!) : https://botan.randombit.net/manual/pubkey.html#serializing-public-keys

datPubKey = Botan::X509::BER_encode(privKey); 
    txtPubKey = Botan::X509::PEM_encode(privKey); 

    datPrivKey = Botan::PKCS8::BER_encode(privKey, CBotanInitEx::RNG(), pwd); 
    txtPrivKey = Botan::PKCS8::PEM_encode(privKey, CBotanInitEx::RNG(), pwd);

ich erhalte eine Ausnahme:

PK algo ECDH has no defined OIDs

obwohl botan Initialisierung diese Zeile nicht passiert:

add_oid(config, "1.3.36.3.3.2.8.1.1.13", "brainpool512r1");

Wie serialisieren ich ein ECDH_PrivateKey?

Quelle

2016-08-30 peterchen

Die OID der Kurve unterscheidet sich von der OID des Schlüsseltyps. Warum * müssen * Sie einen ECDH-Schlüssel serialisieren? Static DH wird nicht so oft benutzt. Oder verwenden Sie es für ECDSA (anderer Algorithmus, gleicher Schlüsseltyp)? –

Raten Sie, ich muss nachlesen, was ich eigentlich tue - all die TLA..FLA macht mich verrückt. Ich komme von einem vorhandenen RSA öffentlichen Schlüssel "Beispiel", wo Schlüssel zum Austausch zwischen den Endpunkten serialisiert werden. – peterchen

RSA - Ihr vorheriger Algorithmus - wird für die Authentifizierung/Signierung verwendet, daher würde ich hier von ECDSA ausgehen. In diesem Fall sollten Sie ECDSA_PrivateKey anstelle von ECDH_PrivateKey verwenden. ECDSA kann zur Authentifizierung und zum Signieren verwendet werden, während ECDH zur Schlüsselübereinstimmung verwendet wird.

Die Diffie-Hellman-Schlüsselvereinbarung wird normalerweise ohne statische Schlüsselpaare durchgeführt (das E in ECDHE und DHE in den SSL/TLS-Chiffresuiten steht für ephemere). Es sollte also keinen Grund geben, private Schlüssel für die Schlüsselübereinstimmung zu serialisieren/speichern.

In gewissem Sinne müssen Sie vorausdenken und sich selbst in Frage stellen, wenn Sie überhaupt Serialisierung benötigen. Sie sollten Schlüssel - insbesondere private Schlüssel - nicht serialisieren, wenn die Serialisierung nicht benötigt wird. Stattdessen könnten Sie einfach den Objektgriff übergeben.

Quelle

2016-08-31 08:21:20

Danke! Ich habe gerade gemerkt, dass meine Frage ziemlich falsch ist - Die Absicht ist, eine geheime zufällige "Identität" auf einem vertrauenswürdigen Gerät zu erstellen und sie mit einem öffentlichen Schlüssel zu verschlüsseln, um sicher übertragen zu werden. Die Schlüssel sind also mindestens pro Geräteversion persistent. EC wäre wegen der geringeren Leistungsanforderungen an das Gerät gegenüber RSA vorzuziehen. Ich dachte jetzt, dass ECDH "nur" Schlüsselübereinstimmung ist, aber die Bibliotheken, die ich überprüfte, bieten ECDH (E) und ECDSA zum Signieren an - (Standard) EC öffentliche Schlüsselverschlüsselung scheint ECIES zu sein, aber keine der von mir überprüften Bibliotheken dieser Name). – peterchen

@peterchen Für ECIES ** ** scheint ** erforderlich, um den DH privaten Schlüssel des Empfängers zu speichern (wenn nur innerhalb einer Funktion der Bibliothek). Eine Suche nach Botan und ECIES ergab jedoch auch für mich null Ergebnisse (bevor Sie Ihren Kommentar geschrieben haben). Sie könnten möglicherweise ElGamal-Verschlüsselung auschecken, aber beachten Sie, dass RSA-Verschlüsselung - die den öffentlichen RSA-Schlüssel verwendet - * relativ effizient * ist, ist es die RSA-Entschlüsselung (und Schlüsselgenerierung natürlich), die viel Zeit in Anspruch nimmt. –

Botan: serialisiert ECDH private Schlüssel

Antwort

Verwandte Themen