Truecrypt oder Bitlocker

DancingWombat

New member
Themenstarter
Registriert
26 Juni 2014
Beiträge
20
Hallo,

ich habe bisher meine eigenen Dateien in TrueCrypt Containern gespeichert die ich bei Bedarf gemounted habe. Nun ist TrueCrypt ja auch mysteriöse Art und Weise verschwunden und ist angeblich nicht mehr sicher.

Jetzt stellt sich mir die Frage ob ich beim Umstieg auf ein L440 mit Windows 8.1 weiter bei TrueCrypt bleiben soll, oder auf Bitlocker umsteigen soll.
Was meint ihr?

Viele Grüße
Sebastian
 
Mein Punkt ist der, dass die bloße Verfügbarkeit des Sourcecodes noch nicht mit einem Gewinn an Sicherheit gleichzusetzen ist.
Bei einem strengeren Code-Review-Prozess, den es auch bei Closed-Source-Projekten gibt, hätte es beispielsweise Heartbleed vielleicht gar nicht erst in die Codebasis geschafft.
 
Mein Punkt ist der, dass die bloße Verfügbarkeit des Sourcecodes noch nicht mit einem Gewinn an Sicherheit gleichzusetzen ist.
Natürlich nicht. Es muss sich immer noch jemand auf den Hosenboden setzen und wirklich ein ordentliches Review durchführen, was gerade bei einer so komplexen Software wie OpenSSL alles andere als trivial ist.

Die Offenheit des Codes ist aber notwendige Bedingung um überhupt ein Review durchführen zu können. Ich vermute dessen warst du dir auch bei deinem letzten Beitrag bewusst und insofern war der Beitrag nichts weiter als dummes Stammtischgeblöke. Würde ich auf gleichem Niveau antworten wollen, dann würde ich dich fragen, warum du das Review nicht höchstpersönlich durchgeführt hast.
 
Das ist ein Mythos, oder besser gesagt vom Marketing gezielt gestreute Desinformation.

So schwarz oder weiss würde ich die Sache nicht sehen. Das Finden von Problemen ist ja auch eine Form von Review und wie man bei Windows sieht werden regelmäßig Fehler gefunden. Wenn es am Ende hart auf hart kommt dann bleibt einem immer noch das Disassemblieren. Zugegeben, nicht so bequem wie den C Quellcode zu lesen. Hätte aber den eventuellen Vorteil auch den Compiler unter die Lupe nehmen zu können. Gibt ja Stories die ich vor unseren amerikanischen Freunden als urban Legend abgetan hätte wo ein Compiler an jedem Binary das er baute mit Schadroutinen würzte.

Letztendlich hat es wohl auch mit der Verbreitung und den zu erwartenden Gegenwert zu tun wie schnell Probleme gefunden und publik gemacht werden.
 
Wer soll denn dieses Review durchführen - so ganz ohne Code?
Es gibt auch bei kommerzieller Software Code. Und der kann (und sollte) in-house auch regelmäßig reviewt werden.
Und die Hersteller geben den Code durchaus auch an Dritte zum Code-Review raus, wenn die Frage von einem wichtigen Partner kommt und NDAs unterzeichnet werden.

Richtig ist, daß nicht einfach jeder den Code anschauen kann, der will.
Aber die in den letzten Jahren in FOSS gefundenen Fehler zeigen uns, daß die freie Verfügbarkeit von Quellcode auch kein Garant für Fehlerfreiheit ist.

Letztlich ist nicht entscheidend, ob Software quelloffen ist, sondern:
- Arbeiten die Entwickler sorgfältig?
- Gibt es ein 4-Augen-Prinzip?
- Können interessierten und qualifizierten Parteien, die ein Code-Review durchführen wollen, Zugriff auf den Quellcode bekommen?

Und hier ist der Knackpunkt: Natürlich kann nicht jeder Closed Source-Software reviewen, und manche/viele Hersteller geben den Code auch nie heraus. Aber andere tun es, und damit kann man eben nicht allgemein behaupten, Code-Reviews wären bei Closed Source-Software unmöglich.


Zwieblum stellt es hier aber als eine allgemeine Tatsache dar, daß es solche Code-Reviews nicht gäbe. Und wer so eine starke Aussage macht, sollte die auch belegen können.
 
Es gibt auch bei kommerzieller Software Code. Und der kann (und sollte) in-house auch regelmäßig reviewt werden.
Und die Hersteller geben den Code durchaus auch an Dritte zum Code-Review raus, wenn die Frage von einem wichtigen Partner kommt und NDAs unterzeichnet werden.
Und warum sollte ich einem in-house- oder einem NDA unterliegenden Review irgendein Vertrauen schenken? Es ist doch gar nicht überprüfbar wie da gearbeitet wird.

Richtig ist, daß nicht einfach jeder den Code anschauen kann, der will.
Und genau das ist das Problem. Letztendlich bestimmt ausschließlich der Codeerzeuger wer den Code zu sehen kriegt. Ich sehe da einen Interessenkonflikt, du etwa nicht?

Aber die in den letzten Jahren in FOSS gefundenen Fehler zeigen uns, daß die freie Verfügbarkeit von Quellcode auch kein Garant für Fehlerfreiheit ist.
Das ist doch die gleiche Kerbe in die tpm mit seinem Geschwurbel geschlagen hat. Natürlich ist Codeoffenheit kein Garant für Fehlerfreiheit - kann sie gar nicht sein. Aber sie ist eine notwendige Bedingung um überhaupt ein unabhängiges Review durchführen zu können.

Letztlich ist nicht entscheidend, ob Software quelloffen ist, sondern:
- Arbeiten die Entwickler sorgfältig?
- Gibt es ein 4-Augen-Prinzip?
- Können interessierten und qualifizierten Parteien, die ein Code-Review durchführen wollen, Zugriff auf den Quellcode bekommen?
Und wie stellst du dir die Beantwortung dieser Fragen ohne Offenheit vor?
 
@ moronoxyd: Nenn's Insiderwissen, ich bin seit 20 Jahren im Bereich Automatisierung und Medizintechnik unterwegs. Den letzten Brüller im Sinne von "Corect code" hat ein Zulieferer der Tekom gebracht: sie entwickeln nach "Clean Code" was im Sprech der Firma "keine Kommentare oder Dokumentation" bedeutet :facepalm: Im Schnitt ist eine Testcoverage vom 50% schon sehr über Durchschnitt (womit automatisierte Tests gemeint sind), der Rest vom Code ist einfach formal ungeprüft.
 
Zuletzt bearbeitet:
Und warum sollte ich einem in-house- oder einem NDA unterliegenden Review irgendein Vertrauen schenken? Es ist doch gar nicht überprüfbar wie da gearbeitet wird.
Musst du natürlich nicht. Würde ich in vielen Fällen sicher auch nicht.


Und genau das ist das Problem. Letztendlich bestimmt ausschließlich der Codeerzeuger wer den Code zu sehen kriegt. Ich sehe da einen Interessenkonflikt, du etwa nicht?
Was war noch mal deine Frage?
"Wer soll denn dieses Review durchführen - so ganz ohne Code?"
Es gibt Code, und es können (und werden zumindest teilweise) Reviews durchgeführt.

Wenn es dir um die Frage der Glaubwürdigkeit der Reviewer geht, dann stell doch bitte auch diese Frage und nicht eine andere.
Ich habe auf die Fragen reagiert, die gestellt wurden.


Das ist doch die gleiche Kerbe in die tpm mit seinem Geschwurbel geschlagen hat. Natürlich ist Codeoffenheit kein Garant für Fehlerfreiheit - kann sie gar nicht sein. Aber sie ist eine notwendige Bedingung um überhaupt ein unabhängiges Review durchführen zu können.
Wenn ich mich nicht täusche hast du in den vorherigen Beiträgen das Wort "unabhängig" nicht benutzt. Jetzt geht es also nicht um Reviews allgemein, sondern um Reviews, die eine bestimmte Bedingung erfüllen?


Und wie stellst du dir die Beantwortung dieser Fragen ohne Offenheit vor?
Also für mich persönlich ist die Offenheit des Quellcodes irrelevant, da ich nicht über die Expertise verfüge, Code selber ernsthaft zu analysieren.
Ich verstehe gerade genug, um mir einen (sehr groben) Überblick darüber zu verschaffen, was ein Programm tut.


Für mich ist also die Frage: Kann ich dem Reviewer vertrauen?
Und dabei ist es irrelevant, ob der Reviewer mit frei verfügbarem Quellcode gearbeitet hat oder mit Code, den er unter einer NDA erhalten hat.
Entscheidend ist für mich, daß der Reviewer unabhängig ist, Ahnung von der Materie hat und mir den Eindruck vermittelt, daß er das Review ernst genommen hat.
 
Die Offenheit des Codes ist aber notwendige Bedingung um überhupt ein Review durchführen zu können. Ich vermute dessen warst du dir auch bei deinem letzten Beitrag bewusst und insofern war der Beitrag nichts weiter als dummes Stammtischgeblöke.
Offensichtlich hast du von professionellen Softwareentwicklungsprozessen keine Ahnung. Das ist zwar ok, aber wenn du dir anmaßt mit diesem Hintergrund einen Beitrag als "dummes Stammtischgeblöke" zu beurteilen erübrigt sich doch eine sachliche Diskussion.
 
Was war noch mal deine Frage?
"Wer soll denn dieses Review durchführen - so ganz ohne Code?"
Es gibt Code, und es können (und werden zumindest teilweise) Reviews durchgeführt.

Wenn es dir um die Frage der Glaubwürdigkeit der Reviewer geht, dann stell doch bitte auch diese Frage und nicht eine andere.
Ich habe auf die Fragen reagiert, die gestellt wurden.
Tut mir leid, dann habe ich wohl zu viel angenommen, als ich davon ausging, dass die Möglichkeit einer unabhängigen Überprüfung der Arbeit (sowohl der Codeschreiber als auch der -überprüfer) eine Selbstverständlichkeit ist um das Reviewergebnis beurteilen zu können.

Also für mich persönlich ist die Offenheit des Quellcodes irrelevant, da ich nicht über die Expertise verfüge, Code selber ernsthaft zu analysieren.
Das trifft auch auf mich in den meisten Fällen zu (bei OpenSSL mit Sicherheit). Aber offener Code überlässt zumindest mir die Wahl mir einen Reviewer zu zu suchen den ich für vertrauenswürdig halte.

Für mich ist also die Frage: Kann ich dem Reviewer vertrauen?
Und dabei ist es irrelevant, ob der Reviewer mit frei verfügbarem Quellcode gearbeitet hat oder mit Code, den er unter einer NDA erhalten hat.
Für mich ist das nicht irrelevant, denn ich kann ja die Vertrauenswürdigkeit des Reviewers gar nicht einschätzen, z.B. indem ich einen zweiten Reviewer (dem ich vertraue) beauftrage ein weiteres Review durchzuführen.

Entscheidend ist für mich, daß der Reviewer unabhängig ist,
Wie prüfst du das? Du kennst doch die Inhalte des NDA gar nicht.

Offensichtlich hast du von professionellen Softwareentwicklungsprozessen keine Ahnung.
Gut dass du mir das sagst! Ich werde noch heute zu meinem Chef gehen und ihm das mitteilen, denn offenbar hat er mich die letzten knapp 10 Jahre umsonst bezahlt.
 
Die Offenheit des Codes ist aber notwendige Bedingung um überhupt ein Review durchführen zu können. Ich vermute dessen warst du dir auch bei deinem letzten Beitrag bewusst und insofern war der Beitrag nichts weiter als dummes Stammtischgeblöke.
Offensichtlich hast du von professionellen Softwareentwicklungsprozessen keine Ahnung. Das ist zwar ok, aber wenn du dir anmaßt mit diesem Hintergrund einen Beitrag als "dummes Stammtischgeblöke" zu beurteilen erübrigt sich doch eine sachliche Diskussion.
Das Problem mit "professioneller" Softwareentwicklung ist nun mal, dass sie unprofessionell entwickelt wird. Das Fehlen von Sourcecode verschleiert das nur Kunden. Abgesehn davon, wie beweist du die Korrektheit von Software? Schau mal wieviel Aufwand für formal Korrekte Systeme getrieben wird, z.B. hier (Announcement) http://www.metzdowd.com/pipermail/cryptography/2014-June/022026.html
 
Mein vorhin angesprochenes Codereview verstehe ich in erster Linie als Teil des professionellen Entwicklungsprozesses. Wenn der Code den ein Entwickler schreibt erst von anderen Personen überprüft und freigegeben werden muss bevor er es überhaupt in den Release-Branch eines Projekts schafft fliegt eben eine Schwachstelle vielleicht schon auf bevor sie überhaupt in die Codebasis kommt. Dass die Heartbeat-Extension mit Heartbleed-Sicherheitslücke bei OpenSSL unzureichend überprüft und übernommen wurde und dann 2 Jahre lang offensichtlich unbemerkt Teil des öffentlich einsehbaren Sourcecodes geblieben ist zeigt deutlich dass ich mich nicht auf Quelloffenheit als Sicherheitsmaßnahme verlassen kann. Wichtig ist eine Kontrolle als Teil des Entwicklungsprozesses, und die kann es selbstverständlich auch bei Closed-Source-Projekten geben.
 
Aber die in den letzten Jahren in FOSS gefundenen Fehler zeigen uns, daß die freie Verfügbarkeit von Quellcode auch kein Garant für Fehlerfreiheit ist.
Die in den letzten Jahren in FOSS gefundenen Fehler zeigen uns, daß die freie Verfügbarkeit von Quellcode dies überhaupt erst ermöglichte.

Wenn z.B. OpenSSL aus der Schmiede eines grossen Closed Source Herstellers stammen würde, dann könnte sich die NSA weiterhin diebisch darüber freuen, die von ihnen dem Hersteller geheim aufgezwungenen Zwecklücken ohne grosses Aufsehen weiterhin unerkannt schamlos zu nutzen.

FOSS mag zwar nicht fehlerfrei sein, aber in diesem Kontext verzichte ich doch lieber gerne auf Closed Source.

EDIT: Gerade auf heise.de gefunden: Zwanzig-Jahre-alte-Luecke-in-Lempel-Ziv-Kompression-gefaehrdet-Linux-Nutzer.
 
Zuletzt bearbeitet:
Die in den letzten Jahren in FOSS gefundenen Fehler zeigen uns, daß die freie Verfügbarkeit von Quellcode dies überhaupt erst ermöglichte.
Ähhh.. nein.
Heartbleed z.B. wurde nicht durch Analyse des Quellcodes gefunden, sondern durch Tests an Systemen, auf dem entsprechende OpenSSL-Versionen liefen.
Das hätte mit Closed Source-Software genauso funktioniert. Siehe http://readwrite.com/2014/04/13/heartbleed-security-codenomicon-discovery#awesm=~oIou5svinpuo2v


Verfügbarer Quellcode erleichtert theoretisch das Finden von Fehlern und Sicherheitslücken. Aber nur, wenn der Code auch tatsächlich von Dritten überprüft wird.
Und die Erfahrung zeigt, daß das nicht so oft passiert.
Wie alt ist TrueCrypt? Und erst jetzt gibt es ein Code-Review.
 
Das hätte mit Closed Source-Software genauso funktioniert. [snip]
Finden kann man viel, aber das reicht halt nicht. Die gleichzeitige Verfügbarkeit des Quellcodes erlaubt es nichtsdestotrotz ungemein, den gefundenen Fehler zu verifizieren, zu lokalisieren, und letztlich auch zu fixen, ohne auf einen Hersteller warten zu müssen, von dem man sich prinzipbedingt niemals sicher sein kann, ob er die Lücke verifizierbar korrigiert oder nur durch eine Ersatzlücke zugunsten von NSA und Konsorten ersetzt.

Ob man das selbst kann oder nicht, ist dabei wiederum eine ganze andere Frage. Die Möglichkeit ist jedenfalls grundsätzlich gegeben und das ist doch schon mal eine brauchbare Grundlage.

Verfügbarer Quellcode erleichtert theoretisch das Finden von Fehlern und Sicherheitslücken.
Und er ermöglicht praktisch deren Reparatur, so denn sie mal gefunden und identifiziert wurden. Das dies in der real existierenden Wirklichkeit nicht notwendigerweise automatisch von selbst passiert ist natürlich schade, aber mit FOSS sind alle Möglichkeiten gegeben, die es mit Closed Source prinzipiell natürlich nicht gibt.

Den theoretischen heiligen Gral gibt es halt in der Praxis nicht, also brauchen wir das weder zu bejammern noch auszudiskutieren. Aber wenn man in der Wirklichkeit verwurzelt ist, dann ist die praktische Verfügbarkeit von FOSS prinzipbedingt einfach schon mal ein phantastischer Vorteil. Ich denke, das sollte man einfach mal so stehen lassen.
 
Den theoretischen heiligen Gral gibt es halt in der Praxis nicht, also brauchen wir das weder zu bejammern noch auszudiskutieren. Aber wenn man in der Wirklichkeit verwurzelt ist, dann ist die praktische Verfügbarkeit von FOSS prinzipbedingt einfach schon mal ein phantastischer Vorteil. Ich denke, das sollte man einfach mal so stehen lassen.

Ja. Wundere mich auch, dass dieses Thema Material zum Flamefest bieten soll.

Ich würde auch gerne mal den Quellcode von Adobe Flash einsehen. Wie abgef***t muss er sein, dass Adobe ihn gar nicht in den Griff bekommt?
 
Ja. Wundere mich auch, dass dieses Thema Material zum Flamefest bieten soll.
Das Problem ist, daß manche Leute dazu neigen, absolute Aussagen zu treffen und die Welt schwarz/weiß zu malen, ohne die Existenz von Graustufen oder gar Farben einzugestehen.
 
  • ok1.de
  • thinkstore24.de
  • ok2.de - Notebook Computer Server
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben