Wer kennt jemanden der schon erwischt wurde?

Es gibt 169 Antworten in diesem Thema, welches 20.107 mal aufgerufen wurde. Der letzte Beitrag (9. Mai 2008 um 20:45) ist von Sheltem.

  • bei AES ist der _key_ heutzutage üblicherweise 128bit. die verschlüsselten blöcke sind in der regel grösser, wenn man es halbwechs perfomant haben will nimmt man da typischerweise die sektorgrösse des mediums.

    AES ist nur für eine Blockgröße 128 Bit definiert. Wenn du eine andere Blockgröße hast, ist es kein AES mehr.
    Beim AES zugrundeliegenden Algorithmus Rijndael konnte man noch bis 256 Bit hochgehen, aber das war's dann auch.
    Ich hab im Linux-Code nachgeschaut. Dort ist die Blockgröße auf 16*8=128 Bit festgelegt.
    Die beiden anderen Algorithmen die ich verwende, Serpent und Khazad, benutzen 128 Bit bzw. sogar nur 64 Bit.

    Ich bin zwar jetzt kein Experte für Verschlüsselung, aber mir leuchtet nicht ein, wieso die Verschlüsselung bei größeren Blockgrößen viel schneller sein sollte. Man muss nur achten, dass man die Sektorgrenzen des Mediums sauber in Blöcke der Verschlüsselung aufteilen kann, was eigentlich immer der Fall sein sollte.

  • Zitat


    Ich bin zwar jetzt kein Experte für Verschlüsselung, aber mir leuchtet nicht ein, wieso die Verschlüsselung bei größeren Blockgrößen viel schneller sein sollte.

    nicht die verschlüsselung ansich, sondern das handling auf dem medium... auf disk kann immer nur ein kompletter sektor geschrieben werden.

  • nicht die verschlüsselung ansich, sondern das handling auf dem medium... auf disk kann immer nur ein kompletter sektor geschrieben werden.

    Nun ja, aber ob man nun einen Sektor im Speicher, bevor man ihn auf ein Medium schreibt (oder von dort liest), in einzelnen kleinen Blöcken verschlüsselt oder als Ganzes macht ja für den geschriebenen Sektor keinerlei Unterschied. Ich seh immer noch keinen Grund, wieso größere Blöcke bei der Verschlüsselung einen Geschwindigkeitsvorteil bringen sollen. Im Gegenteil: Das System müsste selbst bei winzigsten Änderungen innerhalb des Blocks den gesamten Sektor neu verschlüsseln anstatt nur einen kleinen Teil. Das stelle ich mir als ziemlichen Performancekiller vor.
    Außerdem bedueten um so größere Blöcke größeren Schaden bei einem Defekt.

    Also: Am liebsten bei einer normalen Blockgröße bleiben. Bei einem kleinen Defekt gehen da nur 16 Bytes verloren, und damit muß wirklich jedes nennenswerte Dateisystem klarkommen. Und bei größeren Defekten (ganzer Sektor futsch oder so) gibt es dann praktisch keinen Unterschied vom Risiko her zwischen verschlüsselten und unverschlüsselten Partitionen.

  • Ich hatte mal vor vielen Jahren Probleme wegen ein paar kopien.

    Ein gewisser Freiherr von G. hat die Aktion damals durchgezogen :grr:

    Ich sehe das mit den Kopien von MP3´s gelassen, die Musikindustrie kann den "Krieg" kaum gewinnen, die Filmindustrie wird es auch noch hart treffen.
    Verschlüsselung ist noch sicher, aber in England ist man bereits verpflichtet ggf. die Passwörter rauszugeben, ansonsten Beugehaft.


    Mann kann zwar die Klassischen Tauschbörsen mit der Juristischen Keule kleinkriegen, aber es gibt ja noch das Real Life.

    Aber die kleine Tauschbörse beim Feierabendbier werden sie nicht austrocken Können, und die Festplattenpreise/größe entwickelt sich Postiv für die "Böse Seite" :bgdev

    2008 1TB = 129 Euro ca. 250 000 MP3´s ca. 1000 Filme DIVX ca. 200 Film DVD´s ca. 40 HD Videos
    2010 2TB = ca. 500 000 MP3`s ca. 2000 Filme DIVX ca. 400 Film DVD´s ca. 80 HD Videos
    2012 4TB = ca.1 000 000 MP3´s ca. 4000 Filme DIVX ca. 800 Film DVD´s ca. 160 HD Videos
    2014 8TB= ca.2 000 000 MP3`s ca. 8000 Filme DIVX ca. 1600 Film DVD´s ca. 320 HD Videos
    2016 16TB= ca.4 000 000 MP3´s ca.16000 Filme DIVX ca. 3200 Film DVS´s ca. 640 HD Videos.
    .
    .
    .
    Wenn die Festplattentechnologie wie in der vergangenheit fortschritte macht, gibt es bald den Punkt wo auf eine Festplatte fast alles draufpasst was jemals
    groß veröffendlicht wurde. Die "TB" Sammlungen mit Sauberer Verzeichnisstruktur sind nur noch eine Frage der Zeit, und bei einer runde Choplifter am
    abend werden mal eben millionen Euro getauscht .

  • Verschlüsselung ist noch sicher, aber in England ist man bereits verpflichtet ggf. die Passwörter rauszugeben, ansonsten Beugehaft.

    Interessant ist ja, dass die Beugehaft nur bei Verdacht auf schwere Straftaten angewandt werden soll und auf maximal 5 Jahre (bei minderschweren Vergehen 2 Jahre) begrenzt ist.
    Also wenn ich ein Terrorist wäre, würde ich lieber die 5 Jahre nehmen als 20 oder mehr wenn ich so blöd wäre, das Passwort rauszugeben.
    Ganz zu schweigen davon, dass wirkliche Übeltäter ihr Zeug am besten steganographisch verschlüssen würden, bei der man nicht mal nachweisen kann, dass es überhaupt verschlüsselte Daten gab. (Truecrypt ist glaube ich sowas)

    Ich hab noch nicht gelesen, dass das Gesetz bei Urheberrechtsverletzungen Anwendung findet, bzw. Anwendung finden kann. Könnte aber sein, so gut hab ich mich da auch nicht informiert.
    Betrifft mich selbst zumindest auch nicht. Wenn die Polizei an meine Daten kommen will (mit Durchsuchungsbeschluss) würde ich sie ihnen auch geben. Ich will nur nicht, dass irgendjemand anders da ran kommen könnte.

  • Da die Musikindustrie immer Sonderrechte eingeräumt bekommt ist es sicher nur noch eine frage der zeit bis auch diese hürde fällt.

    Trucrypt unterstüzt versteckte Container.

    Passwort "Himmel" nur die Harmlosen Daten,
    Passwort "Hölle" die verbotenen daten, ca 5 bis 10% der"Himmel" größe sind möglich, der Belegte Speicherplatz ist unter "Himmel" als leer gekenzeichnet
    Da Verschlüsselten Daten wie Zufallszahlen wirken kann man nicht Sagen ob "Himmel" versteckte Daten enthält, ohne das Passwort "Hölle" besteht auch kein
    überschreibschutz für die "Hölle" daten.

  • Aber bei den Verschlüsselungen die ich verwende (AES, Serpent, Khazad) braucht man noch nicht mal einen Header, denn die Information über Verschlüsselungsart und Schlüssellänge werden ja beim Mounten automatisch geliefert. Wenn die falsch sind, kann man halt nicht entschlüsseln, genauso als ob man einen falschen Schlüssel angegeben hat. Diese Info muss aber auch nicht geheim sein.


    Truecrypt verwendet AFAIK als Schlüssel für die Daten nicht das eingegebene Passwort (bzw. einen Hash davon) sondern einen zufällig generierten Schlüssel, der mit dem Hash des Passwortes verschlüsselt im Header gespeichert wird. Dadurch kann man das Passwort ändern ohne sämtliche Daten neu verschlüsseln zu müssen.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Zitat


    Truecrypt verwendet AFAIK als Schlüssel für die Daten nicht das eingegebene Passwort (bzw. einen Hash davon) sondern einen zufällig generierten Schlüssel, der mit dem Hash des Passwortes verschlüsselt im Header gespeichert wird. Dadurch kann man das Passwort ändern ohne sämtliche Daten neu verschlüsseln zu müssen.

    und bei einem bitfehler in besagtem header ist dann der komplette container verloren? grossartig =P

  • Information über Verschlüsselungsart und Schlüssellänge werden ja beim Mounten automatisch geliefert. Wenn die falsch sind, kann man halt nicht entschlüsseln, genauso als ob man einen falschen Schlüssel angegeben hat. Diese Info muss aber auch nicht geheim sein.

    sollte sie aber, weil sonst direkt fest steht welcher algo das ist, somit können die leute sich eingrenzen und das knacken wäre "einfacher"

    LOL. wenn dein verschlüssellungsprogram informationen über den key irgendwo speichert würde ich das an deiner stelle schnell löschen und mich nach einem anderen umschauen =)

    at least backup the volume header (using this function), which contains the master key (size of the backup file will be 1024 bytes).

    wenn das passwort NIRGENDWO im verschlüsselten teil vorhanden wäre, wäre ein verlgiech und somit ein entschlüsseln wohl nicht möglich oder?
    nochmals: cshau dir truecrypt an, die haben ne hammer docu! dann wüsstest du, daß fehler auf der platte kaum einen unterschied machen ob ver oder nicht verschlüsselt


    eidt:
    du warst wieder zu schnell!

    NEIN ist er nicht wenn man vom header ein backup hat was nicht grade groß ist!
    habe ich aber bereits weiter oben geschrieben! lesen! ;)


    Truecrypt verwendet AFAIK als Schlüssel für die Daten nicht das eingegebene Passwort (bzw. einen Hash davon) sondern einen zufällig generierten Schlüssel, der mit dem Hash des Passwortes verschlüsselt im Header gespeichert wird. Dadurch kann man das Passwort ändern ohne sämtliche Daten neu verschlüsseln zu müssen.

    jep :D dazu muß man lange genug die maus bewegen ;)

  • Zitat


    wenn das passwort NIRGENDWO im verschlüsselten teil vorhanden wäre, wäre ein verlgiech und somit ein entschlüsseln wohl nicht möglich oder?

    unsinn. so arbeiten moderne algorithmen nicht.

    Zitat


    nochmals: cshau dir truecrypt an, die haben ne hammer docu! dann wüsstest du, daß fehler auf der platte kaum einen unterschied machen ob ver oder nicht verschlüsselt

    glaub mir, ich hab mich mit verschlüsselung schon ausgiebig beschäftigt.

  • tja,..... finde es dann nur lustig, daß die jungs bei truecrypt, welche ein TOP produkt open source liefern welches REGIERUNGSNIVEAU hat, wohl im gegensatz zu dir keine ahunng haben!

    sorry, unglaubwürdig!

  • Zitat


    tja,..... finde es dann nur lustig, daß die jungs bei truecrypt, welche ein TOP produkt open source liefern welches REGIERUNGSNIVEA hat, wohl im gegensatz zu dir keine ahunng haben!

    du hast auch NIVEA, keine frage.

    und das die jungs von truecrypt ahnung haben hat nie jemand bezweifelt. das zwischen doku lesen und doku verstehen ein unterschied besteht allerdings auch nicht.

  • ich weiß, wikipedia, aber da steht nichts anderes als in der TC docu

    Einzelne defekte Sektoren führen nur dazu, dass die betreffenden Zuordnungseinheiten im enthaltenen Dateisystem nicht mehr gelesen werden können.


    Bitte melde dich an, um diesen Link zu sehen.


    also scheinen hier doch einige von uns ein wenig recht zu haben oder?


    edit: jop du solltest sie lesen und DANN noch versuchen zu verstehen! aber ich hab dir ja nen kleinen satz rausgeuscht den sogar du verstehen solltest.

    ps: wennde an rechtschreibfehler soviel freude hast, bau ich gerne noch welche ein! das hat aber wenig mit der diskussion zu tun

  • Zitat


    Einzelne defekte Sektoren führen nur dazu, dass die betreffenden Zuordnungseinheiten im enthaltenen Dateisystem nicht mehr gelesen werden können.

    ach was, und nichts anderes habe ich gesagt.

  • du hast gesagt, das die verschlüsselten dateien dann defekt sind im großen maßstab.

    wir haben nur gesagt, das es kaum mehr ist, als beim reinen -nicht verschlüsselten- system, das hast du bestritten. dem ist jedoch so, denn das verhalten ist kein anderes als bei unverschlüsseltem system, oder wie verhält es sich da bei defekten sektoren?


  • sollte sie aber, weil sonst direkt fest steht welcher algo das ist, somit können die leute sich eingrenzen und das knacken wäre "einfacher"

    Ich glaube, darüber müssen wir uns jetzt noch keine Gedanken machen. Andere Sicherheitslücken sind viel gefährlicher. Wie eben ein versehentlich unverschlüsselter Swap, ein schlecht gewähltes Passwort und und und...

    wenn das passwort NIRGENDWO im verschlüsselten teil vorhanden wäre, wäre ein verlgiech und somit ein entschlüsseln wohl nicht möglich oder?

    Also eigentlich alle Algorithmen, die ich kenne, funktionieren so nicht. Normalerweise IST das Passwort der Schlüssel. Da gibt es keine Vergleiche. Kann sein, dass Trucrypt das anders macht, ich hab mich über den nicht informiert. Es leuchtet mir einfach nicht ein, wieso man bei symmetrischer Verschlüsselung zusätzlich zu einem Passwort noch einen generierten Schlüssel verwenden will. Denn mit der Sicherheit des Passworts steht und fällt ja die ganze Sicherheit der Verschlüsselung. (Bei asymmetrischer Verschlüsselung ist das natürlich anders, weil man zwei Schlüssel mit nur einem Passwort braucht.)

    Wie dem auch sei, das bedeutet auf jeden Fall, dass ich Truecrypt nicht verwenden will. Zumindest nicht bei größeren Datenmengen. Bei kleineren Sachen bleibt natürlich der Vorteil, dass man verschlüsselte Sachen verstecken kann.

  • Zitat


    du hast gesagt, das die verschlüsselten dateien dann defekt sind im großen maßstab.

    wir haben nur gesagt, das es kaum mehr ist, als beim reinen -nicht verschlüsselten- system, das hast du bestritten. dem ist jedoch so, denn das verhalten ist kein anderes als bei unverschlüsseltem system, oder wie verhält es sich da bei defekten sektoren?

    ein sektor auf dvd==2048bytes

    ein falsches bit in einem unverschlüsselten sektor==1 kaputtes bit, der rest kann oft noch gelesen werden
    ein falsches bit in einem verschlüsselten sektor==2048 kaputte bytes. keine chance die daten zu rekonstruieren

    ich halte das für einen wesentlichen unterschied.

  • ein sektor auf dvd==2048bytes

    ein falsches bit in einem unverschlüsselten sektor==1 kaputtes bit, der rest kann oft noch gelesen werden
    ein falsches bit in einem verschlüsselten sektor==2048 kaputte bytes. keine chance die daten zu rekonstruieren

    ich halte das für einen wesentlichen unterschied.

    Falsch.
    Falsches Bit in einem verschlüsselten Sektor==1 kaputtes Bit, der rest kann noch in den Computer gelesen werden.
    Im Computer wird der Sektor dann entschlüsselt. Bei 128 Bit Block Size des Algorithmus (ist der Standard bei den meisten Algorithmen) gehen 16 Byte verloren.
    Ergo: Ein falsches Bit in einem verschlüsselten Sektor==16 kaputte Bytes. Der Rest kann noch ganz normal entschlüsselt werden.
    Ehrlich: Mit 16 verlorenen Bytes kann ich (und die meisten Dateisysteme) durchaus leben!

    PS@sauhund:
    Du scheinst immer noch davon auszugehen, dass ganze Sektoren der Platte einem Block der Verschlüsselung entspricht. Mir ist kein gängiger Algorithmus bekannt, der erlaubt, eine Blockgröße von 2048 Bytes einzustellen. Kennst du eine? Mich würde das interessieren. Nur so aus Neugier, ich würde mich hüten, so eine zu benutzen.

    Nebenbei ganz praktisch erklärt:
    Wenn ich beispielsweise eine DVD verschlüssele, lege ich erst eine Datei von der Größe der DVD auf meiner Festplatte an. Auf die lege ich ein Loop-Device, das die Verschlüsselung besorgt. Auf dieses Loop-Device erzeuge ich ein Dateisystem, mounte es, und spiele die Dateien drauf. Dann brenne ich diese Datei direkt als Image auf die DVD.
    So, wo bitteschön in all dem soll die Verschlüsselung denn mitbekommen haben, dass es eine bestimmte Sektorgröße einhalten soll? Nirgendwo! Die Verschlüsselung von Festplattenpartitionen läuft genauso. Das Verschlüsselungssystem interagiert nicht mit der Hardware. Es kann gar nicht wissen, welche Sektorengröße es dort geben wird.
    Folglich kann es gar nicht anders sein, als dass die Größe der Einheit, die bei einem Defekt verloren geht, der der Blockgröße des Algorithmus (128 Bit) entspricht.
    Und den Fall, dass ein einziger Defekt gleich die ganze Datei (oder Partition darauf) ausschaltet, kann ich ausschließen: Vorhin habe ich es zur Sicherheit noch mal ausprobiert. Ich hab per Hand Defekte in einer verschlüsselten Datei verursacht. Das Dateisystem darauf hat kaum was mitbekommen und die Dateien sind nur minimal geschädigt worden.

  • Zitat


    Falsches bit in einem verschlüsselten Sektor==1 kaputtes Bit, der rest kann noch in den Computer gelesen werden.
    Im Computer wird der Sektor dann entschlüsselt. Bei 128 Bit Block Size des Algorithmus (ist der Standard bei den meisten Algorithmen) gehen die ersten 16 Byte verloren.
    Ergo: Ein falsches Bit in einem verschlüsselten Sektor==16 kaputte Bytes. Der Rest kann noch ganz normal entschlüsselt werden.
    Ehrlich: Mit 16 verlorenen Bytes kann ich (und die meisten Dateisysteme) durchaus leben!

    selbst dann wäre mir ein einzelnes falsches bit wesentlich lieber als 16 falsche bytes.

    wobei es mir ja eigentlich auch um die unverschlüsselten gebrauchskopien ging :)

  • Also eigentlich alle Algorithmen, die ich kenne, funktionieren so nicht. Normalerweise IST das Passwort der Schlüssel.

    ok, wusste ich so nicht, danke

    ob 1byte oder 16 ist mir wirklich verdammt schnuppe! wenn ich dafür eine verschlüsselung habe welche mit den rechenboliden der heutigen zeit nicht zu knacken ist (passwort muß natürlich gut sein), nehme ich das gerne in kauf!


    dun wieso das ?

    Wie dem auch sei, das bedeutet auf jeden Fall, dass ich Truecrypt nicht verwenden will. Zumindest nicht bei größeren Datenmengen. Bei kleineren Sachen bleibt natürlich der Vorteil, dass man verschlüsselte Sachen verstecken kann.

    außer das performance flöten geht, was bei neueren CPUs 1. nicht mehr ins gewicht fällt und 2. durch integrierte verschlüsselungstechnik garnicht mehr vorkommt.

    unsichere passwärter und swap und sowas sind klar, aber das hat ja mit dem verschlüsselungssystem ansich nichts zu tun!


    @sauhund

    klaro, bei DVDs etc welche man regelmäßig braucht stimmt das mit den medien, hatte ich aber vorher schon gesagt.
    jedoch hätte ich dann vielleicht mal ne dvd oder 20 mp3 auf meinem ipod liegen. und da müssen sie ja erstmal zeigen, daß ich sie NICHT via streamripper ausm netz habe oider von nem freund! was legal ist! ich muß wenn ich se vom kumpel habe nichtmal prüfen ob ER die legal erworben hat! da ich meinen kollegen als sichere quelle ansehe. so zumindest die aktuelle rechtssprechung noch. )
    ich will ja nur verhindern, daß einige leute meine festplatte lesen können! und das kann ich damit verdammt gut