"Umgekehrtes PGP"

Abgesehen von Verschlüsselung ist die Grundanforderung verwandt mit der 
Forderung nach nicht modifizierbarer Archivierung, siehe WORM. Dafür 
gibt es fertige Lösungen, die sicherlich auch mit Verschlüsselung 
ausgestattet werden können. Vielleicht hilft dir das weiter.

??

genau das macht doch PGP (oder per Cert verschlüsselte e-mails)

man verschlüsselt eine e-mail, und nur der Empfänger (und man selber) 
kann sie lesen..

und der Empfänger kann natürlich selber nicht damit verschlüsseln

deshalb ja "private-public" key usw.

und wie " Verwirrter Anfänger " schrieb, selber signieren muss man sie 
noch, damit der absender klar ist..

Peter II schrieb:
> Und mit einem Private Key kann man auch verschlüsseln.

Man verschlüsselt aber mit dem public Key des Empfängers.

Und signiert mit dem eigenen private key. Die Signatur ist der Schlüssel 
zur Authentifizierung des Absenders, nicht die Verschlüsselung. Und die 
sollte sich hier ebenfalls nutzen lassen. Die Verschlüsselung, soweit in 
der Sache überhaupt notwendig, ist dann nur ein Nebeneffekt.

@ Alle, danke für euere Inputs.

Jetzt weiß ich,dass das was ich Suche ist eine Digitale Signatur ist...

Das ist dann ein reiner Signaturmechanismus. Wenn die Daten klein genug 
ist, ist das unproblematisch. Für grössere Daten sollte man bedenken, 
dass Hashverfahren (MD5&Co) mit asymmetrischer Verschlüsselung des Hashs 
wesentlich anspruchsloser sind, als die recht rechenintensive 
asymmetrische Verschlüsselung der kompletten Daten.

> als die recht rechenintensive
>asymmetrische Verschlüsselung der kompletten Daten.

macht "man" doch sowieso nicht!?

sonst könnte man die e-mail ja nicht mal selber lesen..??

bzw. zumindest könnte man nicht eine e-mail an mehrere Empfänger 
schicken:

http://de.wikipedia.org/wiki/Pretty_Good_Privacy

Robert L. schrieb:
> bzw. zumindest könnte man nicht eine e-mail an mehrere Empfänger
> schicken:

Wenn du die kompletten Daten mit einem eigenen privaten Schlüssel 
"verschlüsselst", dann kann jeder es mit deinem öffentlichen Schlüssel 
entschlüsseln. Sogar du selbst. Das ist dann eine reine Signatur.

>Wenn du die kompletten Daten mit einem eigenen privaten Schlüssel
>"verschlüsselst",

warum (und vor allem WIE) macht man das ?

(ich hab extra von E-Mail gesprochen,..)

Wie: Nicht mit PGP. Ich meinte das Verfahren, nicht das Programm. Mit 
PGP geht man dafür den üblichen Weg und signiert ohne zu verschlüsseln. 
Technisch ist das der beschriebene Weg eines so verschüsselten Hashs.

So, ich habe in der Zwischenzeit etwas mehr über Hashes (MD5, SHA), 
Asymetrische Kryptographische Verfahren recherchiert.

So will ich es angehen:

Signieren

"Daten(1GB)" --SHA1--> "HASH" --RSA(private key)--> "verschlüsselter 
Hash"

Verifizieren:

"verschlüsselter Hash" --RSA-public key--> "Hash" == "entschlüsselter 
Hash"?


Soweit ich es verstanden habe ist die Sicherheit der Verifikation in 
diesem Fall nur vom asymetrischen Verfahren abhängig. Bei Verwendung von 
RSA also von der Schlüssellänge. Der Hash wird nur benötigt um die zu 
verschlüsselnde Datenmenge klein zu halten. 1024bit RSA sollten für die 
nächsten 5 Jahre sicher sein.

Aus welchem Grund sollte der Hash eine Auswirkung auf die Sicherheit der 
Signatur haben?

Ich benuütze den Hash ja nur um die Datenmenge die ich asymetrisch 
Verschlüsseln muss zu reduzieren.

Würde ich die Daten mit RSA verschlüsseln, und zum Verifizieren die mit 
dem public Key entschlüsselten Daten mit den erhaltenen Daten 
vergleichen würde das aufs Gleiche kommen.

Oder übersehe ich da was?

Stimmt schon jedoch, finde jedoch auch Daten die einen Sinn ergeben und 
den gleichen Hash haben...

@ __tom
Und? Wo liegt das Problem. Dann kann ich halt vom Hash auf die Daten 
schließen. - Die Daten liegen sowieso vor und sind kein Geheimnis. Das 
sind ja die Daten die ich signieren will.

Der wichtige Aspekt am Hash ist: Es darf nicht möglich sein, mit 
vertretbarem Aufwand ein Datenfile zu produzieren, dass einem gegebenen 
Hashwert entspricht.

Kann ich ja beim verschlüsseln von Passwörtern verstehen aber warum bei 
dieser Anwendung.

Wie gesagt:

Geg.: Daten die von Gerät A zu Gerät B über einen Datenträger 
transferiert werden.

Ges.: Ein Weg herauszufinden ob diese Daten am weg dorthin manipuliert 
wurden.

Lösung:

Daten mit RSA(privat) kodieren.
Auf den Datenträger sowohl die codierten als auch die decodierten Daten 
schreiben

Verifikation
Daten mit RSA(public) decodieren. Selbst decodierte Daten mit 
decodierten Daten vom Datenträger vergleichen. Sind sie gleich wurde 
nicht manipuliert.

Alternative:
Nicht die Daten selbst vergleichen sondern einen Hash dieser Daten, da 
der Hash kleiner ist und somit weniger lang zum codieren braucht.

Falls es Daten gibt die einen gleichen Hash ergeben ist das egal, weil 
die Daten (die ja die eigentliche Nachricht ist und einen Sinn ergeben 
muss) keinen Sinn ergeben werden.

Erwin Witt schrieb:
> Falls es Daten gibt die einen gleichen Hash ergeben ist das egal, weil
> die Daten (die ja die eigentliche Nachricht ist und einen Sinn ergeben
> muss) keinen Sinn ergeben werden.

Die Struktur der Daten ist natürlich eine weitere implizite Sicherheit. 
Nur ist die schlecht als allgemeine Eigenschaft von solchen Algorithmen 
einschätzbar, weshalb deren Beurteilung sich darauf nicht verlassen 
kann. Ob dir ein heute bereits als nicht mehr sicher geltender 
Hash-Algorithmus reicht musst du selbst entscheiden. Willst du 
persönlich die Sicherheit gegen Manipulation, oder muss sie auch von 
dritter Seite anerkannt werden?

Ja, es soll von dritter Seite anerkannt werden. Sprich von einem Kunden. 
Falls ich die Sicherheit argumentieren kann und das glaube ich mit 
obigen Argument zu können wird dies so passen.
In (m)einem System gibt es ganz andere Schachstellen die wesentlich 
wahrscheinlicher sind. z.B.: Einbruch in die Anlage die die Daten 
aufzeichnet und mit dem private Key signiert. --> private Key Diebstahl. 
etc.

Genauer gesagt wird ein AM3359 eingesetzt. Die Hashes habe ich mit 
openssl generiert. Ich wollte mal nur Anhaltspunkte haben wie lange das 
ganze ca. braucht.
Momentan rennt nix parallel. (Ausser irgendwelche idle 
Betriebssystemprozesse)

Apropos, danke für den Link zu dieser Library!