Diskussion:TrueCrypt/Archiv

aus Wikipedia, der freien Enzyklopädie

TrueCrypt kann garnicht kaskadieren

Um die Diskussion mal für diesen Fall ad Absurdum zu führen: TrueCrypt kann die verschiedenen Algorithmen garnicht kaskadieren. Die List der verfügbaren Algorithmen, die man mit TrueCrypt auswählen und in eine Reihenfolge bringen kann, dienen nicht der kaskadierten Verschlüsselung mit all diesen Algorithmen, sondern stellen nur die Reihenfolge der Algorithmen dar, mit denen TrueCrypt versucht, ein Volume zu entschlüsseln. Da in den Volumes wohl nicht auslesbar ist, welcher Algorithmus verwendet wurde, muss bei der Entschlüsselung einfach ausprobiert werden, welcher Algorithmus vernünftige Resultate liefert. Die Anordnung der Algorithmen in den Einstellungen von TrueCrypt dient lediglich der Priosierung dieser Versuche, also in welcher Reihenfolge die Algorithmen verwendet werden sollen um eine Entschlüsselung zu versuchen. Beim VERschlüsseln muss sowieso ein (!) konkreter Algorithmus angegeben werden. (Vorstehender nicht signierter Beitrag stammt von 194.39.1.130 (Diskussion • Beiträge) 13:22, 13. Nov. 2006 (CEST))

Selbstverständlich kann Truecrypt kaskadieren. Es ist korrekt, das TrueCrypt an einem Volume nicht erkennen kann, wie es verschlüsselt wurde. Das benötigt es auch nicht. Wird versucht ein Volume zu mounten, und schlägt die Entschlüsselung mit AES fehl, so wird danach Twofish und danach Serpent probiert. Gelingt dies immer noch nicht, versucht TrueCryut zuerst AES und das damit entschüsslete, aber vermeindlich sinnlose, mit einem nachfolgenden Serpent zu bearbeiten. Insgesamt startet TrueCrypt bis zu acht Versuche bevor es meldet "Passwort falsch oder kein TrueCryp Volume". --80.129.224.98 07:44, 26. Mär. 2009 (CET)

No Comment

@194.39.1.130 Original Zitat aus Dokumentation von TrueCrypt (Quelle: http://www.truecrypt.org/docs/)

AES-Twofish

Two ciphers in a cascade [15, 16] operating in LRW mode (see the section Modes of Operation). Each 128-bit block is first encrypted with Twofish (256-bit key) and then with AES (256-bit key). Each of the cascaded ciphers uses its own key. All encryption keys are mutually independent (note that header keys are independent as well, even though they are derived from a single password – see Header Key Derivation, Salt, and Iteration Count). See above for information on the individual cascaded ciphers. -- 217.233.136.222 23:04, 28. Jun. 2007 (CEST)

Ja, aber diese Kaskaden sind nicht frei kombinierbar, sondern es gibt bestimmte Kombinationen, die vom Anwender wie ein einzelner Algorithmus ausgewählt werden können; von daher ist es korrekt, daß TrueCrypt (außer den konkreten, hartcodierten Ausnahmen) nicht kaskadiert. --Tobias 20:43, 28. Mai 2008 (CEST)
Bevor das mit dem kaskadieren hier rausgenommen wird müsst ihr das noch aus der Software entfernen und natürlich die Hersteller davon überzeugen das das nicht stimmt was Sie schreiben, viel Spaß wünsche ich auch dabei.
TrueCrypt kann kaskadieren - einfach mal den SourceCode zu Rate ziehen und verstehen. Wie das Entschlüsseln einer kaskadierten Verschlüsselung erfolgt, habe ich oben bereits erwähnt. --80.129.224.98 07:47, 26. Mär. 2009 (CET)

Frage...

Im Text dieses Artikel steht doch folgendes: Versteckte Container (Hidden Volumes) können innerhalb des freien Speicherplatzes eines anderen verschlüsselten Volumes versteckt werden. Wird man z. B. gezwungen, das Passwort für das Volume herauszugeben, gibt man nur das Passwort für das äußere Volume her, das versteckte und mit einem anderen Passwort verschlüsselte Volume bleibt unentdeckt. So sieht ein Angreifer nur unwichtige Alibi-Daten, die vertraulichen Daten sind verschlüsselt im freien Speicherplatz des verschlüsselten Volumes verborgen.

Aber woran erkennt TrueCrypt, dass es dieses versteckte Volume nicht überschreiben darf? Und wenn es einen Mechanismus gibt, der TrueCrypt signalisiert "diesen Bereich nicht überschreiben", dann kann ein Angreifer daraus schließen, dass dort ein hidden Volume liegt. ODer lieg ich da falsch?

Entweder laufe ich gefahr mein hidden-volume zu überschreiben oder es ist offensichtlich, dass es eines gibt.

Wenn man etwas in das nicht-versteckte Volume schreiben möchte, sollte man beide Passwörter (Outer+Hidden) angeben - andernfalls kann das mit dem Überschreiben tatsächlich passieren. 91.62.87.225

Zur Plausible-deniability-Konzept-KRITIK. Gilt nicht immer noch die Unschuldsvermutung ? Ist man nicht per default unschuldig, solange einem das Gegenteil bewiesen ist ? Ich lasse mich aber gern belehren. Data01

Rechtsstaatlich schon. Ob sich ein Krimineller mit vorhaltender Waffe jedoch ans "Unschuldigkeits-Prinzip" hält, ist nicht ganz so sicher ;) --Nyks♂ ► Fragen? 12:27, 28. Nov. 2006 (CET)
Ja ist ja richtig, aber ich wollte nur darauf hinweisen. Das uns die aktuelle Lage und Politik alle zu irgendwas (bitte selber eintragen) abstempelt, steht auf einen anderen Blatt. Aber solange der Generalverdacht jedes Einzelnen noch nicht im Gesetzt verankert ist, denke ich sollte man den von mir erwähnten Abschnitt überdenken.

Data 29.10.06 10:45

Ich kann die Kritik an der plausible-denialbility nicht nachvollziehen. Denn die Nicht-Existenz verschlüsselter Daten kann nie nachgewisen werden. Es kann immmer irgendwo irgendeine Datei rumliegen, die verschlüsseltes enthält. Auch ohne die entsprechende Funktion. Insofern bietet das Konzept hier in meinen Augen nur Vorteile. (Der vorstehende, nicht signierte Beitrag stammt von 129.217.139.225 (Diskussion • Beiträge) 24:35, 15. Sep 2007 (CEST) , nachgetragen durch Nyks)
Du hast Recht. Hier werden Tatsachen durcheinanderergebracht. Zwang (Folter) hat mit dem Problem, des Beweisens von verschlüsselten Daten, nichts zu tun. Wir sollten viel eher die berechtigten Einwände von 129.217.139.225 in den Text einarbeiten! 81.5.207.30 05:22, 19. Sep. 2007 (CEST)

Siehe Protection of Hidden Volumes Against Damage: http://www.truecrypt.org/docs/?s=hidden-volume-protection
Man kann beim Mounten des äusseren Volumes das Password des inneren Volumes angeben, somit achtet TrueCrypt darauf, dass nicht fälschlicherweise im Bereich des inneren Volumes geschrieben wird.
Bei gemountetem äußeren Volume und geschütztem inneren Volume ist aber sichtbar, dass es ein inneres Volume gibt.
Falls ein Angreifer deine Volumes im gemountetem Zustand erwischt (ob inneres oder äußeres geschützt), hat er sicher Kenntnis vom inneren Volume. Falls er jedoch bei ungemounteten Volumes ankommt und dich zwingt, dein Password einzugeben, gibst du ja nur das des Äußeren ein, natürlich ohne Protection. Somit erlangt er kein Wissen über das Innere, maximal kann er, wenn er in das Volume schreibt, Daten des inneren Volumes überschreiben. Da der Header des Inneren jedoch am Ende der Daten liegt (somit auch am Ende der Containerdatei), wird das innere Volume noch mountbar sein, solange er nicht die komplette Containerdatei überschreibt.
Cliffer 29.06.2007 13:37

Sicherheit

Gibt es Informationen darüber, als wie sicher die Verschlüsselung von TrueCrypt anzusehen ist? --Fippo 03:27, 23. Jun. 2007 (CEST)

Meinst du ob die Algorithmen sicher sind, oder ob Truecrypt (als Programm) selbst sicher ist? --ich(?!)

Richtig – es gibt nicht die Verschlüsselung von TrueCrypt. Das Programm selbst läßt sich unterschiedlich sicher betreiben. Wenn man z. B. den Hibernate-Modus des Computers benutzt, sollte man den Auto-Unmount bei Abmeldung oder beim Wechseln in den Energiesparmodus aktivieren. Wenn ansonsten kein oder nur ein unsicheres Benutzerpaßwort gesetzt wäre, wäre es mit dem Schutz der verschlüsselten Daten natürlich nicht weit her... mit Verstand gebraucht, und mit hinreichend sicheren Paßwörtern, ist die Sache aber m. E. sehr sicher. --Tobias 21:01, 28. Mai 2008 (CEST)

Plausible-deniability-Konzept ist weitgehend Pseudosicherheit

Von einer glaubwürdigen Abstreitungsmöglichkeit bezüglich des inneren Volumes kann wohl im Allgemeinen kaum die Rede sein. Das hat mehrere Ursachen:

  • Das innere Volume wird in das Dateisystem des äußeren Volumes geschrieben, siehe [1]. Dabei wird es natürlich dort nicht entsprechend eingetragen - dann würde man es ja sehen, wenn man sich das Dateisystem des äußeren Volumes anschaut - sondern es wird einfach parasitär freier Speicherplatz am Ende des Dateisystems des äußeren Volumes genutzt (muss natürlich vorhanden sein). Aus diesem Grund ist auch zwingend FAT als Dateisystems des äußeren Volumes nötig: für andere Dateisysteme ist Truecrypt zum Einen nicht in der Lage freien Speicherplatz zu erkennen und zum Anderen verteilen einige andere Dateisystem auch Daten auf den gesamten Speicherbereich, so dass kein ausreichend großer Bereich zum Verstecken eines inneren Volumes entsteht (man kann es ja nicht irgendwohin schreiben, denn es soll ja auch nicht das äußere Dateisystem beschädigt werden beim Anlegen des inneren Volumes - wäre ja erst recht auffällig). Aus dieser parasitären Speicherplatznutzung ergeben sich aber einige Probleme:
  1. An der Stelle wo das innere Volume hingeschrieben werden soll, standen vielleicht vorher schonmal Daten innerhalb des äußeren Dateisystems, die aber gelöscht wurden (im Dateisystem des äußeren Volumes als frei markiert bzw. das äußere Dateisystem wurde formatiert). Wenn dort nun plötzlich das innere Volume darübergeschrieben wird, dann ist das eventuell erkennbar, da z. B. die Reste einer Textdatei mitten im Satz abbrechen und ab dort die "Zufallsdaten" des inneren Volumes weitergehen - sehr auffällig. Vermieden werden können solche Dinge nur, wenn das innere Volume direkt mit der Erstellung des TrueCrypt-Containers bzw. der TrueCrypt-Partition mit dem äußeren Dateisystem gleich mit erstellt wird.
  2. Die Benutzung des äußeren Dateisystems kann das versteckte Volume zeigen, denn dieses wird von TrueCrypt vor versehentlichen Schreibzugriffen des äußeren Dateisystems geschützt (nicht dass man aus Versehen durch das Anlegen einer zu großen Datei im äußeren Dateisystem das versteckte Volume irreversibel durch Überschreiben beschädigt), siehe [2]. Insbesondere wenn man zur Aufrechterhaltung des Alibis regelmäßig ein paar Dateien in das äußere Volume schreiben muss, kann es sein, dass das Dateisystem mal in den belegten Bereich des mit dem inneren Volume schreiben will (z. B. wegen starker Fragmentierung des äußeren Dateisystems) und dieser Zugriff fehlschlägt. Damit wäre aber die Übergangsstelle zum inneren Volume deutlich sichtbar - dort brechen plötzlich unvermittelt die Daten ab und es geht mit Zufallsdaten weiter. Das wieder in einen unauffälligen Zustand zu überführen ist relativ kompliziert - am besten man macht dann den gesamten Container wieder neu, was aber eventuell auch auffällt (Warum wurde der anscheinend grundlos erneuert?). Selbst wenn man mit regelmäßigen Defragmentierungen verhindert, dass das äußere Dateisystem plötzlich Dateien in den gesperrten Bereich schreiben will, dann stellen diese Defragmentierungen selbst natürlich schon wieder eine Auffälligkeit dar - je nach Größe des versteckten Volumes wäre doch noch jede Menge defragmentierter Platz verfügbar gewesen und damit kein Grund zur Defragmentierung da.
  3. Auch die Formatierung des äußeren Volumes mit FAT (was zwingend notwendig ist, wenn es ein verstecktes Volume geben soll) kann schon eine gewisse Auffälligkeit erzeugen - es gäbe doch jede Menge andere Dateisysteme. Natürlich ist das nur ein geringer Anhaltspunkt, am Ende von [3] wird empfohlen, sich darauf hinauszureden, dass es ja die Standardeinstellung ist.
  4. Ein weitere Anhaltspunkt für die Existenz eines versteckten Volumes kann auch die sehr unvollständige Speicherplatznutzung innerhalb des äußeren Volumes sein, je nach Größe des inneren Volumes. Beispiel: Warum erzeugt man eine 4 GB große Containerdatei und benutzt selbst nach einigen Monaten/Jahren nur 500 MB davon? Insbesondere wenn man an den Daten innerhalb des äußeren Volumes nicht regelmäßig etwas ändert, sondern nur einmalig ein paar Dateien reingeschoben hat, stellt sich die Frage.
  5. Auch schwierig ist eventuell die Bestückung des äußeren Volumes: wenn man zu banale Daten reinpackt, stellt sich die Frage was das soll (insbesondere wenn man vielleicht bezüglich Sicherheitsfragen geht) und ob das nicht extra zur Täuschung dient - zu sensible Daten will man natürlich auch nicht reinpacken.
  • Es gibt erhebliche Sicherheitsprobleme bezüglich von Metadaten, insbesondere wenn es sich um eine Containerdatei und nicht um eine Containerpartition handelt. So speichern fast alle Dateisysteme die Zeit des (letzten) Schreibzugriffes zu einer Datei. Wenn man nun im inneren Volume etwas ändert, dann fällt auf, dass es einen Schreibzugriff auf die Containerdatei gegeben hat, aber gleichzeitig gar kein Schreibzugriff innerhalb des äußeren Dateisystems stattgefunden hat. Es muss also in dem Container noch etwas anders drin sein. Weitere Probleme kann es geben, wenn verschiedene Versionen der Containerdatei auf einem Datenträger existieren, beispielsweise nach einer Defragmentierung (Container wurde verschoben - alte Version in Form von freigegebenen Speicherblöcken aber noch physikalisch vorhanden), weil die Container-Datei in einem Journaling-Dateisystem gespeichert ist (vorzunehmende/vorgenommene Änderungen stehen noch im Journal oder in dem vom Journal ehemals okkupierten Speicherplatz) oder weil der zu Grunde liegende Datenträger Schreibzugriffe immer wieder auf neue Sektoren lenkt, um übermäßigen Verschleiß einzelner Stellen wegen Hot-Spot-Bildung zu vermeiden (Änderungen werden an eine neue Stelle geschrieben, alte Version wird als frei markiert und irgendwann mal wieder überschrieben). In allen Fällen könnte wegen der nun 2 vorhandenen Versionen (von Teilen) der Containerdatei auffallen, dass sich Sektoren im eigentlich freien Speicherplatz des äußeren Dateisystems geändert haben und nun anders "zufällig" aussehen. Dafür gibt es aber normalerweise keinen Grund, also muss sich an der Stelle ein verstecktes Volume finden, siehe dazu auch [4].
  • Ein weiterer Anhaltspunkt kann sich vielleicht schon auch aus der Nutzung von TrueCrypt selbst ergeben. Warum nimmt man ausgerechnet dieses Verschlüsselungsprogramm?

Fazit: insgesamt hängt die Sicherheit hier am sehr, sehr seidenen Faden und es gibt extrem viele Sicherheitsprobleme und Fallstricke bezüglich der glaubwürdigen Abstreitungsmöglichkeit (d. h. es dürfte nichtmal einen Anhaltspunkte für versteckte Daten geben). Man kann also definitiv nicht pauschal behaupten, dass es sehr schwierig ist, die Existenz verschlüsselter Daten nachzuweisen, wie es der Artikel momentan tut. Ganz im Gegenteil: es ist sehr schwierig die Existenz verschlüsselter Daten versteckt zu halten.--Innenrevision 18:18, 4. Jul. 2007 (CEST)

Mein Fazit: Du hast gerade in epischer Breite die alte Weisheit zusammengefasst, daß es absolute Sicherheit nie gibt. Trotzdem sehe ich nur Vorteile am Prinzip der plausible-denialability. Ich könnte jetzt zu jedem Kitikpunkt von dir ein Szenariozeigen, daß durchaus Sinn macht und die Schwachstelle nicht hat. Fakt ist jedoch, daß man durch Hidde Volumes nur an Sicherheit dazugewinnt. (Der vorstehende, nicht signierte Beitrag stammt von 129.217.139.225 (Diskussion • Beiträge) 24:35, 15. Sep 2007 (CEST) , nachgetragen durch Nyks)
Am Prinzip der glaubwürdigen Abstreitbarkeit wurde ja auch gar nichts ausgesetzt - nur an der mangelhaften Umsetzung (mir ist natürlich bewusst, dass es kaum besser geht, aber dann sollte man halt vorsichtig mit solche Begriffen agieren, die man nur mangelhaft umsetzen kann). Es ist ja durchaus schön, dass dir jeweils eine Möglichkeit für ein Szenario einfällt, wo tatsächlich kein Sicherheitsleck besteht. Um solche Best-Case-Fälle geht es aber bei Sicherheitsbetrachtungen nicht, sondern man geht in der Regel vom schlimmsten Fall aus. Das hat den ganz einfach Grund, dass man nie weiß, wie teuer ein *Ups, dumm gelaufen* werden kann. Wenn dein Leben davon abhängen würde, dass die Existenz eines auf diese Art versteckten Volumes nicht bekannt wird, dann würdest du sicherlich vorher ganz genau wissen wollen, was die Grenzen der Anwendung sind und wie glaubwürdig du die Existenz unter welchen Umständen abstreiten kannst. Da ist der Artikel momentan einfach gummihaft, indem man schreibt "es sei sehr schwierig" die Existenz nachzuweisen - so schwierig muss das gar nicht sein.--Innenrevision 11:16, 27. Sep. 2007 (CEST)
"es ist sehr schwierig, die Existenz nachzuweisen" ist nach wie vor korrekt. Denn Hinweise und Indizien für die Existenz versteckter Container, wie Du sie aufführst, sind eben keine Nachweise. Immer schön auf die exakte Formulierung achten ;-) 84.58.48.166 13:51, 28. Okt. 2009 (CET)

Transparente Ver- und Entschlüsselung bei kommerziellen Closed-Source-Produkten

"Transparente Ver- und Entschlüsselung von Daten bieten neben TrueCrypt außerdem AxCrypt, CrossCrypt, dm-crypt sowie die kommerziellen Closed-Source-Produkte SafeGuard Easy und DriveCrypt sowie PGPdisk." - Inwiefern können kommerzielle Closed-Source-Produkte transparent sein? --CyborgMax 13:02, 30. Jul. 2007 (CEST)

Transparent meint nicht das Programm, sondern die Art der Verschlüsselung bzw. die Art der Anwendung: Wurde der Container einmal gemountet merkt man beim normalen Arbeiten nichts davon, dass man mit einem verschlüsseltem Laufwerk arbeitet. Man spricht dann von transparenter Verschlüsselung. Bei Programmen wie PGP muss man hingegen jede Datei einzeln von Hand verschlüsseln. Folglich ist die Verschlüsselung mit PGP auch nicht transparent. BjörnK 21:22, 2. Aug. 2007 (CEST)
Transparenz ist so ein schöner Begriff, einmal bedeutet es Unsichbarkeit, wie in diesem Falle, man merkt nichts davon dass das Laufwerk verschlüsselt wird es verhält sich wie ein normales Laufwerk. Ein anderes mal bedeutet es Durchschaubarkeit im Sinne von Nachvollziehbarkeit, wie bspw. Open Source, man kann jedes Detail sehen. -- Meph666 → post 22:01, 2. Aug. 2007 (CEST)
Das rührt wahrscheinlich von einer falschen Übersetzung des Begriffes "opaque" aus dem Englischen her, dass diese Begriffe oft so verschieden verwendet werden 82.113.106.145 18:54, 23. Sep. 2009 (CEST)
Ein anderes Beispiel für den Transparenzbegriff, wie er in diesem Fall benutzt wird, ist ein transparenter HTTP-Proxy, der den HTTP-Datenverkehr unbemerkt und ohne dass man den Proxy-Server manuell im Browser einstellen muss, puffert. Siehe auch: Proxy (Rechnernetz)#Transparenter Proxy -- Meph666 → post 09:09, 3. Aug. 2007 (CEST)

Weblinks

Brauchen wir wirklich Weblinks zu drei Linux-GUIs? Widerspricht das nicht dem prizip "bitte vom Feinsten" aus WP:WEB? Ich sehe drei Alternativen, (1) entweder einen Absatz zu GUIs unter Linux, evtl mit Referenzen, (2) eine Einigung hier in der Diskussion auf einen GUI oder (3) wenn keine Einigung möglich, entfernen aller drei Links. Als Entscheidungskriterien für ein Produkt würde ich den Funktionsumfang, Projektfortschritt, Dokumentation usw. vorschlagen. Drei nackte Weblinks brauchen wir hier mMn nicht, immerhin ist das keine Linksammlung ... Was haltet ihr davon? Viele Grüße -- Meph666 → post 15:55, 8. Okt. 2007 (CEST)

Den extra Absatz! (Die fehlende graphische Oberfläche stellt für Linux-Nutzer ein erwähnenswertes Problem dar. Würde insofern die jetzige Verweisesammlung als ersten provisorischen Anfang sehen und dem ganzen einen kleinen Absatz gönnen.)--Speck-Made 16:06, 8. Okt. 2007 (CEST)
In dieser Form definitiv nicht sinnvoll und ein Verstoß gegen die Richtlinien. Ich entferne das erstmal wieder.--Innenrevision 10:22, 10. Okt. 2007 (CEST)

Weblinks zu Anleitungen

Das kleine Truecrypt-Tutorial ist für Anfänger besser geeignet als das große. Es geht bei Wikipedia u.a. darum Usern zu helfen. Dann könnte man ja auch gleich eine riesige Anleitung für WIndows, Ubuntu und Linux machen. Bei "Kurzanleitung" weiss man, woran man ist. Man möchte kurz und knapp etwas verschlüsseln. Es wird niemanden umbringen, wenn diese Anleitung dort ist. (Der vorstehende, nicht signierte Beitrag stammt von 87.122.31.119 (Diskussion • Beiträge) 20:40, 16. Okt 2007) Tafkas Disk. +/- Mentor 20:41, 16. Okt. 2007 (CEST)

Das ist leider ein häufiges Missverständnis. Bei Wikipedia geht es nicht direkt darum, irgendwem bei der Bedienung von irgendwas zu helfen, siehe dazu WP:WWNI Nr. 9. Es geht hier viel mehr um eine Auseinandersetzung mit dem Artikelgegenstand auf möglichst sachlicher und wissenschaftlicher Ebene. Für die Weblinks gilt, dass sie Inhalte nach Möglichkeit weiter vertiefen sollten, weil ein allgemeiner Überblicksartikel in einer Enzyklopädie nunmal nicht alle Bereich vollständig abdecken und alle Details nennen kann. Anleitungen fallen allerdings kaum unter diese weitere Vertiefung.
Es ist natürlich auch mir klar, dass diese theoretischen Regeln in der Artikelpraxis etwas anders aussehen. Aber eine gewisse Orientierung an WP:WEB sollte es schon geben: ganz wichtige Grundregeln sind, dass Weblinks sparsam eingesetzt werden sollten - das soll hier kein Linkverzeichnis werden und auch kein Google mit manuell erstellten Inhalten. Es sollten die besten Weblinks sein und nicht mehr als 5 Stück in einem Artikel (der Leser soll nicht aus einer riesigen Linkliste die raussuchen müssen, die tatsächlich hochwertige weiterführende Informationen beinhalten). Wir haben dort nun schon 2 Anleitungen für verschiedene Betriebssysteme, eine davon ebenfalls für Windows. Das sollte genügen, denn es darf vorausgesetzt werden, dass der Leser eine Suchmaschine bedienen kann, falls er noch mehr Anleitungen sucht. Bestenfalls ist also eine entweder-oder-Entscheidung denkbar. Meinst du also, dass die von dir vorgestellte Anleitung besser ist und die andere ersetzt werden sollte? Wenn ja, dann mache das, wenn nein, dann lösche die zweite Windows-Anleitung wieder.--Innenrevision 20:58, 16. Okt. 2007 (CEST)
Meine Anleitung, die auf einem Weblog ist wurde gelöscht. Das andere Tutorial, http://www.verstecken.net/tutorials/truecrypt.html füge ich wieder ein, da hier zu keinem Weblog/Forum verlinkt wird

Ich habe grade das Tutorium gelesen und finde es sehr gut, ist durchaus eine Bereicherung für den Artikel. - Malk 85.183.142.216 19:10, 28. Nov. 2007 (CET)

@Meph666: Ich verstehe die ganze Geschichte nicht recht, versuche aber eine Zusammenfassung:

  • 1. Eine komplett überarbeitete Version von Truecrypt liegt vor, ein Nutzer fügt eine Anleitung zu den Weblinks hinzu, die auf diese Version eingeht.
  • 2. Meph666 macht den Eintrag rückgängig mit der Begründung: "bitte nicht noch mehr Anleitungen, siehe auch WP:WEB".
  • 3. Pere Ubu hält die neue Anleitung für die derzeit relevanteste und macht die Änderung von Meph666 rückgängig. Seine Begründung: "WP:WEB besagt doch "bitte sparsam und vom Feinsten". Dieser Link war vom Feinsten. Mein Vorschlag: statt dessen den Linux-User-Link löschen"
  • 4. Obwohl spätestens hier klar ist, dass Diskussionsbedarf besteht, nutzt Meph666 die Diskussionsseite nicht, sondern beharrt auf seiner Löschung des Links. Die von Pere Ubu entfernte Anleitung, die auf ein kommerzielles Magazin und die Heft-CD verweist, bezeichnet er als "einen wirklich fundierten Hintergrundartikel".
  • 5. Pere Ubu schlägt vor: "Lassen wir einfach fünf Links dort. Der von mir entfernte Linux-User-Artikel ist übrigens alles andere als "fundiert". Es ist auch "nur" eine Anleitung, die eine Heft-CD voraussetzt --> kommerziell."
  • 6. Delta-Bravo interveniert, indem er die Zahl der Anleitungen willkürlich auf die oberen beiden Links reduziert: "vier anleitungen sind eindeutig zu viel!!! zwei davon reichen, lin+win"
  • 7. Da Anleitungen offenbar ungern gesehen sind und die verbleibenden beiden Anleitungen für die aktuelle Version der Software wenig hilfreich sind, entfernt Pere Ubu die beiden Anleitungen. Der wichtigste Link zur Truecrypt-Seite bleibt ja.
  • 8. Meph666, der die Diskussion noch immer nicht nutzt und stattdessen seine Änderungen durchsetzt, wirft Pere Ubu eine "Vergeltungsaktion" vor.
  • 9. Vielleicht könnten wir hier nun mal erötern, welche Anleitungen warum sinnvoll sind?

-- Pere Ubu 08:31, 12. Feb. 2008 (CET)

Ah hallo, habe den Beitrag hier anfangs nicht gesehen, weil ich mir die Versionsgeschichte nicht genau angeschaut habe. Deswegen habe ich eine neue Diskussion am Ende dieser Diskussionsseite angefangen. Pere Ubu, du wirfst mir vor ich würde trotz Diskussionsbedarf auf dem ursprünglichen Artikelzustand bestehen. So weit ich es weiss, ist es durchaus üblich den ursprünglichen Zustand bestehen zu lassen (insbesondere bei den Weblinks), wenn eine Änderung umstritten ist. Und dass normalerweise derjenige, der die umstrittene Änderung durchsetzen möchte, die Gründe warum diese umstrittene Änderung sinnvoll sei, auf der Diskussionsseite erläutert. Außerdem hast du bei deiner Aufzählung etwas vergessen.
Im Punkt 4 schreibst du „Obwohl spätestens hier klar ist, dass Diskussionsbedarf besteht, nutzt Meph666 die Diskussionsseite nicht, sondern beharrt auf seiner Löschung des Links.“ allerdings lässt du bei meiner Begründung etwas wichtiges aus, nämlich „wenn er [der neue Link] wirkl. vom feinsten ist, dann kann mit Sicherh. vorher eine Diskussion stattfinden [...]“. D.h. ich schlage dir vor, zuerst die Diskussionsseite zu benutzen, bevor du deine umstrittene Änderung per revert wiederherstellst, was du allerdings nicht beachtest und den neuen Link trotzdem wiederherstellst.
Und jetzt wirfst du mir vor, ich würde die Diskussion verweigern, das finde ich schon sehr seltsam. Und findest du das so abwägig, wenn ich denke dass du nur aus Trotz, da deine Änderung hier nicht akzeptiert wurde, die anderen, etwas länger bestehenden Weblinks löschst? Und vor allem ohne vorherige Diskussion?
Im Punkt 6, wird übrigens auch der Artikelzustand vor den strittigen Änderungen wiederhergestellt, und keine Willkür verübt ...
Aber OK ... lassen wir nun die gegenseitigen Vorwürfe und versuchen uns auf das eigentliche Thema zu konzentrieren. Ich habe dir auf deiner Diskussionsseite einige Fragen gestellt, die du leider gelöscht hast: warum findest du, dass eine vergleichsweise kurze Anleitung die nur eine Funktionalität (nämlich der Komplettverschlüsselung einer Partition) wertvoller sei als eine allgemeiner gehaltene Anleitung, die mehr Features abdeckt? Und was aus der allgemeineren Anleitung hat mit der Truecrypt-Version 5.0 keine Gültigkeit mehr? Und hier noch eine Frage, findest du bei Links die Hintergrundinformationen zu einem Artikelgegenstand liefern sollen wirklich entscheidend ob der Weblink sich auf die brandneueste Version bezieht und nicht auf eine Version, die vor gerade mal weniger als einem Monat noch die aktuelle war?
In einer Sache muss ich dir allerdings Recht geben, beim Artikel aus dem Linuxuser-Magazin war ich nicht besonders sorgfältig und habe den Inhalt nur überflogen, außerdem habe ich mich dabei eher auf ein Vorurteil verlassen, dass Zeitschriftenartikel im Allgemeinen wertvollere Quellen abgeben als Blog-Beiträge. Ich gebe zu, dass dieser Artikel, verglichen mit den anderen Weblinks tatsächlich nicht besonders toll ist. Daher wäre ich auch dafür, dass man ihn wieder aus der Liste entfernt bzw. nicht wieder reinnimmt. Viele Grüße. -- Meph666 → post 09:54, 12. Feb. 2008 (CET)

Kurze Anmerkung zur Aussage "Und hier noch eine Frage, findest du bei Links die Hintergrundinformationen zu einem Artikelgegenstand liefern sollen wirklich entscheidend ob der Weblink sich auf die brandneueste Version bezieht und nicht auf eine Version, die vor gerade mal weniger als einem Monat noch die aktuelle war? ": Truecrypt 4.2a ist nicht die letzte aktuelle Version vor der 5.0 gewesen. Am 19. März 2007 ist Version 4.3 und am 3. Mai 2007 dann 4.3a erschienen. Nachzulesen unter http://www.truecrypt.org/news.php (Der vorstehende, nicht signierte Beitrag stammt von 88.217.14.109 (Diskussion • Beiträge) 12:02, 12. Feb. 2008) (Diskussionsbeiträge bitte mit vier Tilden unterschreiben ~~~~)

Ja und auf welche Funktion von 4.3a geht die Einleitung nicht ein, die bei 4.2, 4.2a oder 4.3 nicht verfügbar war? Wo findet sich in der Einleitung die Einschränkung auf eine bestimmte Version? Ich will darauf hinaus, dass diese Anleitung für die derzeitig aktuelle Version ebenso gültig ist. Und sich zudem nicht auf ein einziges Feature beschränkt. Gruß -- Meph666 → post 12:15, 12. Feb. 2008 (CET)

Die "allgemeiner gehaltene Anleitung" enthält seit der Version 5.0 Informationen, die den Leser in die Irre führen.

Zitat 1: "Ebenfalls müsst ihr beachten, dass die Festplatte/USB Stick/usw…, die komplett verschlüsselt werden soll, zunächst von TrueCrypt formatiert wird, d.h. alle Daten darauf werden gelöscht! Also vorher wichtige Dateien verschieben/sichern."

Das ist falsch. Der neue Assistent löscht keine Daten auf der Festplatte. Der Text bezieht sich noch auf die vorherigen TrueCrypt-Versionen, das erkennt man aber nicht.

Zitat 2: "Ein entschlüsseln des Containers / Volumes ist leider nicht möglich, d.h. ihr müsst die Containerdatei löschen oder die Festplatte formatieren um die Verschlüsselung wieder aufzuheben."

Das ist leider ebenfalls falsch. Man muss die Festplatte nicht mehr formatieren, um die Verschlüsselung aufzuheben. (Der vorstehende, nicht signierte Beitrag stammt von 84.153.55.118 (Diskussion • Beiträge) 13:19, 12. Feb. 2008) (Diskussionsbeiträge bitte mit vier Tilden unterschreiben ~~~~)

Zu Zitat 1: natürlich wird die Festplatte gelöscht, wenn man nicht die System-Festplatte verschlüsselt, denn genau dies wird in der Anleitung beschrieben. Beim zweiten Zitat gilt genau das gleiche! Habe es eben selbst mit meinem USB-Stick ausprobiert. Dass beim Verschlüsseln der Systempartition diese nicht gelöscht werden kann, immerhin läuft ja Truecrypt gerade drauf, kann man sich eigentlich auch denken ... Noch mal die Frage findet ihr es besser, wenn man eine allgemein gehaltene Anleitung durch eine Anleitung ersetzt, die sich ausschließlich mit einem Feature, nämlich der Verschlüsselung der Systempartition, beschäftigt? -- Meph666 → post 15:18, 12. Feb. 2008 (CET)

Schau dir bitte nochmal den kompletten Text an: Nach "Update" folgt genau ein neuer Satz zur 5.0, danach geht die Beschreibung der alten Funktionen weiter. Verstehst du jetzt, was ich meine? Es erfolgt keine Abgrenzung, als Leser denkt man, das gehört zum "Update".

Zu deiner Frage: Warum denn ersetzen, man könnte sie ja auch nebeneinander stellen. (Der vorstehende, nicht signierte Beitrag stammt von 84.153.55.118 (Diskussion • Beiträge) 17:56, 12. Feb. 2008)

Möchtest du vielleicht vorschlagen, dass man für jedes Feature, dass in der allgemeinen Anleitung nicht angesprochen wurde eine eigene Anleitung verlinkt? -- Meph666 → post 18:24, 12. Feb. 2008 (CET)
PS: es wäre schön wenn du dir angewöhnen könntest, deine Beiträge mit vier Tilden ~~~~, bzw. mit einem Klick auf den zweiten Knopf von rechts, oben über der Editierbox. Dann entsteht keine Verwirrung wer was wann geäußert hat. Meph666 → post

Ich bin dafür, es beim derzeitigen Zustand ohne irgendwelche Anleitungen zu belassen. Zum einen beendet das automatisch den Streit, welche Anleitung wohl die richtige sei, zum anderen sind die Anleitungen allesamt kaum vom feinsten. Da wird jeweils ein Einzelfall aufgegriffen und für diesen speziellen Fall eine Anleitung gezimmert. Gerade bei der neuen Anleitung zur Komplettverschlüsselung wird völlig ignoriert, wie man das in Multibootumgebungen sinnvoll hinbekommt - stattdessen wird der Idealfall einer einzigen Partition mit einem einzigen Betriebssystem aufgegriffen und daran die Erklärung gemacht. Dass TrueCrypt momentan Probleme mit erweiterten Partitionen hat (falls die gesamte Festplatte verschlüsselt werden soll), dass nur ein einziges Betriebssystem verschlüsselt werden kann (falls mehrere auf der Platte liegen, können die anderen nicht verschlüsselt werden bzw. nur mit ganz erheblichem Aufwand), dass es Probleme mit Bootladern wie GRUB gibt (weil TrueCrypt deren üblichen Datenablagebereich hinter dem MBR selbst beansprucht), dass es Probleme bei bestimmten logischen Plattengeometrien gibt, ... wird völlig ignoriert. Insoweit helfen die ganzen Sonnenscheinanleitungen dem Leser kaum weiter, insbesondere weil sie kaum oder gar nicht über das Niveau der TrueCrypt beiliegenden PDF-Anleitung hinausgehen. Ich halte sie deshalb im momentanen Zustand allesamt für verzichtbar.--Innenrevision 10:18, 13. Feb. 2008 (CET)

Hast ja eigentlich Recht, leider liegt die mitgelieferte PDF-Anleitung nicht in deutscher Sprache vor ... also doch alle Anleitungen wieder herausnehmen; und damit auch die (Debian-)Linux-Anleitung, die bis auf die Anleitung selbst eigentlich noch weiterführende Informationen liefert, nämlich eine anschauliche und illustrierte Erklärung der Funktionsweise der hidden Volumes in deutscher Sprache, die man zur Hilfe nehmen kann, wenn man die Erklärung dieses Feature im Artikel ausbauen wollte. Aber nun ja ich kann damit leben. Viele Grüße -- Meph666 → post 11:23, 13. Feb. 2008 (CET)

Keine „Full System Encryption“

Das ist falsch! Auf Windows mag das zutreffen, jedoch nicht auf Linux (o.ä.): Dort habe ich für einige Monate ein System voll verschlüsselt (d.h. alles bis auf die boot-Partition). Es musste nur das mkinitrd-script angepasst werden, so dass vor dem Mounten der eigentlichen root-Partition diese entschlüsselt werden kann. Es gibt hierfür sicherlich keinen Installer und man muss selber frickeln aber der Aufwand liegt bei unter einem Tag, so dass ich das als vertretbare Lösung einstufen würde. Einziges Problem war die Performance, weshalb ich dann doch wieder zu einem teilverschlüsselten System zurückgegangen bin.

Leider war das hier nicht signiert... inzwischen läßt sich bekanntlich die Bootpartition unter Windows verschlüsseln, und zwar im laufenden Betrieb und m. E. in einem ziemlich sicheren Verfahren, das die Bootfähigkeit nach der Verschlüsselung sicherstellen soll. Zumindest solange im Energiesparmodus der Hauptspeicher unter Strom bleibt, ist das auch mit sicherem Schlüssel eine sehr praktikable Lösung (wie sich das mit dem Hibernate-Modus verhalten würde, weiß ich nicht). --Tobias 21:21, 28. Mai 2008 (CEST)
Update: seit Version 6.1 können auch Nicht-Systempartitionen nachträglich verschlüsselt werden, zumindest unter Vista (http://www.truecrypt.org/docs/?s=version-history) --Tobias 20:48, 19. Dez. 2008 (CET)
Ja, das Verschlüsseln im laufenden Betrieb geht unter XP nämlich generell nicht; ich finde das wird hier teilweise suggeriert. Könnte man doch vielleicht mal irgendwo sagen dass das nur mit Vista geht, oder? (nicht signierter Beitrag von 82.82.165.3 (Diskussion | Beiträge) 12:50, 21. Apr. 2009 (CEST))
Äm, da hab ich mich wohl geirrt, es ist falsch dass es unter XP generell NICHT geht, aber manche "Extras" gehen nur unter Vista, speziell dual-boot-Sachen.

Ist das Projekt überhaupt noch aktiv?

Es gibt keine aktuellen News auf der Seite, das Forum ist ständig öffline, die Entwickler antworten scheinbar nicht auf Anfragen.(Der vorstehende, nicht signierte Beitrag stammt von 84.62.141.152 (Diskussion • Beiträge) 10:41, 22. Jan 2008) --Innenrevision 10:53, 22. Jan. 2008 (CET)

Vermutlich schon - immerhin wurde erst im Dezember die Version 5.0 für Januar angekündigt (erfahrungsgemäß kann sich so ein Termin aber natürlich auch verschieben). Dass die Entwicklung nicht wirklich transparent erfolgt, das ist ja bekannt und bei Truecrypt leider nichts Ungewöhnliches. Es hilft halt nur abwarten bis weißer Rauch in Form der Version 5.0 aus dem Kamin steigt.--Innenrevision 10:52, 22. Jan. 2008 (CET)
Version 5 wurde nun x mal verschoben. Ich glaube kaum, dass es heute noch etwas wird. Warum ist die Entwicklung von Truecrypt so verschlossen? Man "wirbt" doch so groß mit freier Open-Source-Software!
Ich warte hier auch schon eine ganze weile bei dieser sog. OSS...

Version 5.0

http://www.heise.de/newsticker/meldung/103054 134.91.200.13 14:06, 6. Feb. 2008 (CET)

Da inzwischen Version 6.1a draußen ist, halte ich die Frage nach der Aktivität für positiv beantwortet; wenn niemand etwas dagegen hat, kann m. E. dieser Abschnitt bei Gelegenheit gelöscht werden. --Tobias 20:48, 19. Dez. 2008 (CET)

Weblinks (mal wieder)

(da die ursprüngliche Diskussion von Benutzer:Pere Ubu einfach gelöscht wurde, verschiebe ich meinen Beitrag hierher)

Hallo Pere Ubu. Wie ich sehe bist du noch nicht sehr lange bei Wikipedia dabei, deswegen möchte ich dich darauf hinweisen, dass es hier nicht üblich ist neue Änderungen per Edit-War durchzusetzen, besonders freundlich ist es auch nicht. Außerdem meine ich in deiner Löschung der Links, die schon etwas länger im Artikel gelistet werden, eine Vergeltungsaktion zu erkennen. Nach dem Motto, wenn ihr meinen Vorschlag nicht akzeptiert, dann mach ich euch das Leben schwer ... deswegen auch mein verweis auf WP:BNS. Übrigens wenn ich eine Änderung an einem Artikel mache, die von mehreren Benutzern rückgängig gemacht wird, dann versuche ich meine Meinung durch Argumente auf der Diskussionsseite zu vertreten, und setze meine Änderung nicht per Edit-War durch. Lass uns mal das ganze objektiv betrachten. Der Sinn der Wikipedia besteht nicht primär darin gute Anleitungen zu Software oder anderen Systemen und Werkzeugen zu liefern und auch nicht darin, alle möglichen Anleitungen in den Weblinks zu verlinken, siehe dazu WP:WWNI und WP:WEB. Sondern vielmehr um eine (Zitat) „um eine Auseinandersetzung mit dem Artikelgegenstand auf möglichst sachlicher und wissenschaftlicher Ebene“. Außerdem besteht der Sinn und Zweck des Weblink-Abschnitt hauptsächlich darin weiterführende Informationen zu dem Thema, das im Artikel behandelt wird, zu liefern. Viele Anleitungen genügen diesem Anspruch nicht. Dabei spielt die Versionsnummer des Artikelgegenstands außerdem eine eher untergeordnete Rolle, was schwerer wiegt ist, ob die Weblinks wertvolle Informationen über die Funktionsweise der Software liefern. Und dies ist beispielsweise bei [5] eindeutig der Fall, dort wird bspw anschaulich und in deutscher Sprache die Funktionsweise der Hidden Volumes erklärt. Kannst du vielleicht begründen warum du denkst dass eine vergleichsweise kurze Anleitung zu einem Feature (nämlich der Komplettverschlüsselung einer Partition) wertvoller sein soll als eine allgemein gehaltene Anleitung, die viel mehr Features abdeckt? Was genau funktioniert mit der Version 5.0 nicht mehr so wie es in der Windows-Anleitung beschrieben wurde? Außerdem wurde diese Anleitung mittlerweile auch angepasst und behandelt die Komplettverschlüsselung von Partitionen ebenso. Viele Grüße -- Meph666 → post 08:38, 12. Feb. 2008 (CET)

Ich habe übersehen, dass Benutzer:Pere Ubu sich in einer der älteren Diskussionen zu diesem Thema geäußert hat, daher führe ich die Diskussion dort weiter. -- Meph666 → post 09:59, 12. Feb. 2008 (CET)

Keine hidden volumes für Mac

In der Mac-Version von TrueCrypt 5.1 gibt es keine Unterstützung für versteckte Container. Nach [6] scheint es aber über Umwege möglich zu sein (Container unter Windows erzeugt). Ist die Mac-Version einfach noch unvollständig, oder gibt es rechtliche Probleme (verbieten etwa irgendwelche Lizenzbedingungen für Mac-OS die Nutzung von plausible deniability-Mechanismen? Dafür würde sprechen, dass es zwar im Prinzip über Umwege möglich ist, aber die direkte Ausführung (mit entsprechender Fehlermeldung) verweigert wird.--SiriusB 20:17, 28. Mär. 2008 (CET)

Für die Zukunft ist eine Implementierung für Mac OS X und Linux geplant [7]. Vielleicht ist es dort nur schwieriger umzusetzen oder es gibt weniger Programmierer. (Ich würde mir für die Knoppix-CD/DVD TrueCrypt wünschen, sodaß man auch damit auf verschlüsselte Container/Partitionen zugreifen kann.) --Starkiller 10:58, 29. Mär. 2008 (CET)

Deutschsprachig: Ja - aktuell aber eher nein

Das deutsche Sprachpaket scheint seit der neusten Version ja nicht mehr zu funktionieren. Ist es somit noch korrekt, dass in der Auflistung "Deutschsprachig: Ja" steht? Die neue Version ist ja nicht seit gestern draußen, von daher ist eine aktuelle Sprackdatei in naher Zukunft eher unwahrscheinlich. --RSX 23:32, 2. Mai 2008 (CEST)

Die deutsche Übersetzung ist nur teilweise, aber zumindestens die wichtigsten Punkte wurden übersetzt, also ein klares Jein! -- 2hochn 23:15, 7. Aug. 2008 (CEST)
Da die jeweiligen Sprachpakete einfache XML-Dateien sind, kann jeder (der über einen Unicode-fähigen Editor verfügt) die fehlenden Übersetzungen nachrüsten; das ist hier beschrieben. --Tobias 20:48, 19. Dez. 2008 (CET)

Glaubwürdigkeit des Codes bzw seiner Programmierer

Da es sich bei True-Crypt um ein Verschlüsselungstool handelt, also ein Programm, bei dem es essentiell ist ob man den Programmierern vertrauen kann keine Hintertür eingebaut zu haben (was bei Cryptoalgorytmen nicht trivial zu erkennen ist, auch nicht bei OpenSource), wäre es da nicht vielleicht angebracht, dem Artikel einen Absatz hinzuzufügen, der darauf hinweist, das die Programmierer von TrueCrypt (also die TrueCrypt-Foundation) absolut anonym bleiben? Es wird auf der Weseite nicht einmal darum geworben an Truecrypt mitzuprogrammieren oder auch nur verraten wie man sich beteiligen könnte. Die einzige Adresse die zur TrueCrypt-Foundation überhaupt rauszufinden ist (auf der Webseite steht dazu überhaupt nichts) ist aus dem Whois-Eintrag der Domäne: Herndon, VA. Und das ist etwa fünf Kilometer vom Hauptsitz der NSA entfernt. (Der vorstehende, nicht signierte Beitrag stammt von 217.80.218.7 (Diskussion • Beiträge) 00:22, 21. Jul. 2008) (Diskussionsbeiträge bitte mit vier Tilden unterschreiben ~~~~)

TrueCrypt ist inzwischen sehr verbreitet. Eine eingebaute Hintertür zu verbergen, wird sehr schwierig sein. Es gibt sicherlich genug Experten in der OpenSource-Gemeinde, die sich das Programm ganz genau angeschaut haben. Nicht einmal um vielleicht eine Hintertür zu entdecken, sondern um (unbeabsichtigte) Implementierungsfehler zu finden. Eine absichtlich eingebaute Hintertür wäre da inzwischen aufgefallen. Außerdem hat die NSA als der wahrscheinlich größte Nachrichtendienst der Welt wohl keinen Grund, eine Scheinfirma nur einige Kilometer entfernt von ihrem Hauptsitz zu gründen. --Sabata 00:44, 21. Jul. 2008 (CEST)
Die versehentliche Hintertür in Debian-OpenSSL ist auch lange Zeit niemandem aufgefallen.--80.136.134.203 11:36, 23. Jul. 2008 (CEST)
(nach Bearbeitungskonflikt) Hallo, es stimmt nicht, dass auf der Website überhaupt keine Namen genannt werden. Wenn man sich die Sammellizenz anschaut, so findet man darin einige Entwickler, die zumindest für einen Teil des Quellcodes verantwortilich sind. Die Vermutungen bezüglich NSA etc. würde ich ohne zuverlässige Quellen als Verschwörungstheorie einstufen. PS: In der Wikipedia wird kein investigativer Journalismus betrieben, sondern es wird ausschließlich mit öffentlich zugänglichen und zuverlässigen Quellen gearbeitet. Viele Grüße -- Meph666 → post 00:47, 21. Jul. 2008 (CEST)
Zudem: Herndon ist 80 km von Fort Meade entfernt, nicht fünf. Solange es keine belastbaren Belege für den von dir implizierten Zusammenhang gibt, gibt es auch keinen Grund und keine Grundlage, diesen im Artikel zu erwähnen. --YMS 00:51, 21. Jul. 2008 (CEST)

Ohne Verschwörungstheorien schüren zu wollen, aber u.a. in diesem Heise-Forums-Thread wurde seinerzeit die Vermutung geäußert, dass zwar nicht der Sourcecode selbst, eventuell aber die Binaries eine Hintertür für die Sicherheitsbehörden haben könnte. Hintergrund: Die meisten Benutzer laden sich die einfach installierbaren Binaries/Installer herunter, statt sich das Programm aus dem Quellcode selbst zu compilieren. Es gibt auch die Aussage, es wäre sehr überraschend, wenn die jeweilige Regierung nicht auf die Entwickler zugehen und eine Hintertür (zumindest für den ausführbaren Code) verlangen würden. Natürlich gehört das so nicht in den Artikel, da mir keine zuverlässigen Quellen dafür bekannt sind.

Warum dann dieser Kommentar, wenn er am Artikel nichts ändern kann/will? Ich möchte hier nur darauf aufmerksam machen, dass die Glaubwürdigkeit von Entwicklern freier Cryptosoftware durchaus Gegenstand von Diskussionen ist und nicht von jedem als naturgegeben hingenommen wird. Nachdenklich stimmen sollte es auch, dass zwar derzeit von den Regierungen alle Mittel in Bewegung gesetzt werden, die eigenen Bürger zu überwachen (und in einigen Ländern, darunter Australien, sogar das komplette Internet einer Vorzensur zu unterziehen), andererseits der öffentlichen Zugänglichmachung von starker Kryptografie scheinbar gelassen zugesehen wird (zumal in den USA der Export solcher Software offiziell verboten ist!). Gerade diese Gelassenheit ist es, die einen durchaus beunruhigen kann. Wenn Regierungen in aller Welt eine Software wie TC verteufeln und bekämpfen/verbieten würden, würde das die Zuverlässigkeit und Vertrauenswürdigkeit dieser Software eher unterstreichen (vgl. z.B. Kopier-Software von SlySoft).--SiriusB 22:31, 15. Okt. 2008 (CEST)

Also eine sehr bekannte Hintertür gibt es nicht, wenn PCs von Raubkopierern usw. einkassiert werden beißen sich die zuständigen Behörden immernoch die Zähne an den Truecrypt PCs aus. Gäbe es eine Hintertür würde sie bestimmt nur gegen Schwerverbrecher eingesetzt werden bei denen die Normalbürger sowieso nicht erfahren ob da Truecrypt im Spiel war oder sonstwas. Wenn jemand seine Platte mit Truecrypt verschlüsselt hat und die Polizei kann sie knacken, würde er sofort Alarm im Netz machen und niemand würde es mehr laden, also wir "Normalbürger" sind denk ich mal sicher selbst wenn es eine Hintertür gib.

Genau um solche Extremfälle ging es ja auch: Sollte es eine von der US-Regierung erzwungende Backdoor geben, so wäre TC eben keine sichere Verschlüsselungsapplikation mehr, auch dann nicht, wenn diese Hintertür nur zur Abwehr von Topterroristen verwendet würde. Klar, so einen Joker würde man nichtmal bei dem gegenwärtigen Druck der Musik- und Filmindustrie und vermutlich auch nichtmal bei Kinderpornografie, organisierter Drogenkriminalität oder Geiselnahmen verheizen, sondern wirklich nur dann, wenn es "um alles" (sprich um die Sicherheit der Nation) geht, also Terrorabwehr oder Spionage in einer dem Kalten Krieg vergleichbaren Situation (wo etwaige Erfolge ja auch top secret bleiben). Dennoch würde auch eine solche als ultima ratio gedachte Hintertür ausreichen, um eine Krypto-Applikation vollständig zu disqualifizieren. Denn das Vertrauen in die Entwickler wäre dann dahin. So wie das Beichtgeheimis bei Geistlichen wertlos wäre, wenn es, auch nur in extremst-Fällen, vom Staat (oder gar von der Kirche selbst) gebrochen werden dürfte. Selbst dann, wenn dies z.B. nur dann geschehen würde, wenn ein Terror-Mitwisser etwa die Existenz einer tickenden nuklearen Zeitbombe in einer Millionenstadt beichten würde.--SiriusB 13:01, 27. Okt. 2008 (CET)
Dem entsprechend würde ich dann aber anmerken, dass auch das Beichtgeheimnis nicht zuverlässig ist. Es dürfte schwer sein einen Priester zu finden, der nach so einer Beichte keine Konsequenzen zieht um das Schlimmste zu verhindern. Kein System ist lückenlos sicher. Das wird auch bei Entwicklern von Verschlüsselungssoftware immer wieder betont. Meist wird allerdings eher kleinen Risiken wesentlich mehr Aufmerksamkeit geschenkt als wesentlich größeren, sehr banalen Gefahren. So lange es keine sich häufenden starken Indizien für ein Sicherheitsleck in TrueCrypt gibt, halte ich Spekulationen darüber für sehr abstrakte, unpragmatische Gedankenspiele. --Onsemeliot 13:09, 10. Jan. 2009 (CET)
Noch mehr Zweifelhaftes zu TrueCrypt, gerade per RSS bei mir reingekommen: http://www.macmacken.com/2009/05/30/6-gruende-gegen-truecrypt/ -- 94.247.216.100 01:53, 31. Mai 2009 (CEST)

Travelermode

ich habe gerade den travelermode ohne Administratorenrechte ausprobier und es funktioniert. Hat sich hier vielleicht etwas geändert? Sollte man im Artikel anpassen.

Wenn du TrueCrypt vorher auf dem Rechner in derselben Version wie den Travelermode installiert hast, kannst du auch mit eingeschränkten Rechten die Travellerversion starten, ansosten nicht, da TrueCrypt einen Treiber benötigt, der nur mit Adminrechten geladen werden kann.

Ein USB Stick, auf dem eine TrueCrypt Partition im Travelermode angelegt wurde, hat bei mir bis jetzt auf jedem Rechner funktioniert, auch da wo ich keine Adminrechte hatte. Im Artikel wird das so dargestellt, als ob der Travelermode nur mit Adminrechten ausgeführt werden kann - das stimmt nicht.


auch auf meinem System funktioniert der Travelermode bei Truecrypt (v.6.1a) ohne Admin-Rechte - der Anschnitt sollte also dringends angepasst werden --Ab the diablo 15:04, 7. Dez. 2008 (CET).

Ganz dringenst solltest du reputable Quellen angeben, wenn du der Projektseite schon widersprichtst. Vielleicht ist deine Definition von Admin-Rechten einfach anders als dort. Danke! --Trac3R 17:26, 7. Dez. 2008 (CET)

6+ Gründe gegen TrueCrypt

Was ist hiervon zu halten? Nemissimo 酒?!? RSX 19:48, 27. Jul. 2009 (CEST)

ImHo nicht viel. Ein paar ziemlich unbegründete Thesen (z.B. mit abweichendem Quellcode zu kompilieren), unpassender Vergleich, ... und ein paar Probleme in der Kommunikation mit den Entwicklern. Mag sein, dass die Entwickler ihre Kommunikation verbessern könnten; aber was bspw der Autor der Kritik konkret bei denen ins Forum schrieb, was die Sperrung auslöste, ... hört sich alles etwas nach WP:Glaskugel an. --Nyks (Kontakt) 21:45, 27. Jul. 2009 (CEST)
Ich finde es sehr bedenklich. Die TrueCrypt leute betreiben genausoviel Verschleierungsaufwand wie die ebenso anonymisierend vorgehenden Entwickler des populären Utilities CCleaner91.9.213.116 19:21, 30. Jul. 2009 (CEST)

Kaskadierte Cipher

Also die 960-Bit habe ich mal raus genommen. Es ist ein Irrtum, dass die Kaskadierung von Ciphern die Sicherheit erhöht. Im besten Fall bleibt der Algorithmus gleich stark, im schlimmsten Fall wird er schwächer. Dazu aus einem anerkannten Kryptostandardwerk, Kapitel 15, "Applied Cryptography" von Bruce Schneier - Combining ciphers: "Combining algorithms in effect creates a new algorithm: So A + B in effect is equivalent to a new cipher C. In some cases C may be easier to break than A or B." --Marko wiki 22:19, 17. Mai 2005 (CEST)

Ein bisschen schwachsinnig die Idee. Mal ein Beispiel: Algorithmus A=AES, B=Twofish

Jemand will die Platte entschlüsseln die mit A verschlüsselt ist, er kriegt es nicht hin. Er nimmt die verschlüsselten Daten und verschlüsselt diese mit B, nun kann er die Daten (wie auch immer) auslesen. Hört sich für mich ein bisschen komisch an...

Die Kaskadierung erhöht nicht die Sicherheit gegen BruteForce - jedoch die Sicherheit gegen mathematische Ansätze gegen eine Schwachstelle eine Algorithmus. Für einen Angreifer gilt "Crypt * Angriffsversuch = sinnvoller Inhalt". Ein gutes Crypt ist jedoch von Zufallszahlen nicht zu unterscheiden. Startet man einen Angriff gegen ein eventuell kaskadiert verschlüsseltes Crypt, bekommt man ein Ergebnis - dies kann ein Fehlversuch sein oder das Crypt eines anderen Algorithmus. Die kann ich nur testen, indem ich das Ergebnis ebenfalls angreife, was mich Zeit und Aufwand kostet. Kaskadierte VErschlüsselung wird verwendet um die Sicherheit gegen kryptoanalythische Angriffe neben Brute Force zu erhöhen. Sollte es einmal möglich sein AES durch einen einfachen "Trick zu knacken" so verbleibt eine weitere Hürde. Damit ein dreifach verschlüsseltes Crypt einfach entschlüsselt werden kann, muss eine einfach kryptoanalytische Angriffsmethode bei TrueCrypt gegen alle drei existieren - AES, Twofish und Sepent. --80.129.224.98 07:55, 26. Mär. 2009 (CET)

Liebe ist alles

Zitat: "Es ist ein Irrtum, dass die Kaskadierung von Ciphern die Sicherheit erhöht"
Yepp, that's right. Und kann man auch an einem simplen Beispiel veranschaulichen: Der sog. "Cäsar-Chiffre" verschiebt jeden Buchstaben eines Wortes um n Stellen im Alphabet, mit Überlauf von Z nach A. Das schöne Wort "Liebe" wird Cäsar(9) chiffriert zu "Urnkn" [Verfahren A] oder alternativ mit Cäsar(17) kodiert "Czvsv" [Verfahren B].
Wendet man nun [A] auf "Liebe" an und [B] auf das Resultat daraus, also auf "Urnkn", hat man eine Kaskadierung zweier Verfahren [A] und [B]. Und, was kommt dabei raus...?!? Der Originaltext = "Liebe", da sich beide Verfahren gegenseitig aufheben, hier durch ungünstige Wahl der Schlüssel n!

Oder anders formuliert: Alles ist Liebe. :-)84.167.171.55

[ ] Du hast das Verfahren und den Hintergedanken der Kaskadierung nicht wirklich verstanden
[ ] Verschlüsselung ist nicht dein Schwerpunktthema.
Dann nämlich wüßtest du, dass was beim Caesar funktioniert bei anderen Verschlüsselungen eben nicht funktioniert. Jeder, der Verschlüsselungsverfahren verstanden hat, wird gerade Caesar nicht zur Veranschaulichung heranziehen. Caesar gehört zu den Substitutionsalgorithmen und nur bei diesen kann es in der Theorie auftreten. Die Verfahren bei AES und Co sind Blockchiffren und da kann das mathematisch beweisbar nicht passieren. Dies gilt auch für die Kaskadierung. 79.209.186.227 13:23, 1. Dez. 2009 (CET)

So ein Unfug

@Marko wiki: Das passiert, wenn man Zitate aus dem Zusammenhang reisst und dann verabsolutiert. Cipher-Kaskaden machen durchaus Sinn, wenn dabei unterschiedliche Schlüssel verwendet werden. Dies ist bei Truecrypt der Fall. Mit den 960-Bit hast DU aber Recht; der Angriffspunkt würde sich nämlich auf ein schwächeres Glied der Kette verlagern (Passwortlänge, Hashfunktion, SocialEngineering, ...).

Zitat: "Cipher-Kaskaden machen durchaus Sinn, wenn dabei unterschiedliche Schlüssel verwendet werden." Nein, machen sie nicht in jedem Fall. 84.167.171.55 hat mit einem einzigen, korrekt argumentierten Gegenbeispiel - Cäsar-Schiffre inkl. zweier unterschiedlicher Schlüssel (sic!) - diese allgemeine These widerlegt. Tatsächlich kann man den Cäsar-Schiffre hundert mal mit unterschiedlichen Schlüsseln kaskadieren und das wirkt letztendlich nicht stärker als ein einziger Lauf. 3DES hingegen ist ein Verfahren, wo mehrfache Anwendung von DES (allerdings in unterschiedlichen Richtungen, ebenfalls mit unterschiedlichen Schlüsseln) tatsächlich stärker verschlüsselt. Verallgemeinern kann man das jedoch definitv nicht und der Nachweis der stärkeren Verschlüsselung ist nicht trivial. HJPhilippi
Ich habe oben die Argumentation der IP Ad-Absurdum geführt. 79.209.186.227 13:25, 1. Dez. 2009 (CET)

@84.167.171.55: Um es kurz zu machen: Du hast leider keine Ahnung wovon Du schreibst. Dein Beispiel ist ein praxisferne Milchmädchenrechnung. 84.182.182.200 10:31, 24. Aug 2005 (CEST)

Ein persönlich werdender Angriff ohne jegliche sachliche Argumentation. Herrlich, eine Zierde für jedes Forum! :-) Soll man das löschen oder als mahnendes Negativbeispiel stehen lassen? HJPhilippi
Hier hat nicht die IP Inkomentenz bewiesen. Ich schreibe die Tag unten noch einmal etwas zu Chiffer-Kaskaden. 79.209.186.227 13:25, 1. Dez. 2009 (CET)

Muss 84.182.182.200 zustimmen

Was 84.167.171.55 sagt, macht wirklich keinerlei Sinn. Natürlich muss eine Kaskade aus verschiedenen Verschlüsselungsverfahren bestehen (und bitte nicht nur unterschiedlichen Schlüsseln @84.182.182.200). Sonst ändert sich ja nur der Schlüssel, was die Sicherheit selbstverständlich nicht erhöht. Marko wiki hat insofern Recht, dass eine Kaskade aus fünf Verfahren nicht die Summe der Schlüssellängen als Schlüssellänge hat. Es ist mehr ein Schutz davor, dass eine Lücke in einem Verfahren entdeckt wird, die die Verschlüsselung wirkungslos macht, außerdem erhöht es die Schwierigkeit des Brechens der Verschlüsselung doch massiv (aber eben nicht unbedingt proportional). Was Bruce Schneier meint, ist, das eventuell die zweite Methode die erste teilweise wieder aufhebt. Das ist aber, wenn man es sinnvoll (d.h. nicht wie bei 84.167.171.55) macht, sehr, sehr unwahrscheinlich. Das wurde natürlich auch in den TC Foren schon diskutiert, siehe hier. Fazit: Bitte nicht über die Sicherheit von Verschlüsselungsverfahren diskutieren, sofern ihr nicht Ahnung vom Thema (z.B. Mathe- oder Informatikstudium) habt. --84.178.88.79 15:05, 10. Sep 2005 (CEST)

Zitat: "Was Bruce Schneier meint, ist, das eventuell die zweite Methode die erste teilweise wieder aufhebt. Das ist aber, wenn man es sinnvoll (d.h. nicht wie bei 84.167.171.55) macht, sehr, sehr unwahrscheinlich". Und eben *das* ist ein großes Risiko - woher weiß ich, was "sinnvoll" oder was "sehr, sehr unwahrscheinlich" ist? Wie berechnet sich das? Woher will der Anwender wissen, dass in der Kette A-B-C nicht Algorithmus B die Anwendung von A teilweise aufhebt - mit gesundem Menschenverstand? Gerade die Umkehrung, nämlich Aussagen über die Sicherheit eines Kryptograhieverfahrens resp. das Zusammenwirken mehrerer Verfahren zu treffen ist wirklich mathematisches Hochland, wo einen der "gesunde Menschenverstand" oft vollkommen trügt! Bruce Schneier hat in jeder Hinsicht recht, ob man das nun auf mehrfache Anwendung von Algorithmus A mit Schlüsseln k1, k2, k3... interpretiert oder auf nacheinander angewendete, unterschiedliche Algorithmen. HJPhilippi

man muss nicht mathe oder info studieren, um sich mit verschlüsselung auseinandersetzen zu können. solche aussagen sind großkotzig, arrogant, dumm.

wikipedia ist ja nicht unbedingt für elitäre fachidioten gemacht. --Siehtnix Juli 2006

truecrypt auf UDF formatierten Medien

ich weiß nicht recht, ob ich meinen Kommentar beim Thema truecrypt, DVD-RAM oder UDF unterbringen soll.

Ich fände es sehr interessant, zu wissen, wie man am geeignetsten eine verschlüsselte dvd-ram erstellt. ich kann im netzt zu diesem thema noch nicht viel finden. sollte man die dvd mit udf formatieren, und dann auch den container der da drauf ist mit udf formatieren? Kann man einen truecrypt container auf allen unterstützen platformen mit udf formatieren und anschliesend auch schreiben und lesen?

1. ist das kein Supportforum. Und 2. steht alles was du wissen willst im TrueCrypt-Artikel. Ob DVD-Ram/+/-/RW, BluRay oder DAT-Band, ist völlig egal. --PinguX 13:12, 16. Okt. 2008 (CEST)

Sie haben das Recht zu schweigen

Das ganze Hick-Hack um die "plausible-denialbility" nicht nachvollziehen. Warum? Weil mich eh niemand zwingen kann das PW für die verschlüsselten Daten herauszugeben:

“Jedoch befindet sich auf der Festplatte ein sogenannter PGP-Container. Aufgrund einer Passwortverschlüsselung kann in diesen Datencontainer nicht Einblick genommen werden. Seitens des Beschuldigten wird eine Herausgabe des Entschlüsselungscodes verweigert.”
Die Staatsanwaltschaft fragte 2x nach, ob das Passwort herausgegeben wird. Die Antwort lautete 2 x nein.
Schließlich stellte die Staatsanwaltschaft das Verfahren ein, wegen fehlenden Tatverdachts.
Es lohnt sich, seine Rechte als Beschuldigter zu kennen. Zu diese Rechten gehört auch, keine Passwörter nennen zu müssen.
(Quelle Law Blog)

Ich denke, das sollte im Artikel erwähnt werden. --Jvaljean 01:32, 10. Jan. 2009 (CET)

Du redest von deutschem Recht, das kenne ich dort so auch. Aber wenn du mit deiner tragbaren Festplatte ins Ausland willst, kannst du an der Grenze definitiv schon Probleme bekommen. Und dabei muß du nicht weit fahren: Großbritannien reicht. --Trac3R 10:36, 10. Jan. 2009 (CET)
Jepp - und es hat sich in GB als zahnloser Tieger entpuppt. So wurde ein Student in Beugehaft genommen und der erklärte nach sechs Wochen, dass er das Passwort nun lange Zeit nicht angewendet habe und er es nun nicht mehr wisse. Da war auch dort die Justiz ein wenig machtlos und dies ist auch der Grund, warum das bei uns kein Thema ist - Schäuble hat nämlich ebenfalls mit einem solchen Gesetz geliebäugelt.
@Jvaljean Seine Passwörte nicht nennen zu müssen ergibt scih schon einmal aus dem Recht, sich nicht selbst belasten und in der Beweisführung gegen dich helfen zu müssen. Ein solches Verfahren wird jedoch niemals wegen mangelnden Tatverdachtes fallengelassen, sondern wegen mangels an Beweisen. Der Tatverdacht beseth nach wie vor noch.79.209.186.227 14:05, 1. Dez. 2009 (CET)
Jepp - und es hat sich in GB als zahnloser Tieger entpuppt. So wurde ein Student in Beugehaft genommen und der erklärte nach sechs Wochen, dass er das Passwort nun lange Zeit nicht angewendet habe und er es nun nicht mehr wisse. Ich wäre vorsichtig mit derartigen Aussagen, dass es ein zahnloser Tiger ist. Im Falle eines Studenten mag das so sein, da die persönlichen Übel, die daraus erwachsen, zwar alles andere als unerheblich sind, aber sich doch in Grenzen halten. Im Falle von Geschäftsleuten, die während ihrer Haftzeit einen Auftrag nach dem anderen wegbrechen sehen ohne einschreiten zu können, eventuell gar die ganze Firma in den Ruin getrieben wird, sieht das schon völlig anders aus. Und auch der Familienvater wird sich sicher überlegen, ob er mal eben 6 Monate zum Vergessen eines Passwortes ins Gefängnis gehen will. Man sollte niemals die Wirksamkeit einer Inhaftierung unterschätzen - Staatsanwälte werden dir da sicher genauer Auskunft geben können, was man mit dem Mittel der Untersuchungshaft zur Geständniserpressung so alles anfangen kann (nach einem Geständnis kommt man oftmals dagegen raus, hängt natürlich auch etwas von der Straftat ab). Nicht umsonst heißt es: U-Haft schafft Rechtskraft. Das gilt hier entsprechend analog.
Seine Passwörte nicht nennen zu müssen ergibt scih schon einmal aus dem Recht, sich nicht selbst belasten und in der Beweisführung gegen dich helfen zu müssen. Das ist vollkommen klar in Deutschland. Hier wäre aber durchaus interessant zu wissen, was passiert, wenn man gar nicht als Beschuldigter sondern als Zeuge eine Rolle spielt. Als Zeuge hat man im allgemeinen kein Auskunftsverweigerungsrecht. Was wäre also, wenn die Ermittlungsbehörden auf der eigenen Festplatte Dateien vermuten, die in einem fremden Strafverfahren eine Rolle spielen könnten? Das ist natürlich ein recht hypothetischer Fall und mir wäre auch nicht bekannt, dass derartiges bereits vorgekommen ist, aber durchaus interessant.--Temp0001 08:57, 3. Dez. 2009 (CET)

Vielen Dank für diese nochmalige Klarstellung, kann vielleicht jemand sagen wie es in Österreich ist? Ich habe schon gehört das in solchen Fällen Beugehaft angedroht wurde? Robert(nicht signierter Beitrag von 77.116.96.61 (Diskussion) 20:05, 10. Feb. 2009 CET)

Es muss ja nicht immer die - an Gesetze gebundene - Staatsanwaltschaft oder Polizei sein, die ein Passwort wissen will. Auch in der Familie oder im Beruf gibt es Situationen, in denen jemand dem massiven Druck ausgesetzt sein kann, ein Passwort zu eröffnen: Herr Capulet will das Tagebuch seiner Tochter Julia lesen, oder Edgar das von seinem Bruder Edward gesicherte Beweismaterial einsehen, oder Frau Macheth will wissen, was Herr Macbeth wirklich von ihr denkt, oder Gertrud will die Aufzeichnungen von Rosenkranz und Güldenstern lieber selbst lesen ... jw188, 05.03.2009
Aber es gibt ja auch die Möglichkeit, durch verstecken der Truecrypt-Texte und einer Fake-Meldung das Fehlen eines Betriebssystems oder einen Hardware-fehler etc. vorzutäuschen.--Jvaljean 03:40, 26. Mai 2009 (CEST)
Und das hat jetzt genau was mit deiner Kritik an der plausiblen Abstreitbarkeit zu tun? Denn es ist weder plausibel, dass du mit einem Rechner ohne Betriebssystem arbeitest, noch dass dieses wegen Hardwarefehler nicht geladen werden kann und du damit mit trotzdem arbeiten kannst. Könnte man vlt. alles machen, wenn das Betrübssystem mitspielt (hätte, könnte, würde - alles Konjunktiv und reine Spekulation), aber auf der anderen Seite gibt es die sinnvolle Einrichtung der plausible-denialbility bereits... --Trac3R 14:39, 26. Mai 2009 (CEST)

Warum immer so kompliziert? Im Zweifelsfall habe ich mein Passwort vergessen, sowas kommt ja öfters mal vor... cefiros 26. Nov 2009 (nicht signierter Beitrag von 95.90.186.199 (Diskussion | Beiträge) 16:34, 11. Nov. 2009 (CET))

Mißverständliches Kapitel

„Bei der Speicherung von Backups, insbesondere auf CD/DVD, ist Vorsicht geboten, da eine Beschädigung des Volume-Header-Bereiches (die ersten 1024 Bytes) dazu führt, dass der Container nicht mehr gemountet werden kann. TrueCrypt bietet daher eine Funktion zum Sichern und Wiederherstellen des Kopfdatenbereiches. Einzelne defekte Sektoren führen nur dazu, dass die betreffenden Zuordnungseinheiten im enthaltenen Dateisystem nicht mehr gelesen werden können.“ Kapier ich nicht. In welchem Zusammenhang tritt das Problem auf? Auf dem Backupmedium? Oder am aktiven Container (aber wenn, warum)? Und inwiefern kann man beim Backuppen Vorsicht walten lassen? Entweder ist die CD verbrannt (Prüfsummencheck, das gilt aber für alle Binärdaten) oder nicht. --85.178.226.177 21:51, 4. Sep. 2009 (CEST)

Mit Beschädigung ist wohl eine mechanische Beschädigung des Mediums nach dem Brennen gemeint, also Kratzer. --Marco.Geisler 07:15, 5. Sep. 2009 (CEST)
Ich werde den Satz ganz entfernen, denn er stimmt aus mehreren Gründen nicht (mehr):
  1. Es gibt einen Ersatzheader ganz am Ende des Volumes. Dieser kann benutzt werden, falls der Originalheader nicht mehr funktioniert.
  2. Die notwendigen Header-Daten für ein normales Volume sind allein in den ersten 512 und nicht 1024 Bytes. Sollte dagegen ein Hidden-Volumen enthalten sein, wären die notwendigen Daten die ersten 65536 + 512 Bytes (65536 Bytes Outer Volume Header, 512 Bytes Hidden Volume Header - nötiger Teil).
Siehe dazu jeweils http://www.truecrypt.org/docs/volume-format-specification--Temp0001 09:10, 3. Dez. 2009 (CET)

Lizenz

Dieser Abschnitt wurde aus dem Archiv wiederhergestellt --Trac3R 14:41, 14. Mär. 2010 (CET)

Hallo zusammen, als ich ein paar kleine Änderungen am Artikel vornahm ist mir aufgefallen, dass dort Kritik geäußert wird, die vermuten lässt, TrueCrypt sei keine freie Software sondern unterläge aufgrund der zahlreichen „autorenspezifischen“ Lizenzen starken Einschränkungen, weswegen man die software nicht forken und unter der GPL veröffentlichen dürfe. Jedoch wird außer acht gelassen, dass Lizenz unter der TrueCrypt veröffentlicht wird, ebenfalls als eine freie Lizenz im Sinne von freier Software angesehen wird (u.a. von Debian [8], en:TrueCrypt), wodurch es möglich ist den Quellcode zu verändern und das Ergebnis weiterhin unter einer freien Lizenz (in diesem Fall der TrueCrypt Collective License Version 1.3) zu veröffentlichen, so dass aus meiner Sicht der Kritikpunkt unberechtigt ist. Auf jeden Fall suggeriert er in der vorliegenden Form, dass wenn ein Fork unter der GPL nicht möglich sei, er auch unter keiner anderen freien Lizenz möglich sei, was aber nicht der Fall ist. Wenn jemand anerer Meinung sein sollte, dann möchte ich denjenigen bitten sich in seiner Argumentation auf zuverlässige Quellen zu beziehen. Ansonsten würde ich den Kritikpunkt aus dem Artikeltext wieder entfernen, oder wenigstens neutraler formulieren. Viele Grüße -- Meph666 → post 15:16, 27. Feb. 2008 (CET)
Nachtrag: ich beziehe mich in in dem obigen Beitrag auf die Artikelversion vom 21. Februar Meph666 → post

Die Lizenz ist nicht frei und auch nicht Open Source, weil weder von der FSF noch von OSI anerkannt. Debian hat sie auch nicht anerkannt, wie du in deiner verlinkten Mail nachlesen kannst. Ich zitiere mal: The license shows many signs of being written by someone with just enough knowledge to be legally dangerous., das Wort lawyerbomb taucht zwei mal auf und der Text endet mit: Overall, this seems like a fairly pointless and dangerous but not clearly unfree license. Das heißt es ist nicht erwiesen, dass die Lizenz frei oder unfrei ist. Im Zweifel ist sie es nicht. Ich hab das im Artikel geändert. --Trac3R 02:49, 29. Nov. 2008 (CET)
Ich würde darum bitten, diese Tatsache nicht zu ignorieren und das auch nicht in der Einleitung. Das Truecrypt Projekt entscheidet nicht darüber, ob ihre Lizenz Open Source und/oder frei ist. Open Source ist definiert von der OSI und Debian Legal (DFSG ist ähnlich definiert) hat Probleme damit festgestellt. Ob eine Lizenz frei ist, entscheidet letzten Endes die FSF. Und hier würde die Entscheidung ähnlich ausfallen. --Trac3R 14:41, 14. Mär. 2010 (CET)
Das Grundproblem ist, dass "Open Source" kein schutzfähiger Begriff ist. Jeder kann also seine Software "Open Source" nennen. Die OSI hätte zwar gern darüber die Deutungshoheit - hat es aber praktisch nicht. Ganz unproblematisch ist dieser Begriff auch nicht, denn so wie ihn die OSI auslegt, ist er nichts weiter als eine Zweitdefinition von "Freier Software", was die FSF ebenfalls bereits kritisiert hat. In meinen Augen ist diese Verknüpfung der puren Eigenschaft Quelloffenheit (etwas anderes sagen die Worte open source nämlich erstmal nicht aus) mit ganz spezifischen Lizenzen unter dem Begriff "Open Source" auch alles andere als glücklich.
Richtig ist allerdings auch, dass die TrueCrypt-Lizenz problematisch ist. Das trifft weniger auf den puren Einsatz von TrueCrypt zu (der sollte unproblematisch sein), sondern vor allem auf Änderungen bzw. Redistribution der Software. Dort gibt es dermaßen viele Unklarheiten und Fallstricke, dass das rechtlich kaum abzusichern ist.
Mit der derzeitigen Version des Artikels sollte man leben können, wobei halt dieser "Open Source"-Begriff in meinen Augen immer deutliche Bauchschmerzen hinterlassen wird und stets zu derartigen Auseinandersetzungen führt.--Entzücklopädie 08:49, 17. Mär. 2010 (CET)
Freie Software ist ebenfalls kein schutzfähiger Begriff. Jeder kann seine Software frei nennen, was ja auch viele Anbieter von Freeware tun. Und das hat nun überhaupt nichts mehr mit den Wunschvorstellungen der FSF zu tun. Die Begriffe hier gegeneinander auszuspielen oder einen wegen seiner rechtlichen Auswirkungen zu bevorzugen macht überhaupt keinen Sinn. Aber ich nehm die Kritik mal als Aufhänger um den Satz genauer auszuführen, denn immerhin gibt es eine sehr spezifische Open Source Definition und ein Certification Mark der OSI, das rechtlich verbindlich ist. --Trac3R 11:19, 17. Mär. 2010 (CET)

Bluefish

Auf der Seite und im Programm selber kann ich nichts von der Verschlüsselung Bluefish finden, sicher dass diese implementiert ist? Cliffer (falsch signierter Beitrag von 87.78.132.117 (Diskussion | Beiträge) 16:00, 28. Jun. 2007 (CEST))

Bluefish hat nichts mit Chiffrierung zu tun. Du meinst sicher Blowfish, was dem Vorgänger von Twofish entspricht. Twofish wiederrum wird von TrueCrypt unterstützt. (nicht signierter Beitrag von 85.178.119.148 (Diskussion | Beiträge) 22:53, 4. Okt. 2007 (CEST))

Erwähnung eines neuen britischen Gesetzes

Hallo zusammen, das Prinzip der glaubhaften Bestreitbarkeit (engl. plausible deniability) gewinnt durch das vor kurzem in Kraft getretene britische Gesetz [9], dass den Beamten die Androhung von bis zu fünfjährigen Haftstrafen ermöglicht, an Bedeutung. So sollte dies auch meiner Meinung nach auch hier in diesem Artikel erwähnt werden. Eine Alternative dazu wäre das anlegen eines eigenen Artikels "Glaubhafte Bestreitbarkeit", weil ich nicht denke dass dieses Konzept nur auf Truecrypt beschränkt ist. Viele Grüße. -- Meph666 → post 12:11, 8. Okt. 2007 (CEST)

Sicherheitsrisiko der Rettungs-CD

"Zu Beginn des Verschlüsselungsvorgangs einer Systempartition oder -festplatte erstellt TrueCrypt eine Rettungs-CD („Rescue Disk“)[4]. Diese ermöglicht nur das Wiederherstellen eines defekten Kopfbereiches. Stellt unter ganz bestimmten umständen ein kleines Sicherheitsrisiko dar, auch wenn das Passwort selbst nicht darin gespeichert ist." Worin besteht dieses Risiko? Die Festplatte enthält genauso wie die CD den Bootloader und den Masterkey. Die CD wird dem Angreifer also nichts helfen. Das einzige Sicherheitsrisiko ist, dass wenn man sein Passwort ändert man mit Hilfe der CD und des alten Passworts die Daten noch entschlüsseln kann. Darauf weißt TrueCrypt aber hin, wenn man sein Passwort ändert und empfiehlt die alte Rettungs-CD zu vernichten. Ich bitte also darum diesen Satz (der nichtmal korrekt ist) "Stellt unter ganz bestimmten umständen ein kleines Sicherheitsrisiko dar, auch wenn das Passwort selbst nicht darin gespeichert ist." entweder zu streichen oder zu erklären anstatt dieses "Risiko" so in der Luft hängen zu lassen.(nicht signierter Beitrag von 87.175.179.133 (Diskussion) 20:49, 14. Nov. 2008 (CET))

Bootkit hebelt Festplattenverschlüsselung aus

heise.de, 30.07.2009 Nemissimo 酒?!? RSX 23:19, 30. Jul. 2009 (CEST)

Änderung / Ergänzung bezüglich des Konzeptes der glaubhaften Abstreitbarkeit

  • Der Satz Sie sind damit von normalen Partitionen oder Dateien voller Zufallszahlen nicht zu unterscheiden. ist in meinen Augen sehr unglücklich formuliert. Zum einen kann man kaum von normalen Partitionen oder Dateien voller Zufallszahlen sprechen, da eine Partition bzw. Datei voller Zufallszahlen eher nicht Normalität sein wird. Zum anderen gibt es doch einige wenige Merkmale dieser Containerdateien, die allgemeine Dateien mit Zufallszahlen nicht unbedingt erfüllen und die sich Programme wie TCHunt zu Nutze machen, um mögliche TrueCrypt-Containerdateien aufzuspühren:
    1. Die Dateigröße ist bei Truecrypt stets ein ganzzahliges Vielfaches von 512 Bytes.
    2. Es gibt eine Mindestdateigröße, die durch die Truecrypt-Header und das Dateisystem vorgegeben wird.
    3. Es gibt keinerlei Dateiheader, so dass sich Truecrypt-Dateien von Dateien mit ähnlichen Entropien (ZIP-Dateien, MP3s, ...) sicher abgrenzen lassen.
Somit kann man also in einigen Fällen zumindest sagen, dass eine Datei - obwohl voller Zufallszahlen - ggf. kein Truecrypt-Volume sein kann. Damit gibt es also doch Unterscheidungsmerkmale (die zwar nicht immer greifen, aber doch in einigen Fällen). Da im Artikel bereits im vorherigen Satz erwähnt ist, dass die Containerdateien wie zufällige Bitfolgen aussehen, halte ich den obigen Satz für komplett verzichtbar.
  • Dass die versteckten Volumes mit hoher Vorsicht zu genießen sind und es sehr viele Stolperfallen gibt, die zur (unabsichtlichen) Aufdeckung des versteckten Volumes führen können, sollte zumindest im Artikel erwähnt werden. Das nun verlinkte Paper bezieht sich zwar auf Truecrypt 5.1, ist aber grundsätzlich nach wie vor gültig (zusammen mit einigen Anmerkungen, die auch in der bereits verlinkten Truecrypt-Dokumentation sind - im Paper gibt es allerdings weitere Gefährdungsszenarien). Eventuell sollte der Artikel in Zukunft aber noch dahingehend ausgebaut werden, dass man die Vorteile des seit Version 6.0 möglichen Versteckens des gesamten Betriebssystems bezüglich dieser Schwachstellen erläutert.--Temp0001 19:55, 10. Nov. 2009 (CET)

Oma-Test

Ich bin kein Informatiker. Es gibt in diesem Artikel längere Passagen, die ich nicht verstehe, weil ich die verwendeten Begriffe nicht kenne und es teils auch keine Artikel zu diesen gibt. Außerdem habe ich den Eindruck, dass der Artikel äußerst Linux-lastig ist (überprüfen kann ich das nicht, dazu müsste ich ja die verwendeten Begriffe kennen). Kann den Artikel bitte mal jemand so umschreiben, dass er den Bedürfnissen von nichtsahnenden WindowsnutzerInnen ohne jegliche Programmierkenntnisse oder Kenntnisse anderer Betriebssysteme entgegenkommt? Es soll nicht unbedingt eine Anleitung werden, aber den "Omatest" sollte er schon bestehen können. Bevor das jetzt jemand mißversteht: Ich möchte nicht, dass irgendetwas aus dem Artikel ersatzlos verschwindet, das den "Omatest" nicht besteht! Ich möchte nur, dass sich der Artikel kontinuierlich verbessert. Thx! MfG, --Klingon83 00:36, 1. Jul. 2010 (CEST)

geschloßene Entwicklung

TrueCrypt bietet weder einen offenen Bug Tracker, noch Version Control (CVS, SVN, git) an um Fehler und Patches einzusehen. Sollte das erwähnt werden, gerade in Hinblick auf die Vertrauenswürdigkeit und Nachvollziehbarkeit der Software (Wer darf einchecken und hat wann, was und warum geändert)? (nicht signierter Beitrag von 78.42.195.34 (Diskussion) 02:18, 20. Aug. 2010 (CEST))

Ich habe da auch einiges darüber gelesen und fände es gut wenn diese Haltung wenigstens in einem Satz erwähnt würde. -- Chromax 10:55, 22. Sep. 2010 (CEST)

Angriffszenario Truecrypt

Hallo! Ich beschäftige mich schon eine Weile mit Truecrypt und frage mich, wie sicher es ist, es einzusetzen, um sensible Daten zu schützen. Sagen wir, jemand entdeckt bei einer Festplattenanalyse eine Partition, die unlesbar für ihn ist und er vermutet daher eine Verschlüsselung. Er versucht den Besitzer der Festplatte zu zwingen, die Verschlüsselung preis zu geben. Wenn der Besitzer das tut, muss er zumindest das äußere Volumen mounten. Dann ist klar, Truecrypt wurde verwendet, denn um ein Volumen zu mounten, muss Truecrypt gestartet werden. Wenn sich nun jemand etwas auskennt, ist es sehr gut möglich, dass er die Existenz eines hidden volume stark vermutet und seinen Angriff darauf richtet. Er kann es zwar nicht beweisen, dass ein solches Volumen existiert, doch er kann versuchen, weiterhin Zwang auszuüben, in der Hoffung, dass auch noch das Passwort für das hidden volume preisgegeben wird. Wie seht ihr das? Wenn ich sicher sein will, darf ich unter keinen Umständen zugeben, Truecrypt zu kennen oder angewandt zu haben. Also darf ich auch kein äußeres Volume nur zum Schein oder als Alibi mounten. Wie soll ich dann aber die Existenz einer Partition erklären, die nicht leserlich ist? Was sagt ihr?

Danke Joe (nicht signierter Beitrag von 67.223.112.89 (Diskussion) 23:29, 4. Jan. 2011 (CET))

Ganz schweres Thema, welches von sehr vielen Umständen abhängt. Hier muss man sehr viele Abwägungen machen, insbesondere welchen technischen Sachverstand man dem Angreifer zutraut. Wenn man selbst Laie ist und es mit einem versierten Angreifer zu tun hat, wird man sich vermutlich sehr schnell in Widersprüche verstricken. Natürlich gilt es auch die entsprechenden Konsequenzen einer Offenlegung der geheimen Daten gegen die einer erkannten Lüge abzuwägen bzw. welche Chance man sich einräumt, mit der Lüge "durchzukommen".
1. Die Verwendungen von TrueCrypt selbst abzustreiten, ist schon gar nicht so einfach. Sollte man z. B. die Systemverschlüsselung gewählt haben, sieht der Angreifer die Verwendung von TrueCrypt an Hand des Bootcodes der Pre-Boot-Authentifizierung. Sollte man nur Container (als Datei oder als Partition) verwenden, hat man vermutlich trotzdem TrueCrypt fest installiert, um auf die Container leicht zugreifen zu können. Auch das würde der Angreifer sehen. Selbst wenn man keine derartigen Spuren hinterlassen hat, so dass man TrueCrypt ggf. abstreiten könnte, so muss man zusätzlich aber dafür sorgen, dass das Alibi plausibel ist. Einfach irgendein anderes Verschlüsselungsprogramm zu nennen, kann gefährlich sein, weil man ggf. auf Grund des Datenformats erkennen kann, dass es dieses auf jeden Fall nicht ist. Auch einfach zu sagen, dass man die Partition zum Löschen mit Zufallsdaten gefüllt hat, ist u. U. mit Risiken verbunden - der Angreifer könnte fragen, mit welchem Programm man das gemacht hat (man sollte als mindestens vorbereitet sein und sich was überlegen). Aber auch dabei besteht wieder die Gefahr, dass diese Programme irgenwelche Metadaten erzeugen, die halt nicht zum vorgefundenen TrueCrypt-Container passen.
2. Wenn man sich dazu breitschlagen lässt, zumindest das Passwort des äußeren Containers herauszugeben und damit auch zuzugeben, dass man TrueCrypt verwendet, wird es keinesfalls einfacher. Denn gerade mit diesen versteckten Volumes kann man als Laie verdammt viel falsch machen und diese auffliegen lassen. Im Diskussionsarchiv gibt es dazu eine entsprechende Betrachtung, was sehr leicht bereits die Sicherheit in dieser Richtung gefährdet und was alles Ansatzpunkte für den Angreifer sind, entsprechend weiter zu bohren.--91.34.228.58 16:26, 10. Jan. 2011 (CET)

Da möchte ich mich anschließen. Außerdem: Kann - vorausgesetzt das reguläre Volume wurde entdeckt und gemountet - nicht innerhalb dieses das versteckte Volume ebenfalls wieder durch Analyse "entdeckt" werden? Also rein auf Grund der Anordnung innerhalb des Volumes? (nicht signierter Beitrag von 78.54.144.227 (Diskussion) 10:01, 9. Jan. 2011 (CET))

Nicht direkt. Es gibt Möglichkeiten, das innere Volume wirklich geheim zu halten. Bei der Erstellung des äußeren Volumes, wird dieses von TrueCrypt stets komplett mit Zufallsdaten gefüllt (auch im gemounteten Zustand sieht es also erstmal komplett wie Zufallsdaten aus - bis auf das Dateisystem). Ein inneres Volume unterscheidet sich deshalb standardmäßig erstmal nicht von dem leeren ihn umgebenden äußeren Volume - sieht beides komplett wie Zufallsdaten aus. Bei der anschließenden Verwendung des äußeren Volumes bzw. auch des inneren Volumes kann man aber so viel falsch machen bzw. bei einer Befragung Fehler begehen und sich dadurch in Widersprüche verstricken, dass es für den Normalanwender gegenüber einem versierten Angreifer / Befrager kaum möglich sein wird, ein inneres Volume glaubhaft abzustreiten. Siehe dazu den oben bereits angesprochenen Diskussionsarchivbeitrag.
Der Wikipedia-Artikel ist in dieser Richtung aber in der Tat ungenügend, weil er zwar die "glaubhafte Abstreitbarkeit" anpreist, aber keine wirklich substantiellen Aussagen macht, unter welchen Umständen dies gilt oder nicht gilt.--91.34.228.58 16:26, 10. Jan. 2011 (CET)

Abschnitt "Angriffsszenario"

Dieser Abschnitt ist in dieser Form nicht sinnvoll und ich werde ihn deshalb entfernen. Das ist nichts weiter als durchsichtige Werbung für eine Software mit sehr zweifelhaftem Wert.

Bei gemountetem (sic!) TrueCrypt-Volume nach dem Schlüssel im Arbeitsspeicher zu suchen, ist nicht sonderlich clever. Man könnte nämlich alternativ auch einfach auf das Volume selbst zugreifen in dem Moment. Auf gut deutsch: Wenn das Volume gemountet ist, kann man auf die Daten zugreifen - Respekt! Dass man dort letztlich den Weg über den Schlüssel geht, der im Speicher liegen muss solange auf verschlüsselte Daten zugegriffen werden soll, ist keine neue Qualität. Das gleiche ließe sich übrigens auch mit jedem Trojaner erreichen. Die Grundvoraussetzung bei allen derartigen Dateiverschlüsselungssystemen ist, dass im entschlüsselten Zustand nur legitime Nutzer Zugriff auf die Daten haben. Insoweit ist ein Angriff auf einen Computer auf dem die Daten gerade entschlüsselt vorliegen etwas, was unter allgemeiner Computersicherheit zu bewerten ist und nicht etwas, was TrueCrypt-spezifisch ist.--Entzücklopädie 12:48, 20. Okt. 2010 (CEST)

Hallo Entzücklopädie!
Die Quellenpflicht führt zu unvermeidbarer Nennung des Namens des (in Deutschland für Privatdetektive illegalen) Programms.
Nein, bei abgemeldetem Benutzer/ gesperrter GUI kann man eben nicht auf das gemountete Volume zugreifen. Nur das beschriebene Angriffsszenario ermöglicht per FireWire den Zugang zum Passwort im Arbeitsspeicher und damit zum Zugriff auf die verschlüsselten Daten. TrueCrypt- und Bitlocker-Nutzer sollten das wissen.
Der Begriff "mounten" stammt aus der Dokumentation von TrueCrypt. Wie nennst du es?
Es ist einerseits eine Einschränkung der Sicherheit von Daten auf TrueCrypt Volumes, dass diese Möglichkeit des Passwort-Auslesens besteht. Vielen Nutzern dürfte das unbekannt sein. Das Schließen dieser Lücke bzw. Ausräumen dieser Möglichkeit (FireWire disablen) ist eine wichtige Anmerkung zum Programm. Andererseits ist durch diesen Absatz im Wikipediaartikel geklärt, dass TrueCrypt nicht etwa geknackt ist, wie es bei oberflächlicher Betrachtung der Beschreibung von Passware verstanden werden könnte. Google liefert 659 Treffer für "passware truecrypt geknackt" z.B. http://www.golem.de/1003/74189.html . Diese Sicherheitslücke ist eine Betriebssystemlücke, denn ein Anwender erwartet es in der Regel nicht, dass per FireWire auch bei gesperrter GUI (Windows-Benutzer-Abmeldung) der Zugriff auf den Arbeitsspeicher inklusive Passwörter möglich ist. Weiß jemand, ob Linux auch betroffen ist? beste Grüße --Hundehalter 19:26, 20. Okt. 2010 (CEST)
Außerdem erlaubt ein evt. nur kurzfristig möglicher Zugriff auf einen solchen Rechner u.U. nicht das Auslesen der kompletten verschlüsselten Volumes. Wenn ich in der Zeit aber das Passwort ermitteln kann, kann ich zu einem späterern Zeitpunkt in Ruhe darauf zugreifen (und dann sogar auch noch die Daten auslesen, die seit meinem Erstzugriff dazugekommen sind). --YMS 20:11, 20. Okt. 2010 (CEST)
das letztgenannte Argument kannte ich noch gar nicht. Stimmt, ein Angreifer kann während meiner Abwesenheit am gesperrten PC das PW ermitteln und dann später meine zwischenzeitlich hinzugefügten verschlüsselten Daten lesen.
ich will selbstverständlich keine Werbung für diese Software machen. Der Verkauf und Besitz dieser Software ist m.E. nach § 202c StGB strafbar. "Wer eine Straftat nach § 202a oder § 202b vorbereitet, indem er (...) Computerprogramme, deren Zweck die Begehung einer solchen Tat ist, herstellt, sich oder einem anderen verschafft, verkauft, einem anderen überlässt, verbreitet oder sonst zugänglich macht...".
ich plädiere dafür, die Löschung durch Entzücklopädie rückgängig zu machen, d.h. seinen Edit nicht zu 'sichten'. beste Grüße --Hundehalter 20:46, 20. Okt. 2010 (CEST)
Nochmal: Dieses Problem ist nichts, was mit TrueCrypt zu tun hat. Und deshalb ist es ziemlich unsinnig, es hier im Artikel zu erwähnen. Es ist eine allgemeine Unzulänglichkeit von Windows und es lässt sich zum Ausführen beliebigen Codes verwenden. Unter http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=211201211 wurde schon vor Jahren erklärt, wie man z. B. die Passwortabfrage dadurch abschaltet und eine gesperrte Maschine zugänglich macht - und damit sämtliche Türen öffnet. Auch das Durchsuchen des Speichers nach möglichen Passwörtern und Schlüsseln ist nicht ungewöhnlich - diese Bedrohung besteht sogar schon bei jedem Trojaner und wurde bereits auch mehrfach für TrueCrypt demonstriert.
Da es hier nicht Sinn sein kann, jede Sicherheitslücke der Systeme zu dokumentieren (monatlich mehrere), die sich auch für TrueCrypt nutzen lässt hier nun konkret die Frage: Was ist die konkrete Besonderheit, die eine Erwähnung im Artikel rechtfertigen würde? Bisher sehe ich nur Firmen-PR, die hier offenbar völlig unreflektiert blind eingefügt wurde.--Entzücklopädie 00:15, 21. Okt. 2010 (CEST)
Hallo Entzücklopädie!
nochmal - die Quellenpflicht erfordert die Nennung der Quelle, diese Quelle nennt nun mal die Firma.
Nach meinem Kommentar "Besitz dieser Software ist m.E. nach § 202c StGB strafbar" finde ich deine Beschuldigung, ich würde Firmen-PR "völlig unreflektiert blind [einfügen]" nicht nachvollziehbar.
Mir ist unerklärlich, warum Du eine Software, die ausdrücklich zu dem Zweck vertrieben wird, TrueCrypt zu "entschlüsseln" ( http://www.cop2cop.de/2010/03/31/passware-kit-forensic-entschlusselt-truecrypt-festplatten-innerhalb-von-minuten/ ) nicht als zugehörig zum Thema TrueCrypt anerkennen kannst. Richtig, andere Artikel wie der zu BitLocker sollten die Information ebenso enthalten. Ich habe mal als Vergleich nach dem Knacken der Premiereverschlüsselung geschaut, erwartungsgemäß findet sich dort ein Abschmitt, der sich mit dem Thema befaßt: http://de.wikipedia.org/wiki/Sky_Deutschland#Verschl.C3.BCsselung . Dort wird zwar kein Anbieter der Smartcard benannt, das dürfte daran liegen, dass diese nicht offen, sondern nur unter der Theke verkauft wurde. Also, mein Standpunkt ist: Wenn eine "Knacksoftware" gegen eine Software erhältlich ist, sollte bei ausreichender Relevanz diese Zweit-Software im Artikel der Erst-Software erwähnt werden. Durch deutschsprachige Angebote auf dem offenen Markt, u.a. an "Privatdetektive", sehe ich hier die Relevanz als gegeben an.
"allgemeine Unzulänglichkeit von Windows" - bist du sicher, dass es unter Linux nicht funktioniert? Gruß --Hundehalter 16:09, 23. Okt. 2010 (CEST)
Hier muss man Entzücklopädie Recht geben, es handelt sich um eine "ganz normale" Eigenschaft von IEEE 1394. Firewire ist in der Tat so gedacht, dass verschiedene Geräte untereinander den Speicher des jeweils anderen über DMA lesen und schreiben können. So etwas wie Zugangskontrolle oder Sicherheit ist da schlichtweg nicht eingeplant. Das hat auch nichts mit Windows oder Linux zu tun, das Betriebssystem merkt von dem Zugriff rein gar nichts. DMA kann man für Firewire i.d.R. abschalten, wodurch es zwar spürbar langsamer wird, sich der Angriff aber auch erübrigt.
Insofern hat "Entzücklopädie" vollkommen Recht, diese supergeheime Spezial-Hackersoftware mit göttlicher Macht tut rein gar nichts, als sich als ein x-beliebiges IEEE 1394 Gerät auszugeben, das gerne DMA-Zugriff hätte. Und den gewährt der freundliche Nachbar gerne. Somit kann das Programm, solange der Computer Strom hat, beliebige Speicherbereiche lesen (oder schreiben), und damit ist die Sache auch schon erledigt. Keine Magie, völlig unspektakulär, und es hat rein gar nichts mit TrueCrypt zu tun.
Nebenbei bemerkt werden TrueCrypt Laufwerke normalerweise ausgehängt, sobald der Benutzer sich ausloggt, das Passwort-Cache wird dabei überschrieben. Der "Angriff bei gesperrter Arbeitsstation" funktioniert also nicht, sofern man nicht mit Einstellungen gespielt hat, von denen man nichts versteht. (nicht signierter Beitrag von 92.192.79.33 (Diskussion) 17:40, 27. Jan. 2011 (CET))

version 2.8 aktuell?

im abschnitt "Lizenz": "Die aktuelle Version 2.8 erlaubt nur eine Weitergabe in unveränderter Form für das komplette Programm. "

tatsächlich hat es laut der history:

http://www.truecrypt.org/docs/?s=version-history

nie eine version 2.8 gegeben, es ging von 2.1a direkt zur 3.0

davon abgesehen ist version 3.0 von ende 2004 (!) - alles andere als aktuell für eine software (nicht signierter Beitrag von 94.223.222.99 (Diskussion) 00:31, 21. Jan. 2011 (CET))

Hier handelt es sich nicht um das SW-Release, sondern um das Lizenz-Release, im Text jetzt entspr. konkretisiert --Andys / ☎ 16:24, 11. Mär. 2011 (CET)

Dropbox

Gerade erlebt TrueCrypt einen neuen Aufschwung in Sachen Dropbox, da es natürlich eine super Methode ist, um seine Daten vor dem Betreiber zu schützen. Mal abgesehen von der schlechten Geschwindigkeit bei großen Containern, wäre es interessant auf den Sicherheitsaspekt in diesem Zusammenhang hinzuweisen. Wird nämlich das Laufwerk schon "blank" auf der Dropbox erstellt, hat der Betreiber mindestens zwei Version der Datei mit leerem Inhalt (und gesetztem Passwort) und gefüllt. Es wäre denkbar, dass das einen Angriff deutlich vereinfacht, da das Passwort ja nicht verändert wird. Es wäre interessant ob Truecrypt da einen Mechanismus gegen hat. Björn Meyer (nicht signierter Beitrag von 77.176.69.206 (Diskussion) 09:32, 11. Mai 2011 (CEST))

Da besteht keine Gefahr. Es ist nicht so, dass TrueCrypt einfach nur XOR verschlüsselt und man durch Kenntnis eines Klartextes (leere Datei) und eines Schlüsseltextes oder von mehreren Schlüsseltexten durch geeignete Verknüpfungen den Schlüssel an der betreffenden Stelle errechnen könnte. TrueCrypt verwendet zur Verschlüsselung den XTS-Modus (leider nur in Englisch verfügbar), siehe auch die TrueCrypt-Dokumentation dazu. Dieser Verschlüsselungsmodus ist explizit darauf ausgelegt, dass Kenntnisse von alten Klartexten oder Schlüsseltexten an der gleichen Stelle nicht helfen. Lediglich wenn man über die Zeit im gleichen Sektor der Datei zweimal den gleichen Schlüsseltext sieht, dann weiß man, dass dort in beiden Fällen der gleiche Klartext stand. Bei zustandslosen Verschlüsselungssystemen lässt sich das aber nicht vermeiden. Es gilt außerdem auch immer nur für den gleichen Sektor - gleiche Schlüsseltexte in unterschiedlichen Sektoren lassen keinen Rückschluss über die Identität der Klartexte zu.
Nebenbei erstellt TrueCrypt unter normalen Umständen keine leeren Dateien im Sinne von Nullen, sondern schreibt Zufallsdaten in die noch ungenutzten Bereiche (es sei denn, man deaktiviert das). Auch deshalb sieht man in dem Sinne keine "leere" Datei.
Prinzipiell wäre es natürlich wünschenswert, wenn der Artikel besser auf die technischen Grundlagen eingehen würde, so dass sich die Frage erübrigt. Leider fehlt der deutschsprachigen Wikipedia dafür etwas das Umfeld (allerdings ist das auch bei der oben verlinkten englischsprachigen Wikipedia nicht viel besser, da wird zwar mehr erwähnt, aber davon eigentlich auch nichts wirklich erklärt). Der Artikel zur Blockverschlüsselung ist auf einem Stand von vor 15-20 Jahren stehen geblieben. Dabei hat sich dort in den letzten ca. 10 Jahren sehr viel getan und es wurden mehrere Modi neu entwickelt, die beweisbare Sicherheitseigenschaften haben sollen (da vorher einige als sicher angenommene Modi gebrochen wurden). Das ist andererseits aber auch kein Thema, was man mal eben aus dem Ärmel schüttelt und locker nebenbei hinschreibt. Die neuen Modi und deren Sicherheitsbeweise sind relativ komplex und nichts wäre schlimmer als dass bei diesem Thema ungenau gearbeitet wird und falsche Dinge da stehen an Hand derer einige unbedarfte Leute dann vielleicht Sicherheitsentscheidungen treffen.--Entzücklopädie 11:40, 11. Mai 2011 (CEST)
Wunderbar - das mit den Zufallsdaten wäre dann eine interessante Ergänzung im Artikel. Auch wenn das Gefühl bleibt, dass die Entschlüsselung durch Kenntnis von zwei Versionen die Entschlüsselung einfacher macht, so wird dadurch plausibel, warum dies zunächst nur eine vernachlässigbare Vereinfachung darstellen kann. Selbst ein Rainbowtable-Ansatz versagt dann Aufgrund der Unkenntnis des Klartextes. Mir ist schon klar das es sehr viel komplexer ist. Aber man braucht für Laien wie mich zumindest ein Plausibilitätsargument. (nicht signierter Beitrag von 77.176.69.206 (Diskussion) 13:41, 11. Mai 2011 (CEST))

Konzept der glaubhaften Abstreitbarkeit

Dort steht unter Punkt 2. folgendes: "Wird man z. B. gezwungen, das Passwort für das Volume herauszugeben[...]." Diese Info ist in der Hinsicht falsch, dass man nicht gezwungen werden kann, sein PW rauszugeben. Zumindest nicht in Deutschland. Entweder der Teil wird also entfernt oder dementsprechend umgeschrieben.--92.76.243.27 13:48, 19. Mai 2011 (CEST)

Man kann gezwungen werden, wenn nicht in Deutschland so anderswo, nichts anderes ist hier gesagt, bleibt also so! --Andys / ☎ 13:52, 19. Mai 2011 (CEST)
Zudem gilt psychischer Druck auch als Zwang und das kann sehr wohl in Europa geschehen. --Netpilots -Φ- 14:56, 19. Mai 2011 (CEST)

Angreifbar?

"If an embedded TPM is involved, a simple swapping of the hard drive will get around all these problems. Once the raw contents are saved to disk, forensics software can retrieve the keys from disk encryption systems such as Vista BitLocker, Apple FileVault, TrueCrypt, dm-crypt, and potentially a bunch of other data encryption solutions as well. Once is key is exposed, the hard drive might as well not be encrypted at all." Cryogenically frozen RAM bypasses all disk encryption methods. Abgesehen vom beschriebenen Kälteangriff scheint das Konzept laut Quelle unsicher.... stimmt das?216.151.191.240 11:15, 19. Nov. 2011 (CET)

Da wurde unsolide recherchiert und wichtige Randbedingungen wurden nicht genannt. TrueCrypt selbst unterstützt überhaupt keine TPMs und wird dies auch in Zukunft nicht tun, siehe TrueCrypt FAQ ("Some encryption programs use TPM to prevent attacks. Will TrueCrypt use it too?" - ca. nach 2/3 der Seite). TrueCrypt-Schlüssel aus einem TPM auszulesen ist also völlig unmöglich, weil TrueCrypt seine Schlüssel dort gar nicht ablegen kann.
Bei anderen Systemen kommt es auf die Randbedingungen an. Der beschriebene Angriff bezieht sich aller Wahrscheinlichkeit nach auf BitLocker in einer unsicheren Standardkonfiguration, siehe hier. In diesem Fall legt BitLocker den Festplattenschlüssel einfach nur im TPM ab und liest ihn von dort bei jedem Start des Systems wieder ein. Insbesondere ist dieser Schlüssel selbst nicht durch ein Passwort geschützt. Damit ist natürlich klar, dass man einfach nur das System starten muss - es gibt keinerlei Sicherheitsfunktion. Das würde also nur gegen einen reinen Festplattendiebstahl helfen. Aber selbst BitLocker könnte man richtig einstellen, so dass zusätzlich eine PIN abgefragt wird mit der dann der Schlüssel verschlüsselt ist - dann funktioniert dieser Angriff auch dort nicht mehr. --Entzücklopädie 12:33, 19. Nov. 2011 (CET)
Herzlichen Dank für die Antwort.91.39.93.231 16:45, 22. Nov. 2011 (CET)

Rescue Disk

Ist die Disk pro verschlüsselten Rechner also indiviuell? Oder braucht man diese Scheibe wirklich nur einmal, wenn man verschiedene Rechner betreut? -- Eynbein ⚗ 13:37, 15. Apr. 2012 (CEST)

im artikel steht, die rescue disk sei "systemspezifisch", also funktioniert sie nur fuer einen rechner. --Mario d 14:13, 15. Apr. 2012 (CEST)
Ok, danke. -- Eynbein ⚗ 16:01, 15. Apr. 2012 (CEST)
Die Rettungs-CD ist deshalb systemspezifisch, da der Master-Schlüssel zur Entschlüsselung der Festplatte / Partition enthalten sein muss. Das Passwort dient nur der Entschlüsselung dieses Master-Schlüssels, allein mit dem Passwort könnte man also nichts anfangen. Demzufolge ist also die Rettungs-CD immer an die entsprechend verschlüsselten Daten gekoppelt. --Entzücklopädie 16:05, 15. Apr. 2012 (CEST)

Offenbar "knackbar" mittels speziell vorbereiteter USB-Sticks

Nach einer Bekanntmachung von F-Secure ist es mit der Software FinFly USB möglich, auch vollständig mit TrueCrypt verschlüsselte Partitionen anzugreifen.--84.178.45.106 19:53, 2. Sep. 2013 (CEST)

das hat mit TC selbst nichts zu tun, infiziert wird ja das system, bspw. der boot sector. --Mario d 17:08, 3. Sep. 2013 (CEST)

"Geschichte" geht mit Version 4.0 für Linus los.

Na toll. Was soll denn das? Die Geschichte einer Software beginnt am Anfang. Wo kommt das Programm her? Der Einleitende Satz "Verschiedene Versionen für Linux gibt es seit Version 4.0." ist so was von fehl am Platze, wie aus dem Zusammenhang gerissen. (nicht signierter Beitrag von 79.240.243.169 (Diskussion) 18:06, 6. Sep. 2013 (CEST))

Wikipedia:Sei mutig! --Nyks (Kontakt) 09:50, 7. Sep. 2013 (CEST)

Zu wenige Informationen zur Geschichte

Was ist mit Version 1.0?

Es fehlen zu allen Versionen die Jahresangaben.... (nicht signierter Beitrag von GWronna (Diskussion | Beiträge) 21:15, 3. Apr. 2014 (CEST))

Zur Referenz: http://en.wikipedia.org/wiki/TrueCrypt_release_history --85.179.0.198 23:14, 4. Jun. 2014 (CEST)

NPOV

Grund: Es werden keine ausreichenden Belege dafür angegeben, dass das Szenario eines Hoax "unwahrscheinlich" sei. Auf der Diskussionsseite gibt es erheblichen Zweifel an den unten gemachten Aussagen. — Alleskoenner (Diskussion) 16:12, 5. Jun. 2014 (CEST)

Hallo "Alleskönner". Eine Quelle hast Du sicher schon gesehen - die Aussage von Matthew Green zwei Abschnitte weiter oben. Inklusive sachlicher Begründung. Auch ansonsten ist der allgemeine Tenor in etwa wie hier "Mittlerweile ist einigermaßen klar, dass es sich nicht um ein Defacement der Webseiten handelt".
Auf den Abschnitt weiter oben ("Vermutung eines Hacks") bist Du nicht mehr eingegangen. Kann man also davon ausgehen, dass Du auch keine Mehrheit oder zumindest eine nennenswerte Zahl von Experten gefunden hast, die auch heute noch einen Hack für wahrscheinlich halten?
Ohne Dir zu nah treten zu wollen nehme ich folglich den NPOV-Baken aus dem Artikel, da er ihn verschandelt, und meiner Ansicht nach, wie oben beschrieben, kein Grund dazu besteht. Ich hoffe, das ist ok für Dich. Viele Grüße, --DanielDüsentrieb (Diskussion) 20:35, 5. Jun. 2014 (CEST)

Quelle stadt-bremerhaven

Gemäß Wikipedia-Regeln bitte die Belegpflicht erfüllen. Sollte der private Blog (!) "stadt-bremerhaven" die Kriterien erfüllen, bitte das begründen, bevor diese Quelle erneut eingefügt wird. Danke, --DanielDüsentrieb (Diskussion) 16:20, 30. Mai 2014 (CEST)

Caschys Blog, inkl. der dort verlinkten Einzelnachweise. --Nyks (Kontakt) 10:24, 6. Jun. 2014 (CEST)

truecrypt.ch

http://truecrypt.ch/ (nicht signierter Beitrag von 178.197.237.2 (Diskussion) 15:31, 30. Mai 2014 (CEST))

Das ist die URL einer Website ohne jeden Inhalt. Falls sich dort eine Community sammeln sollte, die TrueCrypt weiterentwickelt, dann könnte das für den Artikel relevant werden. Derzeit ist es das nicht. --DanielDüsentrieb (Diskussion) 15:40, 30. Mai 2014 (CEST)
Die Website ist nun schon einige Zeit mit Inhalt gefüllt. Zwei Schweizer haben ein Verein zur Fortführung des Projektes gegründet, die pure-privacy association (pure-privacy.org). In ihren Richtlinien verpflichten sie sich einer freien Software, Namensnennung der Programmierer sowie der Offenheit bezüglich Finanzen und Quellcode. Anfang Juli wurde der Name CipherShed für die TruCrypt-Fork bekannt gegeben, da sie nicht den alten Namen (auch nicht in Teilen) verwenden dürfen. Wenn ich es richtig verstanden habe, dann warten sie mit ihrer eigenen Software darauf, bis das Audit von TrueCrypt abgeschlossen ist. --Kutabu (Diskussion) 12:02, 4. Aug. 2014 (CEST)

Closed Source als Alternative?

Es ist doch wohl eigentlich gar nicht vorstellbar, dass ein closed-source-Produkt eine ernsthafte Alternative sein könnte. Vorschlag: Streichen oder mindestens qualifiziert relativieren. 84.179.139.81 10:17, 3. Jun. 2014 (CEST)

die liste ist tatsaechlich ziemlich lang geworden. thema des artikels ist truecrypt, deshalb wuerde ich nur truecrypt-derivate oder von den truecrypt-entwicklern empfohlene programme auflisten. die momentane liste ist jedenfalls nicht zufriedenstellend, weil die gruende fuer die auswahl unklar sind. alle moeglichen alternativen aufzufuehren, ist keine gute loesung. falls jemand in einem eigenen artikel eine liste der alternativen aufstlelen moechte, kann sie natuerlich hier verlinkt werden. --Mario d 14:32, 3. Jun. 2014 (CEST)
Insbesondere sind die genannten Varianten BiltLocker und FileVault nicht plattformunabhängig, was wohl das war, was Truecrypt so groß gemacht hat. Würde die auch unbedingt entfernen. Auch versteckte container machen die Alternativen nicht mit. --Fabiwanne (Diskussion) 19:27, 15. Jun. 2014 (CEST)
was TC gross gemacht hat und welche features wichtig sind, dazu hat wohl jeder eine andere meinung. mir liegt daran, klare kriterien zu haben, was in den abschnitt aufgenommen wird, sonst bringt hier jeder sein lieblingsprogramm ein. das ist der TC-artikel, also sind meine kriterien: a) fork oder weiterentwicklung von TC b) eine ausdrueckliche empfehlung der TC-entwickler. --Mario d 22:02, 15. Jun. 2014 (CEST)
Ich versteh zwar die Argumentation, finde es aber trotzdem nicht gut, den Leuten damit einfach die zweifelhafte Empfehlung zum Wechsel zu Microsofts oder Apples closed-source-Varianten zu empfehlen, weil diese eben für die Kryptographie automatisch als unsicher gelten müssen. Dann könnte man ebenso empfehlen, einfach TrueCrypt zu behalten, da kein Audit große Sicherheitsmangel aufgedeckt hatte (und das ist schon mal mehr, als man von den Closed Source Varianten sagen kann). Also ich würde mir wünschen, dass wir uns das noch mal überlegen, mit den Empfehlungen. Meine Empfehlungskriterien wären: 1) So weit es geht identischer Funktionsumfang, oder besser (das kann auch Portabilität mit einschließen) 2) Open Source. Alternativ kann man natürlich noch >irgendwie< kurz erläutern, wieso eben die beiden geschlossenen Lösungen keine angemessenen Umstiegsmöglichkeiten sind. Gruß Paxnos (Diskussion) 12:02, 13. Aug. 2014 (CEST)
wir sollten gar keine empfehlung aussprechen, das ginge gegen NPOV. wir geben hier die empfehlung der TC-entwickler wieder und es ist klar, dass sie empfehlung von ihnen stammt. hast du eine quelle dafuer, dass die angegebenen alternativen nicht angemessen sind? dazu gibt es sicher einen haufen meinungen, aber gibt es einen konsens? dass in TC keine schweren fehler gefunden wurden, steht bereits an der entsprechenden stelle im artikel. --Mario d 13:09, 13. Aug. 2014 (CEST)
Hallo - klar, selbstständig Dinge empfehlen, das ist nicht unsere Aufgabe. Prinzipiell gibt es nur Indizien gegen diese Programme (soweit mir bekannt). Schwerwiegend ist allerdings die Rechtslage (u.a. PATRIOT Act), die amerikanische Unternehmen schonungslos zur vollständigen Kooperation zwingt, und zwar mit extrem fiesen Mitteln (bspw. Lavabit). Da Closed-Source Software so gut wie gar nicht untersuchbar ist und gerade die amerikanische Rechtslage so radikal ist, gelten diese Varianten als nicht vertrauenswürdig. Die bestätigte Teilnahme Microsofts und Apples am PRISM-Programm (s. unser Wiki-Artikel zu PRISM) alleine lässt schon die Alarmglocken läuten. Aktuell komme ich zeitlich leider nicht dazu, gute Quellen herauszusuchen. Wie man im Artikel das nun konkret formuliert, ist definitiv eine schwere Sache. Ich wollte hier nur noch einmal Überlegungen anstoßen, ob man das so stehen lassen möchte oder wie man den Artikel entsprechend anpassen möchte. Schlimm ist es nicht, wie es jetzt da steht (es wird ja nichts Falsches gesagt), aber ein wenig Bauchschmerzen bereitet es mir schon. Gruß Paxnos (Diskussion) 23:19, 13. Aug. 2014 (CEST)
die genannten produkte sind ja verlinkt, kritik sollte mMn auf deren seite untergebracht werden. fuer TC ist das eher nebensaechlich und ich moechte vermeiden, dass der abschnitt "alternativen" hier zu einer art bewertungsseite fuer HD-encryption mutiert. --Mario d 12:53, 14. Aug. 2014 (CEST)

alternativen

nachdem hier alle paar tage jemand aufschlaegt, der versucht seine lieblingsprogramme in diesem abschnitt unterzubringen, tendiere ich dazu, den abschnitt zu loeschen und durch einen link zu Festplattenverschlüsselung#Software zu ersetzen. alternativ koennte ich mir die beschraenkung auf nachfolger, die zu TC voll kompatibel sind, vorstellen. jedenfalls brauchen wir harte kriterien. --Mario d 10:41, 18. Sep. 2014 (CEST)

Ich würde den Abschnitt einfach vollständig entfernen. Ist einfach zu POVig und auch nicht Aufgabe des Artikels irgendwelche alternative Crypto-SW weiterzuempfehlen.
Was die ursprünglichen TC-Entwickler empfehlen, würde ich in den Abschnitt Geschichte packen, denn die Autoren sind unbekannt und haben mE. keine Authorität irgendwelche Alternativen zu empfehlen (was der derzeitige Abschnitt "Alternativen" suggeriert).--Plankton314 (Diskussion) 10:53, 18. Sep. 2014 (CEST)
Also hier hat ja in diesem Sinn jetzt ja keiner sein Lieblingsprogramm untergebracht...
Ob und wieweit die Löschung sinnvoller ist als eine möglichst unvoreingenommene (aber kritische) Darstellung der Empfehlung, kann ich jetzt nicht beurteilen - so genau hab ich die Edits jetzt nicht verfolgt. Trotzdem kann ich Deinen Einwand hinsichtlich (m)einer "Privatmeinung" nicht ganz nachvollziehen. Ich habe nicht behauptet, daß es so ist, sondern lediglich auf (belegbare,) eindeutige Widersprüche hingewiesen - und dies ist durchaus ein hartes Kriterium. Insofern ist dies auch weit weniger Spekulation als etwa die Aussage, bei der Einstellung wäre evtl. Druck ausgeübt worden.
Ich bitte Dich, noch einmal zu überlegen, ob Dein Rückgängigmachen meiner Änderung wirklich notwendig war. (Evtl. könnte man mit so einer Darstellung auch weitere Edits verhindern/einschränken - zumindest wenn sie sich um diesen Punkt drehen).
(Weiterhin wäre auch zu hinterfragen, inwieweit überhaupt die "Empfehlung eines Herstellers" unkommentiert in ein Lexikon aufzunehmen ist - selbst wenn sie ernst gemeint ist...)--Katzmárek2 (Diskussion) 11:01, 18. Sep. 2014 (CEST)
es ist unsere aufgabe, gesichertes wissen darzustellen, nicht etwas zu empfehlen, zu kritisieren oder vor etwas zu warnen. "Inwieweit es sich hierbei um einen ernst gemeinten Hinweis aus innerem Antrieb des Entwicklerteams handelt, darf [...] hinterfragt werden" - so ein satz wuerde in keinem artikel durchgehen. das ist nichts anderes als deine meinung - also POV in reinform, wenn auch leicht kaschiert, der auch nicht dadurch gerettet wird, dass es "weniger Spekulation" ist als andere aussagen. letzten endes gibt es zu diesem punkt einfach wenig fakten, dafuer aber viel spekulation und die hat hier nichts verloren. ich sehe nicht, wie man kritik hier angemessen einbauen kann, so stehen lassen koennen wir es aber wohl auch nicht. daher plaediere ich fuer loeschen (gerne auch mit erwaehnung im abschnitt "geschichte", um den anschein zu vermeiden, wir wuerden eine empfehlung aussprechen). bei google kann man sich leicht ueber alternativen informieren, das ist aber nicht unsere aufgabe. --Mario d 13:46, 18. Sep. 2014 (CEST)
Du schreibst: "es ist unsere aufgabe, gesichertes wissen darzustellen". Dies ist so nicht ganz richtig (bzw. wird nicht konsequent eingehalten). Es gibt z.B. Artikel über Gott, UFOs, Yetis und das Ungeheuer von Loch Ness. Auch für den Artikel selbst trifft es nicht zu, denn dort steht: "Während anfangs über ein mögliches Defacement der TrueCrypt-Website spekuliert und vor dem Download der neuen Version gewarnt wurde, wird ein solches Szenario inzwischen für unwahrscheinlich gehalten: Die neuen Programm-Downloads tragen die korrekte offizielle elektronische Signatur des Herstellers. Zudem wurde im Quelltext keine Hintertür oder ähnliches gefunden, und ersten Berichten zufolge wurde das zum Download angebotene ausführbare Programm tatsächlich aus dem angebotenen Quelltext erstellt. Allerdings gibt es weiterhin Spekulationen, ob die Autoren von TrueCrypt einen National Security Letter erhalten und aus diesem Grund das Projekt eingestellt haben könnten".
Nochmal: Die Empfehlung widerspricht vorigen eigenen Aussagen der Entwickler. Dies kann (und sollte) erwähnt werden, ohne hier Spekulation oder Theoriefindung zu unterstellen. Dies kann meiner Meinung nach genauso eingebaut werden, wie ich es formuliert hatte - ggf. kann man es auch anders formulieren. Meine Meinung ist dies übrigens nicht. Über meine Meinung hab ich nichts geschrieben.
Zudem sind es ja gerade die möglichen Umstände der Einstellung, die auch hier im Artikel die Haupt-Mitteilung - sogar unter einer eigenen Überschrift - darstellen (was angesichts der öffentlichen Rezeption auch gerechtfertigt ist); anderenfalls würde es reichen, mitzuteilen, "Die Entwicklung wurde am 28.5.14 eingestellt".--Katzmárek2 (Diskussion) 14:10, 18. Sep. 2014 (CEST)
Ich habe nochmal darüber nachgedacht.
Das Problem ist ja hauptsächlich, daß die "Alternativen" hier als Empfehlung der TC-Entwickler dargestellt wird (bzw. aufgefasst werden kann). Also entweder könnte man ja diese Empfehlung in den Kontext der Projekt-Einstellung stellen (so wie ich es versucht habe) - dann muß man aber auch auf die Umstände hinweisen. Oder man stellt die Alternativen neutral (und vor allem unabhängig von der Empfehlung) dar. Dann würde es sich eigentlich ebenfalls verstehen, daß man den Haupt-Mangel dieser Alternative erwähnt - und das wäre dann auch ganz ohne POV- und Spekulationsverdacht möglich...
So wie es jetzt ist, kann es aber nicht bleiben! Immerhin steht da jetzt eine Empfehlung (zumindest ist es nicht spekulativ, daß dies so verstanden wird) für ein potentiell unsicheres Produkt; und zwar für einen Produktwechsel zu einem Produkt, das - egal ob die Überlegung hinsichtlich einer erzwungenen Einstellung zuträfen - im Sinne derer wäre, denen man dies unterstellt.--Katzmárek2 (Diskussion) 17:11, 18. Sep. 2014 (CEST)

Ich habe jetzt mal den Abschnitt mit den Empfehlungen der TC-Entwickler nach Geschichte verschoben. Dabei ist mir aufgefallen, dass auf der Homepage keine Empfehlung für MacOS FileVault, dm-crypt o.ä. zu finden ist, sondern nur für Bitlocker.
Spricht nun noch etwas gegen die Entfernung des Abschnitts Alternativen, zumindest solange wir keine vernünftigen Kriterien finden?--Plankton314 (Diskussion) 12:35, 19. Sep. 2014 (CEST)

das ist definitiv eine verbesseurng. eine moeglichkeit waere die umbenennung in "nachfolger". forks gibt es mWn keine, aber mehr oder weniger kompatible nachimplementierungen. --Mario d 12:55, 19. Sep. 2014 (CEST)
Es in diesen Kontext zu stellen ist sicher besser. (Trotzdem könnte es bei unvoreingenommenem Lesen noch ein wenig wie eine Empfehlung klingen, die "ja im Lexikon steht..." - ich wäre dafür, es ganz fortzulassen!)
Was spricht nun aber dagegen, unter Alternativen bzw. Nachfolger zu erwähnen, daß Programme, deren Quelltext nicht öffentlich ist, gerade unter diesem Aspekt als potentiell unsicher gelten müssen? Ebenso kann man darauf hinweisen, daß TC weiterhin verwendet werden kann - gerade, weil ja, wie oben erläutert, das Vorhandensein von Hintertüren (und groben Fehlern) nahezu ausgeschlossen werden kann. Gerade hierzu kann aber bei nicht-quelloffenen Programmen überhautpt keine Annahme getroffen werden.
Dies umso mehr, als es ja keinen übergeordneten Artikel "Festplattenverschlüsselung" gibt, wo dies thematisiert wird.--Katzmárek2 (Diskussion) 14:29, 19. Sep. 2014 (CEST)
Also, ich hänge nicht sehr an dieser Empfehlung, von mir aus kann sie auch ganz draußenbleiben.
Wir können den Abschnitt statt Alternativen wie Mario vorgeschlagen hat in sowas wie Nachfolger oder TC-kompatible Nachbildungen umbenennen. Ein echter Fork ist glaube ich wegen der Lizenz nicht möglich. Das ist zumindest mal eine wesentlichere Einschränkung ggü. bloßen Alternativen.
Ansonsten würde ich mich auf einem komplexen Umfeld wie der Kryptologie nicht zu solchen Aussagen hinreissen lassen. Und außerdem ist das hier ja "nur" ein Artikel über eine konkrete Verschlüsselungssoftware. Wenn, dann wäre sowas mE. in einem allgemeineren Artikel unterzubringen.--Plankton314 (Diskussion) 18:16, 19. Sep. 2014 (CEST)
Dann sollten wir das so machen...
Ich will nicht weiter streiten (mehr scheint mir erstmal nicht "rauszuholen" zu sein...). Dies also als OT: Um nachzuvollziehen, daß man nicht weiß, welche Funktionen ein Programm (oder Gerät) hat, solange man nicht nachvollziehen /-prüfen kann, was eingebaut wurde, braucht man kein Kryptologie- oder Softwareexperte sein. Bei komplexer Software gibt es einfach keine Möglichkeit nachzuvollziehen, was diese tatsächlich kann (bei vielen Programmen lassen sich je nach Lizenz z.B. Features einfach freischalten - würde dies nicht beworben, gäbe es keine Möglichkeit, davon zu wissen bzw. diese zu nutzen). Bei quelloffenem Code ist es (zumindest von Experten) leicht nachvollziehbar - hier muß man als Anwender nur darauf vertrauen, daß das Programm tatsächlich aus dem veröffentlichten Quellcode stammt (bzw. daß es schon irgendwem auffällt, wenn dies nicht so ist). Andernfalls muß man sich einzig auf die Zusage/Dokumentation des Herstellers verlassen - es gibt aber schlichtweg keine Kontrollmöglichkeit! Aber es stimmt sicher, daß dies in einem eigenen Artikel tiefgreifender beleuchtet werden könnte (und sowieso betrifft es ja nicht nur Verschlüsselungssoftware...).
Mir ging es wirklich nicht darum, ein Programm madig zu machen - eher darum, die Problematik aufzuzeigen.--Katzmárek2 (Diskussion) 21:02, 19. Sep. 2014 (CEST)
Nun, bei Closed-Source kann durchaus ein unabhängiges Audit stattgefunden haben, aber es stimmt, dass man sich meist auf die Aussagen des Herstellers verlassen muss. Andererseits bringen die meisten Anwender nicht genug Wissen und Zeit mit, um zu überprüfen ob Open-Source-Programme wirklich das tun, was man behauptet. Bei TC hat in den vergangenen 10 Jahren keiner - trotz verfügbarem Quellcode - tiefer reingeschaut. Das alleinige bestehen einer Kontrollmöglichkeit reicht also nicht unbedingt aus.--Plankton314 (Diskussion) 14:44, 20. Sep. 2014 (CEST)
Ich habe gerade auch nochmal nachgeschaut... Eigentlich wird BitLocker auch gar nicht empfohlen. Es wird gesagt, daß die Systeme nach WinXP eine bordeigene Verschlüsselung anbieten. Laut hier und dort gibt es BitLocker sowieso nur auf manchen Win-Editionen. (Und "Ultimate" ist wahrscheinlich kaum das, was im heimischen PC läuft.)--Katzmárek2 (Diskussion) 21:18, 19. Sep. 2014 (CEST)
Ich habe den Satz nochmal gekürzt und nur allgemein die integrierten Verschlüsselungslösungen erwähnt.--Plankton314 (Diskussion) 14:44, 20. Sep. 2014 (CEST)

Neue Version 7.2

Nachdem nicht klar ist, ob Version 7.2 wirklich von den Entwicklern stammt und nicht etwa vielleicht die Website/SourceForge-Zugänge gehackt wurden, wäre es besser 7.1a als aktuelle Version stehen zu lassen, damit sich diese (möglicherweise schädliche Version) nicht noch mehr verbreitet.(nicht signierter Beitrag von Raincp (Diskussion | Beiträge) 23:30, 28. Mai 2014‎)

Ich hab mal die Sichtung rausgenommen, jetzt bekommen unangemeldete Besucher noch die alte Artikel-Version zu sehen.
Ja, das ist alles schon etwas komisch. Fefe und Ars-Tech schreiben, dass zumindest die Signatur korrekt wäre. Das einzige, was der ganzen Sache etwas Glaubwürdigkeit verleiht...--Plankton314 (Diskussion) 23:37, 28. Mai 2014 (CEST)
Ich habe wieder auf 7.1a umgestellt, da die 7.2 laut diversen Quellen gehackt ist und nicht funktioniert. Zudem ist es ja die 7.1a, die einem Audit unterzogen wurde, der rel. positiv ausgefallen ist. --Túrelio (Diskussion) 10:32, 29. Mai 2014 (CEST)
Die ganze Geschichte ist schon seltsam, aber wie Plankton314 schon schrieb, ist die Signatur korrekt. Abgesehen davon gibt es keinen "offiziellen" Download der 7.1a mehr. -- Widar23 (Diskussion) 10:53, 29. Mai 2014 (CEST)
Hallo ihr. Ich kann gut nachvollziehen, dass gerade Aufregung herrscht. Allerdings sollten wir trotzdem nüchtern an die Arbeit gehen...
Es spielt erst einmal gar keine Rolle, ob die Version 7.2 besser ist oder schlechter als die 7.1a. In jedem Fall ist sie neuer und damit aktueller. Im Artikel habe ich zudem explizit auf die Unterschiede der beiden Versionen hingewiesen. da die 7.2 laut diversen Quellen gehackt ist ist gelinde gesagt unbewiesen. Im Gegenteil, die Signatur ist korrekt und das Binary stimmt offenbar mit den Sourcen überein. In den Sourcen wurde bisher keine Backdoor gefunden. Seit heute Nacht schauen allerdings so einige Leute weltweit da rein. Also ist der derzeitige Stand, dass Version 7.2 aktuell ist (und noch dazu allem bisherigen Wissen nach eben ohne Backdoor). Aufgabe der Wikipedia ist es, den aktuellen Informationsstand darzustellen - also, dass 7.2 aktuell ist. Und weil wir es gut meinen, können wir ja auf die Umstände der Version 7.2 und auf die Version 7.1a hinweisen. Absichtlich inkorrekte Versionen können wir dagegen nicht darstellen.--DanielDüsentrieb (Diskussion) 10:55, 29. Mai 2014 (CEST)
Das hat Sinn. Die Diffs zwischen 7.1a und 7.2 weisen übrigens nicht auf eine Backdoor hin, in erster Linie ist nur Code rausgeflogen um Container anzulegen etc -- Widar23 (Diskussion) 10:59, 29. Mai 2014 (CEST)
Korrekt. Das mit den Sourcen kann ich bestätigen, ich habe mir die heute Nacht selbst angeschaut.--DanielDüsentrieb (Diskussion) 11:11, 29. Mai 2014 (CEST)
Wenn ich Verschwörungstheoretiker wäre, würde ich fragen, ob ihr alle für die NSA/den BND arbeitet.
Gemäß Wikipedia:Neuigkeiten gehören solche ungesicherten Angaben überhaupt nicht in die Wikipedia. Wie bekannt, wurde der Quellcode von 7.1a einem Audit unterzogen, der im Prinzip positiv ausgegangen ist. Zu 7.2 gibt es bislang keinerlei verlässliche Angaben. Es spricht einiges dafür, dass entweder die Site gehackt wurde oder der inkonsistente aktuelle Inhalt der umgelenkten Website eine versteckte Botschaft der TC-Leute ist, weil sie einen NSA-Security letter erhalten haben und zum Schweigen verpflichtet wurden. --Túrelio (Diskussion) 11:05, 29. Mai 2014 (CEST)
Die Vermutung mit dem NSL liegt nahe, ist aber trotzdem wilde Spekulation im Moment. Alles definitive ist nunmal das, was auf truecrypt.sourceforge.net steht... -- Widar23 (Diskussion) 11:09, 29. Mai 2014 (CEST)
Entschuldige, Turelio, aber Verschwörungstheorien haben keinen Platz in der Wikipedia. Wir stellen die aktuelle Version dar, wir weisen sogar explizit auf seltsame Umstände und auf die Vorversion hin. Mehr können wir nicht tun. Die Wikipedia stellt Informationen dar, keine Verschwörungstheorien und auch keine bewusst falschen/nicht mehr aktuellen Informationen.--DanielDüsentrieb (Diskussion) 11:11, 29. Mai 2014 (CEST)
Problem ist nur dass die Angaben auf sourceforge völlig ungesichert und massiv strittig sind. --Túrelio (Diskussion) 11:20, 29. Mai 2014 (CEST)
Zum ersten Punkt ("ungsichert"): Die Hintergründe um TrueCrypt waren schon immer mysteriös. Man weiß nicht, wer die Autoren sind - sie wollen anonym bleiben. Das sind die Tatsachen. Folglich gibt es lediglich zwei Möglichkeiten, wie "gesicherte" Informationen zustande kommen können: Zum einen Antworten auf den offiziellen Kontakt-E-Mail-Adressen, zum anderen Verlautbarungen auf der offiziellen Website. Auf Kontaktmöglichkeiten wird nicht mehr verwiesen - die Jungs wollen offenbar nicht mehr kontaktiert werden. Und die offizielle Website leitet nun (quasi eben offiziell) auf Sourceforge um. Ergo ist das maximale, was man an "Sicherung" haben kann, dass die Information auf der TrueCrypt-Seite von Sourceforge stehen kann.
Zum anderen Punkt (massiv strittig): Das ist Theoriefindung bzw. falsch. Fakt ist, offiziell wird (übrigens *nur noch*) die Version 7.2 angeboten. Wenn Du Backdoors meinst: Finde und beweise eine. Alle die es vor Dir versucht haben, sagen aber, sie haben bisher keine gefunden. Aber sowas gehört nicht hierher. --DanielDüsentrieb (Diskussion) 11:26, 29. Mai 2014 (CEST)
+1. Die aktuelle Darstellung im Artikel ist mE. in Ordnung. Die jüngsten Geschehnisse werden hinreichend neutral dargestellt und momentan sprechen die Diff-Links der v7.2 sowie die Signatur nicht für die Hacker-Verschwörungstheorie. Außerdem kann man es jederzeit ändern, sobald neue Fakten bekannt werden.--Plankton314 (Diskussion) 12:55, 29. Mai 2014 (CEST)

Im aktuellen Wikipedia Artikel heißt es "Weiterhin wird dort [...] gewarnt, die Software sei unsicher". Das ist falsch. Im Original heißt es "Using TrueCrypt is not secure as it may contain unfixed security issues". Das heißt es wird lediglich davor gewarnt, dass zukünftig entdeckte Lücken nicht mehr geschlossen werden, und daher könnte TrueCrypt in Zukunft unsicher werden. --93.194.120.238 12:48, 29. Mai 2014 (CEST)

Halb richtig, halb falsch. Die Aussage ist ganz klar, es ist nicht sicher. Grund: Es könnte Lücken enthalten. Also ist die Aussage korrekt übersetzt. Ja, ich denke auch, dass damit die von Dir frei formulierte Aussage gemeint ist. Aber das wäre eine Interpretation, und die können wir nicht beweisen. Man könnte nun die Begründung (es könnten Lücken existieren) noch mit anführen. Das ist im Fließtext auch so gemacht worden. In der kurzen Einleitung kann man sich darüber streiten, ob man so sehr ins Detail gehen will. Ich hab es jetzt mal gemacht, Service für den Leser und so. Danke für den Hinweis! --DanielDüsentrieb (Diskussion) 13:00, 29. Mai 2014 (CEST)
(BK) Ist halt die Frage, wie man es liest. "Using TrueCrypt is not secure …" ist erstmal eindeutig. Nur die nachgeschobene Begründung "… as it may contain unfixed security issues" relativiert das ganze etwas.
Das kann man jetzt auch so lesen, dass es grundsätzlich unsicher ist, gerade weil es möglicherweise Sicherheitslücken enthält.
DanielDüsentrieb kam mir gerade zuvor, aber so ist es mE. die neutralste Wiedergabe (und steht so auch im en.Wiki).--Plankton314 (Diskussion) 13:09, 29. Mai 2014 (CEST)

Die Tatsache, dass True Crypt nun nach einem Audit welches sich positiv über den Code äusserte nun auf der Webseite als unsicher bezeichnet und ein Wechsel zum proprietären Bitlocker empfohlen wird, sollte Anlass zu Mißtrauen über Legitimität der Meldung geben - das hat ja quasi April-Scherz Charakter. Es kann sehr gut sein, dass die Webseite lediglich gehackt wurde. Somit könnte die angebotene, neue TC Version 7.2 auch kompromittiert worden sein, da sie auch mit einem älteren Schlüssel signiert wurde und vorherige Versionen von der Seite verschwunden sind. Darauf sollte auch im Artikel hingewiesen bzw vor dem neuen Binary gewarnt werden, bis die Sachlage geklärt ist. --84.160.236.172 11:38, 30. Mai 2014 (CEST)

Ich habe jetzt mal beide Versionen in den Kasten aufgenommen. Damit dürfte dem Leser klar sein, dass er, wenn er den vollen Funktionsumfang nutzen möchte, wohl eher auf die Version 7.1a zurückgreifen sollte. Es spricht meiner Meinung nach nichts dagegen, beide Versionen im Infokasten zu erwähnen. Die Version 7.1a wird übrigens auch noch von heise.de zum Download angeboten. Die anderen einschlägigen Software-Verteiler wie chip.de usw. bieten ebenfalls die Version 7.1a und nicht die Version 7.2 an. -- Viele Grüße -- Kleiner Stampfi (Diskussion) 12:03, 30. Mai 2014 (CEST)

Ich denke, mit den zwei Versionsangaben können wir leben. Allerdings habe ich das eventuell unsicher entfernt. Das ist eine Mutmaßung und geht dann doch deutlich zu weit. Immerhin stellt die Wikipedia Informationen dar. Demzufolge würde es reichen, wir schreiben, dass die Version 7.2 die aktuellste ist. Genau das ist die Faktenlage.
Jetzt bieten wir eh schon einen großen Service für die Nutzer an. Wir schreiben in der Einleitung und im Fließtext, dass die Version 7.2 irgendwie "besonders" ist. Wir haben in der Infobox einen Link zu den Umständen der 7.2, und wir haben auch noch die Vorversion angegeben. Wir haben hier keinen Auftrag, unsere Benutzer zu erziehen oder zu warnen. Trotzdem tun wir es, aber mit all diesen Informationen haben wir wirklich genug getan, um unsere Benutzer zu informieren.
Die Mutmaßung ist einfach nicht mehr enzyklopädisch. Noch dazu, wenn sie aller Wahrscheinlichkeit nach auch noch falsch ist. Immerhin wurde im Quellcode keine Backdoor gefunden, und es wurde nachgeprüft, ob das Binary auch wirklich aus dem Quellcode entstanden ist. Ich denke, in der jetzigen Form (und ohne Mutmaßung) ist das eine runde Sache.--DanielDüsentrieb (Diskussion) 12:22, 30. Mai 2014 (CEST)
Auffällig finde ich, dass schon in der ersten Zeile auf der offiziellen Truecrypt-Website die Formulierung "Not Secure As" verwendet wurde. Weiterhin macht die Begründung, dass Truecrypt wegen dem fehlenden Support von Windows XP eingestellt wurde, genauso wenig Sinn wie der Rat, auf Microsofts Bitlocker umzusteigen. Mittlerweile sollte bekannt sein, dass Microsoft mit der NSA kooperiert. Unsinnig ist auch der Rat der Entwickler an Linux-Benutzer, statt Truecrypt einfach irgendeine vorhandene Verschlüsselungssoftware zu nutzen ("Use any integrated support for encryption. Search available installation packages for words encryption and crypt, install any of the packages found and follow its documentation.") Hinzu kommt, dass die Entwickler von Truecrypt nicht begründen, warum Truecrypt nun ungelöste Fehler beinhalten könnte, und warum es sicherer ist, auf Bitlocker umzusteigen. Schließlich kann es bei jeder Software ungelöste Fehler geben, somit also auch bei Bitlocker, die Begründung der Entwickler ist also überhaupt keine Begründung und widerspricht auch der aktuelen Untersuchung des Truecrypt-Quellcodes, der bekannterweise keine Sicherheitslücken ans Tageslicht gebracht hat. 80.226.24.13 06:27, 3. Juni 2014 (CEST) (falsch signierter Beitrag von 80.226.24.13 (Diskussion) 18:21 Uhr, 3. Juni 2014)
Hallo 80.226.24.13,
Ich habe deine Ergänzung im Artikel rückgängig gemacht, weil es sich dabei nur um Vermutungen handelt, nicht aber um (bestätigte) Fakten.
Die von dir beschriebenen Beobachtungen kommen sicherlich etlichen Leuten komisch vor. Allerdings sind das Schlüsse, die du aus deinen Beobachtungen ziehst und keine Fakten.
Falls in (naher oder ferner) Zukunft etwas über die Hintergründe herauskommt, kannst du das natürlich gerne ergänzen. Gib dann aber bitte dazu eine (glaubwürdige) Quelle an, aus der du diese Information beziehst.--Plankton314 (Diskussion) 18:51, 3. Jun. 2014 (CEST)

Wenn man sich die Versions History von TrueCrypt anschaut, kann man das Argument der Hersteller schon nachvollziehen, dass sie einfach kein Interesse mehr an der Fortentwicklung haben:

Versionen nach Jahr:
2004 - 6
2005 - 3
2006 - 1
2007 - 1
2008 - 6
2009 - 4
2010 - 2
2011 - 1
2012 - 1
2013 - 0
2014 - Eingestellt
--85.179.0.198 23:13, 4. Jun. 2014 (CEST)

@85.179.0.198
Wie du siehst, gab es von 2005 bis 2007 schon einmal eine Phase, in der wenige neue Truecrypt-Versionen veröffentlicht wurden. Trotzdem wurde das Projekt nicht eingestellt.
Hätten die Entwickler das Projekt aus mangelndem Interesse eingestellt, dann hätten sie das schreiben können. Sie hätten schreiben können, dass sie nicht mehr die Zeit für das Projekt haben und sich jetzt mit anderen Projekten beschäftigen. Niemand hätte ihnen das übel genommen. Es ist menschlich, dass sich Interessen ändern. Warum sollten sie uns stattdessen Lügen erzählen? Die Erklärung auf der offiziellen Truecrypt-Website ist ja, dass Truecrypt wegen dem fehlenden Support von Windows XP eingestellt wurde. Diese Erklärung ergibt überhaupt keinen Sinn. Was hat denn Windows XP mit der Weiterentwicklung von Truecrypt zu tun? Es gibt keinen logischen Grund. Ihre Website quillt ja geradezu über vor unsinnigen Begründungen und Empfehlungen. Jede Software kann ungeschlossene Sicherheitslücken beinhalten, was hilft uns also der Hinweis, dass Truecrypt ungeschlossene Sicherheitslücken beinhalten könnte, wenn uns die Entwickler nicht einmal einen Ansatz einer Begründung für diese Annahme liefern?
Ich fasse zusammen:
1. Was auf der Truecrypt-Website steht, ergibt keinen Sinn. Mit einem Hackerangriff kann man das Ganze nicht erklären, weil der Inhalt jetzt schon über eine Woche lang online ist, und die Entwickler Zeit genug gehabt hätten, ihre Website wieder zurückzubekommen und die Bevölkerung über den Hackerangriff aufzuklären.
2. Dass die Entwickler das Projekt aus mangelndem Interesse eingestellt hätten, ist ebenfalls auszuschließen, weil sie es schlicht nicht geschrieben haben und sie in diesem Fall auch keinen Grund dafür gehabt hätten, uns alle zu belügen. Sie hätten einfach schreiben können, dass sie das Projekt aus mangelndem Interesse eingestellt haben.
Übrig bleibt die Theorie, dass die Entwickler von Truecrypt mit einem National Security Letter zur Einstellung des Projekts und zum Schweigen darüber gezwungen wurden. Somit wäre der Rat, auf Bitlocker umzusteigen und die Formulierung "Not Secure As" in der ersten Zeile ihre Nachricht an uns, dass sie von der NSA erpresst wurden. Diese Theorie ist in sich schlüssig, und es wäre höchst irrational, sie zu verwerfen.
Ist es in der Wikipedia denn nicht erlaubt, auf Spekulationen hinzuweisen?
62.226.243.252 20:20, 6. Jun. 2014 (CEST)
Doch, klar! Es gibt ja z.B. auch einen Artikel über Kreationismus - Du mußt halt nur irgendwo einen (akzeptierten) Beleg finden... Also einen Beleg, wo diese Spekulation dargelegt wird. So streng ist das nicht, das muß kein Fachbuch sein - grad bei aktuellen Vorgängen reichen da durchaus Verweise auf Radio, Fernsehen oder Zeitungen. Halt irgendwas seriöses - nicht irgendein Diskussionsforum oder so. (Ich glaube, der DLF hatte dies letzte Woche Samstag in "Computer & Kommunikation" (16.30) z.B. auch thematisiert; sollte man nachschauen, ob es da was verlinkbares gibt.)--Katzmárek2 (Diskussion) 22:40, 6. Jun. 2014 (CEST)
Vermute mal, auch die Betreiber des Internet Archive haben einen National Security Letter gekriegt und haben deshalb die Inhalte gesperrt.Joli Tambour (Diskussion) 15:48, 27. Nov. 2014 (CET)

BitLocker?!

Der Artikel empfahl bis eben für Windows-Nutzer die Benutzung von BitLocker, einem Verschlüsselungsprogramm von Microsoft.

Obwohl auch ich Windows nutze, muss ich mal fragen: Das soll doch ein schlechter Scherz sein, oder? Windows wird auf geschätzt mehr [sic!] als 100% aller Desktop-PCs genutzt. Und da denk ich noch nicht mal an die Informationen zum "NSA-Key", die vor einigen Jahren in die Presse kamen. Microsoft wird für Windows einen National Security Letter erhalten haben, als der noch gar nicht so hieß! Und das Gegenteil lässt sich auch kaum nachweisen, denn darüber dürfen sie ja nicht reden - selbst, wenn sie wollten. In Anbetracht dieser Umstände hab ich diese fast schon an Lächerlichkeit grenzende "Empfehlung" erstmal rausnehmen müssen. --88.130.95.196 23:14, 17. Sep. 2014 (CEST)

Nicht "der Artikel" empfiehlt, sondern "die Entwickler von Truecrypt empfehlen", was genau eine Zeile darüber steht.--Plankton314 (Diskussion) 23:20, 17. Sep. 2014 (CEST)
Sofern es sich - was zumindest nicht auszuschließen ist - um eine erzwungene Einstellung des Projekts handelt, kann nicht ausgeschlossen werden, daß es sich ebenfalls nicht um eine erstgemeinte Empfehlung handelt. Dieser Teil der Aussage ist natürlich Spekulation.
Trotzdem kann und muß diese Empfehlung hinterfragt werden, da diese der "Projektphilosophie" völlig zuwider läuft und dieser Aspekt auch etwa in der Anleitung völlig anders dargestellt wurde. Dieser Widerspruch ist in jedem Fall vorhanden und darf nicht verschwiegen werden! (denn zu behaupten/festzustellen, eine Aussage widerspricht vollständig früheren Aussagen ist in diesem Sinn letztlich keine Spekulation sondern auch ein Fakt)
Und in gewisser Weise kann natürlich auch der Artikel empfehlen - je nachdem, wie der Inhalt ausgewählt wird... Auf die Diskrepanz muß zumindest hingewiesen werden... Und nicht jeder Leser steckt soweit in der Materie, daß er diesen Widerspruch unbedingt selbst hinterfragt! (Recht Vielen wird er kaum auffallen!)--Katzmárek2 (Diskussion) 10:38, 18. Sep. 2014 (CEST)
Die Einstellung war nicht erzwungen. Sondern man wollte erzwingen dass ein Backdoor eingebaut wird. Dies kann die NSA aber nur dann fordern wenn das Programm verschlüsseln kann! Deswegen gab es nochmals eine Version welche nur entschlüsseln konnte (es gibt keinen Weg an dieser Stelle noch ein Backdoor einzubauen, da hier die Verschlüsselung bereits stattgefunden hat, und dieses Programm nur entschlüsseln kann). Dass keiner der Tipps von denen ernst gemeint war wird doch jedem denkendem klar wenn er liest "Installiert auf Linux halt irgendwas mit crypt im namen". Es ist verboten über solche Schreiben zu Berichten, es ist Verboten die Nutzer zu warnen, es ist Verboten die Software zur Verschlüsselung ohne Backdoor anzubieten. Es ist ihnen sogar untersagt anderen die Weiterentwicklung zu ermöglichen, sie mussten also alle Versionen die sie selbst angeboten haben entfernen. Nur so konnten sie ihre User bewahren vor dieser Aktion --95.88.224.174 19:57, 9. Dez. 2014 (CET)

Irgend wie ist das Logo abhanden gekommen. Hat das noch jemand? --Fabiwanne (Diskussion) 18:51, 26. Jan. 2015 (CET)

Du meinst dieses hier: en:File:TrueCrypt Logo.png?
Wurde anscheinend nie in dewp übernommen, kenne mich da aber auch nicht so aus. Es gab auch mal einen Screenshot, der wurde aber gelöscht, kA wieso. Grüße, --#Reaper (Diskussion) 19:57, 30. Jan. 2015 (CET)

sicher, nicht sicher?

Es heißt einerseits immer, es gäbe Sicherheitslücken. Auch hier: "Im September 2015 wurde von einem Sicherheitsforscher eine Sicherheitslücke in TrueCrypt entdeckt, die beim Fork VeraCrypt behoben wurde." Andererseits wurde TrueCrypt eingestellt. Genau Gründe unbekannt. Keinesfalls unwahrscheinliche Variante ist aber die mit National Security Letter. Da gab es also ein Programm, das war so sicher, unknackbar und hintertürfrei, dass womöglich verboten wurde. Und selbst wenn das doch nicht die Wahrheit war, dann war das Programm wenigstens derart hochsicher, dass dieses Gerücht entstehen konnte. Und gleichzeitig fand und findet man dennoch immer wieder Sicherheitslücken ??! Manche WP-Artikel, in denen z.B. mit mathematischen Formeln nur so um sich geschlagen wird und jegliche Omatauglichkeit verlorgen geht sind ja nun nicht gerade vorbildhaft. Man muss ja nicht gleich soweit gehen, hier Programmquellcode von Bugs zu veröffentlichen, oder so. Aber ganz allgemeinverständlich zu erklären, wie es sich genau verhält, wäre schon mal sehr nett und angemessen. Bisher werden hier, wie gesagt, letztendlich nur zwei total gegensätzliche "Zustände" erklärt, eben extreme Sicherheit gleichzeitig mit Sicherheitslücken. --93.200.252.194 15:20, 14. Aug. 2016 (CEST)

Mit ein wenig Hirnschmalz und Recherche käme man mal drauf. Die Verschlüsselung selbst ist sicher. Es existieren aber Angriffsvektoren auf die Software selbst. Jedoch nicht auf die Verschlüsselung, die ist und bleibt sicher. --93.221.228.76 (04:54, 12. Jan. 2017 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Vermutung eines Hacks

Nachdem anfänglich Überraschung herrschte, warum bei Aufruf der TrueCrypt-Website plötzlich eine Warnung ausgesprochen wird, wurden schnell Defacement-Vermutungen ("Hacker") geäußert. Nach der ersten Aufregung wurden die Fakten gesehen:

  • Keine Rückgängigmachung durch die Verantwortlichen, kein Dementi der Verantwortlichen
  • Für ein Defacement ungewöhnlich großer Aufwand (Überarbeitung des Quellcodes)
  • Das zum Download angebotene Binary ist korrekt signiert

Der Tenor von Experten ist nun vielmehr wie der hier: I think it unlikely that an unknown hacker (a) identified the Truecrypt devs, (b) stole their signing key, (c) hacked their site.. Äußern auch jetzt noch (!) mit diesem Wissen immer noch Experten (!) in ausreichender Anzahl die "Hack"-Vermutung, so dass dies relevant für den Artikel ist? Bitte gemäß Belegpflicht vor/beim Einfügen belegen. Danke, --DanielDüsentrieb (Diskussion) 16:20, 30. Mai 2014 (CEST)

Abschnitt Kryptos löschen?

Der abschnitt über Kryptos enthält keine Infos. Löschen? Joeby (Diskussion) 16:57, 15. Jan. 2015 (CET)

TrueCrypt ist sicher!

Siehe https://www.youtube.com/watch?v=IO6wRzKuRzg Betrifft nur die Version 7.1a

Bitte Artikel updaten. Danke

--Baldoius (Diskussion) 17:53, 21. Apr. 2015 (CEST)

Mutmaßlicher Quellcode

Die verlinkte schweizer Seite mit einem unoffiziellen Download-Archiv verlinkt auf diese URL mit einem mutmaßlichen Quellcode-Archiv: https://github.com/FreeApophis/TrueCrypt --Robb der Physiker (Diskussion) 10:50, 6. Jul. 2016 (CEST)

Gründe der Einstellung

Es heißt als möglicher Grund "... ob die Autoren von TrueCrypt einen National Security Letter erhalten und aus diesem Grund das Projekt eingestellt haben." Für Wikipedia eigentlich unangemessen, in diesem Fall bleibt nicht mehr als zu spekulieren. Andere Gründe sind nie bekannt geworden, hätten es aber können und dürfen, falls zutreffend. Dieser Grund würde nie offiziell bekannt und wird damit sehr wahrscheinlich. Es heißt ferner: "Durch Recherchen des Journalisten Evan Ratliff konnte jedoch aufgezeigt werden, dass TrueCrypt seinen Ursprung in der Software "E4M" hat, die durch Paul Le Roux programmiert wurde." Heißt also, Paul Le Roux war schon lange nicht mehr dabei? Der scheint doch sonstwo in der Welt zu leben, ein US-amerikanischer "National Security Letter" dürfte ihn doch somit weniger tangieren? Heißt andersherum...? Truecrypt wurde zuletzt in den USA weiterentwickelt? Wäre die Schlussfolgerung, damit ein "National Security Letter" greifen kann ?? Aber nirgends so zu lesen? --93.200.252.194 15:13, 14. Aug. 2016 (CEST)

GostCrypt?

Wurde GostCrypt von unabhängigen dritten rezipiert? Existiert ein Nachweis der Verbreitung / Relevanz als Alternative zu TrueCrypt abseits der Webseite des Herstellers? (die sich jeder Hinz und Kunz zusammenbasteln könnte) --TheRandomIP (Diskussion) 00:07, 6. Sep. 2020 (CEST)

Habe (auch) keinen Hinweis darauf gefunden. Wurde 2016 eingeworfen und gemäß weiten Sichtungsregeln als vandalismusfrei gesichtet: Scheint sehr deutlich der Bekanntmachung zu dienen, ich gönne es den freien Softwareenthusiasten, auch wenn ichs wohl nicht gesichtet hätte, aber nach bald fünf Jahren immer noch nichts, das ist Leserirreführung. Fazit: Ist zu entfernen. --Trollflöjten αω 13:36, 6. Sep. 2020 (CEST)
Ja, ich empfehle auch, den gesamten Absatz über GostCrypt rauszunehmen. Du kannst es gerne übernehmen. --TheRandomIP (Diskussion) 14:14, 6. Sep. 2020 (CEST)
Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:TrueCrypt/Archiv&oldid=216038276“