Hallo! Weis jemand, ob es Raid-Chips gibt die eine Full Disk Encryption unterstützen und das Passwort vom Bios an die angeschlossenen Platten weiterreichen? Im Moment ist bei mir alles per Software (TrueCrypt) verschlüsselt, das ist vom Raid unabhängig. Aber Software FDE und SSDs sind ja bekanntlich keine Freunde. Danke schon mal...
Raid und HW Full-Disk-Encryption
- Ersteller tracer
- Erstellt am
DerKleine49
Banned
- Registriert
- Jan. 2008
- Beiträge
- 3.358
@da Mittermayer sagt: paranoid dazu
Laut truecrypt webseite: "TrueCrypt supports hardware/software RAID as well as Windows dynamic volumes."
Mir selber ist keine software bekannt, die BIOS passworteingabe an truecrypt oder eine andere full disk encryption weiterleiten kann. Das problem fängt ja schon beim sicheren austausch zwischen bios mit der encryption software. Ein bios passwort ist in den meisten fällen auch nicht "sinnvoll".
Was meinst du bzgl SSDs? Ich bin nicht im besitz einer SSD, aber verschlüsselung müsste damit ohne probleme möglich sein. Der zugriff auf den datenträger (SSD, HDD, ...) erfolgt ja grundlegend transparent für die software.
Mir selber ist keine software bekannt, die BIOS passworteingabe an truecrypt oder eine andere full disk encryption weiterleiten kann. Das problem fängt ja schon beim sicheren austausch zwischen bios mit der encryption software. Ein bios passwort ist in den meisten fällen auch nicht "sinnvoll".
Was meinst du bzgl SSDs? Ich bin nicht im besitz einer SSD, aber verschlüsselung müsste damit ohne probleme möglich sein. Der zugriff auf den datenträger (SSD, HDD, ...) erfolgt ja grundlegend transparent für die software.
Ja, unter TrueCrypt läuft es problemlos, das ist ja auch mein status qou.
Die Variante die ich anstrebe ist eine Festplatte mit Hardwareverschlüsselung. Hierfür wird beim booten vom Bios ein Passwort abgefragt, dass dann an die Festplatte weitergereicht wird (Teilweise fällt das auch unter den Begriff "ATA-Security"). Die Frage ist jetzt, ob es Raidcontroller gibt, die das abgefragte Passwort an die Platten weiterreichen....
Eines der Probleme mit SW-FDE ist, das TRIM nicht mehr vernünftig verwendet werden kann, da das ja nur bei einer nicht vollen Platte funktioniert und bei SW-FDE ist ja alles bis zum letzten Byte mit zufallszahlen vollgeschrieben... Die Variante mit den 10% unpartitionierten Bereich um TRIM zu ermöglichen ist auch wieder umstritten, zum birgt es sicherheitstechnische Probleme, zum anderen wird befürchtet, dass die Lebensdauer dennoch vermindert wird, da Trim nur zu eingeschränkt eingesetzt werden kann.
Die Variante die ich anstrebe ist eine Festplatte mit Hardwareverschlüsselung. Hierfür wird beim booten vom Bios ein Passwort abgefragt, dass dann an die Festplatte weitergereicht wird (Teilweise fällt das auch unter den Begriff "ATA-Security"). Die Frage ist jetzt, ob es Raidcontroller gibt, die das abgefragte Passwort an die Platten weiterreichen....
Eines der Probleme mit SW-FDE ist, das TRIM nicht mehr vernünftig verwendet werden kann, da das ja nur bei einer nicht vollen Platte funktioniert und bei SW-FDE ist ja alles bis zum letzten Byte mit zufallszahlen vollgeschrieben... Die Variante mit den 10% unpartitionierten Bereich um TRIM zu ermöglichen ist auch wieder umstritten, zum birgt es sicherheitstechnische Probleme, zum anderen wird befürchtet, dass die Lebensdauer dennoch vermindert wird, da Trim nur zu eingeschränkt eingesetzt werden kann.
Eines der wichtigsten security features von verschlüsselungssoftwar wie TrueCrypt ist ja die tatsache, das man nichtmal nachweisen kann das was auf der festplatte drauf ist. Wenn ATA Security systeme dies anders handhaben, nicht das gesamte laufwerk sondern nur die einzelnen bits die darauf gespeichert werden verschlüsseln, verliert man die "plausible deniability".
Wird TRIM nicht teilweise durch das OS gesteuert? Ich erinnere mich noch vage an die tatsache, dass TRIM nämlich nicht mit jedem OS funktioniert/funktionierte? Für das laufende system ist die festplatte natürlich nicht komplett voll.
Raidkonfiguration läuft dann wohl wirklich nur so wie du es dir vorstellt. Das bios muss das entsprechende passwort direkt an die hw weiterleiten oder aber die entsprechenden festplatten müssten alle einzeln nach dem passwort fragen. Bei intel raids ist es zumindest so, dass die im bios, wenn sie im raid integriert sind, nichtmal richtig als vorhanden angezeigt werden. In diesem fall würde ein raid mit hw verschlüsselung wohl nicht funktionieren.
Wird TRIM nicht teilweise durch das OS gesteuert? Ich erinnere mich noch vage an die tatsache, dass TRIM nämlich nicht mit jedem OS funktioniert/funktionierte? Für das laufende system ist die festplatte natürlich nicht komplett voll.
Raidkonfiguration läuft dann wohl wirklich nur so wie du es dir vorstellt. Das bios muss das entsprechende passwort direkt an die hw weiterleiten oder aber die entsprechenden festplatten müssten alle einzeln nach dem passwort fragen. Bei intel raids ist es zumindest so, dass die im bios, wenn sie im raid integriert sind, nichtmal richtig als vorhanden angezeigt werden. In diesem fall würde ein raid mit hw verschlüsselung wohl nicht funktionieren.
Zuletzt bearbeitet:
Blutschlumpf
Fleet Admiral
- Registriert
- März 2001
- Beiträge
- 20.473
Meines Erachtens nach kann TRIM in dem Fall nicht genutzt werden.
Da ein leerer Block im Dateisystem nach der Verschlüsselung kein leerer Block auf der physikalischen Platte ist kann TRIM den nicht als leer markieren und somit nicht die Zellen löschen.
Das sind 2 Paar Schuhe.
Da ein leerer Block im Dateisystem nach der Verschlüsselung kein leerer Block auf der physikalischen Platte ist kann TRIM den nicht als leer markieren und somit nicht die Zellen löschen.
Ich glaube du hast nicht ganz die Funktionsweise von TRIM und den "Sinn" der brachliegenden Sektoren bei den ersten SSD-Generationen für das wear-leveling verstanden.
Das sind 2 Paar Schuhe.
Ja, wenn TRIM ausschließlich auf der SSD ausgeführt wird liegst du richtig. Wenn TRIM jedoch durch das OS gesteuert wird (infos das daten geschrieben und wo sie wieder gelöscht werden auch wenn die ssd dann verwalterisch tätig wird um die zellen gleichmäßig zu altern), dann sollte TRIM verwendet werden können. Für reguläre HDDs gibt es ja kein "voll" oder "leer" von der sie weiß, das weiß nur das OS bzw das steht im dateisystem. Vielleicht findet sich jemand im forum der sich damit besser auskennt und den sachverhalt aufklären kann.
Die Thematik SSD & TrueCrypt wurde schon dutzende Male diskutiert, leider kam nie eine entgültige Feststellung ob es Probleme bereiten wird, oder nicht. Ein paar Links hier:
https://www.computerbase.de/forum/threads/ssd-mit-truecrypt-verschluesseln-schaedlich.843034/
https://www.computerbase.de/forum/threads/ssd-speed-nach-true-crypt-bei-der-c300.864465/
https://www.computerbase.de/forum/threads/intel-i7-2600k-mit-aes-ni-ssd-trucrypt-komplettverschluesselung.839099/
https://www.computerbase.de/forum/threads/ssds-verschluesseln.547398/
https://www.computerbase.de/forum/threads/intel-x25-m-verschluesseln-mit-truecrypt.820490/
https://www.computerbase.de/forum/threads/notebook-mit-ssd-wie-sichern-bringt-mir-tpm-etwas.817819/
Die relevanten TrueCrypt-Beschreibungen sind hier:
http://www.truecrypt.org/docs/?s=trim-operation
http://www.truecrypt.org/docs/?s=wear-leveling
Daher mein Entschluss auf die HDD-HW-Verschlüsselung umzusteigen. Findet man dann allerdings Seiten wie diese www.hddunlock.com/ komme ich ganz schnell wieder zu TrueCrpyt zurück.
Plausible deniability ist mir nicht wichtig, ich möchte nur im Falle eines Hardwareverlusts nicht auch noch überlegen müssen wer was mit meinen Daten anstellt.
Die Optimallösung wäre wenn man in TrueCrpyt eine Option setzen könnte nur die "echten Daten" zu verschlüsseln und zu schreiben. Plausible deniability hätte man nicht und es könnte jeder einsehen wieviel Datenvolumen auf der Platte liegt, aber Trim und wear-leveling würden uneingeschränkt funktionieren und niemand müsste sich (mit gewissen Sicherheitseinschränkungen, welche aber sicher für viele verkraftbar wären) Gedanken über die Lebensdauer der SSD's machen. Zudem kann man sich die XX% unpartitionierten Bereich fürs wear-leveling sparen.
https://www.computerbase.de/forum/threads/ssd-mit-truecrypt-verschluesseln-schaedlich.843034/
https://www.computerbase.de/forum/threads/ssd-speed-nach-true-crypt-bei-der-c300.864465/
https://www.computerbase.de/forum/threads/intel-i7-2600k-mit-aes-ni-ssd-trucrypt-komplettverschluesselung.839099/
https://www.computerbase.de/forum/threads/ssds-verschluesseln.547398/
https://www.computerbase.de/forum/threads/intel-x25-m-verschluesseln-mit-truecrypt.820490/
https://www.computerbase.de/forum/threads/notebook-mit-ssd-wie-sichern-bringt-mir-tpm-etwas.817819/
Die relevanten TrueCrypt-Beschreibungen sind hier:
http://www.truecrypt.org/docs/?s=trim-operation
http://www.truecrypt.org/docs/?s=wear-leveling
Daher mein Entschluss auf die HDD-HW-Verschlüsselung umzusteigen. Findet man dann allerdings Seiten wie diese www.hddunlock.com/ komme ich ganz schnell wieder zu TrueCrpyt zurück.
Plausible deniability ist mir nicht wichtig, ich möchte nur im Falle eines Hardwareverlusts nicht auch noch überlegen müssen wer was mit meinen Daten anstellt.
Die Optimallösung wäre wenn man in TrueCrpyt eine Option setzen könnte nur die "echten Daten" zu verschlüsseln und zu schreiben. Plausible deniability hätte man nicht und es könnte jeder einsehen wieviel Datenvolumen auf der Platte liegt, aber Trim und wear-leveling würden uneingeschränkt funktionieren und niemand müsste sich (mit gewissen Sicherheitseinschränkungen, welche aber sicher für viele verkraftbar wären) Gedanken über die Lebensdauer der SSD's machen. Zudem kann man sich die XX% unpartitionierten Bereich fürs wear-leveling sparen.
DUNnet
Lt. Commander
- Registriert
- Sep. 2008
- Beiträge
- 1.612
Hey,
also diese Passwortabfrage ist, falls noch nicht geklärt, nicht vom BIOS sondern das funktioniert über den Bootloader, denn zu einer Hardwareverschlüsselung gehört immer ein Backend, also eine Software.
Diese installiert man und erstellt damit dann eine neue Bootloader Datei.
Genauso macht es TrueCrypt auch, wenn man z.B. die Bootpartition verschlüsselt.
Zum Thema TC auf SSD:
Ich habe eine Intel G2 Postville 80GB im Laptop und hab hier im Board sicher ein Topic rumfliegen
Ansich bestand damals die Frage wegen TRIM, Garbage Controll etc. Diese werden soweit ich informiert bin mit V7 nicht weitergegeben.
Das verursacht dann vll. eine schnelle Abnutzung einzelner Zellen.
Dann ist da noch das Problem das irgendwelche Leute meinen die SSD Controller sollte man entgegen kommen und 10% der SSD unpartioniert lassen, halte ich mitlerweile für überholt.
Die Frage ob die Zellen wegen der Verschlüsselung allgemein oft genutzt werden, nein! Egal ob verschlüsselt oder nicht (das macht eh nur der CPU!) der Bit wird so oder so nur einmal, wie normal halt, ausgelesen.
Ich habe mit dem Intel Tool damals aufgezeichnet wie viel Read und vor allem Write ich hatte, das erhöhte sich 0 und war nach 1 Jahr Betrieb grad mal bei 1,8TB - MLC Chips schaffen bei 80GB * 10.000 beschreiben, lesen unendlich = 800.000GB write = 800TB! Im Worst Case (das der MLC Chip vll. nur 5.000 Zyklen packt) 400TB, aber ich nutz die doch keine 20 Jahre mehr
Zu der Wirkung von einer vollverschlüsselten SSD:
Ich hatte eine 3x Serpant Twofish AES Verschlüsselung mit Whirlpool als Hash
Dazu ein 30 stelliges PW was aber uninteressant ist (da das PW nur den "Schlüssel" entschlüsselt, welcher dann erst aufmacht, deshalb kann man das PW ja auch immer ändern, wäre es direkt angebunden müsste man immer alles neu formatieren oder verschlüsseln!)!
Die Geschwindigkeit ging von ca. 210MB/s - 260MB/s runter auf 70! Random war es sogar noch übler!
Und die Latenz stieg extrem.
Counter Strike wollte damals gar nicht mehr laden (immer aufgehangen)! Immer frisch installiert, klappte nie. Kaum die Verschlüsselung weg: Alles wieder rasant.
Ach, und am CPU lags nicht die Auslastung ging nichtmal auf 30% weil ich ein DualCore T9900 mit 3GHz drin hab, der war schon janz potent
Alles im allen:
Wenn manverschlüsselt, dann vll. nicht mit so starken Algorythmen und nicht so vielen, vll. gehts dann besser! Aber so - nein nicht bis sowas wirklich 100% miteinander arbeitet ähnlich zur HDD! Da ist der Unterschied nicht so gravierend.
Gruß
also diese Passwortabfrage ist, falls noch nicht geklärt, nicht vom BIOS sondern das funktioniert über den Bootloader, denn zu einer Hardwareverschlüsselung gehört immer ein Backend, also eine Software.
Diese installiert man und erstellt damit dann eine neue Bootloader Datei.
Genauso macht es TrueCrypt auch, wenn man z.B. die Bootpartition verschlüsselt.
Zum Thema TC auf SSD:
Ich habe eine Intel G2 Postville 80GB im Laptop und hab hier im Board sicher ein Topic rumfliegen
Ansich bestand damals die Frage wegen TRIM, Garbage Controll etc. Diese werden soweit ich informiert bin mit V7 nicht weitergegeben.
Das verursacht dann vll. eine schnelle Abnutzung einzelner Zellen.
Dann ist da noch das Problem das irgendwelche Leute meinen die SSD Controller sollte man entgegen kommen und 10% der SSD unpartioniert lassen, halte ich mitlerweile für überholt.
Die Frage ob die Zellen wegen der Verschlüsselung allgemein oft genutzt werden, nein! Egal ob verschlüsselt oder nicht (das macht eh nur der CPU!) der Bit wird so oder so nur einmal, wie normal halt, ausgelesen.
Ich habe mit dem Intel Tool damals aufgezeichnet wie viel Read und vor allem Write ich hatte, das erhöhte sich 0 und war nach 1 Jahr Betrieb grad mal bei 1,8TB - MLC Chips schaffen bei 80GB * 10.000 beschreiben, lesen unendlich = 800.000GB write = 800TB! Im Worst Case (das der MLC Chip vll. nur 5.000 Zyklen packt) 400TB, aber ich nutz die doch keine 20 Jahre mehr
Zu der Wirkung von einer vollverschlüsselten SSD:
Ich hatte eine 3x Serpant Twofish AES Verschlüsselung mit Whirlpool als Hash
Dazu ein 30 stelliges PW was aber uninteressant ist (da das PW nur den "Schlüssel" entschlüsselt, welcher dann erst aufmacht, deshalb kann man das PW ja auch immer ändern, wäre es direkt angebunden müsste man immer alles neu formatieren oder verschlüsseln!)!
Die Geschwindigkeit ging von ca. 210MB/s - 260MB/s runter auf 70! Random war es sogar noch übler!
Und die Latenz stieg extrem.
Counter Strike wollte damals gar nicht mehr laden (immer aufgehangen)! Immer frisch installiert, klappte nie. Kaum die Verschlüsselung weg: Alles wieder rasant.
Ach, und am CPU lags nicht die Auslastung ging nichtmal auf 30% weil ich ein DualCore T9900 mit 3GHz drin hab, der war schon janz potent
Alles im allen:
Wenn manverschlüsselt, dann vll. nicht mit so starken Algorythmen und nicht so vielen, vll. gehts dann besser! Aber so - nein nicht bis sowas wirklich 100% miteinander arbeitet ähnlich zur HDD! Da ist der Unterschied nicht so gravierend.
Gruß
Zuletzt bearbeitet:
Kleiner Monolog zur Morgenstunde:
http://de.wikipedia.org/wiki/TrueCrypt#Funktionalit.C3.A4t_mit_Solid_State_Drives_.28SSD.29 würde bedeuten, das ist was ich suche: Ich verschlüssele die ganze Platte (Systempartition, nicht versteckt). Die Trim-Befehle von Win 7 werden von TC durchgereicht und die damit als frei gekennzeichneten Bereiche können fürs wear-leveling verwendet werden. Das auf Kosten der Plausible deniability und weiteren Sicherheitsrisiken lt. TC-HP mit denen ich aber leben kann, weil der Aufwand die Daten zu rekonstruieren mit 99,9XXX% Aufwändiger ist als der Wert der Daten. Die Lösung ist duch optimal wenn man nicht gerade Staatsgeheimnisse auf seinem Rechner transportiert :-)
@DUNnet: Dass bei 3x Serpant Twofish AES Verschlüsselung mit Whirlpool die Performance im Keller ist glaube ich sofort, dafür hat weder Intel noch AMD Hardware-Implementation soweit ich weis. Aber seit Intel die AES-NI hat liegt der Benchmark für AES bei 2,6 GB/s. Mit HDTune konnte ich kaum einen Unterschied verschlüsselt <> unverschlüsselt feststellen. Gefühlt ohnehin nicht. Da merke ich das nur bei dem Atom-Netbook - dafür umso mehr
http://de.wikipedia.org/wiki/TrueCrypt#Funktionalit.C3.A4t_mit_Solid_State_Drives_.28SSD.29 würde bedeuten, das ist was ich suche: Ich verschlüssele die ganze Platte (Systempartition, nicht versteckt). Die Trim-Befehle von Win 7 werden von TC durchgereicht und die damit als frei gekennzeichneten Bereiche können fürs wear-leveling verwendet werden. Das auf Kosten der Plausible deniability und weiteren Sicherheitsrisiken lt. TC-HP mit denen ich aber leben kann, weil der Aufwand die Daten zu rekonstruieren mit 99,9XXX% Aufwändiger ist als der Wert der Daten. Die Lösung ist duch optimal wenn man nicht gerade Staatsgeheimnisse auf seinem Rechner transportiert :-)
Ergänzung ()
@DUNnet: Dass bei 3x Serpant Twofish AES Verschlüsselung mit Whirlpool die Performance im Keller ist glaube ich sofort, dafür hat weder Intel noch AMD Hardware-Implementation soweit ich weis. Aber seit Intel die AES-NI hat liegt der Benchmark für AES bei 2,6 GB/s. Mit HDTune konnte ich kaum einen Unterschied verschlüsselt <> unverschlüsselt feststellen. Gefühlt ohnehin nicht. Da merke ich das nur bei dem Atom-Netbook - dafür umso mehr
@ DUNnet
Sr, aber das ist paranoid! Kein mensch braucht realistisch gesehen eine verschlüsselungskaskade! Außerdem kann so eine kaskade die sicherheit sogar reduzieren.
Bei TrueCrypt wurde vor einiger zeit AES verschlüsselung in assembler eingeführt. Soll bedeuten: AES verschlüsselung ist so richtig schnell. Man kann z.B. auch Twofish etc verwenden, welches grundlegend nicht viel sicherer ist als AES aber eben nicht in assembler implementiert.
Dazu kommt die von neuen intel prozessoren unterstützte aes ver- und entschlüsselung direkt im prozessor. Wenn du truecrypt verwenden möchtest, verwende AES.
Leute mit einem mobilsystem haben so gut wie keinen grund mehr ihr system nicht zu verschlüsseln. Bei desktopsystemen ist es eigentlich nicht anders. Die höhere latenz bei plattenzugriffen ist richtig, aber bei der verwendung eines einzelnen algorithmus wie z.B. AES in fast allen fällen nicht störend.
Ach und DOCH es lag an der CPU in der verbindung mit TrueCrypt. Woran sonst? Die SSD hatte ja noch platz nach unten. Mittlerweile unterstützt TrueCrypt multicore systeme deutlich besser.
Mein laptop mit Core i5 U430 schafft (trotz AES in assembler, keine hardware AES beschleunigung, dafür gute multicore unterstützung im neueren TrueCrypt) unter vollast! nur 70 mb/s AES und eine AES-Twofish-Serpent-Kaskade mit nur 18 MB/s. Leider kann ich keinen benchmark auf meinem desktop machen. Der Q9550 hätte ganz andere werte, jedoch ist auch dort bei 80 MB/s oder so bei den kaskaden schluss.
@ tracer
Danke für die info. Also war doch was mit OS abhängigkeit. Gut zu wissen das es darüber hinaus noch vom treiber bzw spezieller software (in diesem falle TrueCrypt bei vollverschlüsselung) unterstützt werden muss.
Ach und die methode mit TrueCrypt (auf die du dich beziehst) ist auch vollkommend ausreichend wenn du hochbrisante staatsgeheimnise transportierst
.
Sr, aber das ist paranoid! Kein mensch braucht realistisch gesehen eine verschlüsselungskaskade! Außerdem kann so eine kaskade die sicherheit sogar reduzieren.
Bei TrueCrypt wurde vor einiger zeit AES verschlüsselung in assembler eingeführt. Soll bedeuten: AES verschlüsselung ist so richtig schnell. Man kann z.B. auch Twofish etc verwenden, welches grundlegend nicht viel sicherer ist als AES aber eben nicht in assembler implementiert.
Dazu kommt die von neuen intel prozessoren unterstützte aes ver- und entschlüsselung direkt im prozessor. Wenn du truecrypt verwenden möchtest, verwende AES.
Leute mit einem mobilsystem haben so gut wie keinen grund mehr ihr system nicht zu verschlüsseln. Bei desktopsystemen ist es eigentlich nicht anders. Die höhere latenz bei plattenzugriffen ist richtig, aber bei der verwendung eines einzelnen algorithmus wie z.B. AES in fast allen fällen nicht störend.
Ach und DOCH es lag an der CPU in der verbindung mit TrueCrypt. Woran sonst? Die SSD hatte ja noch platz nach unten. Mittlerweile unterstützt TrueCrypt multicore systeme deutlich besser.
Mein laptop mit Core i5 U430 schafft (trotz AES in assembler, keine hardware AES beschleunigung, dafür gute multicore unterstützung im neueren TrueCrypt) unter vollast! nur 70 mb/s AES und eine AES-Twofish-Serpent-Kaskade mit nur 18 MB/s. Leider kann ich keinen benchmark auf meinem desktop machen. Der Q9550 hätte ganz andere werte, jedoch ist auch dort bei 80 MB/s oder so bei den kaskaden schluss.
@ tracer
Danke für die info. Also war doch was mit OS abhängigkeit. Gut zu wissen das es darüber hinaus noch vom treiber bzw spezieller software (in diesem falle TrueCrypt bei vollverschlüsselung) unterstützt werden muss.
Ach und die methode mit TrueCrypt (auf die du dich beziehst) ist auch vollkommend ausreichend wenn du hochbrisante staatsgeheimnise transportierst
.
Zuletzt bearbeitet:
Alle (mir bekannten) Algorithmen basieren entweder auf der Primfaktorzerlegung oder eliptischen Kurven. Eine Kaskade würde nur dann Sinn machen wenn je ein Algorithmus aus beiden Bereichen verwendet würde. Als paranoider Nutzer wäre das sogar ratsam, weil wenn ein Algorithmus kompromitiert wird hält der zweite noch stand. Ob das einen von uns betrifft wag ich aber eher zu bestreiten, sofern eine Möglichkeit gefunden wird sehr große Zahlen schnell in Primfaktoren zu zerlegen bricht ohnehin erst mal die weltweite Wirtschaft und das Finanzsystem zusammen, weil dort in vielen Fällen nicht kasdiert wird (bzw. werden kann, allein schon wegen der Rechenleistung). Immer voraussgesetzt das die Algorithmen fehlerfrei implementiert werden. Aber das wird jetzt doch zu philosophisch.
Ich hab meine Lösung gefunden und halte jetzt die Augen offen nach einer SSD mit akzeptabler Geschwindigkeit zu einem vernünftigen Preis. Mal sehen was die neuen Crucial C400 oder Intel 320 Series oder eine mit SF2000 zu bieten haben werden... Und als Algorithmus kommt bei mir ohnehin nur AES in Frage.
Ich hab meine Lösung gefunden und halte jetzt die Augen offen nach einer SSD mit akzeptabler Geschwindigkeit zu einem vernünftigen Preis. Mal sehen was die neuen Crucial C400 oder Intel 320 Series oder eine mit SF2000 zu bieten haben werden... Und als Algorithmus kommt bei mir ohnehin nur AES in Frage.
