RSA Signature Size Mismatch

Question

Wie angegeben here, ist die Länge der Nachrichtensignatur gleich dem Modul des privaten Schlüssels, aka der öffentliche Schlüssel.

Ich implementiere ein System, das eine Nachricht signiert, und ich habe eine Größenabweichung, die ich nicht lösen kann. Ich verwende crypto++.

Hier ist der Code, die ich benutze:

/* Create RSA Keys */ 
RSA::PrivateKey privateKey; 
privateKey.GenerateRandomWithKeySize(prng, 3072); 
RSA::PublicKey publicKey(privateKey); 
cout << ">> RSA Keys generated"; 
    /* Key Size */ 
    string spki; 
    StringSink sSink(spki); 
    publicKey.Save(sSink); 
    cout <<" ("<< spki.size()<<" bytes)"<<endl; 

RSASSA_PKCS1v15_SHA_Signer signer(privateKey); 
size_t length = signer.MaxSignatureLength(); 
cout <<"MaxSignatureLength " <<length<<endl; 
    SecByteBlock signature(length); 

Und der Ausgang ist:

>> RSA Keys generated (420 bytes) 
>> ServerHello sent (436 bytes) 
    MaxSignatureLength 384 
    RSA Signature length 384 

Sollte nicht die MaxSignatureLength und die RSA Signature length 420 Bytes lang?

Ist das Problem mit dem Algorithmus, den ich verwende?

Answer 1

Sollte die MaxSignatureLength und die RSA Signature Länge nicht 420 Bytes lang sein?

Nein. Sie fragen nach einem Schlüssel mit 3072 Bits oder 384 Bytes. Das ist die Grenze für die Größe der Signatur.

Jedes Kryptosystem wird wahrscheinlich in diesem Bereich anders sein.

cout <<" ("<< spki.size()<<" bytes)"<<endl; 

Dies ist die Größe von {OID,n,e} mit dem ASN.1 Framing oder Overhead. Sehen Sie Ihre vorherige Frage Sending PublicKey within packet payload für wie es aussieht (insbesondere die Ausgabe des Befehls dumpasn1 rsa-public.der).

cout <<"MaxSignatureLength " <<length<<endl; 

Dies ist n - 1 für RSA, wenn ich mich richtig erinnere.

Ist das Problem mit dem Algorithmus, den ich verwende?

Nein, Sie tun Dinge richtig, indem Sie MaxSignatureLength() aufrufen.

---

>> RSA Keys generated (420 bytes) 
>> ServerHello sent (436 bytes) 

Ich spekulierte einfach, aber es scheint, dass Sie erscheinen Designprobleme zu haben, auch.

Wenn Sie eine Nachricht wie die ServerHello verschlüsseln, verschlüsseln Sie sie normalerweise unter einer symmetrischen Chiffre wie AES oder Camellia. Dann nehmen Sie diesen symmetrischen Verschlüsselungsschlüssel und verschlüsseln ihn unter dem RSA-Schlüssel. Schließlich senden Sie das Paar {encrypted symmetric cipher key, encrypted message under symmetric cipher} an die andere Partei.

In dem oben beschriebenen System verschlüsseln Sie nur 16 oder 32 Bytes unter dem öffentlichen Schlüssel.

---

ich denken, was Sie sollten ein integriertes Verschlüsselungsschema tun verschlüsselte Nachricht wird unter Verwendung hin und her zu senden. Siehe dazu Elliptic Curve Integrated Encryption Scheme (ECIES) und Discrete Logarithm Integrated Encryption Scheme (DLIES). ECIES arbeitet über elliptischen Kurven und DLIES über ganze Zahlen.

Integrierte Verschlüsselungsschemata haben einige sehr wünschenswerte Sicherheitseigenschaften, wie sie sind IND-CCA2. Sie erreichen es durch nicht ermöglicht Ihnen einige Dinge zu tun, wie die Wiederverwendung eines Sicherheitskontextes, so dass die Sicherheit in das Schema gebacken wird.

Sie müssen das Schlüsselverteilungsproblem jedoch noch lösen. Das ist ein heikles Problem, und wir haben keine gute, skalierbare Lösung.

Und jetzt sehen Sie, warum Algorithmus Agilität wichtig ist, und warum Sie wollen, dass OID als Teil des Schlüssels während der Handshake-Phase gesendet :)