TrueCrypt @ GPU (wäre das möglich?)

[Warhammer Online]

Hallo zusammen,
Das nVidia GPUs (dank Cuda) für das Knacken bzw. Rechnen von Codes genutzt werden ist ja nix neues.
Oder halt Physik Berechnung.

Wäre es möglich diese Technik auch bei TrueCrypt zu nutzen?
Die GPU Power ist ja bekanntlich viel stärker in solch einem Fall.
Der Vorteil wäre ja das im Office Betrieb die CPU so gesehen ihren Zweck erfüllt so wie sonst immer (naja ok gut... an der CPU Perfomance wird auch gesaugt aber nicht so wie nur mit CPU-Verschlüsseln und Entschlüsseln).
Da die GPU im Officebetrieb (Texte,Surfen,hier und da bishen) sowieso nix zutun hat wäre das doch eine gute Lösung oder?

Aber es wird sicherlich einen Grund geben warum das noch nicht gemacht wurde.
Darum gehe ich davon aus das es doch nicht möglich oder nur begrenzt möglich ist oder?

Ich entschuldige mich schon mal vorab... ich bin selber ein newbie und mir ist der Gedanke nur in Sinn gekommen.
Allso nicht bitte gleich Totbashen...danke :smile:

EDIT:
Falls ich hier falsch bin.... verschieben

[Warhammer Online]

Evtl. in Technologie verschieben oder doch richtig?^^

[Gast]

Lass doch einfach mal ne Woche stehen. Wenn dann noch nix gekommen ist könntest du einen Mod fragen ob er verschiebt. Da nicht jeder Thread von einem Mod gelesen wird bringt die Frage nach Verschieben hier nicht wirklich viel.

[Gast]

Das Thema sollte hier schon richtig sein.

Für transparente Verschlüsselung wie sie der Linux-Devicemapper oder Truecrypt bietet, stelle ich mir die Nutzung einer GPU als nicht sehr lohnenswert vor. Dazu kommen noch Probleme wie die Tatsache, dass der Grafiktreiber geladen sein muss, was vor dem Entschlüsseln der Root-Partition nicht der Fall ist. So würde sich das ganze auf nach dem Booten eingehängte Partitionen bzw. Container beschränken, wenn man nicht irgendeine exotische Lösung nutzen will. Außerdem wäre das ganze wohl Windows-exklusiv, selbst wenn es denn realisiert werden würde, was den Nutzen weiter einschränkt.

Im Gegensatz zu Bruteforce-Attacken wäre ich mir auch alles andere als sicher, dass die GPU-Nutzung bei transparenter Verschlüsselung überhaupt einen Vorteil mit sich bringt, gerade wenn dieser noch massiv Nachteile auszugleichen hätte. Da die Nutzung von kryptographischen Verfahren aber stark ansteigt, auch ohne dass der Nutzer davon etwas mitbekommt, finde ich eine Beschleunigung der dafür benötigten Operationen seitens der CPU recht sinnvoll. Via bietet sowas ja schon eine halbe Ewigkeit an. Genau das ist auch der Grund dafür, dass Via im Bereich der Netbooks für mich aktuell und in nächster Zeit wohl das beste Produkt anzubieten hat, da z.B. Intels Atom (auch wenn ursprünglich nicht für diesen Bereich entwickelt, wird er dort doch am häufigsten verwendet) meiner Einschätzung nach starke Probleme mit konsequenter Nutzung von Festplattenverschüsselung zeigen sollte.

Kann jemand sagen, ob die Via-CPUs aufgrund der "Cryptoengine" trotz ihrer vergleichsweise geringen Grundleistung zur Nutzung von komplett verschlüsselten Festplatten mittels DM-Crypt/Cryptsetup-Luks und einem ansonsten schlanken GNU/Linux stark genug sind? Die Verwendung eines unverschlüsselten mobilen Computers ruft in mir starkes Unwohlsein hervor. Mobile Geräte mit starken CPUs sind aber alles andere als billig, wobei eine solche Leistung meist gar nicht benötigt würde, wenn die schwächere CPU dennoch günstige Verschlüsselung bieten würde.

Intel kündigt auf einer Folie zu Clarkdale ja auch "AES Acceleration" an.

Entschuldige bitte das Abschweifen. Wenn du diesen Thread lieber auf ausschließlich GPU-beschleunigte Verschlüsselung beschränken möchtest, sags einfach, ich würde dann überlegen eventuell einen weiteren Thread zum Thema "spezielle Hardwarebeschleunigung von kryptographischen Verfahren" aufmachen. ;)

[Gast]

Diese Aussage im "Truecrypt und Netbook"-Thread etwas weiter unten klingt ja schon recht vielversprechend:
Mit AES-256 ist ein 1.8 Ghz Nano schneller als ein E8400 (wenn nur ein Core benutzt wird). Das gleiche gilt für SHA.Wenn diese Angabe nicht völlig aus der Luft gegriffen ist, ist dies schon ein gigantischer Vorteil. In Sachen Transistorbudget sollte derartiges doch auch nicht so stark reinhauen, oder? Wenn der Aufwand auch bei einer High-End-CPU ala Bloomfield noch überschaubar sein sollte (gerade für Chipzilla), weshalb erweitern Intel, AMD oder auch IBM ihre CPUs nicht schon länger mit solchen Funktionen?

Wenn das Design nicht von Anfang an daraufhin ausgelegt sein muss, sollte man hier doch einen enormen Geschwindigkeitsschub bieten können.

[Warhammer Online]

Ne macht ja nix aus... und danke für deinen Beitrag. :smile:

[Gast]

Die Ts von Sun und der Nano bieten eine s.g. Kryptoeinheit. Diese sind Rechenidioten die sich extrem nur auf die Operationen spezialisiert haben, die man in gängigen Verschlüsselungsmethoden findet. Diese Lehre ist ein erforschtes Gebiet und es sheint nicht als wenn sich in der nahen zukufnt viel davon ändern würde. Wer sich mit Methoden wie S-Boxen, Substitution, Feistelchiffre oder Substitutions-Permutations Netzwerken beschäftigen möchte, dem sei es gegönnt ;)

Der Fokus bei diesen Kryptoeinheiten liegt zwar neumodisch auf AES, alle anderen Algorithmen können dadurch aber ebenfalls enorm beschleunigt werden. Bildlich und vereinfacht dargestellt ist das wie mit TrueCrypt seitdem es MP unterstützt. Mit dem neuen Kode hat AES zwar zusätzlich noch dazugewonnen, aber insgesamt haben auch Twofish und Serpent durch MP enorm zugelegt.

Intel wird das gleiche mit extra paar Befehlen mehr für AVX versuchen.

Wenn der Nano nur mit AES umgehen kann, dann ist das zwar ok, aber gleichzeitig auch recht beschränkt. Nichtsdestotrotz läuft die spezielle Version von GPG darauf wie der Teufel :tongue:

Bereits ausgeklügelte Nutzung von MMX kann schon ausgezeichnete Früchte tragen
http://gladman.plushost.co.uk/oldsite/cryptography_technology/serpent/index.php
http://gladman.plushost.co.uk/oldsite/cryptography_technology/index.php

@Warhammer Online
Ich denke prinzipiell und aus Überzeugung in dieser Szene wird Verschlüsselung nie auf GPUs lauffähig gemacht. Angesichts der Kryptoeinheiten oder zukünftigen SIMD extensions wird auch niemand diesen zusätzlichen Zirkus veranstalten.
Die Sicherheit aka Implementierung der Lösung sollte nicht zusätzlich noch von einem Grakatreiber abhängig gemacht werden. Darauf werden sich keine ernsthaften Entwickler einlassen.

[Gast]

Und wenn die CPU Hersteller AES falsch implementieren dann wird das ganze sogar noch höchst unsicher.


Ich könnte mir sogar vorstellen, daß die Hardwareeinheit eine Backdoor enthält.

[h'lore]

Ich könnte mir sogar vorstellen, daß die Hardwareeinheit eine Backdoor enthält.Sollte sowas rauskommen, könnte der entsprechende Hersteller aber einpacken. Bei Skype kann man sich sowas vielleicht erlauben, betrachtet man die Zielgruppe, einem der großen Hardwarehersteller aber würde auf ewig ein entsprechender Ruf anlasten und das völlig zurecht. Ich kann nur hoffen, dass sowas nicht eintreten wird und der Widerstand auch auf die ganze Bevölkerung gesehen bei derartigen Aktionen zu groß wäre, wobei ich mit der Zeit zumindest an letzterem immer mehr Zweifel habe.

[Trap]

Ich bin mir nicht sicher, ab die GPU das wirklich schneller kann, Verschlüsselung ist eine Aneinanderreihung von sehr vielen Operationen, die alle voneinander abhängen. Da sind CPUs normalerweise besser drin.

Beim Knacken ist es OK z.B. 150 Tests mit 10% der CPU Geschwindigkeit parallel zu machen, aber bei TrueCrypt hat man üblicherweise nur 1 Datenstrom zu (de-)codieren.

[Gast]

Und wenn die CPU Hersteller AES falsch implementieren dann wird das ganze sogar noch höchst unsicher
Du bist der totale Checker. nur lesen kannst du nicht. Ich schreib, daß es eine Einheit ist die auf die in erwähnten Algorithmen vorkommende Operationen spezialisiert ist. Das ist aber kein AES drin! Lamers in da house :|
Hier werden nur mathematische Operationen implementiert und keine Verschlüsselungsmethoden.

Ich könnte mir sogar vorstellen, daß die Hardwareeinheit eine Backdoor enthält.Was zum Glück absolut garnichts bedeutet.

[Nasenbaer]

Also ich hatte mal nen Via Eden, der auch AES beschleunigen konnte. Das brachte enorm viel aber das Problem war, dass das Potential ausschließlich unter Linux nutzbar war. Ich habe nicht eine transparente Windows Verschlüsselungssoftware gefunden, die VIAs Cryptoeinheit genutzt hat.

Das Problem ist sicher, dass da eine Insellösung ist und darum auch niemand Zeit reinsteckt. Sobald aber OpenCL da ist, ist eine gemeinsame Schnittstelle für GPGPU geschaffen und somit könnte man GPUs bestimmt recht gut für TrueCrypt etc. nutzen.
Dass der Grafikkarten-Treiber aber erstmal geladen werden muss wäre kein Problem, denn die Algorithmen existieren ja schon für die CPU. Diese könnte ja solange arbeiten bis die GPU nutzbar ist. Dannach übernimmt halt die GPU die Arbeit.
Die Frage ist nur ob das switchen zwischen CPU und GPU problemlos klappt aber wenn ja wäre das ja sicher ne Möglichkeit. Das andere Problem wäre sicher der Aufwad für die erneute Implementation der Algorithmen. Sind die nämlich nicht ordentlich umgesetzt, so sind die wohl wesentlich leichter knackbar als gedacht, obwohl sie im Kern alles richtig machen.

[Gast]

Die Frage ist nur ob das switchen zwischen CPU und GPUDie Frage ist ob die Integers die bei den gängigen Verschlüsselungen genutzt werden einen Sinn auf einer GPU machen.

Warum sollte man nicht so verfahren, daß jeder der keine Fragen hat an den Threads teilnimmt, die Themen behandeln, von welchen er Ahnung hat. Was wäre denn daran verkehrt?

[Nasenbaer]

Die Frage ist ob die Integers die bei den gängigen Verschlüsselungen genutzt werden einen Sinn auf einer GPU machen.

Warum sollte man nicht so verfahren, daß jeder der keine Fragen hat an den Threads teilnimmt, die Themen behandeln, von welchen er Ahnung hat. Was wäre denn daran verkehrt?
Ich bin kein Experte aber IMO ist MD5 auch Integer-lastig und diese Hashes lassen durchaus schneller mit GPUs berechnen.

[albix64]

Dazu kommen noch Probleme wie die Tatsache, dass der Grafiktreiber geladen sein muss, was vor dem Entschlüsseln der Root-Partition nicht der Fall ist.
Damit hat sich die Sache doch erledigt, oder? Zumindest auf der Hauptpartition?

Außerdem wäre das ganze wohl Windows-exklusiv, selbst wenn es denn realisiert werden würde, was den Nutzen weiter einschränkt.
Der Nvidia-Linuxtreiber unterstützt doch auch CUDA, ebenso wie der ATI-Linuxtreiber, welcher Stream unterstützt.

[Nasenbaer]

Damit hat sich die Sache doch erledigt, oder? Zumindest auf der Hauptpartition?

Lies dir mal meinen ersten Post durch. Hab da ne Lösungsmöglichkeit angebracht.

[albix64]

Lies dir mal meinen ersten Post durch. Hab da ne Lösungsmöglichkeit angebracht.
Sorry, habe ich überlesen. Aber so etwas ähnliches habe ich mir auch schon gedacht. ^^

[Gast]

Ich bin kein Experte aber IMO ist MD5 auch Integer-lastig und diese Hashes lassen durchaus schneller mit GPUs berechnen.Ich höre.

[The Cell]

Das Thema agb es schon vor einiger Zeit.
Hier mal der Link, den ich dazu gepostet habe: http://arstechnica.com/old/content/2008/12/gpu-based-wpawpa2-crack-struggles-with-good-passwords.ars

Wäre es meiner Meinung nach möglich?

Ja

Ist es meiner Meinung nach sinnvoll?

Nein, denn der Flaschenhals ist in den seltensten Fällen der Prozessor.

Viele Grüße
TC

[Nasenbaer]

Ich höre.
Na denk doch mal nach. Ob ich mit Integern arbeite also die Zahl 145 bspw. habe oder mit FP also 145,0000 habe ist doch unerheblich.
Wenn die Ganzzahl-Operationen, die ich nutze den Lörper der ganzen Zahlen nicht verlassen, so kann ich ruhigen Gewissens auch FP-Zahlen nutzen. Probleme gibt es mit FPs nur, dass sie manche Nachkommastellen des Dezimalsystems nicht 1:1 mittels IEEE 754 abbilden können. Solange man aber ganzzahlig bleibt gibt es keine Probleme.
Also erstmal mit der Theorie beschäftigen und dann große Sprüche klopfen. ;D


@The Cell
Ob die CPU der Flaschenhals ist, hängt auch vom Anwendungsgebiet ab. Hab ich z.B. das komplette System verschlüsselt um keine Lücke zu lassen und dann Videoschnitt oder Spiele nutze, dann ist die CPU ohnehin stark belastet und mit kombinierter GPU/CPU Leistung wäre ordentliche Lastverteilung möglich. Bei aktuellen Quad-Core sollte sich der Leistungsschub allerdings in Grenzen halten.
Aber man könnte dadurch ja auch eher kaskadierte Verschlüsselungen nutzen oder längere Schlüssel usw.

[Kommandofrosch]

Die GPU sollte dann auch die Mathematik bezüglich Cryptographie auch tatsächlich schneller als eine CPU ausführen. Eine GPU erledigt ja nur bestimmte Instruktionen schneller als eine CPU.
Wie sieht es denn mit E-Funktionen, Exponenten, Sinus, Cosinus, elliptische Kurven aus?
Zudem sollten auch Crypto-Algorithmen verwendet werden, welche theoretisch und praktisch noch nicht geknackt wurden.
Selbst eine GPU als Crypto-Beschleuniger würde denn meisten Personen nichts bringen, da grundlegende Sicherheitskenntnisse einfach fehlen. Keys können noch dennoch ausgelsen werden. --> Speicherbild, SWAP/Temp und sonstige schwächen im Betrieb.
Vor allem mangelt es an Passwortstärke.
Fast habe ich den eigentlichen Flaschenhals vergessen, Graka Anbindung und Festplatte!

Und Wirklich, wer interessiert sich für euern Crap?

Trickreicher ist, fremden Personen den Eindruck zu hinterlassen, dass nichts auffälliges auf dem PC zu finden ist. --> Blinddaten, individuelle Struktur.

[Gast]

Na denk doch mal nach. Ob ich mit Integern arbeite also die Zahl 145 bspw. habe oder mit FP also 145,0000 habe ist doch unerheblich.:LOL:

[Nasenbaer]

:LOL:
Wenn man von Mathematik keine Ahnung hat, sollte man... naja vielleicht studieren und nicht andere mit seinen unnützen Kommentaren belästigen. Und wenn du der MEinung bist, dass ich was falsches erzähle, dann reiß nicht nur Sprüche, sondern begründe endlich auch mal deinen Kommentare und versteck dich nicht hinter der Anonymität deines Gast-Zugangs. ;)

[Nasenbaer]

Ist es meiner Meinung nach sinnvoll?

Nein, denn der Flaschenhals ist in den seltensten Fällen der Prozessor.

Viele Grüße
TC
Muss mich korrigieren und dir doch Recht geben. Mittlerweile ist es wohl echt sinnlos. Bei meinem Core i7 erzeugt TrueCrypt weniger Last als der VirenScanner, wenn ich Daten kopiere. Selbst bei voll ausgelasteter CPU sollte da kein merklicher Unterschied mehr feststellbar sein.

[Gast]

Wenn man von Mathematik keine Ahnung hat, sollte man... naja vielleicht studieren und nicht andere mit seinen unnützen Kommentaren belästigen. Und wenn du der MEinung bist, dass ich was falsches erzähle, dann reiß nicht nur Sprüche, sondern begründe endlich auch mal deinen Kommentare und versteck dich nicht hinter der Anonymität deines Gast-Zugangs. ;)Ja paßt schon. Hauptsache du hast dich nun korrigiert.

[Nasenbaer]

Ja paßt schon. Hauptsache du hast dich nun korrigiert.
Ich hab mich nur dahingehend korrigiert, dass es auf aktuellen MultiCore-CPUs mit den aktuellen Verschlüsselungen keinen Sinn machen würde die GPU mit einzubeziehen. An der prinzipiellen Möglichkeit die GPU zu nutzen ändert sich dabei nichts und ich lege dir immer noch ein Studium der Mathematik oder Informatik ans Herz bevor du wieder große Töne spuckst - d.h. falls du der selbe Gast wie damals bist.

[Coda]

:LOL:
Er hat recht. Innerhalb der Genauigkeit der Mantisse lassen sich Ganzzahlen auch mit Floats exakt repräsentieren. Allerdings sind das bei FP32 eben nur 24 Bit.

D3D10-GPUs müssen aber auch ganz normale 32-Bit-Integer unterstützen.

Wie sieht es denn mit E-Funktionen, Exponenten, Sinus, Cosinus, elliptische Kurven aus?
Die ganzen Sonderfunktionen gehen in einem Takt auf modernen GPUs, können aber nicht immer in die Pipeline geschoben werden.

[Gast]

Na denk doch mal nach. Ob ich mit Integern arbeite also die Zahl 145 bspw. habe oder mit FP also 145,0000 habe ist doch unerheblich.
Wenn die Ganzzahl-Operationen, die ich nutze den Lörper der ganzen Zahlen nicht verlassen, so kann ich ruhigen Gewissens auch FP-Zahlen nutzen. Probleme gibt es mit FPs nur, dass sie manche Nachkommastellen des Dezimalsystems nicht 1:1 mittels IEEE 754 abbilden können. Solange man aber ganzzahlig bleibt gibt es keine Probleme.

du hast wohl noch nie nachgesehen wie FP-zahlen funktionieren, sonst wüsstest du dass sich Integers nicht immer genau auf FPs abbilden lassen.

eine FP32-zahl kann nicht jede zahl die eine INT32-zahl annehmen kann eindeutlig darstellen.

[Nasenbaer]

du hast wohl noch nie nachgesehen wie FP-zahlen funktionieren, sonst wüsstest du dass sich Integers nicht immer genau auf FPs abbilden lassen.

eine FP32-zahl kann nicht jede zahl die eine INT32-zahl annehmen kann eindeutlig darstellen.
Bist du auf Stunk aus? Ich hab doch nie behauptet, dass ich mit FP-Zahlen einer bestimmten größe, alle Integer-Zahlen der selben Speichergröße abbilden kann. Da ich den IEEE 754 Standard kenne, bin ich mir dessen vollkommen bewusst.
Ich habe nur gesagt, dass ich mit FP-Zahlen prinzipiell jede Integer-Zahl darstellen kann. Dass sich diese im FP-Format nicht so effektiv im Speicher halten lassen sollte klar sein.

[Gast]

Ich hab mich nur dahingehend korrigiert, dass es auf aktuellen MultiCore-CPUs mit den aktuellen Verschlüsselungen keinen Sinn machen würde die GPU mit einzubeziehen.Wer will eigentlich riskieren daß er nach einem Update des Grakatreibers und einem Fehler dadrin seine Laufwerke nicht mehr mounten kann? 100% sichere checks und CPU-fallbacks für den Start zu programmieren ist extrem kompliziert und das was die Hersteller manchmal mit ihren Treibern treiben =) ist alles andere als vertrauensvoll.

Wie erleben spätestens jeden Monat wieviel Gemurkse mit den Treibern betrieben wird. Deswegen wird das auch nie kommen. Es ist den Machern zu unseriös. Ich kann das auch vollkommen verstehen.

Selbst wenn 2 Tage später ein Hotfix zum Update :ulol: kommen würde, bei PBE läßt er sich nicht mehr aufspielen ;)

[Nasenbaer]

Wer will eigentlich riskieren daß er nach einem Update des Grakatreibers und einem Fehler dadrin seine Laufwerke nicht mehr mounten kann? 100% sichere checks und CPU-fallbacks für den Start zu programmieren ist extrem kompliziert und das was die Hersteller manchmal mit ihren Treibern treiben =) ist alles andere als vertrauensvoll.

Wie erleben spätestens jeden Monat wieviel Gemurkse mit den Treibern betrieben wird. Deswegen wird das auch nie kommen. Es ist den Machern zu unseriös. Ich kann das auch vollkommen verstehen.

Selbst wenn 2 Tage später ein Hotfix zum Update :ulol: kommen würde, bei PBE läßt er sich nicht mehr aufspielen ;)
Jo das sind natürlich gute Argumente aber einen CPU Fallback zu programmieren sollte kein Problem darstellen. Windows merkt sich ja auch, wenn ein Bluescreen auftrat und will das nächste mal per "abgesicherten Modus" starten - das sollte so nicht das Problem sein.
Aber ich denke eher der geringe nutzen ist das größere Problem. Auf kleinen Rechnern könnte man spezielle Zusatz-Einheiten nutzen wie es VIA tut und ausgewachsene MultiCores haben im Normalfall genug Reserven.

[Gast]

Aber ich denke eher der geringe nutzen ist das größere Problem. Auf kleinen Rechnern könnte man spezielle Zusatz-Einheiten nutzen wie es VIA tut und ausgewachsene MultiCores haben im Normalfall genug Reserven.Mit VIAs PadLock oder Intels AVX hat sich das sowieso erledigt. Ich denke damit hat man soviel Leistung, daß sich so eine Entwicklung und die zusätzlichen Problemfälle für die Entwickler einfach nicht mehr rechnen.

Mit dem was TC mit simplem MMX und auch noch auf Multicores auf halbwegs aktuellen CPUs erledigt stehen die Entwickler wie die User unter keinem Leistungsdruck.
Selbst auf einem 3200+ Barton läuft 6.1a hier absolut annehmbar.

[Nasenbaer]

Mit VIAs PadLock oder Intels AVX hat sich das sowieso erledigt. Ich denke damit hat man soviel Leistung, daß sich so eine Entwicklung und die zusätzlichen Problemfälle für die Entwickler einfach nicht mehr rechnen.

Mit dem was TC mit simplem MMX und auch noch auf Multicores auf halbwegs aktuellen CPUs erledigt stehen die Entwickler wie die User unter keinem Leistungsdruck.
Selbst auf einem 3200+ Barton läuft 6.1a hier absolut annehmbar.
Naja aber Netbooks sind ja beispielsweise nicht so leistungsstark und erst recht nur kleinere Computer also Handhelds/Smartphones. Ich kann mir vorstellen, dass es durchaus Leute gibt, die die darauf enthaltenen Daten auch scützen wollen - erst recht weil solche Kleingeräte noch eher verloren gehen als des Dekstop zu Hause. Das ist dann natürlich alles keine Sache mehr wo man über GPU-Beschleunigung und TrueCrypt reden müsste aber spezielle Felder würden durchaus noch von "AES-Beschleunigern" profitieren.

[Gast]

Solche Geräte haben aber auch eher selten GPUs die das steigernd oder überhaupt beschleunigen könnten. Alleine der API des jeweiligen OS wegen.
Von denen die sowas doch haben zieht man nun die, die sich dafür leider garnicht interessieren und man erhält eine SEHR kleine Zahl. Es lohnt einfach nicht, auch wenn es sinnvoll wäre. Für uns

Daß Intel im Atom kein PadLock-Derrivat hat ist nicht die Schuld der TC-Foundation. Daß der Nano nicht nur da besser ist, ist für Leute die sich dafür auch wirklich interessieren kein Geheimnis.

[Nasenbaer]

Solche Geräte haben aber auch eher selten GPUs die das steigernd oder überhaupt beschleunigen könnten. Alleine der API des jeweiligen OS wegen.
Von denen die sowas doch haben zieht man nun die, die sich dafür leider garnicht interessieren und man erhält eine SEHR kleine Zahl. Es lohnt einfach nicht, auch wenn es sinnvoll wäre. Für uns

Hab ich doch gesagt, dass man da nicht von GPU-Beschleunigung reden braucht mangels einer solchen Recheinheit, die dafür geeignet wäre. Dafür aber sowas wie das PadLock.
Also ich meine nur, dass hier aus Hardware-Sicht durchaus ein Einsatz von PadLock u.ä. sinnvoll wäre und dann natürlich die Betriebssysteme aber selbst gleich die Verschlüsselung managen.
Das würde einfach sinnvoll sein, da solche Geräte natürlich besonders gefährdet sind entwendet zu werden.


Daß Intel im Atom kein PadLock-Derrivat hat ist nicht die Schuld der TC-Foundation. Daß der Nano nicht nur da besser ist, ist für Leute die sich dafür auch wirklich interessieren kein Geheimnis.
Wobei TrueCrypt aber auch nicht PadLock unterstützt - in sofern hilft es auch nicht ne Nano-CPU zu nehmen, wenn man TrueCrypt als Verschlüsselungsoftware nutzen will. Der Linux kernel leistet mit dm-crypt zusammen aber eine super Arbeit. Hab so ein System ne Zeit lang auf nem Via Eden 1.2GHz laufen lassen und der Performance-Gewinn war enorm.

[Gast]

Also ich meine nur, dass hier aus Hardware-Sicht durchaus ein Einsatz von PadLock u.ä. sinnvoll wäre und dann natürlich die Betriebssysteme aber selbst gleich die Verschlüsselung managen.Damit hat man auf Wintel eine sehr schweren Stand. Bitlocker kommt an TrueCrypt oder Compusec nicht ansatzweise ran. Wir kennen unsere Schweine ja am Gang. Bei Linux und anderen sieht es wie du schon erwähnst anders aus.

Selbst API-mäßig siehts bei Wintel immerweider sehr mager aus. Überleg mal wie lange schon XP und folgende eine ZIP-Komprimierung anbieten und im Explorer ZIP-Archive so behandeln als wenn es Ordner wären. Beispielweise.
Hast du seit XP von Versuchen gehört, diese Funktionalität der WinOSe über API auf WinRAR oder 7-zip zu erweitern? Microsoft suckt einfach zu sehr. Für das eine wie für das andere. Und in vielen anderen Belangen.

[Gast]

Hast du seit XP von Versuchen gehört, diese Funktionalität der WinOSe über API auf WinRAR oder 7-zip zu erweitern? Microsoft suckt einfach zu sehr.Abwägung zwischen lizenzrechtlichen Problemen und dem Nutzen für den gemeinen Elektronikmarkt-PC-Käufer? Neben Unternehmen stellt dieser die wohl wichtigste Kundengruppe für MS dar.