2012-07-12 3 views
8

Ich lese gerade diesen Artikel RSA keys under 1024 bits are blocked, und in meiner .NET-Software verwende ich umfangreich 384bit-Schlüssel. Kann mein Programm mit dem RSACryptoServiceProvider Schlüssel aus dem MachineKeyStore erzeugen/speichern/lesen? Oder muss ich einen Patch aussenden?.Net: Funktionieren meine RSA-Schlüssel auch nach August 2012?

+0

wow dank funktioniert dies auch weiterhin dafür, dass ich bemerken. – ericosg

+0

Am wahrscheinlichsten werden Sie in Schwierigkeiten geraten (wenn nicht mit diesem Patch dann mit einem der nächsten), aber Ihr aktueller Code ist an erster Stelle fehlerhaft: 384-Bit-RSA-Schlüssel sind SCHWACH und Sie müssen sie mindestens aktualisieren 1024 Bit ASAP warten nicht auf Microsofts Patches. –

+0

Sie könnten einen 384-Bit-Schlüssel auf einem Desktop-Computer in ein paar Tagen knacken. Oder waren es Wochen? – Wug

Antwort

0

Dies ist eine vorgeschlagene Antwort auf eine Frage, die in den Kommentaren kam.

Sie könnten wahrscheinlich eine Möglichkeit finden, eine symmetrische Methode zur Authentifizierung von Clients zu verwenden. Ich gehe davon aus, dass Sie gerade ein typisches RSA-Signaturschema verwenden, bei dem ein Nachrichtenhash von einem privaten Client-Schlüssel signiert wird, der dann durch den öffentlichen Schlüssel verifiziert werden kann.

Sie könnten vielleicht einen Austausch eines persistenten Schlüssels durchführen und dann den Nachrichtenauszug mit diesem Schlüssel anstelle des asymmetrischen Schlüssels verschlüsseln. Sie würden immer noch garantieren, dass derjenige, der die Nachricht gesendet hat, den geheimen Schlüssel kannte, obwohl Sie keine Möglichkeit hätten, zu überprüfen, ob die Nachricht vom Client oder vom Server gesendet wurde (da beide den Schlüssel kennen). Wenn der Client den Server während der Authentifizierung anforderte, würde dies dazu beitragen, die mittleren Angriffe zu verhindern (obwohl der Client den öffentlichen Schlüssel des Servers lokal eingebettet haben müsste)

+0

Ich weiß Ihren Vorschlag zu schätzen, aber er hat nichts mit der ersten Frage zu tun. Es wird eine gewaltige Aufgabe sein, alle meine Benutzer vor August 2012 zum Upgrade zu überreden, also ändere ich den Code oder das Verschlüsselungsschema lieber nicht. Außerdem ist das System dezentral wie E-Mail, so dass Clients keine feste Liste öffentlicher Schlüssel speichern können, sondern sie müssen zusammen mit der Nachricht übertragen werden. Sie können dann bestimmte Schlüssel auf die Weiße Liste setzen, so dass sie, wenn sie eine andere Nachricht erhalten, sicher sein können, dass sie vom selben Absender wie zuvor stammen. – Muis

0

Wenn die Signaturgröße kritisch ist, ist RSA schlecht Wahl zu beginnen. DSA und ECDSA produzieren beide kürzere Signaturen mit viel größerer Stärke als RSA. Weder DSA noch ECDSA kommen jedoch der Signaturprüfungsgeschwindigkeit für RSA 384 nahe.

Wenn Sie jedoch weiterhin die verwendeten Schlüssel verwenden müssen, müssen Sie Ihren Code ändern, um die Verwendung von Microsoft-Kryptografie-APIs zu vermeiden. Sie können beispielsweise die Bouncycastle C# -Bibliothek verwenden, wenn Sie C# verwenden. Schließlich können Sie sich bei Microsoft darüber beschweren. Ich bezweifle, dass es etwas nützen wird, aber du kannst es immer versuchen.

+0

Meine Hauptbeschwerde ist, dass sie dies nur 1 Monat angekündigt haben, bevor sie diese bahnbrechende Änderung vornehmen werden. Ich habe eine installierte Basis von fast einer halben Million Benutzern und keine Auto-Update-Funktion, so dass es keine Möglichkeit gibt, sicherzustellen, dass jeder vor dem Patch aktualisiert wird. – Muis

+0

@Joshua Ich höre dich. –

+0

Beachten Sie, dass die Generierung von Schlüsseln und vor allem die Erstellung von Signaturen viel schneller ist, wenn ECDSA verwendet wird, verglichen mit einem RSA-Schlüssel ähnlicher Stärke. Es kommt also auf das Protokoll und das Gesamtsystem an, das am vorteilhaftesten ist. –

4

bekam ich eine Antwort von Microsft (Kurt L Hudson), und dieses Update sollte chainbuilding nur beeinflussen, so scheint es RSACryptoServiceProvider mit kleinen Schlüsselgrößen nach August 2012

+0

Laut dem verknüpften Artikel ist alles betroffen, was die Funktion zum Erstellen von Ketten verwendet, einschließlich SSL und S/MIME (auch bekannt als CMS). Andere Benutzer mit kleinen Schlüsselgrößen sollten prüfen, welche Protokolle und Funktionen sie verwenden. –

Verwandte Themen