PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Verschoben: TrueCrypt5.0a!


Gast
2008-02-13, 13:02:30
http://www.truecrypt.org/docs/?s=version-history

http://www.truecrypt.org/downloads.php

Gast
2008-02-13, 18:26:03
On computers equipped with certain brands of audio cards, when performing the system encryption pretest or when the system partition/drive is encrypted, the sound card drivers failed to load. This will no longer occur. (Windows Vista/XP/2003)

Super!
Kann ich es endlich wieder auf meinem Notebook nutzen.

Gast
2008-02-13, 22:05:24
Außerdem wurden wohl Optimierungen vorgenommen, die Benchs laufen bei mir rund 10% schneller - 68 statt 61 MiB/s in Twofish :)

Gast
2008-02-14, 02:27:01
Das ist richtig. Im Gegensatz zu dem loop-AES asm-Kode http://www.forum-3dcenter.org/vbulletin/showthread.php?t=403624 von dem ich nicht so 100% überzeugt bin, was seine überprüfte "Sicherheitsstärke" angeht, wurde Twofish ab Werk von der Foundation MERKBAR beschleunigt.

Und da Twofish sowieso eine theoretisch stärkere Sicherheit als AES bietet die sogar garnicht so weit entfernt von Serpent liegt, kann ich jedem nur empfehlen, falls man nicht gleich Kaskadieren möchte, ab 5.0a am besten nur noch Twofish zu benutzen.

Es ist theoretisch um eine ganze Klasse sicherer als AES und mit 5.0a auf einem C2D @3.2Ghz hier um 10% schneller beim Verschlüsseln und knapp 30% schneller beim Entschlüsseln als AES.

Der asm-Kode von Gladman (??) den Andi reingefrimmelt ist ~ 20% schneller als das Original aus 5.0. Damit dürfte Twofish in 5.0a mindestens genausoschnell arbeiten wie der Loop-AES, welchen die Foundation aber anscheinend nicht verwenden möchte.

Grundsätzlich sollte man solchen Tunigsmassnahmen von Sicherheitssoftware erstmal skeptisch gegenüber stehen. Wenn man schon den originalen Kode ersetzt, also indirekt der Meinung ist, daß die Macher nicht 100% wissen was sie am besten wie tun sollten, warum sollte man so einer Software überhaupt noch vertrauen?

ESAD
2008-02-14, 02:36:54
Das ist richtig. Im Gegensatz zu dem loop-AES asm-Kode http://www.forum-3dcenter.org/vbulletin/showthread.php?t=403624 von dem ich nicht so 100% überzeugt bin, was seine überprüfte "Sicherheitsstärke" angeht, wurde Twofish ab Werk von der Foundation MERKBAR beschleunigt.

Und da Twofish sowieso eine theoretisch stärkere Sicherheit als AES bietet die sogar garnicht so weit entfernt von Serpent liegt, kann ich jedem nur empfehlen, falls man nicht gleich Kaskadieren möchte, ab 5.0a am besten nur noch Twofish zu benutzen.

Es ist theoretisch um eine ganze Klasse sicherer als AES und mit 5.0a auf einem C2D @3.2Ghz hier um 10% schneller beim Verschlüsseln und knapp 30% schneller beim Entschlüsseln als AES.

Der asm-Kode von Gladman (??) den Andi reingefrimmelt ist ~ 20% schneller als das Original aus 5.0. Damit dürfte Twofish in 5.0a mindestens genausoschnell arbeiten wie der Loop-AES, welchen die Foundation aber anscheinend nicht verwenden möchte.

Grundsätzlich sollte man solchen Tunigsmassnahmen von Sicherheitssoftware erstmal skeptisch gegenüber stehen. Wenn man schon den originalen Kode ersetzt, also indirekt der Meinung ist, daß die Macher nicht 100% wissen was sie am besten wie tun sollten, warum sollte man so einer Software überhaupt noch vertrauen?


aes wurde afaik nur genommen weil es einfach und günstig in hardware zu implimentieren war

Gast
2008-02-14, 03:06:10
aes wurde afaik nur genommen weil es einfach und günstig in hardware zu implimentieren warSo ungefähr. Und weil er merkbar schneller bei Operationen an/mit Schlüsseln (key setups) ist. Was ihn ideal für WPA2 und viele embedded applications macht. Zum Beispiel Smartcards und ähnliches.

Was die Laien aber nicht wissen ist, daß es kein Allroundtalent ist. Man kann es für fast alles benutzen, genauso kann man aber immernoch DES für fast alles benutzen ;) AES ist einfach nur ein Blockchiffre von vielen.

Er ist nicht der theoretisch sicherste und er ist nicht der praktisch schnellste. Es gab auf NISTs Prioritätenliste einige Schwerpunkte die bei der Wahl von Rijndael überwiegt haben.
Diese Schwerpunkte sind aber bei einer Verschlüsselung mit welcher ein Anwender daheim aktiv über eine x86 CPU interagiert absolut irrelevant.

nacht