[C#] Generiere mehrere Öffentliche Schlüssel aus einem privaten Schlüssel

[Gateway_man]

Hallo,

ich suche aktuell nach einer .NET Klasse die es mir ermöglich aus einem privaten Schlüssel mehrere verschiedene Öffentliche Schlüssel zu generieren.

Existiert so was bereits ohne muss ich mir selber einen Algorithmus schreiben der das für mich macht?

Mit der Klasse RSACryptoServiceProvider kann man hervorragend ein Schlüsselpaar generieren lassen, jedoch leider immer nur jeweils einen öffentlichen Schlüssel für einen private Schlüssel.

Da ich jedoch nicht vor habe allen Nutzern den selben öffentlichen Schlüssel zu geben, ist das ganze recht nutzlos.

LG

Gateway

[Klotzkopp]

Da ich jedoch nicht vor habe allen Nutzern den selben öffentlichen Schlüssel zu geben, ist das ganze recht nutzlos.

Warum hältst du das für nutzlos? Was ist der Anwendungsfall?

[SilentDemise]

Da funktioniert mit RSA rein vom Algorithmus her nicht. Das ist ja eben mit absicht eindeutig und einmalig.

[Gateway_man]

Wenn ich jedem Nutzer denselben öffentlichen Schlüssel geben würde, könnte er die Kommunikation jedes Clients zum Server mithören. Dann müsste ich vor der asymmetrischen Verschlüsselung die Daten zusätzlich Symmetrisch Verschlüsseln um eine sichere Kommunikation zum Server gewährleisten zu können.

Das wäre ein abnormaler Aufwand, deswegen wollte ich einfach aus einem privaten Schlüssel mehrere öffentliche Schlüssel generieren.

LG

Gateway

[SilentDemise]

mit dem öffentlichen Schlüssel kannst du nur verschlüsseln, lediglich der private kann entschlüsseln. Darum heißen sie öffentlich und Privat ;-)

Übrigens machen wir das alle jeden Tag mit SSL so: wir alle nutzen denselben öffentlichen Schlüssel von Amazon um den Key Exchange zu verschlüsseln, aber nur Amazon selbst kann die Nachricht mit dem Private Key lesen.

[Gateway_man]

Dann hat sich das damit erledigt danke

[Gateway_man]

So nebenbei ist das aber nicht das höchste der Gefühle. Das heißt ja dann wenn ich beispielsweise Online-Banking mache, kann zwar niemand meine Authentifizierung Daten abgreifen, jedoch kann jeder sich meine Bewegungsdaten abgreifen, da diese ja dann unverschlüsselt vom Server zurückkommen.

Da bleib ich dann doch lieber bei symmetrischen Verschlüsselungstechniken .

[Klotzkopp]

Das heißt ja dann wenn ich beispielsweise Online-Banking mache, kann zwar niemand meine Authentifizierung Daten abgreifen, jedoch kann jeder sich meine Bewegungsdaten abgreifen, da diese ja dann unverschlüsselt vom Server zurückkommen.

Nein. Informiere dich bitte, wie TLS funktioniert.

[Gateway_man]

Ich hab das jetzt nur so aus dem Text erschlossen. Wenn es heißt das der öffentliche Schlüssel nicht entschlüsseln kann muss er die Daten ja im Klartext erhalten. Naja egal. Ich hab mich kurzerhand für was hybrides entschieden.

Für den Verbindungsaufbau mit dem Server verwende ich RSA. Der Client generiert einen Zufälligen String und (verschlüsselt diesen mit dem öffentlichen Schlüssel) und schickt diesen an den Server.

Der entschlüsselt diesen dann und nutzen den String dann für die Nutzung einer Symmetrischen Verschlüsselung zwischen dem Client und Server. Mein Problem ist damit gelöst.

Danke für den Hinweis.

[Guybrush Threepwood]

Wäre ja auch Unsinn ein etabliertes System zu benutzen

[Gateway_man]

Wäre ja auch Unsinn ein etabliertes System zu benutzen

Die meisten Erfahrungen sammelt man, indem man es selbst ausprobiert . Zudem bin der Meinung, das das Thema Kompatibilität häufig überschätzt wird .

Ich finde ich die Cryptograhpy Klassen im .NET sind sehr schwer zu nutzen (nicht immer ganz klar was da wieder nicht passt).

Ich hab gestern mal wieder den ganzen Tag damit verbracht den Fehler "Zeichenabstände sind ungültig und können nicht entfernt werden." zu beheben. Beheben ist eventuell eine leichte Übertreibung. Ich hab das Padding einfach deaktiviert....Und ja dafür schäme ich mich....

Lg

Gateway

[Gateway_man]

Sorry für Doppelpost, aber an dieser Stelle eine generelle Frage zu dem Asymmetrischen Verfahren RSA.

Stimmt es das die zu verschlüsselnden Datenpackete kleiner sein müssen als die Schlüsselgröße?:beagolisc

...

As mentioned in other answers asymmetric encryption is only designed for encrypting data smaller than it's key size.

...

Ich bekomme hier die ganze Zeit Exceptions mit "Ungültiger Länge..".

Nach der Logik von oben hab ich also angefangen größere Packete zu splitten (aktuelle Schlüsselgröße 2048).

Alle Datenpackete sind nun kleiner als 2048. Jedoch erhalte ich bei der Verschlüsselung immer noch "Ungültige Länge".

Ich hab das mal per Hand ausgelotet und er bringt die Meldung nichtmehr bei 200 Bytes. Eine Eigenschaft für die Maximal zulässige Packetgröße scheint es nicht im RSACryptoServiceProvider zu geben.

Kann man das irgendwie berechnen?

Ich muss sagen das ganze verliert hier momentan immens an Charme. Ich meine 200 Bytes sind ja quasi nichts.

Reicht aktuell noch nicht einmal für die Authentifizierung.

Ich habe testweise eine "große Datei eingelesen" (17KB). Daraus macht er momentan 87 Byte Arrays. (Kostet auch überhaupt keine Performance das ganze....)

Was mir total wichtig wäre ist:

Wie kann ich die Maximal erlaubte Packetgröße ermitteln?

Lg

Gateway

[Klotzkopp]

Die meisten Erfahrungen sammelt man, indem man es selbst ausprobiert

Insbesondere wiederholt man alle Fehler, die Andere bereits gemacht haben. Und merkt es hoffentlich. Oder man bastelt irgendetwas zusammen, was nur so aussieht, als ob es tut.

Nochmals der Hinweis, den du offenbar nicht befolgt hast: Informiere dich, wie TLS funktioniert. Im Ernst. Du kannst dir in Jahrzehnten gesammelte Erkenntnisse der Kryptographie nicht durch Ausprobieren aneignen.

[Gateway_man]

Nochmals der Hinweis, den du offenbar nicht befolgt hast: Informiere dich, wie TLS funktioniert. Im Ernst. Du kannst dir in Jahrzehnten gesammelte Erkenntnisse der Kryptographie nicht durch Ausprobieren aneignen.

Danke dir für die Information. TLS scheint ja eine Kombi aus RSA und AES zu sein. Das ganze klingt eigentlich genau nachdem was ich gesucht habe, passt aber leider nicht in mein aktuelles Klassenkonzept. Dafür müsste ich den SslStream nutzen und das krieg ich so nicht hin ohne die ganze Klassenhierarchie über den Haufen zu werfen.

Eventuell hab ich etwas mit den Infos gegeizt. Daher kommt jetzt das ganze Packet.

Ich schreibe aktuell eine Socket Klasse, welche um immens viele Funktionalitäten erweitert werden sollte.

Der Grund? Da ich relativ viel mit Netzwerkprogrammierung mache, hab ich so ein paar Dinge kennengelernt, die mich jedes Mal fast in den Wahnsinn treiben.

Beispielsweise den genauen Status der Verbindung (bei der Socket Klasse des .NET Frameworks ist der Status einer Verbindung faktisch nicht ohne eine Interaktion mit der gegenstelle zu ermitteln).

Ich will zu jeder Zeit ohne jegliche Zusatzoperationen den aktuell gültigen Status der Verbindung abfragen können.

Zudem möchte ich ebenfalls die Möglichkeit haben, gewisse Events abfangen zu können (Beispielsweise bei Verbindungsabbrüchen).

Jetzt gibt es folgende Zustände:

    [Flags]

    public enum SocketConnectionState

    {

        Unknown = 0x0,

        NotInitialized = 0x1,

        AcceptingSync = 0x2,

        AcceptingAsync = 0x4,

        Listening = 0x8,

        Connecting = 0x10,

        ConnectingAsync = 0x20,

        Etablished = 0x40,

        Lost = 0x80,

        Disconnecting = 0x100,

        DisconnectingAsync = 0x200,

        Disconnected = 0x400,

        Sending = 0x800,

        SendingAsync = 0x1000,

        Receiving = 0x2000,

        ReceivingAsync = 0x4000,

        SendClosed = 0x8000,

        ReceiveClosed = 0x10000,

        Closed = 0x20000,

        SendingKeepAlivePackage = 0x40000,

        ReceivingKeepAlivePackage = 0x80000

    };

Man hat die Möglichkeit dem Socket eine KeepAliveDefinition zu übergeben, in der man das Interval und auch das Datenpacket festlegen kann. Jetzt kam zusätzlich noch der Wunsch dazu, das man dem Socket direkt einen "Cryptography Layer" übergeben kann. Somit soll der Socket sich selbst um die korrekte Verschlüsselung/Entschlüsselung kümmern. Dafür verlangt die Socket Klasse jetzt eine Klasse die das Interface ICryptoLayer implementiert:

    public interface ICryptoLayer

    {

        bool IsHybrid { get; }

        bool CanChangeEncryptionMode { get; }

        SocketEncryptionDirection EncriptionDirection { get; }

        bool CanEncrypt { get; }

        bool CanDecrypt { get; }

        bool IsBlockchiffre { get; set; }

        int BlockSize { get; set; }

        HybridEncriptionState CryptoState { get; }

        byte[] Encrypt(byte[] input);

        bool TryEncrypt(byte[] input, out byte[] output);

        byte[] Decrypt(byte[] input);

        bool TryDecrypt(byte[] input, out byte[] output);

        bool ChangeCryptoMode();

        bool Inheritable { get; set; }

    }

Da prinzipiell jedes Verschlüsselungsverfahren unterstützt werden soll, gibt es aktuell drei Klassen die von dem Interface erben:

--> SymmetricCryptoLayerCfg (Verlangt im Konstruktor einen Typen der von der Klasse SymmetricAlgorithm erbt)

--> AsymmetricCryptoLayerCfg (Verlangt im Konstruktor einen Typen der von der Klasse AsymmetricAlgorithm erbt)

--> HybridCryptoLayerCfg (Verlangt im Konstruktor zum einen eine SymmetricCryptoLayerCfg Instanz und eine AsymmetricCryptoLayerCfg Instanz).

Beispielsweise kann ich jetzt bei der Verwendung von Hybriden Verfahren bequem über die Property CryptoLayer der Socket Klasse zwischen den einzelnen Techniken wechseln.

Und auch um die Verschlüsselung muss ich mich nichtmehr kümmern. Wenn ich die Daten verschlüsselt übertragen möchte, muss ich lediglich dem Socket die entsprechende Verschlüsselungsschicht übergeben. Dann übergebe ich die Daten wie man das bei einem normalen Socketobjekt auch macht. Intern kümmert sich die Socketklasse selbst um die Verschlüsselung/Entschlüsselung.

Die größte Hürde war definitiv die Kryptographie Schicht. Harmoniert aber jetzt endlich wunderbar .

Danke @ all.

Lg

Gateway