Diskussion:TrueCrypt/Archiv

message: Gibt es Informationen darüber, als wie sicher die Verschlüsselung von TrueCrypt anzusehen ist? --Fippo 03:27, 23. Jun. 2007 (CEST)
replies: text: 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)
thread_title:  Sicherheit 

message: 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 . 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:
:# 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.
:# 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 . 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.
:# 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  wird empfohlen, sich darauf hinauszureden, dass es ja die Standardeinstellung ist.
:# 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.
:# 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 .
* 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)
replies: text: 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)
replies: text: 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)

text: "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)
thread_title:  Plausible-deniability-Konzept ist weitgehend Pseudosicherheit 

message: "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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  Transparente Ver- und Entschlüsselung bei kommerziellen Closed-Source-Produkten 

message: 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)
replies: text: 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)
replies: text: In dieser Form definitiv nicht sinnvoll und ein Verstoß gegen die Richtlinien. Ich entferne das erstmal wieder.--Innenrevision 10:22, 10. Okt. 2007 (CEST)
thread_title:  Weblinks 

message: :(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  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)
replies: text: 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)
thread_title:  Weblinks (mal wieder) 

message: In der Mac-Version von TrueCrypt 5.1 gibt es keine Unterstützung für versteckte Container. Nach  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)
replies: text: Für die Zukunft ist eine Implementierung für Mac OS X und Linux geplant . 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)
thread_title:  Keine hidden volumes für Mac 

message: 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)
replies: text: Die deutsche Übersetzung ist nur teilweise, aber zumindestens die wichtigsten Punkte wurden übersetzt, also ein klares Jein! -- 2hochn 23:15, 7. Aug. 2008 (CEST)
replies: text: 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)
thread_title:  Deutschsprachig: Ja - aktuell aber eher nein 

message: 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)
replies: text:  Die versehentliche Hintertür in Debian-OpenSSL ist auch lange Zeit niemandem aufgefallen.--80.136.134.203 11:36, 23. Jul. 2008 (CEST)

text: (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)

text: 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)

text: 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)
replies: text: 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)

text: 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)
thread_title:  Glaubwürdigkeit des Codes bzw seiner Programmierer 

message: 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)
replies: text: 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)
thread_title:  Travelermode 

message: Was ist hiervon zu halten? Nemissimo  酒?!? RSX 19:48, 27. Jul. 2009 (CEST)
replies: text: 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)

text: 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)
thread_title:  6+ Gründe gegen TrueCrypt 

message: 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)
thread_title:  Liebe ist alles 

message: 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)
thread_title:  truecrypt auf UDF formatierten Medien 

message: 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)
replies: text: 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)
thread_title:  Bluefish 

message: Hallo zusammen, das Prinzip der glaubhaften Bestreitbarkeit (engl. plausible deniability) gewinnt durch das vor kurzem in Kraft getretene britische Gesetz , 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)
thread_title:  Erwähnung eines neuen britischen Gesetzes 

message: heise.de, 30.07.2009  Nemissimo  酒?!? RSX 23:19, 30. Jul. 2009 (CEST)
thread_title:  Bootkit hebelt Festplattenverschlüsselung aus 

message: *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:
*#Die Dateigröße ist bei Truecrypt stets ein ganzzahliges Vielfaches von 512 Bytes.
*#Es gibt eine Mindestdateigröße, die durch die Truecrypt-Header und das Dateisystem vorgegeben wird.
*#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)
thread_title:  Änderung / Ergänzung bezüglich des Konzeptes der glaubhaften Abstreitbarkeit 

message: 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)
thread_title:  Oma-Test 

message: 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)
replies: text: 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)
thread_title:  geschloßene Entwicklung 

message: 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)
replies: text: 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)
thread_title:  version 2.8 aktuell? 

message: 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)
replies: text: 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)
replies: text: Zudem gilt psychischer Druck auch als Zwang und das kann sehr wohl in Europa geschehen. --Netpilots -Φ- 14:56, 19. Mai 2011 (CEST)
thread_title:  Konzept der glaubhaften Abstreitbarkeit 

message: 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)
replies: text: im artikel steht, die rescue disk sei "systemspezifisch", also funktioniert sie nur fuer einen rechner. --Mario d 14:13, 15. Apr. 2012 (CEST)
replies: text: Ok, danke. -- Eynbein ⚗ 16:01, 15. Apr. 2012 (CEST)
replies: text: 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)
thread_title:  Rescue Disk 

message: 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)
replies: text: 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)
thread_title:  Offenbar "knackbar" mittels speziell vorbereiteter USB-Sticks 

message: 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)
replies: text: Wikipedia:Sei mutig! --Nyks (Kontakt) 09:50, 7. Sep. 2013 (CEST)
thread_title:  "Geschichte" geht mit Version 4.0 für Linus los. 

message: 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)
thread_title:  Zu wenige Informationen zur Geschichte 

message: 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)
replies: text: Caschys Blog, inkl. der dort verlinkten Einzelnachweise. --Nyks (Kontakt) 10:24, 6. Jun. 2014 (CEST)
thread_title:  Quelle stadt-bremerhaven 

message: http://truecrypt.ch/ (nicht signierter Beitrag von 178.197.237.2 (Diskussion) 15:31, 30. Mai 2014 (CEST)
replies: text: 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)

text: 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)
thread_title:  truecrypt.ch 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Closed Source als Alternative? 

message: 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)
replies: text: 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)
thread_title:  sicher, nicht sicher?  

message: 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)
thread_title:  Vermutung eines Hacks 

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

message: 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)
thread_title:  TrueCrypt ist sicher! 

message: 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)
thread_title:  Mutmaßlicher Quellcode 

message: 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)
thread_title:  Gründe der Einstellung  

message: 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)
replies: text: 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)
replies: text: Ja, ich empfehle auch, den gesamten Absatz über GostCrypt rauszunehmen. Du kannst es gerne übernehmen. --TheRandomIP (Diskussion) 14:14, 6. Sep. 2020 (CEST)
thread_title:  GostCrypt?