Nicht gleiche Sitzungsschlüssel immer nach dem Decodierung Nutzlast unter RSA

Question

Ich bin nicht gleichen Sitzungsschlüssel nach der Codierung erhalten und Dekodieren es unter Funktionen, welche Krypto wird ++ Bibliothek:

CryptoPP::RSA::PrivateKey RSA_master_privKey; 
CryptoPP::RSA::PublicKey RSA_master_pubKey; 

std::string generate_Master_Keys() 
{ 
    std::string rsaParams; 
    try { 
     CryptoPP::InvertibleRSAFunction parameters; 
     RSA_master_privKey = CryptoPP::RSA::PrivateKey(parameters); 
     RSA_master_pubKey = CryptoPP::RSA::PublicKey(parameters); 
    } 
    catch (const CryptoPP::Exception& e) 
    { 
     std::cerr << e.what() << std::endl; 
     b_success = false; 
    } 
    return rsaParams; 
} 

PAES_KEY_WITH_IV create_session_key(void) 
{ 
    CryptoPP::AutoSeededX917RNG<CryptoPP::AES> rng; 
    PAES_KEY_WITH_IV aes_info = new AES_KEY_WITH_IV; 
    try { 
     aes_info->key.resize(CryptoPP::AES::DEFAULT_KEYLENGTH); 
     rng.GenerateBlock(aes_info->key, aes_info->key.size()); 
     aes_info->iv.resize(CryptoPP::AES::BLOCKSIZE); 
     rng.GenerateBlock(&aes_info->iv[0], aes_info->iv.size()); 
    } 
    catch (const CryptoPP::Exception& e) 
    { 
     std::cerr << e.what() << std::endl; 
     b_success = false; 
    } 
    return (aes_info); 
} 

std::string encrypt_session_key(PAES_KEY_WITH_IV pKey) 
{ 
    std::string ciphered; 
    CryptoPP::SecByteBlock block(pKey->key.size()); 
    try { 
     CryptoPP::RSAES< CryptoPP::OAEP<CryptoPP::SHA> >::Encryptor enc(RSA_master_pubKey); 
     enc.Encrypt(rng, pKey->key, pKey->key.size(), block); 
     ciphered.assign((char *)block.BytePtr(), 192); 
    } 
    catch (const CryptoPP::Exception& e) 
    { 
     std::cerr << e.what() << std::endl; 
     b_success = false; 
    } 
    return ciphered; 
} 

PAES_KEY_WITH_IV decrypt_session_key(std::string & ciphered) 
{ 
    CryptoPP::SecByteBlock rec(ciphered.size()); 
    CryptoPP::SecByteBlock block((const byte *)ciphered.data(), ciphered.size()); 
    PAES_KEY_WITH_IV pKey = new AES_KEY_WITH_IV; 
    try { 
     CryptoPP::RSAES< CryptoPP::OAEP<CryptoPP::SHA> >::Decryptor dec(RSA_master_privKey); 
     dec.Decrypt(rng, block, block.size(), rec); 

     pKey->key = rec; 
    } 
    catch (const CryptoPP::Exception& e) 
    { 
     std::cerr << e.what() << std::endl; 
     b_success = false; 
    } 
    return pKey; 
} 

Tailing von 192 Bytes nicht mit Original angepasst zu werden Sitzungsschlüssel Bytes.

Kann mir jemand dabei helfen?

Vielen Dank im Voraus.

Answer 1

Ich bin nicht immer gleiche Sitzungsschlüssel nach der Codierung und Decodierung es unter Funktionen

Ich glaube, Sie sind in der Nähe zu dem, was Sie brauchen. Es gibt auch eine Möglichkeit für Verbesserungen in der Art, wie Sie es tun. Ich zeige Ihnen den verbesserten Weg und Sie können ihn auch auf die bestehende Methode anwenden.

Der verbesserte Weg verwendet einfach FixedMaxPlaintextLength, CiphertextLength und einige Freunde, um Größen zu bestimmen. Es verwendet auch eine Technik von Integrated Encryption Schemes (IES).

Zuerst die rohen Seed-Bytes und nicht das {key, iv}-Paar transportieren. Wenn Sie dann das {key, iv}-Paar benötigen, leiten Sie die benötigten Bytes aus den Seed-Bytes ab. Ihre Ableitung sollte ein Verwendungskennzeichen und eine Versionsnummer enthalten.

Zweitens, die offene Frage: wie viele Bytes transportieren Sie als Seed-Bytes. Diese Antwort ist FixedMaxPlaintextLength() oder MaxPreimage() (ich erinnere mich nicht welche). Das ist die Größe des Klartexts, der unter dem Schema verschlüsselt werden kann, und hängt von Dingen wie der Modulgröße und dem Padding-Schema ab.

Eine Menge des Codes unten wird unter RSA Encryption Schemes und anderen Stellen im Crypto ++ Wiki diskutiert. Aber es ist nicht offensichtlich, dass Sie sie besuchen müssen, weil Sie immer noch einige der Techniken lernen.

---

Das folgende generiert einen zufälligen Seed und verschlüsselt es unter dem öffentlichen Schlüssel.

RSA_master_pubKey = RSA::PublicKey(parameters); 
RSAES< OAEP<SHA> >::Encryptor enc(RSA_master_pubKey); 
SecByteBlock seed(enc.FixedMaxPlaintextLength()); 

AutoSeededX917RNG<AES> rng; 
rng.GenerateBlock(seed, seed.size()); 

SecByteBlock block(enc.CiphertextLength(seed.size())));  
size_t req = enc.Encrypt(rng, seed, seed.size(), block); 
block.resize(req); 

// Transport block to peer as session seed 

---

Wenn der Peer den verschlüsselten Samens Block empfängt, sie müssen es entschlüsseln. Hier ist, wie es geht.

// Received from peer 
SecByteBlock block(...); 

RSAES< OAEP<SHA> >::Decryptor dec(RSA_master_privKey); 
size_t req = dec.MaxPlaintextLength(block.size()); 

SecByteBlock seed(req); 
DecodingResult result = dec.Decrypt(rng, block, block.size(), seed); 
seed.resize(result.isValidCoding ? result.messageLength : 0); 

Sie könnten sogar eine Ausnahme, wenn result.isValidCoding kehrt false geworfen:

DecodingResult result = dec.Decrypt(rng, block, block.size(), seed); 
if (!result.isValidCoding) 
    throw Exception(OTHER_ERROR, "Failed to decrypt seed bytes"); 

seed.resize(result.messageLength); 

---

Wenn Sie wollen mit AES verschlüsseln oder zu entschlüsseln, benötigen Sie einen Schlüssel, iv abzuleiten und möglicherweise eine hmac Schlüssel (authentifizieren Sie die Daten?).

// Random seed from above 
SecByteBlock seed; 

HKDF<SHA256> kdf; 
SecByteBlock aesKey(AES::DEFAULT_KEYLENGTH); 
SecByteBlock aesIV(AES::BLOCKSIZE); 

const byte aesLabel[] = "AES encryption key, version 1"; 
kdf.Derive(aesKey, aesKey.size(), seed, seed.size(), NULL, 0, aesLabel, COUNTOF(aesLabel)); 

const byte ivLabel[] = "AES initialization vector, version 1"; 
kdf.Derive(aesIV, aesIV.size(), seed, seed.size(), NULL, 0, ivLabel, COUNTOF(ivLabel)); 

IF Sie Ihre Daten authentifizieren, dann können Sie einen HMAC-Schlüssel mit dem folgenden ableiten.Aber im Allgemeinen, sollten Sie vielleicht eine Authenticated Encryption Betriebsart verwenden:

const byte hmacLabel[] = "HMAC authentication key, version 1"; 
kdf.Derive(hmacKey, hmacKey.size(), seed, seed.size(), NULL, 0, hmacLabel, COUNTOF(hmacLabel)); 

HKDF was added at 5.6.3 or 5.6.4. Wenn Sie es nicht haben, dann schnappen Sie sich hkdf.h von Wei Dai's GitHub (nur die Kopfzeile). Indem Sie von einem Basis-Seed mit eindeutigen Labels ableiten, verwenden Sie eine Technik, die als unabhängige Ableitung bezeichnet wird.

Sie fügen die Beschriftungen und die Versionsinformationen hinzu, um Lücken wie in Attacking and Repairing the WinZip Encryption Scheme beschrieben zu vermeiden. Auch die Verwendung der gesamten FixedMaxPlaintextLength Seite Schritte einige kryptografische Angriffe im Zusammenhang mit der Länge der Nachricht.

---

Sie möchten vielleicht auch Integrated Encryption Schemes (IES) betrachten. Wir haben den Key Encapsulation Mechanism (KEM) von IES im Wesentlichen aufgehoben. Es gibt einen Data Encapsulation Mechanism (DEM), der ebenfalls aufgehoben werden kann.

Wenn Sie das KEM und das DEM ausleihen möchten, können Sie das Schema auch verwenden. Dazu finden Sie im folgenden auf der Crypto ++ wiki:

• Elliptic Curve Integrated Encryption Scheme
• Discrete Logarithm Integrated Encryption Scheme

Wenn Sie eine der integrierten Verschlüsselungsschemas, dann ändern Sie die zugrunde liegende mathematische Problem. RSA ist Integer-Faktorisierung (IF), während IES ist Diffie-Hellman und Diskrete Logs (FF).

Die Verwendung eines integrierten Verschlüsselungssystems ist eine gute Wahl. Seine IND-CCA2, die eine sehr starke Vorstellung von Sicherheit ist. Ich glaube, es hat bessere Sicherheitseigenschaften als Ihr ursprüngliches Schema.