Gibt es Verschlüsselungsprogramme die Fehler in einer Datei kompensieren können?

[Catonga]

Gibt es redunante Verschlüsselungsprogramme
bei denen man die verschlüsselte Datei auch dann noch entschlüsseln
kann wenn ein Teil der Datei defekt ist?



Also ähnlich wie bei Packprogrammen die die Daten in einer Datei teilweise selbst dann wieder retten können wenn ein Teil der Datei defekt ist?


Wenn man nämlich z.b. eine Datei erstellt und
diese dann mit GnuPG verschlüsselt und bei der verschlüsselten Datei
nur ein einziges Bit umkippt, dann kann man die Datei nicht mehr wiederherstellen..
(Man kann das Bit umkippen mit einem Hexeditor erledigen und ausprobieren)


Beim Packer wäre es etwas anderes, da kann die Datei wieder entpackt werden
falls 1 Bit oder ein paar mehr umkippen, jetzt bräuchte ich das gleiche für Verschlüsselungsprogamme.


Oder ist die einzige Möglichkeit die Datensicherheit einer verschlüsselten Datei zu gewährleisten nur die, in dem man die verschlüsselte Datei nochmals
mit einem Packer (z.b. Gzip) packt, der dieses Reparaturfeature im Gegensatz zum alleinigen GnuPG bietet?


Denn was habe ich vom besten Verschlüsselungsalgorithmus,
wenn ich die Daten nicht mehr entschlüsseln kann, weil das Backup Medium
einen kleinen Defekt hatte?

[Thomas Engelke]

Hängt das nicht vom Algorithmus ab? Ich stelle mir da die Frage, wie du "entschlüsseln" definierst.

Ich kann ja durch "zufällige" Veränderungen der Bits irgendwann durch Zufall auf die richtige Datei kommen. Wie jedoch bemerke ich, das dies die eigentlich gewollte Art der Datei ist? Das geht nur über Querprüfungen, wie sie beispielsweise CRCs bieten. Sind nun die CRCs über einen bestimmten Abschnitt der Datei gespannt (pro 1k eine CRC) und nicht inkrementell (nach jedem 1k eine CRC, die die letzte existierende CRC mitrechnet), so sollte das möglich sein.

Aber das ist alles nur amateurhaftes Gefasel.

AD!

[LX-Ben]

WinRAR hat so etwas (Datensicherheitsinformationen speichern/ Wiederherstellungsinformationen), dürfte also bei Linux-RAR auch enthalten sein. Und (mit ziemlich hoher Sicherheitsstufe) kann RAR auch verschlüsseln.

Doch kostet 'Speichern mit Wiederherstellungsinformationen' viel Zeit und ist letztlich nutzlos, sofern ein Datenträgerfehler auftritt. Rationeller ist es deshalb, die Sicherungsabstände zu verkürzen und auf jeweils getrennte externe Sicherungsdatenträger zu achten, evtl. auch noch unterschiedliche Aufbewahrungsorte.

[Jasper]

Original geschrieben von Catonga
Gibt es redunante Verschlüsselungsprogramme
bei denen man die verschlüsselte Datei auch dann noch entschlüsseln
kann wenn ein Teil der Datei defekt ist?


damit würdest du die verschlüsselung schwächen. für die wiederherstellung müssten ja zusätzliche redundante informationen abgespeichert werden mittels derer man auf die verschlüsselten daten rückschliessen könnte. simples beispiel: parity-bit.


-j

[Catonga]

Original geschrieben von Jasper
damit würdest du die verschlüsselung schwächen. für die wiederherstellung müssten ja zusätzliche redundante informationen abgespeichert werden mittels derer man auf die verschlüsselten daten rückschliessen könnte. simples beispiel: parity-bit.


-j

Nicht wenn die Datei in Abständen z.b. alle 4 Byte mit einer Prüfsumme versehen wird.

Das wäre im Grunde eigentlich auch nach dem Verschlüsseln möglich.

In meinem Buch Computerarchitektur von Andrew Tanenbaum steht
da sowas drin wie das genau funktioniert (Parity-Bit ist schonmal die richtige Richtung), aber leider habe ich das Buch gerade nicht da.

Im Grunde wäre es aber klasse wenn so ein Feature standardmäßig in GnuPG einebaut wäre, so das man beim Verschlüsseln nur noch so ne Parity Option angeben muß und die Datei dann so abgelegt wird, das sie zusätzlich noch
Parity Bits enthält.

[Catonga]

Original geschrieben von LX-Ben
Und (mit ziemlich hoher Sicherheitsstufe) kann RAR auch verschlüsseln.

Welchen Algorithmus verwendet RAR zum Veschlüsseln?




Doch kostet 'Speichern mit Wiederherstellungsinformationen' viel Zeit und ist letztlich nutzlos, sofern ein Datenträgerfehler auftritt.


Wieso? Das kommt doch auf die Schwere des Datenträgerfehlers an.
Wenns nur ein leichter Krazer ist...



Rationeller ist es deshalb, die Sicherungsabstände zu verkürzen und auf jeweils getrennte externe Sicherungsdatenträger zu achten, evtl. auch noch unterschiedliche Aufbewahrungsorte. [/B]

Ja, das wäre eine Möglichkeit.

Ist halt leider IMHO nur etwas aufwendig und teuer.



Inwiefern bietet denn der ISO9660 Standard für CDs überhaupt eine Datensicherheit?
Gibt es da so etwas wie Parity Bits?

[Jasper]

Original geschrieben von Catonga
Nicht wenn die Datei in Abständen z.b. alle 4 Byte mit einer Prüfsumme versehen wird.

Das wäre im Grunde eigentlich auch nach dem Verschlüsseln möglich.


ein checksumming nach der verschlüsselung hat aber nichts mehr mit der verschlüsselung an sich zu tun. das kannst du natürlich machen. dabei wird die verschlüsselungsstärke nicht beeinflusst.



In meinem Buch Computerarchitektur von Andrew Tanenbaum steht
da sowas drin wie das genau funktioniert (Parity-Bit ist schonmal die richtige Richtung), aber leider habe ich das Buch gerade nicht da.


oje, der olle tanenbaum. ist das immer noch pflichtlektüre im informatikstudium? :)

was du meinst ist vermutlich hammingcode. wird wenn ich mich noch recht entsinne im tanenbaum behandelt.



Im Grunde wäre es aber klasse wenn so ein Feature standardmäßig in GnuPG einebaut wäre, so das man beim Verschlüsseln nur noch so ne Parity Option angeben muß und die Datei dann so abgelegt wird, das sie zusätzlich noch
Parity Bits enthält.

das bläht das file aber ordentlich (fast 50% auf). hamming benötigt 3 error bits für 4 datenbits. sags doch mal den gnupg-leuten, vielleicht bauen die es ein.


-j

[LX-Ben]

Und (mit ziemlich hoher Sicherheitsstufe) kann RAR auch verschlüsseln. -- Welchen Algorithmus verwendet RAR zum Veschlüsseln?(Mir) nicht bekannt. Erfolgreiche Angriffe sind nur mit bruteforce bekannt, allerdings oberhalb von 6stelligem Kennwort (Buchstaben, Ziffern, Sonderzeichen) aus Zeitgründen praktisch aussichtslos.


Rationeller ist es deshalb, die Sicherungsabstände zu verkürzen und auf jeweils getrennte externe Sicherungsdatenträger zu achten, evtl. auch noch unterschiedliche Aufbewahrungsorte. -- Ja, das wäre eine Möglichkeit. Ist halt leider IMHO nur etwas aufwendig und teuer.Bei den heutigen Anschaffungskosten für CDRW- bzw. DVD-RW sicher keine große Hürde mehr. Und billiger als ein Neuanfang :)

[amun]

Original geschrieben von Catonga
Gibt es redunante Verschlüsselungsprogramme
bei denen man die verschlüsselte Datei auch dann noch entschlüsseln
kann wenn ein Teil der Datei defekt ist?


die gängigen symetrischen verschlüsselungsalgorithmen wie DES oder blowfish sind blockchiffren. d.h. der plaintext wird in gleichgroße blöcke aufgeteilt, jeweils verschlüsselt und im einfachsten fall wieder in gleicher reihenfolge zusammengesetzt. DES werwendet 8 byte große blöcke. ein fehlerhaftes bit würde also einen 8 byte großen block unlesbar machen bzw. 7 byte, da ein byte als parity-byte benutzt wird.
je nach algorithmus werden die blöcke aber nach einem verschlüsselungsdurchgang vermischt oder vertauscht. dadurch erzeugt ein fehlerhafte block der ersten runde in der nächsten runde mindestens einen neuen fehlerhaften block.
ein paar fehlerhafte bits sollten also eine block-chiffrierte-datei nicht komplett unbrauchbar machen.
ich denke gnu-pgp merkt anhand von parity-bits, dass ein block fehlerhaft ist und bricht dann einfach die entschlüsselung ab.
versuch es mal mit bestcrypt (www.jetico.com). das programm erstellt verschlüsselte container-dateien, die unter window und linux gemountet werden können. außerdem lassen sich in den containern "versteckte bereiche anlegen". ist ein 100 MB container mit 10 MB daten gefüllt, wird der 90-MB-rest mit zufälligen bits gefüllt. da in den restelichen 90 MB auch irgendwo verschlüsselte nutzdaten anfangen könnten, weiß ein angreifer weder ob noch wo verschlüsselte daten in dem container liegen.
denke nicht, dass es in den containern dann paritäts bits gibt. sonst könnte ein angreifer ja erkennen ob in dem container nur datenmüll oder noch nutzdaten liegen.

gruß, amun

edit:
hier steht genaueres zu DES:
http://home.nordwest.net/hgm/krypto/mod-sym.htm

[fsd]

ein fehlerhaftes bit würde also einen 8 byte großen block unlesbar machen bzw. 7 byte, da ein byte als parity-byte benutzt wird.

Das würde bedeuten, dass die verschlüsselten Daten größer sind, als die unverschlüsselten. Dies trifft bei Blowfish jedoch nicht zu. Es wird lediglich auf den nächsten vollen 8 byte block gepaddet.

MFG fsd.

[amun]

Original geschrieben von fsd
Das würde bedeuten, dass die verschlüsselten Daten größer sind, als die unverschlüsselten. Dies trifft bei Blowfish jedoch nicht zu. Es wird lediglich auf den nächsten vollen 8 byte block gepaddet.

MFG fsd.

hab ich was anderes behauptet??
habe nur geschrieben das es bei DES ein paritäts-byte gibt.

[sauertopf]

Original geschrieben von Jasper
das bläht das file aber ordentlich (fast 50% auf). hamming benötigt 3 error bits für 4 datenbits. sags doch mal den gnupg-leuten, vielleicht bauen die es ein.
-j [/B]

Lieber nicht, laut unix-Philosophie, erfüllt ein Programm immer nur einen Zweck, den aber optimal. Am besten wäre es wohl: Erst komprimieren (entropie maximieren), das Ergebnis verschlüsseln, diesem Ergebnis Redundanz hinzufügen (error-correction-code).

MfG sauer