Java FileOutputStream

@andr_gin: Den ObjectOutputStream muss er in Verbindung mit den (vermutlich vorgegebenen?) RSA-Klassen halt nutzen...

und sonst hat das meiste was du schreibst irgendwie gar nichts mit dem Thema zu tun :-)

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...
 
Also wenn Du den verschlüsselten Text (oder was auch immer) in einem Texteditor anzeigbar machen willst, solltest Du nach der Verschlüsselung noch eine BinHex, Base64, UUencode oder Ascii85 Kodierung nachschieben. Dann erhältst Du ein File, in dem (je nach Kodierung) nur "lesbare" Zeichen verwendet werden.
Günstig wäre z.B. eine einfache Ascii85 Kodierung, da hier der Overhead relativ klein und der Algorithmus sehr einfach ist. Selbstverständlich muß vor der Entschlüsselung das Ganze wieder dekodiert werden.
Da ich mit Java absolut nix am Hut habe, weiß ich nicht, ob eine der o.g. Kodierungen schon fest eingebaut sind, würde aber auf Base64 tippen.
 
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.
Deswegen verstehe ich auch nicht, warum ihm hier jeder erklären will, dass das ja so sei, wegen der Verschlüsselung ...

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.

Und nochmal auch für dich zum Mitschreiben: Auch mit jeden Stream lassen sich Dateien erzeugen, die problemlos von Menschen erzeugt werden können (wenn man denn will!). Darauf wurde aber bei der Implementierung der RSAOutputStream/RSAInputStream-Klassen gar kein Wert gelegt, es hat auch keinen Mehrwert...

"lassen sich Dateien erzeugen, die problemlos von Menschen erzeugt werden können"? ;-)

Es ist nunmal Fakt, dass Streams nur Bytecode in eine Datei schreiben... egal wie man es anstellt, lesbar wird es nie.
 
@Slartibarfast: Das Encoding wird nichts bringen, da die Zahlen ja serialisiert, also wirklich nicht in Klartext gespeichert werden. Im Grunde ist ja die Serialisierung ein Encoding/Decoding...

@Redirion: Sorry, du zitierst meinen Code, bist nicht mal in der Lage, diesen anzuschauen (mit String-Serialisierung hat das ncihts zu tun) und dass das Ergebnis problemlos sogar von dir trotz offensichtlicher Leseschwäche lesbar ist, steht auch nicht zur Debatte.

Und wenn du mir jetzt noch sagen könntest, welchen Mehrwert es hat, die Zahlen einfach am Stück zu schreiben, dann bekommst nen Lolli von mir... das macht mehr Probleme als es löst... (um genau zu sein löst es nur das Problem, dass der Thread-Ersteller zufrieden ist...)

Und hör mal mit dem nichtssagenden "Byte-Code"-Gerede auf... jede Datei besteht wenn du so magst aus Byte-Code...

Klar arbeiten die Writer textorientiert, machen z.B. normalerweise automatisch die korrekten Zeilenumbrüche für die jeweilige Plattform... aber dann hat es sich eigentlich auch mit den fundamentalen Unterschieden...
 
Zuletzt bearbeitet:
"b) hast du beim Einlesen auch die inverse Multiplikative vom Exponent verwendet? "

Klar.

"Sein Verschlüsselungsergebnis sieht vor dem Speichern in eine Datei ganz anders aus, was er mit Sysouts prüfen kann."

Genau richtig, so habe ich das auch getestet.
 
@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.

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.



sianon schrieb:
"Sein Verschlüsselungsergebnis sieht vor dem Speichern in eine Datei ganz anders aus, was er mit Sysouts prüfen kann."

Genau richtig, so habe ich das auch getestet.

na dann war ich wohl doch auf der richtigen Fährte ;-)
 
Also bei mir klappt die Ver- und Entschlüsselung problemlos mit dem von mir geposteten Code-Abschnitt.

Dass du nicht das von dir erwartete Zeichen in deiner Datei sehen wirst, hab ich bereits erklärt. Das macht wie gesagt durchaus Sinn (Post #17).

Also ist dein Problem, dass die Datei nicht so aussieht, wie sie soll (nicht sinnvoll lösbar in meinen Augen), oder klappt die Entschlüsselung nicht?

@Redirion:
Du machst mich echt sprachlos, wenn du nicht mal in der Lage bist, den Codeschnipsel selbst zu testen... der Byte-Salat beim Thread-Ersteller kommt nur vom serialisierten BigInteger-Objekt...
und die Datei, die mein Code-Schnipsel erstellt, enthält keinen Byte-Salat - zumindest nicht aus menschlicher Sicht (denn Byte-Salat gibt's eh nur aus Sicht von Menschen...)...

"na dann war ich wohl doch auf der richtigen Fährte ;-)" - Einbildung ist auch ne Bildung...

Und mit Streams kannst du wenn du willst alles in eine Datei schreiben, die sind universell nutzbar... klar macht es für Text mehr Sinn, direkt nen Writer zu nehmen, aber daran liegt es nicht.
 
Zuletzt bearbeitet:
@1668mib:

wir brauchen uns nicht streiten, denn wir wollen ja beide nur dem TE helfen.
Der TE wollte nunmal anhand der von ihm erstellten Datei sichergehen, dass auch sein Verschlüsselungsergebnis in der Datei gelandet ist. Also durch "menschliches Draufschauen".
Klar, er kann die Datei direkt wieder mit einem objectinputstream lesen und dann wieder mit Sysouts überprüfen, ob das Eingelesene der Erwartung entspricht, aber der TE war nunmal lediglich über die Chinazeichen verwundert, da er die Funktionsweise von Streams wohl nicht so genau kannte...

das ist alles..
also grundsätzlich haben wir beide Recht.. ich wollte ihm halt nur eine Möglichkeit zeigen, seine Datei lesbar zu machen. Es funktioniert natürlich auch mit Streams.

Hoffe wir können uns vertragen und dann entspannt schlafen gehen ;-)


edit: damit wir auch mal einen richtigen gemeinsamen Punkt haben
Und mit Streams kannst du wenn du willst alles in eine Datei schreiben, die sind universell nutzbar... klar macht es für Text mehr Sinn, direkt nen Writer zu nehmen, aber daran liegt es nicht.
Diese Aussage unterstreiche ich voll. Es ist auch wirklich einfacher Objecte zu serialisierung und zu deserialisieren. Ich würde auch Streams verwenden.
Aber damit wäre die Frage des TE nicht beantwortet gewesen... ;-)

edit2: wenn ich mir das hier nochmal so durchlese, sieht es aus, als hätte es ein riesiges Missverständnis gegeben... ich wollte die Verwendung von Streams nie in Frage stellen. Wenn ich von "Byte-Salat" und "nicht lesbar" sprach, meinte ich wirklich nur für den menschlichen Betrachter - also im Sinne des TE "Kästchen" und "Chinazeichen". Dass trotz des "Byte-Salats" die korrekten Daten in der Datei liegen, ist mir klar - dein Codeschnipsel sah für mich auch korrekt und nachvollziehbar aus.
Nur leider wollte hier irgendwie jeder dem TE erklären die unleserliche Datei sei ein Ergebnis seiner Verschlüsselung, obwohl der TE genau weiß, wie sein Verschlüsselungsergebnis "für Menschen lesbar" hätte aussehen müssen.
 
Zuletzt bearbeitet:
Ich habe es gerade getestet, und es funktioniert tatsächlich. Danke Jungs ;-)

Und ich brech mir nen Ast ab, weil ich das manuell überprüfen wollte ^^
 
Zuletzt bearbeitet:
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]
 
@andr_gin: Ob die Klasse Murks ist tut nichts zur Sache... wirklich verkehrt ist es in meinen Augen nicht. Es ist schon sinnvoll, die BigInteger-Objekte, die von den hier verwendeten RSA-Klassen eingesetzt werden, serialisiert zu speichern...

Oder was wäre deiner Meinung nach die Alternative?
 
Falls wirklich nur der Integer verwendet wird, geht das eventuell noch, aber auch hier hat man keine Kontrolle darüber, ob der Integer als BigEndian oder LittleEndian gespeichert wird.
 

Ähnliche Themen

Zurück
Oben