Unter Linux gibt es ja gute Alternativen die auch weit besser ins System integriert sind. Aber unter Windows ist TrueCrypt ja irgendwie “DER Standard”.

Aus meinen persönlichen Erfahrungen kann ich nur sagen, dass Programmierer faul sind. Ich selbst hab schon mehrere tausend Zeilen Quellcode verfasst, aber freiwillige (wenn ich für den Quellcode bezahlt werde, muss natürlich auch Doku sein) Kommentare sind bei mir wohl noch im unteren 3-stelligen Bereich. Warum kann es denn nicht möglich sein, dass die Leute um TC einfach nur genauso faul sind. Immerhin machen die das (ich treff jetzt mal die Annahme, dass keine krummen Sachen laufen) in ihrer Freizeit und ohne finanzielle Gegenleistung. Durch ihre Anonymität gibt es ja nichtmal den Ruhm. Ich find es zwar auch nicht unbedingt schön, kann es aber nachvollziehen. Ich weiß auch nicht, wieviel eMails das Team erreicht, aber es könnten so viele sein, dass die Zeit gerade mal zum überfliegen reicht. Gerade bei OpenSource-Projekten muss man ja beachten, dass die Programmierer vermutlich noch einen 8-Stunden Job und Freizeit haben und nebenbei etwas Schlaf brauchen. Von daher hat jeder, der kostenlos für die Allgemeinheit nützliche Programme schreibt, meinen Respekt.
Und wo ich gerade vom Job schreibe. Man braucht ja nur mal überlegen, was für eine Arbeit das sein könnte, bei einem fähigen Programmierer… Es wäre wirklich möglich, dass der Arbeitgeber zum Beispiel ein Softwareunternehmen ist, welches teure Verschlüsselungssoftware anbietet. Dass dem Chef das nicht gefallen wird, wenn ähnliche Software umsonst angeboten wird, muss man ja bestimmt nicht erklären. Daher ist auch soetwas nachvollziehbar (nur dank der Anonymität nie überprüfbar). Davon aber abgesehen, sollte JEDER selbst entscheiden dürfen, ob er in die Öffentlichkeit gelangen will oder nicht. Egal ob er ein kleines Gadget programmiert oder sicherheitskritische Software. Es muss nur die Überprüfbarkeit der Software gegeben sein, und dass ist sie, durch das Bereitstellen der Quellen. Dass sich daraus keine identischen Binaries erzeugen lassen, ist fast offensichtlich bei der Menge an Compilerschaltern und Compilern selber. Auch das einzelne Zugriffe (auf den Container) nochmals optimiert werden können, sollte klar sein. Ist aber natürlich ein Ansatzpunkt, um die Binaries genauer zu überprüfen.

Wer den Binaries nicht vertraut, durchleuchtet den Source selber. Wer das nicht kann und auch niemanden kennt, der das macht, sollte aber auch nicht auf andere Software ausweichen. Nur das Wissen, welche Person hinter einem Produkt steht, macht es noch lange nicht vertrauenswerter. Was stört dieser Person der Imageschaden, wenn besagte Person gerade den vierten Caipirinha in der Karibik schlürft – und das bis ans Ende der Rente (durch die paar Millionen vom Geheimdienst gesponsorten Backdoor).

Mein Fazit ist ähnlich dem meines Vorgängers: Dein Beitrag ist nicht falsch, aber richtig macht ihn das noch lange nicht. Persönliche Einstellungen der Entwickler dem Programm negativ anzukreiden finde ich sehr oberflächlich. Hättest du dir die Mühe gemacht und die Binaries mit eigenen Kompilaten zu vergleichen, hätte der Bericht schon mehr Substanz. So klingt das aber eher wie an den Haaren herbeigezogen.

Also: Alles Gute allerseits auch von mir!

kann eine differenz der beiden dateien (binaries – selbstcomp.) evtl. auch durch die kompilierungsmethode bzw. den compiler selbst zustande kommen, oder lässt sich mit gewissheit darauf schliessen, dass die beiden dateien von unterschiedlichen sourcecodes erstellt wurden? (wahrscheinlich schwer zu beantworten…)

Ja – die Differenz liesse sich auch durch Kompilierungsmethoden erklären.
Ein simples “march=native” beim gcc erwirkt z.B. eine auf den Prozessortypen optimierte Ausgabe. Aber auch die restlichen Flags sind entscheidend.
Zudem geben verschiedene Compiler natürlich verschiedene Kompilate aus.

noch ein weiteres bedenken: wie kann man ausschliessen, dass nicht durch die compiler selbst
(die sind meist closed source) gewisse funktionen eingebaut oder verändert werden?

Ich übergebe hier mal an Ken Thompson der dazu ein geniales Paper veröffentlicht hat.
http://cm.bell-labs.com/who/ken/trust.html

M.a.W. wie lässt sich prüfen, dass die kompilierte fassung exakt dieselben und nur diejenigen funktionen hat, wie der quellcode es suggeriert? maschinencode entziffern? (für menschen annähernd unmöglich, oder?)

Dafür gibt es Disassembler, allerdings ist Assembler nur für die Hardcode Machochisten unter uns
Allerdings wird keiner so doof seine seine Backdoor so einzubauen dass die so offensichtlich auffindbar ist, das ganze muss man natürlich direkt in den Verschlüsselungsmethoden integrieren.
Der aktuelle Wirbel um IPSEC lässt grüssen

kann eine differenz der beiden dateien (binaries – selbstcomp.) evtl. auch durch die kompilierungsmethode bzw. den compiler selbst zustande kommen, oder lässt sich mit gewissheit darauf schliessen, dass die beiden dateien von unterschiedlichen sourcecodes erstellt wurden? (wahrscheinlich schwer zu beantworten…)

noch ein weiteres bedenken: wie kann man ausschliessen, dass nicht durch die compiler selbst
(die sind meist closed source) gewisse funktionen eingebaut oder verändert werden? M.a.W. wie lässt sich prüfen, dass die kompilierte fassung exakt dieselben und nur diejenigen funktionen hat, wie der quellcode es suggeriert? maschinencode entziffern? (für menschen annähernd unmöglich, oder?)

beste grüße ins forum
andrej

(besser zum Fazit scrollen, falls das zu lang ist )

Ich will über die Sicherheit und Funktionalität von TC gar nicht sprechen. Was mir aber wichtig ist:
Solange TC korrekt funktioniert ist das drumherum doch total uninteressant. Das einzige Problem dabei ist, dass sowas bei einigen einen faden Beigeschmack hinterlässt. Und warum? Weil die Mehrheit der Nutzer nämlich auf das “blinde” Vertrauen setzen muss. Es gibt leider keine objektive Instanz, die für uns die Vertraulichkeit der Software TC prüft. Auch wenn es Analysen gibt, so ist doch immer die Frage, ob die Analyse korrekt und vollständig ist? Wo wir wieder bei Vertrauen wären.

.. dürfte für eine Zeitschrift nicht tragbar sein, schliesslich ist ein solches Unterfangen sehr anspruchsvoll und zeitintensiv.

Journalismus ist eh fraglich… ABER wem kann man denn dann trauen? Wer hat die Mittel und das know-how? Und die, welche eben dieses know-how und besagte Mitte haben, ist denen denn überhaupt zu trauen? Bei solchen Leuten/Gruppen/Organisationen stellen sich wieder ganz andere Vertrauensfragen.

Des Öfteren habe ich Aussagen gelesen oder gehört die sinngemäß besagen, dass Schmu oder Sicherheitslücken schon von den vielen Usern/Proggern/Geeks/Orgas gefunden würden und sich niemand mit gutem Ruf so eine Schandtat leisten könne.
Mit Google(Streetview/Datenschutz) und Apple (Iphone hotspot-Datensammlung) passieren solche Dinge, die sich die Unternehmen leisten können ohne größere Folgen. (Im Gros betrachtet, bzw. Marktwert, Marktanteile)
Und wie lange hat es gedauert, bis das raus kam? Zumindest bei Apple.
Offensichtlich kann man sich solche Schnitzer also erlauben und es sind doch nicht so viele oder zumindest keiner so intensiv auf der Suche, um Macken zu finden.

Fazit:
Ich finde den Beitrag generell nicht verkehrt, da er zum Nachdenken anregt (unabhängig von seiner Richtigkeit). Allerdings ist der Bericht etwas einseitig und oberflächlich, was ich schade finde. Zudem sind die Gründe nicht objektiv und an Fakten vorbei.

6+ Gründe gegen TrueCrypt

-> Ist die Software wirklich schlecht? hmm.. Hier wird scheinbar eher ein Entwicklungskonzept bemängelt, als die eigentliche Software.

Soweit mein Salmon. Die Haltung von FanFare sagt mir übrigens am ehesten zu. (nebenbei: Ich hätte keine Lust so einen langen Kommentar zu lesen, wie den meinen )
Alles Gute allerseits

MacMacken hat ganz Recht, den Entwicklern ist allein schon angesichts ihres Verhaltens nicht zu trauen. Aber es gibt noch einen weiteren interessanten Aspekt.

Ich wundere mich schon seit langem, warum bei Truecrypt noch niemand bemängelt hat, dass die auf deren Webseite verfügbaren Binaries signifikant von selbstkompilierten abweichen.

Der Kniff der Truecrypt Foundation liegt also darin, die Öffentlichkeit mit der (momentan hippen) Ist-Eh-Open-Source-Beruhigungspille zu täuschen. Und wie gewünscht wird allerorts, wie auch hier, immer nur über den Quelltext diskutiert, in dem kein Hintertürchen gefunden werden kann. Wer macht sich denn schon die Mühe, die Sourcen selbst zu kompilieren, wenn er sich die vermeintlich daraus entstandenen Binaries soo bequem von der Website downloaden kann…

Ich habe mir jedenfalls die Mühe gemacht, die Schreib- und Lesezugriffe von TC bei beiden Versionen zu vergleichen. Beim TC von der Website wird beim Anlegen eines Containers genau einmal mehr auf den Container zugegriffen als bei meinem selbstkompilierten TC. Ein Schelm, wer Böses dabei denkt.

Dann darf ich also TC nicht mehr nutzen, weil es unsicher ist? Kann mir jemand eine glaubhafte Quelle nennen, dass ein TC-Container schon mal geknackt wurde?

Eine andere These:

Ich verschicke per Email einen TC-Container (5 MB). In diesem Container befindet sich nur ein einziges Dokument mit den Zugangsdaten für ein PayPal-Konto. Der Container ist natürlich mit der höchstmöglichen Verschlüsselung geschützt inklusive einem ellenlangen Passwort. Wer die Datei als Erster öffnet, kann das PayPal-Konto leerräumen. Würde sich irgendjemand zutrauen, an die PP-Zugangsdaten zu kommen?

Freilich können sie gezielt versuchen, der Community zu schaden, aber da es sich grade bei Open Source Projekten oft um sehr un-hierarchisch entwickelte Dinge handelt, die schlichtweg einfach mal geforked werden können, wenn einem das Verhalten der Community nicht passt, ist das auch schwerer als sonst. Es kann sein, dass alle kommerziellen oder sogar weit verbreiteten Verschlüsselungs-Lösungen Backdoors haben, es kann sein, dass es Gesetze gibt, die Leuten verbieten, andere einzusetzen, aber wenn jemand wirklich – auch unter Strafe – Daten verstecken will, dann wird er das können.

Ein Geheimdienst wird dann wohl eher die betreffende Person bis auf den Darm verwanzen um irgendwie an seinen Key zu kommen. Und da gibt es genug Möglichkeiten, von Hardware-Keyloggern, bis zum Abfangen von EM-Strahlung.

Was ich damit sagen will: Ich stimme zu, man sollte Verschlüsselung einsetzen um seine Privatsphäre zu schützen, aber nicht, um sich vor staatlichen Authoritäten zu verstecken. Letzteres geht eher schief, aber das liegt dann eher nicht an den eingesetzten Algorithmen, sondern an den zahlreichen anderen Möglichkeiten. Trotzdem ist es durchaus berechtigt, einer Verschlüsselungssoftware, die von diversen Interessensvertretern (NSA, etc.) mitentwickelt wurde, ein gesundes Misstrauen entgegenzubringen.

Wenn ein mit TrueCrypt verschlüsselter Datenträger oder Computer von Durchschnitskriminellen entwendet wird, so darf davon ausgegangen werden, dass diese an die Daten nicht heran kommen.

Alles andere ist bei TrueCrypt so sicher oder unsicher, wie es bekannt oder unbekannt ist. Das gleiche gilt auch für jede andere Software. Und hier meine ich nicht den Einfluss der Geheimdienste, sondern die persönliche Gesinnung der TrueCrypt-Entwickler, entweder sind sie die “Guten” oder die “Bösen” – solange die Hintergründe für ihr Verhalten nicht bekannt sind, kann man die Sicherheit nur schwer abschätzen.

Wenn das FBI die PGP Corporation nach einem Hintertür-Key fragt, dann gerät so eine Frage nie in Öffentlichkeit. Somit hat das Unternhemen auch keinen Ruf zu verlieren.

Freie Software bewegt sich nicht in einem rechtsfreien Raum – die Freiheit ergibt sich ja gerade aus den jeweiligen Rechtsordnungen.

Ein freies Projekt, welches keinem Unternehemn unterliegt, muss sich beispielsweise nicht den Vorgaben der NSA untergeben. Es ist ja immerhin bekannt, das Apple und Microsoft und viele andere US Unternehmen mit der NSA arbeiten. Linux muss bzw. kann das gar nicht.

Wieso sollte man mit Verschlüsselungssoftware keinen Gewinn erzielen dürfen? Ohne Gewinnerzielung ist es schwierig, Software dauerhaft weiterzuentwickeln – ich störe mich jedenfalls nicht an Gewinnerzielung, sofern die notwendige Transparenz gegeben ist.

Ich habe nicht gesagt, dass man kein Geld machen darf. Doch wenn z.B. die NSA kommt und dem Unternehmen 1’000’000 Dollar bietet, für z.B. einen Backdoor-Key, dann wüsste ich nicht, wieso das Unternehemn ablehnen sollte. Man hört ja oft genug von Datenskandalen. Ich möchte meinen Gedanken anhand eines Beispiels weiterspinnen: Wenn nun die NSA es schafft den LAptop von Osama bin Laden zu stehlen und sie feststellen, das der mit PGP-Verschlüsselt ist, dann werden sie wohl die PGP Corporation dazu zwingen irgend’ so ‘nen Backdoor-Key zu geben

Punkt 1: Auf welche Verschlüsselung im Kernel beziehst Du Dich?

Punkt 2: Siehe oben.

Ich finde das sehr interressant, vor allem den ersten Abschnitt: http://0x4d.ch/m

Man kann Linux verschlüssellung ganz gut in den Kernel integrieren, und da es an keine Landesgesezen untergeben ist, ist es perfekt erweiterbar.

Bestimmt nicht! Ich wette eher das ein Unternhemen (gegen Geld, oder wegen dem Gesetz) eine entsprechendem Hintertür-Key einbaut, als das es nicht Kommerzeile Software tun würde.

Schwierig zu beurteilen – bei PGP hat immerhin ein renommiertes Unternehmen seinen Ruf zu verlieren, bei TrueCrypt hingegen weiss man nicht einmal, wer sich dahinter verbirgt …

Auch ist Freie Software nicht an entsprechende Landesgesetze gebunden, nichtz so wie beispielsweise die PGP Corporation.

Freie Software bewegt sich nicht in einem rechtsfreien Raum – die Freiheit ergibt sich ja gerade aus den jeweiligen Rechtsordnungen.

Dies war nur meine Meinung. Man sollte in Sachen Verschlüsselung keinem Gewinnorientiertem Unternhemen trauen.

Wieso sollte man mit Verschlüsselungssoftware keinen Gewinn erzielen dürfen? Ohne Gewinnerzielung ist es schwierig, Software dauerhaft weiterzuentwickeln – ich störe mich jedenfalls nicht an Gewinnerzielung, sofern die notwendige Transparenz gegeben ist.

PS: Deshalb würde ich wichtige Daten auf eine Linux-Distribution ablegen, da dieses Betriebssystem 1. Verschlüssellung bereits im Kernel hat, 2. Nicht an nationale Gesetze gebunden ist.

Punkt 1: Auf welche Verschlüsselung im Kernel beziehst Du Dich?

Punkt 2: Siehe oben.

Auch ist Freie Software nicht an entsprechende Landesgesetze gebunden, nichtz so wie beispielsweise die PGP Corporation.

Dies war nur meine Meinung. Man sollte in Sachen Verschlüsselung keinem Gewinnorientiertem Unternhemen trauen.

PS: Deshalb würde ich wichtige Daten auf eine Linux-Distribution ablegen, da dieses Betriebssystem 1. Verschlüssellung bereits im Kernel hat, 2. Nicht an nationale Gesetze gebunden ist.

Damit man hinterher niemanden Verfolgen oder korrumpieren kann.

Werden Entwickler von Verschlüsselungs-Software verfolgt?

Außerdem: Der Source ist offen. Ich muss den Leuten nicht trauen.

Seriöse Verschlüsselungs-Software liegt immer als Open Source vor.

Und für Mac OS X gilt wohl leider: Es gibt keine wirkliche Alternative.

PGP legt den Quelltext auch offen und bietet darüber hinaus auch Support sowie sonstige Dienstleistungen, wie sie insbesondere auch geschäftliche Anwender benötigen.

Und für Mac OS X gilt wohl leider: Es gibt keine wirkliche Alternative. Das Einzige was einigermaßen hinkommt ist EncFS. Das macht aber nun unter Windows wieder Probleme.

TrueCrypt wird grundlos anonym und ohne Transparenz entwickelt. Cui bono?

Hmm… wenn ein mangelndes Changelog und Geheimhaltung von Änderungen ein Grund sein sollte, eine Software nicht einzusetzen, dann sollte man Software aus dem Hause Apple dann wohl auch nicht nutzen.

Es geht um Verschlüsselungssoftware, nicht um Software im Allgemeinen – zwar wären Transparenz, usw. auch für Letztere wünschenswert, aber bei Software zur Verschlüsselung sind diese Aspekt von absoluter Bedeutung.