Bei asymetrischen Verfahren wie RSA gibt es immer ein SchlüsselPaar...
- einen PrivateKEY und einen zugehörigen PublicKEY
- der PublicKey ist öffentlich, DARF UND SOLL also verteilt werden... wie z.B. hier in die EXE einkompiliert werden
- es gilt erstens, mit dem Key welchen man zu Verschlüsselung benutzt hat, kann man die Daten nicht mehr dekodieren (=> ASYMETRISCHES VERFAHREN)
- es gilt zweitens: was mit dem PublicKEY "verschlüsselt" wird, kann nur mit dem "PrivateKEY" entschlüsselt werden
- es gilt dritens: was mit dem PrivateKEY "verschlüsselt" wird, kann man mit dem "PublicKEY" dekodieren und so die Herkunft prüfen, denn nur der Besitzer des PrivateKEY konnte das so erstellen... deshalb nennt sich dieser Weg auch "signieren" und nicht verschlüsseln


Der Trick an RSA ist ja, das man im unsicherem Gebiet, also im ClientBereich oder bei der Übertragung (Server,INET,..) NIEMALS den PrivateKey herausgeben muss und trotzdem per PublicKey sowohl sichere Verschlüsselung aus auch sichere Herkunftsprüfung(im Sinne von Identifikation und Authentifizierung) möglich ist.

Die Besonderheiten Asym. Cryptoverfahren und die sich daraus ergebende jeweils sinnvolle Anwendung der Keys bzw. Methoden zum PrivatKeyManagement sprengen den Rahmen dieses Threads, hier geht es um eine sinnvoll Absicherung von Updates, und da bietet es sich an NICHTS mit geheimen Schlüsseln oder Passwörtern im Clientprogramm zu machen. Genau da ist der PublicKey der Ideale KEY.
So kann sogar wenn der Client zum Server damit echt verschlüsselte Daten schicken, die dann im Server undekodierbar lagern, bis man sie selbst von dort abholt und in eigener sicherer Umgebung dann mit dem PrivateKey dekodiert... so gibt es nie Datenschutzprobleme auf dem Server, denn dort liegen stets nur wertlose verschlüsselte Binärdateien und keinerlei Keys.

Also kurz gefasst:
Dateien auf dem Server mit dem privateKey kodieren und den publicKey in die Exe aufnehmen, damit diese die runtergeladenen Dateien dekodieren kann?

Wo bekommt man irgendwas mit RSA denn her? DEC scheint ja keine zwei Keys zu unterstützen http://www.delphipraxis.net/75286-rs...b-und-wie.html
Ich hätte hier zwar was, aber das ist glaube ich nur für Strings http://delphiforfun.org/programs/Mat...SA_KeyDemo.htm

..."Dateien auf dem Server mit dem privateKey kodiert speichern und den publicKey in die Exe aufnehmen, damit diese die runtergeladenen Dateien dekodieren kann"...
=> ja genau so



http://tmssoftware.com/site/tmscrypto.asp

sorry, auch bei sowas ist mir die Suche nach Freewarevarianten zu lässtig, wenn es für unter 100Eur was gibt was gepflegt wird und gut mit Support noch gut dokumentiert ist

Zu teuer Außerdem halte ich von TMS nix.

Was ist denn davon zu halten? https://github.com/TurboPack/LockBox3

RSA steht bei LockBox3 mit dabei... und genau da ist jetzt der Unterschied... bei an TMS schreibste denen was du vor hast und die antworten dir mit welchen ihrer Komponenten es wie geht

Jedem das seine, ich finde DevArt und TMS haben angemessene Preise und überleben so trotz der Freewarealternativen ja auch.
Und TMS+UniDAC machen günstiger für DB und Cloud aus einem Delphi-Pro mehr, wie einem ein Delphi-Ent für teuer Geld bietet, sogesehen ist TMS da sogar "billig", zumal Source und 2Jahre VollSupport immer dabei

Ich habe nix gegen Freeware und Leute die diese machen oder die es nutzen, nur die Suche nach XY nervt im Delphibereich, weil es im INet dazu kaum eine breite offene Sourcebasis gibt.
Da stehe ich dann dazu, das ich privat bei 100€ max. 5h meiner Zeit investieren würde, denn 20€/h ist mir meine Freizeit wert. Geschäftlich würde ich bei 100€ Kosten die Grenze schon bei nur 3h setzen.

Zitat von mensch72:

..."Dateien auf dem Server mit dem privateKey kodiert speichern und den publicKey in die Exe aufnehmen, damit diese die runtergeladenen Dateien dekodieren kann"...
=> ja genau so

Sicher? Gerade hast du es andersherum gesagt und nur andersherum kenne ich es auch. Der private Schlüssel kann entschlüsseln und der public Key verschlüsseln. Also irgendwie macht das gerade keinen Sinn. Oder habe ich jetzt einen Knoten im Hirn?

Knoten im Hirn. Wenn jemand was an dich schickt nimmt er den Public Key. Das kannst nur du mit deinem Private Key entschlüsseln und niemand sonst.

Verschickst du, nimmst du logischerweise den Private Key. Das kann der Empfänger mit deinem Public Key entschlüsseln.

wenn man den PrivateKey zum "verschlüsseln" nimmt, bezeichnet man das ja auch besser gleich als SIGNIEREN und nicht mehr als "verschlüsseln", dass verhindert ev. ein paar Knoten im Hirn.. schafft aber neue weil man wissen muss wo der sicherheits technische Unterschied ist:
- einmal kann nur der Empfänger es dekodieren und weiß so, das es "nur für ihn ist" (das mach Sinn für vertrauliche Daten die nur für EINEN Empfänger bestimmt sind)
- andererseits kann jeder es per PublicKey dekodieren und jeder weiß dabei "von wem es ist" (das mach Sinn für verlässliche Updates aus sicherer Quelle)

=> es gibt dann aber noch zig mehrstufige Kombinationen daraus, wo dann meist noch temporäre symetrische SessionKeys erzeugt und sicher ausgetauscht werden... kann man auch beim Updateprozess mit vorsehen, wenn es um Austausch/Freischaltung von Lizenzinfos an/für genau einen Client geht, aber das sprengt die einfache Threadfrage, wie man "sicher" ein Update an mehrere Clients verteilt.

Signieren und verschlüsseln ist zweierlei, aber es macht wenig Sinn, etwas mit meinem privaten Schlüssel zu verschlüsseln. Da ist es üblicher, etwas zu signieren.

Signieren ist eine Prüfsumme bilden und diese mit dem privaten Schlüssel verschlüsseln.
Diese Prüfsumme kann jeder mit dem öffentlichen Schlüssel verifizieren.

Beim Signieren wird aber der Inhalt nicht verändert und schon gar nicht unles- bzw. unnutzbar.

Beim Verschlüsseln wird der Inhalt genommen - oft komprimiert - und mit dem passenden Schlüssel verschlüsselt.

Der passende Schlüssel ist bei Verschlüsseln und Signieren:
a) Wenn ich den Inhalt nur einem Zugänglich machen will: Der private Schlüssel des Gegenüber
b) Wenn ich den Inhalt öffentlich machen will: Mein Privater Schlüssel

Private Schlüssel gehen nie übers Netz oder an jemanden Dritten. Sonst sind sie nicht mehr privat!