[gelöst] .txt ausführbar verschlüsselt?

[debnuxer]

Hi !

Bisher verwendete ich immer Locknote von Steganos.

Das erstellte eine mit einem Passwort geschützte und mit AES verschlüsselte .exe aus einer .txt und die Datei blieb auf Anhieb ausführbar.

Kennt jemand vielleicht ein ähnliches Packet mit dem das auch auf Linux möglich ist?

Den gesamten Stick will ich nur ungerne verschlüsseln, zu schützen sind ehe nur einige Textdateien.

[shakky4711]

Einen ähnlichen Thread gibt es hier http://debianforum.de/forum/viewtopic.p ... lit=ccrypt

Ich habe mich bei der gleichen Konstellation (ein paar Text Dateien verschlüsselt auf einem USB-Stick immer bei mir zu haben) für ccrypt entschieden. Ist sehr klein, gibt es für alle Linuxe, FreeBSD und (mittels cygwin.dll auch als Windows Paket mit 1,2MB Größe)

Unter Windows habe ich mir zwei kleine Batch Dateien erstellt, eine mit dem Syntax zum Verschlüsseln und die andere zum Entschlüsseln. Die dann noch mit dem üblichen bat2exe inhaltlich verschleiert und man kann ohne Kommandozeile einfach nur durch Draufklicken im Explorer an die Daten. Ccrypt ist auf allen meiner Debian und FreeBSD Systemen installiert, insofern war das für mich die einfachste Lösung.

Gruß
Shakky

[wanne]

Sowas kannst du ganz einfach erstellen:
Du schreibst einfach fogende Zeilen in eine Datei und packst dann die mittels gpg -a --symmetric verschlüsselte Textdatei darunter:

Code: Alles auswählen

#/bin/sh
gpg -d $0
exit

Wenn du lieber mit private-Keys arbeitest kannst du das --symmetric auch weglassen. (Aber ich glaube, das ist dir so lieber.)
Also die volle Prozedur sieht dann so aus:

Code: Alles auswählen

echo -e '#/bin/sh\ngpg -d $0\nexit' > /datei/auf/Stick.sh
echo "der Text" | gpg -a --symmetric >> /datei/auf/Stick.sh
chmod +x  /datei/auf/Stick.sh

Natürlich lässt sich das echo "der text" auch durch cat /datei/mit/Klartext.txt ersetzen. Wenn der Stick mit FAT formatiert ist kannst du die letzte Zeile weg lassen.
Die Datei dürfte sich dann auf so ziemlich jder Distro ohne zusätzliche Programme ausführen lassen. (gpg wird von so ziemlich jeder Distro für die Paketverwaltung gebruacht und ist deswegen überall schon dabei.)

WARNUNG: Egal was dir irgend jemand erzählt: Es ist technisch unmöglich, eine Datei, die mal im Klartext auf einem Stick abgespeichert wurde nachträglich zu verschlüsseln. Das ist schon bei "gewöhnlichen" HDs glückssache. Bei SSDs oder USB-Sticks kannst du drauf gehen, dass es nicht funktioniert. Die verschlüsselte Datei ist zwar da, aber der Inhalt der alten Datei mit dem Klartext taucht mit der Zeit wider auf. (Zwar nicht als Datei, aber so dass man ihn mittels dd wider herholen kann.

[Cae]

Frage am Rande, was machst du, wenn dein Stick mit noexec in der fstab steht und du nur ein Benutzerkonto hast?

Gruß Cae

[DeletedUserReAsG]

WARNUNG: Egal was dir irgend jemand erzählt: Es ist technisch unmöglich, eine Datei, die mal im Klartext auf einem Stick abgespeichert wurde nachträglich zu verschlüsseln.

Aus zwei Gründen würde ich nun keine Panik entstehen lassen: einerseits ist es für $normalmensch nicht möglich, die Speicherzellen direkt auszulesen und b) kann man sehr wohl einen Stick nullen. Wenn dessen wear-leveling Zellen ausgelagert hat, nicht mehr komplett, aber dann ist es noch schwerer, an die verbliebenen Fragmente heranzukommen, als es so schon ist.

cu,
niemand

[wanne]

inerseits ist es für $normalmensch nicht möglich, die Speicherzellen direkt auszulesen

Also was an dd if=/dev/sdxX so schwer sein soll weiß ich nicht. Ich habe schon mehrmals Dateien widerhergestellt, indem ich einfach dd zusammen mit grep düber die gesamte Partitionlaufen lassen habe. Ist komischerweise sogar einigermasen performant.

kann man sehr wohl einen Stick nullen. Wenn dessen wear-leveling Zellen ausgelagert hat, nicht mehr komplett, aber dann ist es noch schwerer, an die verbliebenen Fragmente heranzukommen, als es so schon ist.

Die können aus Zufall wider auftauchen. Aber ich gebe dir recht ausnullen ist in vielen Fällen eine ausreichende Lösung. Aber ich glaube nicht, das er bie jedem encrypten den ganzen Stick ausnullen will. Das braucht ewig und ist dazu noch eine unnötige belastung für den Stick.
=> Das kann eine Lösung sein, wenn der Klartext versehentlich doch mal auf den Stick kam. Aber als soll-Lösung einfach den Klartext auf den Stick packen und dann die Datei verschlüsseln und den alten inode mehrmals überschreiben (wie das diverse Tools machen) ist keine Lösung. Vor solchen Ansätzen wollte ich warnen.
Wenn die Lösung einigermasen sicher sein soll, dann muss sie im RAM oder auf der sicheren HD encrypten und nicht auf dem Stick. Lieber DES (Weil das bekommt echt praktisch niemand geknackt.) als so eine Lösung.

[debnuxer]

Danke für die Tipps, nun hab ich mich für ccrypt entschieden.

[DeletedUserReAsG]

Da das Thema offensichtlich gelöst ist, noch ein wenig OT:

Also was an dd if=/dev/sdxX so schwer sein soll weiß ich nicht. Ich habe schon mehrmals Dateien widerhergestellt, indem ich einfach dd zusammen mit grep düber die gesamte Partitionlaufen lassen habe

Je nach Szenario. Bei mehreren GB Daten eine Passwortdatei zu finden, wird so schon etwas schwieriger. Aber es ging mir um das direkte Auslesen der Speicherbausteine.

Die können aus Zufall wider auftauchen

Magische Selbstheilung und Reintegration durch den Controller bei 10€-Sticks? Ich weiß nicht …

Lieber DES (Weil das bekommt echt praktisch niemand geknackt.) als so eine Lösung.

Oha. Lieber nochmal nachlesen. Für DES in seiner Reinform muss ich nicht mal Cuda bemühen, um es in ansprechender Zeit zerlegen zu können.

Kommt drauf an, wie paranoid man ist, und welchen Aufwand man betreiben möchte. Die tollste Verschlüsselung ist spätestens dann hinfällig, wenn das System, von dem aus die Datei gelesen wird, kompromittiert ist. Oder auch nur unsicher konzipiert, wie ich es von älteren Win-Versionen noch kenne.

cu,
niemand

[wanne]

Magische Selbstheilung und Reintegration durch den Controller bei 10€-Sticks? Ich weiß nicht …

Auch bei USB-Sticks kann es Wear-Levelling geben.

Lieber DES (Weil das bekommt echt praktisch niemand geknackt.) als so eine Lösung.

Oha. Lieber nochmal nachlesen. Für DES in seiner Reinform muss ich nicht mal Cuda bemühen, um es in ansprechender Zeit zerlegen zu können.

Na das will ich sehen. Wetten, dass du es auch mit CUDA nicht schaft. (Ich glaube aber das CUDA der falsche Weg ist.)
Hier bitte: Du hast 7 Tage Zeit, das zu entschlüsseln:

Code: Alles auswählen

4c 0e 1e 6d cb 38 98 16  70 0e fc 8e 01 e1 00 3b
42 ed 54 ab 66 ca 29 57  76 03 bf 26 86 a2 31 33
ab 42 4c e1 9d f9 6a 0f  48 a2 99 77 14 38 f9 4c
9a 98 20 7f f1 87 0b 43

Je nach Szenario. Bei mehreren GB Daten eine Passwortdatei zu finden, wird so schon etwas schwieriger.

Falls du KDE versendest, und die Passwörter unferschlüsselt speicherst: Lass das mal über deine HD laufen (Das PW gibt's dann mit nem leicht abgewandelten Cesar (Wenn du mir die ausgabe gibst gebe ich dir deine PWs.) Und das ist die ganze Home-Partiton nicht ein USB-Stick:

Code: Alles auswählen

dd if=/dev/mapper/crypt_sde6 | grep -A 20 AccountID | grep Password

[DeletedUserReAsG]

Auch bei USB-Sticks kann es Wear-Levelling geben.

Ich ging vom Nullen des Sticks aus. Nicht gelöscht würden dabei meinem Verständnis nach lediglich Dateifragmente, die in als defekt markierten Zellen liegen, und die tauchen bei dd auch nicht mehr auf. Direktes Auslesen wäre die einzige Möglichkeit. Wie gesagt, das ist mein Kenntnisstand. Sollte der falsch sein, würde ich mich über entsprechende Doku freuen.

Na das will ich sehen. Wetten, dass du es auch mit CUDA nicht schaft. (Ich glaube aber das CUDA der falsche Weg ist.)
Hier bitte: Du hast 7 Tage Zeit, das zu entschlüsseln:

Code: Alles auswählen

4c 0e 1e 6d cb 38 98 16  70 0e fc 8e 01 e1 00 3b
42 ed 54 ab 66 ca 29 57  76 03 bf 26 86 a2 31 33
ab 42 4c e1 9d f9 6a 0f  48 a2 99 77 14 38 f9 4c
9a 98 20 7f f1 87 0b 43

Challenge accepted. Wenngleich ich mangels Vorarbeit wahrscheinlich tatsächlich keine Chance habe. Aber ich erwarte in sieben Tagen dann auch den Schlüssel, um nachzusehen, ob es wirklich DES ist. Was Cuda angeht: ich denke schon, dass 192 parallel testende Kerne (in meinem Fall, GTX260) Vorteile gegenüber den zwei CPU-Kernen haben.

Ich bitte dich an dieser Stelle, die verschlüsselten Bytes noch in eine eindeutige Reihenfolge zu bringen, deine Darstellungsweise erlaubt zwei Interpretationsmöglichkeiten, und ich will nicht massig Strom verschwenden, weil ich die falsche gewählt habe.

Eigentlich wollte ich zwar nur auf „Weil die Schlüssellänge nur 56 Bit beträgt, konnte DES bereits durch Brute-Force-Angriffe gebrochen werden, indem systematisch alle möglichen Schlüssel (256 = ca. 72 Billiarden) getestet wurden.“ (Wikipedia) hinaus und darauf hinweisen, dass es seit Jahren nicht mehr als ausreichend sicher betrachtet wird, und es für heutige Maßstäbe sichere Verfahren gibt, aber nun gut …

Falls du KDE versendest, und die Passwörter unferschlüsselt speicherst: […]

Weder verwende ich KDE, noch sind meine Passwörter in irgendwelchen Dateien gespeichert, die einen zum Greppen sinvollen String enthalten.

Your turn.

niemand

[cirrussc]

Das ist schon bei "gewöhnlichen" HDs glückssache.

Klassische Festplatten überschreiben die betroffenen Sektoren aber (vorausgesetzt man hat wirklich alle); da ist ohne Eingriffe in Firmware und Hardware der HDD nichts "wiederzuholen".

Lieber DES (Weil das bekommt echt praktisch niemand geknackt.) als so eine Lösung.

Und deswegen nimmt sich niemand nun der Herausforderung an

Aber es ging mir um das direkte Auslesen der Speicherbausteine.

Diese DiscOnChip-Speicher sind eh proprietären Mysterien unterworfen, welche manchmal sogar selbst die komplette Speicherverwaltung erledigen.

[DeletedUserReAsG]

Ah, vergessen: wanne, einen kleinen Hinweis auf den Inhalt der Message bräuchte ich noch. Wenn es Text sein sollte, würden mir Zeichensatz und Sprache wahrscheinlich sehr helfen.

cu,
niemand

[wanne]

ich denke schon, dass 192 parallel testende Kerne (in meinem Fall, GTX260) Vorteile gegenüber den zwei CPU-Kernen haben.

Ja schon aber du brauchst trotzdem mehere Monate. Es gibt da noch andere Möglichkeiten als mit der CPU zu brutforcen.

und es für heutige Maßstäbe sichere Verfahren gibt

Ich hatte es ja als Beispiel für schlechte Crypto gewählt. (Wobei es im Moment immernoch fast ungebrochen ist.) Und wollte damit nur zum Ausdruck bringen, das die Implementierung meist viel einfacher anzugreifen ist, als der Algorythmus selbst.

Wenn es Text sein sollte, würden mir Zeichensatz und Sprache wahrscheinlich sehr helfen.

Ja selbst Cesar ist gut wenn man nicht weiß nach was man sucht (und die Nachricht kurz ist). Das war eigenlich mit eingepreist. Aber gut: Deutsch ASCII (eigentlich UTF-8).

Ich bitte dich an dieser Stelle, die verschlüsselten Bytes noch in eine eindeutige Reihenfolge zu bringen, deine Darstellungsweise erlaubt zwei Interpretationsmöglichkeiten

Ist eigentlich Wurst. (Die 7 Blöcke sind ja unabhängig voneinander verschlüsselt. Ich nahm an, das du mit reinem DES ECB vorschreiben wolltest.) Aber es ist die Ausgabe von hexdump -C also so wie es prkatisch jeder Hex-Editor anzeigt. Aber egal wie du die bytes anordnest, wenn du den Schlüssel hast kommt ne ASCII Nachricht raus. Du weist dann schon, dass du getroffen hast.

[wanne]

Auch bei USB-Sticks kann es Wear-Levelling geben.

Ich ging vom Nullen des Sticks aus. Nicht gelöscht würden dabei meinem Verständnis nach lediglich Dateifragmente, die in als defekt markierten Zellen liegen, und die tauchen bei dd auch nicht mehr auf. Direktes Auslesen wäre die einzige Möglichkeit. Wie gesagt, das ist mein Kenntnisstand. Sollte der falsch sein, würde ich mich über entsprechende Doku freuen.

Naja, teurere USB-Sticks verschieben oft genutzte Blöcke beim nächsten Übreschribvorgang in einen nicht adressierbaren Bereich. Wenn die anderen noch öfter überschrieben wurden, holt er sie da wider raus und verschiebt die dann da hin. Das zu provizieren ist wohl nicht so einfach. Aber wenn man den Stick nach ein paar Wochen in die Hände bekommt, kann der Block aus Zufall wider an irgend einer Stelle aufgetaucht sein.

[wanne]

noch sind meine Passwörter in irgendwelchen Dateien gespeichert, die einen zum Greppen sinvollen String enthalten.

Also in praktisch jeder unverschlüsselten Datei befinden sich typische Byte-Seqeunzen. Für den FF bietet sich da z.B %password-checkVersion und moz_disabledHosts an.

[DeletedUserReAsG]

Ja schon aber du brauchst trotzdem mehere Monate.

Wird sich zeigen. Das Geheimnis von COPACOBANA und RIVYERA war, soweit ich das gerade überblicke, deren Möglichkeit, parallel zu rechnen. Im Moment scheint aber das Aussieben von möglichen Schlüsseln und das Verifizieren der übriggebliebenen Schlüssel am nächsten Block der Punkt zu sein, der zuviel Zeit frisst. Die Wettbewerbe (bei denen der Schlüssel vor Jahren schon in wenigen Stunden gefunden wurde), gingen von bekanntem Klartext aus.

Es gibt da noch andere Möglichkeiten als mit der CPU zu brutforcen.

Ja, nur habe ich a) nicht die Ahnung davon, und b) nicht die Möglichkeit, mal eben die 64TB Klartext/Schlüsseltextpaare zu laden und unterzubringen.

Ich hatte es ja als Beispiel für schlechte Crypto gewählt.

Hättest du dazuschreiben sollen, dann hätte ich nun nicht angefangen

(Wobei es im Moment immernoch fast ungebrochen ist.)

Das meinte ich mit „Oha. Lieber nochmal nachlesen.“ – schon die erste Anlaufstelle (ich gebe zu, ist bei mir Wikipedia), listet auf, wann es das erste Mal in weniger als 24h geknackt wurde (vor über dreizehn Jahren(!)) und wann er mit vergleichsweise erschwinglichen Maschinen in weniger als einem Tag geknackt wurde (vor knapp 3,5 Jahren). Heute hat Amazon GPU-Rechenwölkchen, es gibt Netzwerke für verteiltes Rechnen und was nicht alles. Heute noch zu schreiben: „Lieber DES (Weil das bekommt echt praktisch niemand geknackt.)“, ist grob fahrlässig.

Unabhängig davon, ob ich das nun hinbekomme – mir geht’s um das Prinzip. Wenn ich nun zeigen kann, dass mein Rechner das in einem Monat berechnen könnte, oder auch länger, lässt sich das auf aktuelle Hardware und Möglichkeiten hochrechnen. Und ich behaupte immer noch, dass es da keinen Tag und wenig Geld braucht (wenn man die Hardware nicht rumstehen hat, mietet man halt für eine Handvoll Euro die Rechenleistung. Oben erwähnten COPACOBANA konnte man übrigens auch für nicht zuviel Geld mieten.

Ich haue mich erstmal ins Bett, mir raucht der Kopf. Vielleicht mag ein Mod, wenn er hier drüberstolpert, unseren Teil vom Thread abtrennen und in Smalltalk verschieben? Und falls mir jemand helfen möchte, kann er sich gerne via PN melden

cu,
niemand

[uname]

Ich habe nicht alles gelesen, wollte jedoch eine kleine Lösung präsentieren, auch wenn sie vielleicht nicht mehr interessiert.

test.txt

Code: Alles auswählen

#! /bin/bash
echo "Test"

Verschlüsselung.
cat test.txt | aespipe > test.aes

Entschlüsselung und Ausführung:

Code: Alles auswählen

cat test.aes | aespipe -d | bash

Nicht schön aber hässlich. Passwort muss mindestens 20 Zeichen lang sein. Als Paket wird aespipe benötigt. Den Shebang kann man noch weglassen. Auch hier erkennt man, dass man erst entschlüsseln und dann ausführen müss.

Sollte es Programme geben, die dieses in einem Schritt können, so sieht es schlecht für die "Glaubhafte Abstreitbarkeit" aus

[wanne]

(Wobei es im Moment immernoch fast ungebrochen ist.)

Das meinte ich mit „Oha. Lieber nochmal nachlesen.“ – schon die erste Anlaufstelle (ich gebe zu, ist bei mir Wikipedia), listet auf, wann es das erste Mal in weniger als 24h geknackt wurde (vor über dreizehn Jahren(!))

Das es per brute force geknackt werden kann war von anfang an absicht. Man wollte eine Krypo schafffen, die sich knacken lässt (Was anderes hätte man entweder nicht ausführen dürfen oder es währe extrem Rechenaufwenig und kompliziert geworden.) aber eben nur von Leuten mit viel Rechenleistung. Das nenne ich nicht gebrochen.

Und ich behaupte immer noch, dass es da keinen Tag und wenig Geld braucht (wenn man die Hardware nicht rumstehen hat, mietet man halt für eine Handvoll Euro die Rechenleistung. Oben erwähnten COPACOBANA konnte man übrigens auch für nicht zuviel Geld mieten.

Mir würde sogar jemand einfallen, der's um sonst machen würde wenn man einen guten Grund hätte. (Den du zum Glück nicht hast.) Das war aber das was ich damit meinte, das es bessere methoden als deine GPU gibt. All das will ich auch nicht bestreiten. Aber wenn's nur drum geht, dass niemand auf anhieb die Pornos findet reicht's meistens.

PS: Ich fände es auch cool, wenn man den Teil mit der Wette abtrennt.

[uname]

offtopic:
Falls mal jemand ein interessantes Buch zum Thema Verschlüsselung lesen will:

Geheime Botschaften. Die Kunst der Verschlüsselung von der Antike bis in die Zeiten des Internet. (dtv-Verlag)

[hikaru]

völlig OT:

Lieber DES (Weil das bekommt echt praktisch niemand geknackt.) als so eine Lösung.

Und deswegen nimmt sich niemand nun der Herausforderung an

In diesem Kontext ist der Benutzername genial!

[wanne]

So, jetzt sind's noch 2 Tage brauchst du verlängerung oder soll ich mogen (wir haben nach 12) auflösen?

[DeletedUserReAsG]

Im Grunde könntest du auflösen. Das Projekt ist bei mir ein wenig in den Hintergrund geraten, wenngleich noch nicht tot.

„Gebrochen“ ist eine Verschlüsselung für mich, wenn $normalmensch innerhalb akzeptabler Zeit in der Lage ist, an den Klartext zu kommen – gleich, ob nun mit reiner Rechenleistung oder Kryptoanalyse. Dass Ersteres bei DES möglich ist, gedenke ich weiterhin zu demonstrieren. Kann aber noch etwas dauern, zur Zeit ist anderes wichtiger.

cu,
niemand

[wanne]

Alo der Key war:

Code: Alles auswählen

8caffee6ab4fe15b

Zumindest in nächster Zeit mache ich die Wette auf jeden Fall wieder ich würde mal schätzen man braucht immer noch 5000 bei gut optimierten Code 500 Moderne Hochleistungs-GraKas umd DES in 7 Tagen zu knaken. Aber wenn's jemand schafft will ich den Source...