1668mib schrieb:
@andr_gin: Den ObjectOutputStream muss er in Verbindung mit den (vermutlich vorgegebenen?) RSA-Klassen halt nutzen...
Sorry, aber wenn das tatsächlich so ist, dann ist die RSA Klasse einfach ein murks. Was will denn bitte eine Klasse, die Daten binär verschlüsselt an großartig an Objekten in einen Stream schreiben? Das kann bestenfalls ein Integer sein, da die Daten nach der Verschlüsselung ja sowieso als Zahlen zur Verfügung stehen. Da würde ich gleich versuchen eine Klasse von ObjectOutputStream abzuleiten, die bei allem außer Ints eine Exception wirft und einen Int Little Endian in ein Byte Array codiert.
und sonst hat das meiste was du schreibst irgendwie gar nichts mit dem Thema zu tun :-)
Das waren nur einige wichtige Erfahrungen aus der Praxis, die man auf jeden Fall beachten sollte, sonst endet das beim ersten richtigen Projekt in einer Katastrophe.
[/quote]und dass das von dir genannte Verfahren ziemlich anfällig für einen Man-in-the-Middle-Angriff wäre (wegen a) ), ist auch off-topic...[/QUOTE]
Welches a) meinst du hier?
Das Senden des öffentlichen RSA Keys ist kein Problem, da sowieso nur der Sender den privaten Key hat. Wenn es wirklich eine Applikation ist, die so kritisch ist, dass wirklich jemand das Protokoll nachbaut, dann steht es dem Client natürlich immer noch offen die Authentizität des Senders zu überprüfen. Entweder kompliziert über ein Zertifikat oder einfach über einen hinterlegten Config-Wert an erlaubten Public Keys, der dann eben irgendwo sicher am Client hinterlegt werden muss.
Redirion schrieb:
ich bin meiner Meinung nach genau auf das Problem von sianon eingegangen.
In seinen Dateien landeten seltsame Zeichen, ich habe ihm erklärt, woran es liegt, und wie er es beheben kann. Dieser unleserliche Murks mit den Kästchen und Chinazeichen hat ÜBERHAUPT NICHTS mit der Verschlüsselung zu tun!, sondern ist das Ergebnis der Verwendung von Streams. Sein Verschlüsselungsergebnis sieht vor dem Speichern in eine Datei ganz anders aus, was er mit Sysouts prüfen kann.
Ein Stream an sich verändert die Ausgabe nicht. Ein Stream leitet grundsätzlich nur Bytes zum Ziel weiter. Das Problem ist hier der ObjectOutputStream, der eben undstandardisierten Murks erzeugt abseits von jeglicher Norm. Es absolut unmöglich das Dateiformat irgendwie zu dokumentieren, da man selbst nicht weiß, wie was geschrieben wird und es gibt auch keine Garantie mehr, ob die Daten bei einer Änderung der Java Version, geschriebenen Klasse usw. überhaupt noch lesbar ist.
Ich ging weiterhin davon aus, dass es sich um seine eigenen Klassen handelt und er entsprechend die Outputstreams gegen Writer und die Inputstreams gegen Reader austauschen kann.
Das kann ich auch nicht exakt beantworten, ob die Klassen selbst gebaut sind. Wenn ja, dann macht das die Sache natürlich um ein Eck einfacher.
Ich verstehe nur nicht ganz, was die Sache mit den Writern soll. Die Standardisierung über Streams hat schon seinen Sinn. Da kann man sehr einfach an jedes Ziel schreiben. Es ist nur der ObjectOutputStream, der entfernt werden muss. Die RSA Klasse soll Byte Arrays verschlüsseln, also gar nicht erst Strings, Integer etc. entgegen nehmen und genauso nur Bytes ausspucken. Die Umwandlung von komplexen Objekten in Bytes muss IMMER von der Klasse/Methode geschehen, die den Speichervorgang durchführt, da nur diese Klasse Kenntnis über die verwendeten Datentypen, Kodierungen etc. hat.
Es ist nunmal Fakt, dass Streams nur Bytecode in eine Datei schreiben... egal wie man es anstellt, lesbar wird es nie.
In einer Datei stehen IMMER nur Bytes. Ob die Datei mit einem Editor lesbar ist oder nicht, kommt alleine auf den Aufbau der Datei an. Das hat mit Streams nichts mehr zu tun. Das ist die Aufgabe der Applikation. Wenn man ein neues Dateiformat entwickelt, so muss man sich über den genauen Aufbau im Klaren sein und ausreichend dokumentieren, wobei nur ein Auszug aus dem verwendeten Code der Applikation keine Dateispezifikation ist.
Im Einfachsten Fall bei einer Textdatei wird nur festgelegt, welche Kodierung verwendet wird (z.B. UTF-8).
Redirion schrieb:
@1668mib:
hast du überhaupt schonmal mit Java versucht einen String lesbar in eine Textdatei zu schreiben? Dann viel erfolg mit deinen Streams. Zeig mir bitte danach mal den Dateiinhalt.
Meine String-Serialisierung über writeObject und readObject war eine Antwort auf dein unnötiges Umwandeln eines Strings in ein byte[]. Das geht damit nämlich eleganter. Object mit writeobject in die Datei schreiben, mit readobject lesen, Typcast, fertig.
Und wie willst du dann eine Dateispezifikation erstellen? Das ReadObject und WriteObject funktioniert nur solange, wie sich an der verwendeten Programmiersprache (Java), der Java Version, der Version der Klasse, dem verwendeten Betriebssystem, der Regionaleinstellungen, dem Vornamen des Haustiers deiner Tante und 17 anderen Komponenten nichts ändert. Das kann sich je nach Objekt von einem Tag auf den anderen ändern und man hat genau 0 Kontrolle darüber.
Eigentlich ziemlich witzig, denn indem du den String zunächst in ein byte[] umwandelst, um es dann in den Stream schmeisst, müsste jedem klar sein, dass nichts lesbares am Ende bei rauskommt.
Das hat dann wie schon so oft gesagt, nichts mit der Verschlüsselung zu tun, sondern ist halt nur byte-Salat.
Wenn der String mit der richtigen Kodierung in den Byte Array umgewandelt wird und die UTF-Preambel am Dateianfang richtig gesetzt wurde, kann man den Text 1:1 wieder auslesen, solange dieser nicht verschlüsselt ist und zwar mit JEDER Software, die die Kodierung unterstützt und nicht nur mit der eigenen.[/QUOTE]