Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Welcher Algorithmus ist sicherer, Blowfish oder Twofish?

136 views
Skip to first unread message

Heiko Blank

unread,
Nov 13, 2004, 5:54:59 AM11/13/04
to
Hallo,
ich benutze ein Container-Festplatten-Verschlüsselungsprogramm das zur
Verschlüsselung sowohl den
Twofish-Algorithmus mit 256 Bit Verschlüsselung (Key-Length) und
Blowfish-Algorithmus mit 448 Bit Verschlüsselung (Key-Length) anbietet.

Welchen soll ich nehmen? Ich merke keinen nennenswerten
Geschwindigkeitsunterschied beim erstellen eines Containers.
Ist nicht automatisch die 448-Bit Verschlüsselung sicherer?

Es gibt immer wieder Gerüchte, dass selbst so hohe Verschlüsselungen für
Behörden/Geheimdienste kein Problem zum knacken wäre.
Ich kann das nicht glauben wenn man mal die möglichen Kombinationen sieht?!
Das dürfte doch selbst für Superrechner ein Problem sein!?


Message has been deleted

Erhard Schwenk

unread,
Nov 13, 2004, 6:35:31 AM11/13/04
to
Sebastian Gottschalk wrote:

> 2^128 ist ziemlich groß. Für einen Quantencomputer von der Größe der Sonne
> @ 100 GHz wären das noch 40000 Jahre Arbeit,

Ich dachte immer, Quantencomputer erledigen solche Aufgaben in einem
Taktzyklus, weil sie sozusagen alle Ergebnisse gleichzeitig berechnen?

--
Erhard Schwenk

Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de
k-itx Webhosting - http://webhosting.k-itx.de

Harald Laabs

unread,
Nov 13, 2004, 6:39:48 AM11/13/04
to
Hallo,
Heiko Blank <spam-s...@gmx.de> schrieb:

> ich benutze ein Container-Festplatten-Verschlüsselungsprogramm das zur
> Verschlüsselung sowohl den
> Twofish-Algorithmus mit 256 Bit Verschlüsselung (Key-Length) und
> Blowfish-Algorithmus mit 448 Bit Verschlüsselung (Key-Length) anbietet.

Da stellen sich noch ganz andere Fragen als die Schluessellaenge...

> Welchen soll ich nehmen? Ich merke keinen nennenswerten
> Geschwindigkeitsunterschied beim erstellen eines Containers.
> Ist nicht automatisch die 448-Bit Verschlüsselung sicherer?

Nein.
Sowohl Twofish als auch Blowfish sollten bei diesen Schluessellaengen
hinreichend sicher sein. Das aber die Zahl der Bits nichts ueber die
Sicherheit eines Algorithmus aussagt sollte bei einem kurzen Blick auf
Viginere oder RSA klar werden. Ersteres ist grundsaetzlich unsicher
und letzteres ist unter 512 Bit definitiv auch unsicher. (Es gaebe
auch sinnvolle Beispiele mit tatsaechlich genutzten symmetrischen
Ciphern, ich bin nur grad noch nicht ganz wach.)
Bei gleicher Schluessellaenge wuerde ich Twofish fuer sicherer halten.
Solange niemand einen praktikablen Angriff vorlegt kann man bei sowas
allerdings immer voll danebenliegen - da gab es schon genug Beispiele
in der Vergangenheit.

> Es gibt immer wieder Gerüchte, dass selbst so hohe Verschlüsselungen für
> Behörden/Geheimdienste kein Problem zum knacken wäre.
> Ich kann das nicht glauben wenn man mal die möglichen Kombinationen sieht?!
> Das dürfte doch selbst für Superrechner ein Problem sein!?

Es gibt immer wieder Idioten die nicht wissen wovon sie reden und
deswegen Unsinn streuen. Es weiss natuerlich niemand was die NSA genau
im Keller stehen hat (deswegen _Geheim_dienst), aber es muesste nicht
nur ein zu gross geratener konventioneller Supercomputer sondern
wirklich vollstaendig neue Technik sein - oder oeffentlich nicht
bekannte Verfahren, so wie damals die differentielle Kryptoanalyse - um
damit Twofish, Blowfish, AES, Serpent oder die anderen ueblichen
Verfahren bei diesen Keylaengen zu brechen. Es wirkt ziemlich weit
hergeholt.
Tatsaechlich irgendwie unsicher werden alle diese Verfahren wenn zu
kurze Passworte verwendet (8 Zeichen Passworte kann man natuerlich
mit entsprechender Rechenleistung durchtesten - etwa 75 verschiedene
Zeichen, 8 Stellen -> _bestenfalls_ 50 Bit echte Schluessellaenge)
oder wenn die eingesetzte Software grundlegende Designfehler hat.
ECB waere zum Beispiel eine ganz bloede Idee. Und stetig gleiche
IVs und Schluessel fuer jeden Block genauso.
Ob Dein Program einigermassen sicher gegen bestimmte Angriffe ist, kann
Dir also niemand sagen solange Du nicht verraetst was zu verwendest.

Gruss,
Harald
--
A marketing department is something you keep in a locked cage like the
wild animal it is, and whatever it spits out you filter through sane
people before use. A company that fails to do this gets no sympathy from
me, only suspicion. -- Nicholas Knight on bugtraq

Message has been deleted

Heiko Blank

unread,
Nov 13, 2004, 11:43:50 AM11/13/04
to
"Sebastian Gottschalk" <se...@seppig.de> schrieb
> Kein AES? Mies!

Müßte ich schauen ob das "nachrüstbar" ist.
>
>> Welchen soll ich nehmen?
>
> AES. Im Zweifelsfalle Blowfish mit 128 Bit.

Warum eigentlich AES? Was ist denn an Blowfish bzw Twofish schlecht? Soviel
ich weiß hat noch niemand Lücken im Code entdeckt und es wurden beide noch
nicht geknackt.

>> Ich merke keinen nennenswerten Geschwindigkeitsunterschied beim erstellen
>> eines Containers.
>

> Der Unterschied entsteht logischerweise erst bei der Benutzung...

Nö, das ist falsch. Die Erstellung des Containers dauert je nach Größe
mehrere Stunden. Bei Benutzung öffnet sich dann ein weiteres Laufwerk mit
eigenem Buchstaben und man kann ohne Zeitverzögerungen Dateien rein und raus
schaufeln.

> Ich kann nicht glauben daß du das mit der Verschlüsselung wirklich ernst
> meinst, wenn man sieht welche Sicherheitslücke du als Newsreader
> verwendest...

Ja gerade dann muß ich doch meine Daten sicher machen! Mein PC könnte jetzt
völlig offen und ungeschützt sein (ist er aber nicht) und an die Daten auf
dem verschlüsselten Container kommt trotzdem niemand ran. Mal abgesehen von
Datenverlust durch Viren.


Heiko Blank

unread,
Nov 13, 2004, 11:48:19 AM11/13/04
to
"Harald Laabs" <news...@dasr.de> schrieb

> ...Tatsaechlich irgendwie unsicher werden alle diese Verfahren wenn zu


> kurze Passworte verwendet (8 Zeichen Passworte kann man natuerlich
> mit entsprechender Rechenleistung durchtesten - etwa 75 verschiedene
> Zeichen, 8 Stellen -> _bestenfalls_ 50 Bit echte Schluessellaenge)
> oder wenn die eingesetzte Software grundlegende Designfehler hat.
> ECB waere zum Beispiel eine ganz bloede Idee. Und stetig gleiche
> IVs und Schluessel fuer jeden Block genauso.
> Ob Dein Program einigermassen sicher gegen bestimmte Angriffe ist, kann
> Dir also niemand sagen solange Du nicht verraetst was zu verwendest.

Der Container läßt sich nur mit einer E4 Chipkarte öffnen. Diese Karte
wiederum verlangt einen 6-stelliges Pin-Code. Wird der PIN Code drei mal
falsch eingegeben ist die Karte zerstört.
Das sollte doch in Bezug auf "Paßwortsicherheit" ausreichen ;-)


Message has been deleted

Hendrik Weimer

unread,
Nov 13, 2004, 3:15:19 PM11/13/04
to
Erhard Schwenk <esch...@fto.de> writes:

> Sebastian Gottschalk wrote:
>
> > 2^128 ist ziemlich groß. Für einen Quantencomputer von der Größe der Sonne
> > @ 100 GHz wären das noch 40000 Jahre Arbeit,
>
> Ich dachte immer, Quantencomputer erledigen solche Aufgaben in einem
> Taktzyklus, weil sie sozusagen alle Ergebnisse gleichzeitig berechnen?

Nein. Quantencomputer arbeiten zwar mit superponierten Eingabedaten,
die Gatter werden aber klassisch gesteuert und sind getaktet.

Die gegenwärtigen Konzepte für Quantencomputer sind für symmetrische
Verschlüsselung auch nicht besonders bedrohlich, da Brute-Force-
Angriffe nur eine Verbesserung um eine Quadratwurzel bringen. Ein
128-Bit-Schlüssel kann also mit einem Quantencomputer so gut geknackt
werden wie ein 64-Bit-Schlüssel auf einem vergleichbaren klassischen
Rechner. Bei 256-Bit-Schlüsseln ist dann auch für Quantencomputer
erstmal Schluß.

Es gibt allerdings Ideen, wie man aus Quantencomputern noch mehr
rausholen könnte, sodaß NP in BQP liegt. Ob das aber überhaupt
funktioniert, ist jedoch keineswegs klar.

Hendrik

Volker Birk

unread,
Nov 13, 2004, 5:15:11 PM11/13/04
to
Sebastian Gottschalk <se...@seppig.de> wrote:
> > Twofish-Algorithmus mit 256 Bit Verschlüsselung (Key-Length) und
> > ...
> Kein AES? Mies!

Was an AES ist besser als Twofish?

> > Welchen soll ich nehmen?
> AES. Im Zweifelsfalle Blowfish mit 128 Bit.

Twofish.

> 2^128 ist ziemlich groß. Für einen Quantencomputer von der Größe der Sonne

> @ 100 GHz wären das noch 40000 Jahre Arbeit, allein der Bau eines solchen
> Computers dürfte wohl eher 40 Mio. Jahre dauern.

Na, das sind mal Aussagen *G*

Viele Grüße,
VB.
--
"Es gibt gute Gründe den Netzzugang als erstes auf einen (Screening)
Router zu leiten. Dieser Router schützt (auf seiner Ebene) alles
dahinter - auch Firewalls." - Georg Dingler über den Microsoft ISA Server
auf de.comp.security.misc

Message has been deleted
Message has been deleted

Volker Birk

unread,
Nov 13, 2004, 5:59:00 PM11/13/04
to
Sebastian Gottschalk <se...@seppig.de> wrote:

> Volker Birk wrote:
> > Was an AES ist besser als Twofish?
> Beweisbarkeit gegen bekannte Angriffe.

?

> Eingehendere Analyse.

Naja, Twofish ist auch veröffentlicht. Natürlich ist AES besser unter-
sucht - und AES hat theoretische Schwächen, für Twofish sind AFAIK
keine bekannt.

> >> AES. Im Zweifelsfalle Blowfish mit 128 Bit.
> > Twofish.

> Kann man sehen wie man will. Twofish ist schwerer zu analysieren, für
> Blowfish existiert ein probabilistischer Angriff akademischer Art und Weak
> Keys akademischer Art. Von der Geschwindigkeit her sind beide etwa gleich.
> 128 Bit reichen aber in besagtem Anwendungsfalle mit Sicherheit.

Spricht für Twofish statt Blowfish.

> > Na, das sind mal Aussagen *G*

> Es gibt leider immer noch Leute die sich 128 Bit Keyspace Bruteforce nicht
> vorstellen können.

Naja, man nimmt ja sowieso 256bit Schlüssel für Twofish, auch wenn die
Blockgröße 128bit bleibt.

Einen 256bit Bruteforce kann ich mir mit derzeit vorhandenen Mitteln
schlecht vorstellen.

Message has been deleted

Christian Kahlo

unread,
Nov 13, 2004, 6:20:29 PM11/13/04
to
Sebastian Gottschalk wrote:

>>Twofish-Algorithmus mit 256 Bit Verschlüsselung (Key-Length) und
>>Blowfish-Algorithmus mit 448 Bit Verschlüsselung (Key-Length) anbietet.

> Kein AES? Mies!

Warum mies? Weil AES als Standard propagiert wird?

>>Welchen soll ich nehmen?


> AES. Im Zweifelsfalle Blowfish mit 128 Bit.

Twofish gilt eigentlich als weiter entwickelt ggue. Blowfish.
Was fuehrt Dich zu dieser Aussage?

>>Es gibt immer wieder Gerüchte, dass selbst so hohe Verschlüsselungen für
>>Behörden/Geheimdienste kein Problem zum knacken wäre.

> 2^128 ist ziemlich groß. Für einen Quantencomputer von der Größe der Sonne
> @ 100 GHz wären das noch 40000 Jahre Arbeit, allein der Bau eines solchen
> Computers dürfte wohl eher 40 Mio. Jahre dauern.

Was bringt Dich zu diesen Zahlen?

[ ] Du weisst welche Schwaechen AES besitzt und hast begriffen, dass
AES geradezu dazu einlaedt neue Angriffsmethoden auszuprobieren.
Ich verweise u.a. auf aktuelle Papers zu dem Thema.
AES wurde _genau aus diesem Grund_ als Standard gepusht.
[ ] Du hast die Unterschiede zwischen S-Box Chiffen, Feistelchiffren
und diskreten mathematischen Problemen verstanden.
[ ] Du hast begriffen wo die Unterschiede zwischen Hardware-
Implementierungen und Software-Implementierungen liegen sowie
der Unterschied zwischen einer Implementation nach Spezifikation
und einer Implementation optimiert aus Gesichtspunkten der
(differentiellen) Cryptoanalyse.
[ ] Du hast verstanden warum man genau unterscheidet und auch unter-
scheiden sollte inwiefern Quantencomputer diskrete mathematische
Probleme oder komplexere, nicht trivial physikalisch abbildbare,
Formeln loesen koennen.
[ ] Du weisst, dass Quantencomputer eigentlich keine Taktfrequenz in
dem Sinne besitzen - hoechstens Ihre Interfacelogik nach aussen,
welche aber unabhaengig von der eigentlichen Berechnung ist.
[ ] Du hast mitbekommen, dass man auf dem besten Wege ist Transistoren
und Gatter in der Groessenordnung 100 GHz herzustellen.
[ ] Du kannst abschaetzen, dass die Standard-Implementierung des
Algorithmus in Hardware bei 100 Mrd. Zyklen pro Sekunde Dir nicht
wesentlich weiterhilft.
[ ] Du hast verstanden, dass die auf Cryptoanalyse optimierte Fassung
von AES laengst nicht die oben genannten Ausmasse braucht.
[ ] Du weisst, dass eine z.B. FPGA mit einem Volumen von ungefaehr
1,41 × 10^18 km^3 viel zu lange Kommunikationswege (c angenommen)
hat, um die Zyklen mit 100 GHz zu durchlaufen. Es waeren also
verschraenkte Quanten notwendig welche als Zeitgrenze nur das
Plancksche Wirkungsquantum setzen (quasi der Refreshzyklus des
Universums).
[ ] Du hast Deine eigenen Aussagen ueberdacht und begriffen.

>>Ich kann das nicht glauben wenn man mal die möglichen Kombinationen sieht?!

> Ich kann nicht glauben daß du das mit der Verschlüsselung wirklich ernst
> meinst, wenn man sieht welche Sicherheitslücke du als Newsreader
> verwendest...

Und ich bin die Zahnfee.
*Netiquette nachles*
"Wenn man keine Argumente mehr hat, dann zieht man ueber den
Poster, seinen Newsreader oder sein Betriebssystem her."

Haette ich da jetzt mit tin von meiner SGI posten sollen?

Fuer den OP:

Suche bei Google nach Verschluesselungsprogrammen, dann betrachte
welche Algorithmen ueber die Menge aller Programme am Haeufigsten
implementiert sind. Diese Algorithmen moechtest Du in Deine engere
Auswahl nehmen. Nun suchst Du mit Google nach Papers zur Crypto-
Analyse dieser Algorithmen. Es wird eine Restmenge ueber bleiben
zu der kein weiterer Angriff ausser Brute-Force bekannt ist. Der
Einfachheit halber, um nicht auf die Rundenzeiten und evtl. leakende
Keybits auf Grund minimal unterschiedlichem Zeitverhalten eingehen
zu muessen, empfehle ich einen Algorithmus Deiner Wahl bei mind.
ca. 80% der maximal unterstuetzten Schluessellaenge zu verwenden.

Gruss,
Christian

Christian Kahlo

unread,
Nov 13, 2004, 6:25:31 PM11/13/04
to
Heiko Blank wrote:

> Der Container läßt sich nur mit einer E4 Chipkarte öffnen. Diese Karte

E4 besagt lediglich, dass der Programmcode grob dokumentiert wird und
das irgendjemand grob erklaert hat welche Funktion welche Aufgabe hat.
Welche ITSEC E4 (hoch) evaluierte Karte setzt Du ein?
Welcher Chip? Welches OS? Welche Applikation?
Wie ist die Implementation?
Bei "E4 Chipkarte" fallen mir eine Reihe wirksamer Angriffe ein.

> wiederum verlangt einen 6-stelliges Pin-Code. Wird der PIN Code drei mal
> falsch eingegeben ist die Karte zerstört.

Blah.

> Das sollte doch in Bezug auf "Paßwortsicherheit" ausreichen ;-)

Schwach.

Harald Laabs

unread,
Nov 13, 2004, 6:50:54 PM11/13/04
to
Heiko Blank <spam-s...@gmx.de> schrieb:

Ok, damit ist die Passwortlaenge keine relevante Frage mehr.
Wenn es allerdings doch jemand schafft die Karte zu analysieren sieht
man natuerlich alt aus. Da gab es in den letzten Jahren immer mal
wieder lustige neue Ideen.
Es stellen sich dann aber eine Reihe andere Fragen:
- Was tut man bei kaputter Karte? Nur eine Karte fuer meine Daten waere
ein nicht akzeptabler SPOF, aber das kommt auf den Einzelfall an.
- Wie wird der Key erzeugt? Schlechter PRNG -> unsicher.

Und es bleibt natuerlich dabei das man mit den ueblichen und beliebten
Designfehlern die Sicherheit des Ganzen minimieren kann.

Irgendwo war da noch der Kommentar, dass die Sicherheit Deines
Newsreaders bzw. Rechners ja egal sei, da der Container Deine Daten
ja vor fremdem Zugriff schuetzt: Wenn der Container aktiv ist, ist
das natuerlich sowieso Unfug, aber Du stehts auch bloed da, wenn jemand
die Gelegenheit nutzt entsprechende Systemkomponenten auszutauschen
damit beim naechsten Mal der Key irgendwo gespeichert wird...
Wenn man solchen Aufwand betreibt sollte es ja vermutlich auch einem
gezielten Angriff standhalten - und das tut es nicht wenn Deine
Einstellung dazu wirklich jener Aussage entspricht.

Heiko Blank

unread,
Nov 13, 2004, 6:53:13 PM11/13/04
to
"Christian Kahlo" <use...@empire.weimar.thur.de> schrieb

> Welche ITSEC E4 (hoch) evaluierte Karte setzt Du ein?

Auf der Karte steht "Telesec"

> Welcher Chip?
Weiß ich nicht. Woran erkennt man das?

>Welches OS?
Meinst Du vom PC? Das ist Windows Xp Prof

>Welche Applikation?
Die heißt "BestCrypt7"

> Wie ist die Implementation?
Einfach ;-) Ich habe auf "setup" geklickt.

> Bei "E4 Chipkarte" fallen mir eine Reihe wirksamer Angriffe ein.

Echt? Welche denn?

>> wiederum verlangt einen 6-stelliges Pin-Code. Wird der PIN Code drei mal
>> falsch eingegeben ist die Karte zerstört.
> Blah.

Wieso? Da kann man auch nix mehr mit PUK oder so machen, ist echt ein Fall
für den Mülleimer.

Bernd Eckenfels

unread,
Nov 13, 2004, 6:55:34 PM11/13/04
to
Sebastian Gottschalk <se...@seppig.de> wrote:
> Es gibt leider immer noch Leute die sich 128 Bit Keyspace Bruteforce nicht
> vorstellen können.

Vorstellen im Sinne von den Aufwand beurteilen oder im Sinne von es
unmöglich halten?

Da der berühmte Informationstechnsiche Ansatz einen Energieverbrauch bedingt
der auf der Erde nicht zu leisten ist würde ich mich zur ersten Gruppe
zaehlen und kann mir vorstellen dass es nicht möglich ist.

Gruss
Bernd

Heiko Blank

unread,
Nov 13, 2004, 6:58:36 PM11/13/04
to
"Christian Kahlo" <use...@empire.weimar.thur.de> schrieb
> ...Es wird eine Restmenge ueber bleiben

> zu der kein weiterer Angriff ausser Brute-Force bekannt ist. Der
> Einfachheit halber, um nicht auf die Rundenzeiten und evtl. leakende
> Keybits auf Grund minimal unterschiedlichem Zeitverhalten eingehen
> zu muessen, empfehle ich einen Algorithmus Deiner Wahl ..

Ich frag mal ganz einfach:
Welchen würdest Du denn wählen wenn Du die Wahl zwischen:
a) Twofish-Algorithmus mit 256 Bit oder
b) Blowfish-Algorithmus mit 448 Bit
hättest (sag jetzt bitte nicht keinen von beiden)?
Und warum?


Bernd Eckenfels

unread,
Nov 13, 2004, 7:05:47 PM11/13/04
to
Heiko Blank <spam-s...@gmx.de> wrote:
>> Bei "E4 Chipkarte" fallen mir eine Reihe wirksamer Angriffe ein.
> Echt? Welche denn?

E4 sind ziemlich günstige Implementationen, nicht umsonst fordert das SigG
E5Hoch.

Gruss
Bernd

Volker Birk

unread,
Nov 13, 2004, 7:06:28 PM11/13/04
to
Sebastian Gottschalk <se...@seppig.de> wrote:
> Auch für Twofish gibt es Weak Keys und Memory-Time-Tradeoffs, die schlimmer
> sind als die von AES.

Hast Du da Quellen?

Christian Kahlo

unread,
Nov 13, 2004, 7:10:20 PM11/13/04
to
Heiko Blank wrote:

>>Welche ITSEC E4 (hoch) evaluierte Karte setzt Du ein?
> Auf der Karte steht "Telesec"

Alles klar, war zu vermuten.
Mit hoher Wahrscheinlichkeit TCOS 2.0 Release 2 oder 3.
Public Key Service (also SigG) oder Netkey?
Ist ein stilisierter Schluessel darauf oder nicht?
Ist sie weiss oder blau?
Ist das Layout des Chipmoduls eher rundlich oder eher eckig?

>>Welcher Chip?
> Weiß ich nicht. Woran erkennt man das?

In der Regel am Chipmodul, siehe oben.
SLE66CX160 oder SLE66CX32(0/2)P

>>Welches OS?
> Meinst Du vom PC? Das ist Windows Xp Prof

Von der Karte, es ist TCOS.

>>Welche Applikation?
> Die heißt "BestCrypt7"

Der Begriff "BestCrypt" ist sehr beliebt.
Heisst der Hersteller Jetico? Wenn nein, gibt es eine
URL unter der es mehr Informationen gibt?

>>Wie ist die Implementation?

Ich recherchiere, das taete mich aus aktuellem Anlass
auch interessieren.

>>Bei "E4 Chipkarte" fallen mir eine Reihe wirksamer Angriffe ein.
> Echt? Welche denn?

Fuer TCOS 2.x nur Labor und nur gegen den Chip, das OS ist
gut implementiert. Ich mag es, es hat nur ganz wenige
Bugs und Schwaechen aus meiner Sicht. Haben TCOS2.0.2 selbst
in Tausenderstueckzahlen eingesetzt.

>>>wiederum verlangt einen 6-stelliges Pin-Code. Wird der PIN Code drei mal
>>>falsch eingegeben ist die Karte zerstört.
>>Blah.
> Wieso? Da kann man auch nix mehr mit PUK oder so machen, ist echt ein Fall
> für den Mülleimer.

Nein, TCOS 2.0.x vernichtet die Daten nicht bei abgelaufener
PIN/PUK. D.h. Du wirfst Deine abgelaufene Karte weg und ich
hole mir den Key raus.

TCOS ist gut, die beste Karte der Art am Markt.
Insofern eine vernuenftige Wahl, ich haette es nicht anders getan.

Es gibt besseres, aber deutlich teurer, nicht komptabil zu
Bestcrypt und nicht so einfach zu kriegen.

Gruesse,
Christian

Christian Kahlo

unread,
Nov 13, 2004, 7:13:54 PM11/13/04
to
Bernd Eckenfels wrote:

> E4 sind ziemlich günstige Implementationen, nicht umsonst fordert das SigG
> E5Hoch.

Seit wann?
Ja, E5 wird ueblicher.
Was habe ich verpasst?

Gruesse,
Christian

Carsten Krueger

unread,
Nov 13, 2004, 7:20:15 PM11/13/04
to
"Heiko Blank" <spam-s...@gmx.de> wrote:

>Welchen würdest Du denn wählen wenn Du die Wahl zwischen:
>a) Twofish-Algorithmus mit 256 Bit oder
>b) Blowfish-Algorithmus mit 448 Bit
>hättest (sag jetzt bitte nicht keinen von beiden)?

Twofish weil es der Nachfolge von Blowfish ist und Twofish nur knapp
gegen RIJNDAEL bei der AES-Wahl verloren hat.

Gruß Carsten
--
http://learn.to/quote - richtig zitieren
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://oe-faq.de/ - http://www.oe-tools.de.vu/ - OE im Usenet
http://www.spamgourmet.com/ - Emailadresse(n) gegen Spam

Christian Kahlo

unread,
Nov 13, 2004, 7:33:03 PM11/13/04
to
Carsten Krueger wrote:

>>Welchen würdest Du denn wählen wenn Du die Wahl zwischen:
>>a) Twofish-Algorithmus mit 256 Bit oder
>>b) Blowfish-Algorithmus mit 448 Bit
>>hättest (sag jetzt bitte nicht keinen von beiden)?
> Twofish weil es der Nachfolge von Blowfish ist und Twofish nur knapp
> gegen RIJNDAEL bei der AES-Wahl verloren hat.

Fully ACK.
Twofish fehlte die passende Lobby.
DES ist von Einigen als grosser Fehler in der Geschichte aufgefasst
worden.

Gruesse,
Christian

PS: Hat schonmal jemand eine HBCI-Karte mit RSA Keys
groesser 768 Bit gesehen? Wenn ja, welche Bank,
welche Software und ab welchem Datum?

Richard W. Könning

unread,
Nov 13, 2004, 7:36:02 PM11/13/04
to
Sebastian Gottschalk <se...@seppig.de> wrote:

>Heiko Blank wrote:
>
>> Warum eigentlich AES? Was ist denn an Blowfish bzw Twofish schlecht? Soviel
>> ich weiß hat noch niemand Lücken im Code entdeckt und es wurden beide noch
>> nicht geknackt.
>

>Bei AES lassen sich Resistenzen gegen viele bekannte Angriffe sogar
>beweisen, bei *Fish nur gegen reltiv wenige. Schlecht ist an den anderen
>deshalb nichts, aber AES ist dadurch vertrauensmäßig bessergestellt. Und es
>ist ziemlich effizient.

Andererseits läßt sich AES in relativ geschlossener Form darstellen,
was so manchem Kryptographen (u.a. auch Ferguson und Schneier) ein
gewisses Unwohlsein bereitet. Und ein DJB ist gerade in sci.crypt der
Meinung, viele AES-Implementierungen mehr oder weniger über einen
Timing-Angriff gebrochen zu haben, aber an DJB scheiden sich des
öfteren die Geister ;-).

Die Bewertung von Verschlüsselungsalgorithmen ist letztlich eine
Aus-dem-Bauch-heraus-Entscheidung eines Kryptographen nach Betrachtung
aller relevant erscheinenden Eigenschaften, durchaus vergleichbar mit
der Beurteilung der Attraktivität von Frauen (bei der von Männern ist
es vermutlich auch nicht viel anders).
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München

Message has been deleted
Message has been deleted

Heiko Blank

unread,
Nov 13, 2004, 7:46:02 PM11/13/04
to
"Christian Kahlo" <use...@empire.weimar.thur.de> schrieb

> Public Key Service (also SigG) oder Netkey?
NetKey

> Ist ein stilisierter Schluessel darauf oder nicht?
Ja

> Ist sie weiss oder blau?
weiß

> Ist das Layout des Chipmoduls eher rundlich oder eher eckig?
Hmm, ich würde sagen quadratisch mit abgerundeten Ecken

> Der Begriff "BestCrypt" ist sehr beliebt.
> Heisst der Hersteller Jetico?

Ja, ist Jetico

> Nein, TCOS 2.0.x vernichtet die Daten nicht bei abgelaufener
> PIN/PUK. D.h. Du wirfst Deine abgelaufene Karte weg und ich
> hole mir den Key raus.

Das habe ich aber anders gehört. Wieso benötige ich dann eine ganz neue
Karte und kann die alte nicht mehr verwenden? PUK gibt es nicht.


Message has been deleted
Message has been deleted

Christian Kahlo

unread,
Nov 13, 2004, 7:56:39 PM11/13/04
to
Heiko Blank wrote:

>>Public Key Service (also SigG) oder Netkey?
> NetKey
>>Ist ein stilisierter Schluessel darauf oder nicht?
> Ja
>>Ist sie weiss oder blau?
> weiß
>>Ist das Layout des Chipmoduls eher rundlich oder eher eckig?
> Hmm, ich würde sagen quadratisch mit abgerundeten Ecken

Release 2, ausser sie ist aelter als 3 Jahre.

>>Der Begriff "BestCrypt" ist sehr beliebt.
>>Heisst der Hersteller Jetico?
> Ja, ist Jetico

Hmmm.

>>Nein, TCOS 2.0.x vernichtet die Daten nicht bei abgelaufener
>>PIN/PUK. D.h. Du wirfst Deine abgelaufene Karte weg und ich
>>hole mir den Key raus.
> Das habe ich aber anders gehört.

Was genau hast Du gehoert?
Verhalten ausserhalb der Spec?

> Wieso benötige ich dann eine ganz neue
> Karte und kann die alte nicht mehr verwenden?

Sie verwehrt Dir den Zugriff auf die Daten, ja.
Aber nicht mehr.

> PUK gibt es nicht.

Sollte es auch nicht. Maximal 3DES challenge-response fuer
einen extra key, der das reset- aber nicht das update-Recht
besitzt.

Gruesse,
Christian

Christian Kahlo

unread,
Nov 13, 2004, 8:12:19 PM11/13/04
to
Sebastian Gottschalk wrote:

>>Warum mies? Weil AES als Standard propagiert wird?

> Ja. Ein Kryptosoftware sollte stets auch Standardalgorithmen anbieten.

Auch Standards die vernuenftiger Kryptosoftware/-hardware mangels
Sinnhaftigkeit fehlen sollten?

>>>>Welchen soll ich nehmen?
>>>AES. Im Zweifelsfalle Blowfish mit 128 Bit.
>>Twofish gilt eigentlich als weiter entwickelt ggue. Blowfish.
>>Was fuehrt Dich zu dieser Aussage?

> Blowfish ist etwas schneller. :-)

ACK.

>>Was bringt Dich zu diesen Zahlen?

> Nüchternes Rechnen sowie die Feststellung, daß die Menge der mit qubits
> erheblich schneller lösbaren Probleme nur sehr gering sind.

--verbose

[Widerspruch]

Dann erlaeutere Deine Zahlen und Ansichten bitte genauer.

> [X] Du hast hast den Inhalt der Aussage begriffen.

Informationen weg zu lassen ist kein Grund dem Gegenueber mangelnde
Faehigkeiten der Wahrsagerei als Nachteil zu unterstellen.

> [X] Du erzählst teilweise Unsinn. Quantencomputer haben dank ihrer
> Wellennatur eine zur Größe und Energie der Quantenobjekte äquivalente
> Frequenz.

man Lichtgeschwindigkeit
man Plancksches Wirkungsquantum
man Implementation von Quantencomputern

Magst Du neben der Mathematik nun auch die Physik brechen?
Dann erklaere Deine Ansichten bitte mit Hintergruenden.
Ueber Mathematik und Physik in 40.000 Jahren brauchen wir nicht
zu spekulieren, interessant ist das hier und jetzt bzw. die
naechsten 50 Jahre.

>>*Netiquette nachles*
>>"Wenn man keine Argumente mehr hat, dann zieht man ueber den
>> Poster, seinen Newsreader oder sein Betriebssystem her."

> *Logikbuch nachles*
> (A -> B) -> (B -> A) ist keine Tautologie. Du vertauschst unzulässigerweise
> Prämisse und Konsequenz.

Ich bin mir keiner Schuld bewusst.

> OE ist eine Sicherheitslücke. Verschlüsselung benötigt Schutz des Keys. OE
> zu nutzen läuft diesem Ziel zuwider. Was genau hast du daran nicht
> verstanden?

Ich kann OE benutzen und den Key schuetzen.
Welchen Teil hast Du nicht verstanden?

Bernd Eckenfels

unread,
Nov 13, 2004, 9:21:27 PM11/13/04
to
Christian Kahlo <use...@empire.weimar.thur.de> wrote:
>> E4 sind ziemlich günstige Implementationen, nicht umsonst fordert das SigG
>> E5Hoch.
> Seit wann? Ja, E5 wird ueblicher. Was habe ich verpasst?

Nein, ich hatt nen Off-By-One :) Es ist EAL4 und E3, aber die
Mechanimenstärke muss mich Hoch bewertet werden bei einem hohen
Angriffspotential.

Gruss
Bernd

Christian Kahlo

unread,
Nov 14, 2004, 2:52:38 AM11/14/04
to
Heiko Blank wrote:

>>Der Begriff "BestCrypt" ist sehr beliebt.
>>Heisst der Hersteller Jetico?
> Ja, ist Jetico

Mehr Informationen bitte.
Ich konnte keine Hinweise auf eine TCOS Integration in BestCrypt finden.
Also wer hat das BDK-Modul fuer TCOS gebaut, wo hast Du es her und wo
gibt es mehr Informationen, z.B. URL?

Haettest Du selbst recherchiert, haettest Du dort auch die Antwort
auf Deine Frage gefunden: http://www.jetico.com/plugins.htm
Demnach ist Twofish minimal schneller als Blowfish.

Gruss,
Christian

Juergen P. Meier

unread,
Nov 14, 2004, 4:09:53 AM11/14/04
to
Heiko Blank <spam-s...@gmx.de>:

> Warum eigentlich AES? Was ist denn an Blowfish bzw Twofish schlecht? Soviel
> ich weiß hat noch niemand Lücken im Code entdeckt und es wurden beide noch
> nicht geknackt.

AES ist performanter.

> Ja gerade dann muß ich doch meine Daten sicher machen! Mein PC könnte jetzt

Du musst dein System sicher machen!

> völlig offen und ungeschützt sein (ist er aber nicht) und an die Daten auf
> dem verschlüsselten Container kommt trotzdem niemand ran. Mal abgesehen von
> Datenverlust durch Viren.

Schwachsinn! *SOLANGE* *DU* an diese Daten rankommst, kommt *JEDES*
*ANDERE* Programm, das auf deinem System laeuft, *AUCH* an diese Daten
ran! Inklusive Schadsoftware, Backdoors und Remote-Access Software etc.pp.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"

Message has been deleted

Richard W. Könning

unread,
Nov 14, 2004, 11:25:58 PM11/14/04
to
Sebastian Gottschalk <se...@seppig.de> wrote:

>Richard W. Könning wrote:
>
>> Und ein DJB ist gerade in sci.crypt der
>> Meinung, viele AES-Implementierungen mehr oder weniger über einen
>> Timing-Angriff gebrochen zu haben, aber an DJB scheiden sich des
>> öfteren die Geister ;-).
>

>Timing-Angriffe sind so ziemlich gegen jeden AES-Endkandidaten relativ
>wirkungsvoll. AES/Rindjael dürfte sogar der resistenteste sein.

Timing-Angriffe richten sich nicht gegen Algorithmen, sondern gegen
Implementierungen derselben. Man kann jede Implementierung immun
machen, wenn man zu Beginn einen Timer mit der maximal benötigten Zeit
aufzieht und das Ergebnis erst nach Ablauf des Timers zurückliefert.

>> Die Bewertung von Verschlüsselungsalgorithmen ist letztlich eine
>> Aus-dem-Bauch-heraus-Entscheidung eines Kryptographen nach Betrachtung
>> aller relevant erscheinenden Eigenschaften, durchaus vergleichbar mit
>> der Beurteilung der Attraktivität von Frauen (bei der von Männern ist
>> es vermutlich auch nicht viel anders).
>

>Jein. Wenn man von ordentlicher Beweisbarkeit ausgehen kann, zählt
>eigentlich fast nur noch Geschwindigkeit. Deshalb nutzen wir auch
>heutzutage noch RC4.

Beweisbarkeit von was? Daß ein Algorithmus gegen bestimmte
Angriffsmechanismen beweisbar immun ist? Und wo ist dann der Beweis,
daß es keine anderen, noch unbekannte Angrifsmechanismen gibt?

Richard W. Könning

unread,
Nov 14, 2004, 11:25:58 PM11/14/04
to
Christian Kahlo <use...@empire.weimar.thur.de> wrote:

>[ ] Du weisst, dass eine z.B. FPGA mit einem Volumen von ungefaehr
> 1,41 × 10^18 km^3 viel zu lange Kommunikationswege (c angenommen)
> hat, um die Zyklen mit 100 GHz zu durchlaufen.

Wenn ich richtig gerechnet habe, dann liegt die Masse obigen FPGAs
(unter der Annahme, daß er weit überwiegend aus Silizium besteht)
schon etwas über dem Chandrasekhar-Limit, d.h. wenn er nicht noch
Masse abwirft, dann schrumpft er zu einem schwarzen Loch, was den
Zugriff auf das Ergebnis etwas erschwert ;-).

Lutz Donnerhacke

unread,
Nov 15, 2004, 3:37:24 AM11/15/04
to

Dieser Ansatz funktioniert nur unter der Annahme eines in jedem Schritt
thermodynamisch stabilen Computers. Dieser Computertyp scheint mehr und mehr
der Vergangenheit anzugehören.

Message has been deleted

Christian Kahlo

unread,
Nov 15, 2004, 9:11:26 AM11/15/04
to

Sebastian Gottschalk wrote:

>>>Ja. Ein Kryptosoftware sollte stets auch Standardalgorithmen anbieten.
>>Auch Standards die vernuenftiger Kryptosoftware/-hardware mangels
>>Sinnhaftigkeit fehlen sollten?

> Hm... was hast du gegen AES?

AES wurde gezielt als Kompromiss zwischen Stabilitaet und
Geschwindigkeit gewaehlt. Was bei immer schneller werdenden
Hardware-Implementierungen nahezu unsinnig ist.
Denn das Angriffsrisiko ueberwiegt die Geschwindigkeitsvorteile.
Es war bereits bei der Auswahl von AES klar, das Rijndael dazu
einlaedt u.a. auch neue Angriffe auszuprobieren.

Das "Advanced" in AES bekommt einen herben Beigeschmack in
Richtung "Advanced Key Recovery Methods" anstatt Advanced
Encryption Standard.

>>[Widerspruch]
> ?

Das Formular war nicht zum Ausfuellen gedacht.

>>Dann erlaeutere Deine Zahlen und Ansichten bitte genauer.

> 2^128 / (pi / 6 * ( Größe der Sonne / Abstand zweier Wasserstoffe-Atom in
> einem hochkomprimierten Wasserstoff-Gas, das gerade mal so nicht zur Fusion
> übergeht)^3 * (100 GHz) * 1 Instruction / Atom)

Mich hat nicht interessiert wie lange diese Maschine braucht,
sondern warum sie so gross sein muss und bei (exemplarischen?)
fixen 100 GHz laeuft.

Aber wo Du das schon so schoen aufschreibst, hast Du das mal
ausgerechnet? Faellt Dir was auf?

> Daß du so einen riesigen Computer nur als klassischen Computer und nicht
> als Quantencomputer betreiben kannst sollte wohl auch klar sein.

In dem Posting davor hiess es noch "Für einen Quantencomputer von der
Größe der Sonne".

Was meinst Du nun? Klassischer Computer oder Quantencomputer?
Warum sollte es nicht moeglich sein einen QC mit Hilfe eines
Netzwerks aus verschraenkten Quanten in dieser Groessenordnung
zu bauen?

> Den Rest kann du z.B. bei <http://www.qubit.org/library/introductions.html>
> oder in einem der unzähligen Threads von sci.crypt nachlesen. Z.B. gibt es
> bislang keinen quantenalgorithmischen (geiles Wort :-) Angriff gegen ECC.
> qNP liegt irgendwo zwischen P und NP und ist ziemlich klein. Und nein, es
> gibt sehr viele gute Gründe zur Annahme daß P!=NP gilt.

Jo. Und?

>>Informationen weg zu lassen ist kein Grund dem Gegenueber mangelnde
>>Faehigkeiten der Wahrsagerei als Nachteil zu unterstellen.

> Als Nichtwahrsager wahrsagen zu wollen ist kein Nachteil, sondern
> einfach nur Unsinn. :-)

Ich stelle nur Fragen bzw. Hinterfrage Deine Aussagen weil mich der
Weg zu Diesen interessiert. Jedoch sind die Antworten darauf bisher
nur Bruchstuecke die auch nur widerwillig zusammen passen. Nicht mehr.
Oder meinst Du, dass Du uns grade mit Unsinn veralberst?

>>Dann erklaere Deine Ansichten bitte mit Hintergruenden.

> man Dirac-Wellenlänge

Schoen, die Abbildung eines quantenmechanischen Zustandes auf den
Ortsraum. Wunderbar, damit koennen wir sagen was in dem Quanten-
computer passiert. Weiter?

>>>>*Netiquette nachles*
>>>>"Wenn man keine Argumente mehr hat, dann zieht man ueber den
>>>> Poster, seinen Newsreader oder sein Betriebssystem her."
>>>*Logikbuch nachles*
>>>(A -> B) -> (B -> A) ist keine Tautologie. Du vertauschst unzulässigerweise
>>>Prämisse und Konsequenz.
>>Ich bin mir keiner Schuld bewusst.

> Du bist dir keiner Schuld bewusst, ein ungültiges Argument zu einem
> persönlichen Angriff gegen einen anderen Poster zu verwenden?
> Ich glaube eher genau dies fällt eher unter die Netiquette.

Du sagtest zum OP, dass Du nicht glauben kannst, dass er das mit
der Verschluesselung ernst meint in Anbetracht welche Sicherheits-
luecke er als Newsreader benutzt. Insofern war das ein Angriff auf
seinen Newsreader, ohne seine Frage wirklich richtig zu beantworten.
Auf seine eigentliche Frage bist Du in Deinem Posting nur an einer
Stelle eingegangen und das ist, Verzeihung wenn ich so deutlich
werde, _VOLLKOMMENER BLOEDSINN_ jemandem bei der Auswahl zwischen
Twofish-256 und Blowfish-448, Blowfish-128 zu empfehlen.
Denn der Keysize ist hier nur beim key scheduling entscheidend.
Ist die Entropie einmal drin laeuft das Ding. Insofern wenn man
die Moeglichkeit hat viel Entropie in den Algorithmus zu stecken
und dies unterstuetzt wird, dann sollte man dies auch tun.
Und die Implementation (siehe anderes Posting) gibt mir dabei Recht.

Leute, die dagegen argumentieren ohne klare Aussagen faellen zu
koennen bewegen sich haeufig in der Umgebung von Nachrichtendiensten -
die dann naemlich auf den Allerwertesten fallen weil Sie es nicht
mehr lesen koennen.

>>Ich kann OE benutzen und den Key schuetzen.
>>Welchen Teil hast Du nicht verstanden?

> Den unsichtbaren Teil mit den ungepatchten Lücken, den schlecht gepatchten
> gepatchten Lücken und dem kaputten Programmdesign, das wohl noch viel mehr
> Lücken enthält. Was ist eigentlich aus den MIME-Header-Bugs geworden,
> wurden die irgendwasnn mal gepatcht?

Das ist mir im wesentlichen egal. Du spielst auf die schlechte
Implementierung eines Keystores an.
Aus diesem Grund haette ich von Heiko gern einen Link auf den
Hersteller seines BestCrypt7 Moduls was Ihm das TCOS anbindet.
Um genau diesen Aspekt analysieren und bewerten zu koennen.

Es gibt Implementationen, die davon ausgehen sich den Rechner mit
malizioeser Software teilen zu muessen. Sie sind erstaunlich
widerstandsfaehig. Ein OE ist zwar nicht schoen aber dagegen
immer noch nur eine potentielle Luecke.

Gruss,
Christian

Carsten Krueger

unread,
Nov 15, 2004, 9:48:09 AM11/15/04
to
Christian Kahlo <use...@empire.weimar.thur.de> wrote:

>Oder meinst Du, dass Du uns grade mit Unsinn veralberst?

Selbstverständlich meint er das.

Christian Kahlo

unread,
Nov 15, 2004, 10:13:37 AM11/15/04
to
Carsten Krueger wrote:

>>Oder meinst Du, dass Du uns grade mit Unsinn veralberst?
> Selbstverständlich meint er das.

Ups, vielleicht sollte ich nicht alles so ernst nehmen.
Sorry, die bloede Erkaeltung drueckt mir auf die Stimmung.

Carsten Krueger

unread,
Nov 15, 2004, 12:01:14 PM11/15/04
to
Christian Kahlo <use...@empire.weimar.thur.de> wrote:

>Ups, vielleicht sollte ich nicht alles so ernst nehmen.

Er hält das natürlich für ganz Ernst.

>Sorry, die bloede Erkaeltung drueckt mir auf die Stimmung.

Such dir mal mehr Postings von ihm, das heitert ungemein auf :-)

Message has been deleted

Christian Kahlo

unread,
Nov 15, 2004, 2:17:08 PM11/15/04
to
Sebastian Gottschalk wrote:

[Schnelle Algrotihmen]

Ja, RC4 ist bei extrem hohen Geschwindigkeiten die letzte Wahl.
Allerdings sind Anwendungsfaelle mit 10GBit Verschluesselung sehr
selten. Fuer 155 - 622 MBit/s gibts Chips fuer die populaeren
Algorithmen. Selbst haben wir uns mit 3DES-EDE-CBC @ 800MBit/s
beschaeftigt. Als Nutzlast haetten wir eh nicht wesentlich mehr
ueber den 1GBit PHY drueber pruegeln koennen.
Trotz 10,325 GBps Rocket-IO.

Ausserdem: Es gibt Kunden die fangen an Misstrauen zu hegen wenn
Ver- und Entschluesselung fuer Ihre Vorstellungen "zu schnell"
verlaufen. 10MByte/s wurden mir schonmal als unserioes an den
Kopf geworfen, ich war happy gewesen den 3DES ueberhaupt auf dem
System so fix hin zu kriegen.

[QC]
[End of Discussion, es bringt nichts]

>>Denn der Keysize ist hier nur beim key scheduling entscheidend.

> Bingo. Was ist einfacher zu schützen? 128 Bit oder 448 Bit?

Unerheblich. Wenn Dein Schutzverfahren bei 448 Bit Material nicht
mehr zu gebrauchen ist, solltest Du es auch nicht fur 128 Bit
einsetzen.

>>Es gibt Implementationen, die davon ausgehen sich den Rechner mit
>>malizioeser Software teilen zu muessen. Sie sind erstaunlich
>>widerstandsfaehig.

> Im Falle von Festplattenverschlüsselung landet der Key irgendwann im RAM,

Der Sessionkey fuer den gerade betreffenden Block Daten, ja.
Wir haben das Dateibasiert gemacht, allerdings eine Client-Server
Loesung in der der Client verschluesselt und der Server sich um die
die physikalische Lagerung kuemmert anstatt lokalem Dateisystem -
obwohl man es auch mounten koennte wenn man webDAV als
compatibility-layer dazwischen klemmt.

> oder man liest den Zustand des Ciphers aus. Solange du nicht alles komplett
> auf der SmartCard/dedizierten Hardware erledigst, dann kann das nicht
> sonderlich widerstandsfähig sein.

Cryptohardware am PCI/PCMCIA-Bus ist natuerlich optimal. Leider darf
ich das Stueck Metall offiziell gar nicht haben, also braucht man ueber
breite Anwendung gar nicht zu diskutieren. Bandbreite 50MBit/s am
16-Bit PCMCIA, leider kein CardBus :-(
Das scheint fuer den Desktop-Einsatz jedoch auszureichen. Die Platten
sind zwar u.U. wesentlich schneller, aber das OS schauffelt in der
reellen Anwendung die Daten gar nicht so schnell weg. Direkt aufm
Controller mit RC4 haelt sich der Datenstrom auf ca. 200MBit/s.
Und das ist auch nur nen aufgebohrter ARM7.

Was Smartcards angeht so gibt es durchaus sinnvolle Verfahren solange
die Implementierung sauber ist und nicht "works-for-me".
Ich evaluiere auch grade (kommerzielle) Software fuer Plattenver-
schluesselung.

> Echte BlackBox-Krypto in Software, wie du sie beschreibst, funktioniert
> übrigens beweisbarerweise nicht sicher.

Ich habe in keiner Silbe von puren Software-Implementationen gesprochen.
Den Key kann man zuverlaessig durch Hardware schuetzen.
Und dort gehe ich sogar soweit zu behaupten, dass es besonders fuer die
Zwecke der Datenlagerung zuverlaessige Mechanismen gibt um auch Angriffe
auf die Chipstruktur wertlos zu machen. Das ist allerdings unter NDA.

>>Ein OE ist zwar nicht schoen aber dagegen immer noch nur eine
>>potentielle Luecke.

> Ist dies nun doch ein Eingeständnis, daß OE eine Gefahr für Integrität des
> Keys ist?

Nein, in keiner Weise.
Wobei mir OE wie gesagt egal ist und auf meinem Rechner nichtmal mehr
existiert. Fuer den OP waere entscheidend wie die Implementation seines
Moduls aussieht und inwiefern sein OE und die moeglichen Loecher einen
Angriff auf seine Karte ermoeglichen.
Das taete mich ja auch interessieren, um zu entscheiden ob ich mir das
was Heiko da einsetzt auch mal kaufen sollte.

Gruesse,
Christian

Message has been deleted

Christian Kahlo

unread,
Nov 15, 2004, 3:41:26 PM11/15/04
to
Sebastian Gottschalk wrote:

>>>Echte BlackBox-Krypto in Software, wie du sie beschreibst, funktioniert
>>>übrigens beweisbarerweise nicht sicher.
>>Ich habe in keiner Silbe von puren Software-Implementationen gesprochen.
>>Den Key kann man zuverlaessig durch Hardware schuetzen.

> Ja, und welche? Wir reden doch hier noch über ATA/SCSI-Festplatten in
> non-TCG-x86ern, wie's wohl beim OP und angesichts der benannten Software zu
> erwarten ist? Auch der SmartCard-Reader ändert daran nix, daß die
> Festplattenverschlüsselung selber im RAM erfolgt.

Das habe ich auch gar nicht bestritten.
Es gibt im Wesentlichen 2 Moeglichkeiten:
a) das System des OP, ich reduziere mal meine Systeme auf dasselbe
Niveau. TCG wuerde ich da aber eher als Gegenargument auf Grund
von Key Recovery werten. Man koennte die Keys in einem nicht
dokumentierten Flash ablegen welches locker 1MByte umfassen kann
ohne fuer den Laien erkennbar zu sein.
Und dazu sage ich Dir ganz klar, dass in TCG und auch SecureDigital
Cards (die Nachfolger der MMC Speicherkarten mit DRM und Crypto-
Funktionen) in den Spezifikationen blinde Flecken enthalten sind,
die nicht oder nur extrem schwer zu bekommen sind.
Wir versuchen gerade die Spec fuer einen ganz bestimmten Crypto-
Algorithmus (nicht TCG und nicht SD) zu bekommen, faszinierend wie
dumm die sich stellen - und das ist schon EU, also quasi Staat und
nichtmal privates Wirtschaftskonsortium.

b) Ein System mit PCI/PCMCIA Hardware. Wie hier mehrere Varianten
rumliegen oder ein Firewire-IDE-Controller mit Cryptofunktion
aus eigener Entwicklung.

Fuer a) moechte man Session-Keys pro Datei erzeugen und diese
verschluesseln. Dies macht Sinn da man abgeschlossene Bloecke
definierter Laenge hat zu denen man sich die passende Key-Reference
merken kann. Das funktioniert ganz gut und macht offenbar Sinn.
Aus diesem Grund finde ich Partitionsbasierte- oder Containerbasierte
Festplattenverschluesselungssoftware welche nicht auf der Ebene
von Files und Inodes ansetzen fuer gefaehrlich. Da fuer alles nur
ein Key existiert. Das liefert einerseits jede Menge Material fuer
known-plaintext Attacken (Boot record, Meta Daten, bekannte
(System-)Files) und erzwingt andererseits einen Key fuer Alles im
RAM.
Aus diesem Grund sind 15 Verschluesselungsprogramme im Wert zwischen
0 Euro und 4.500 Euro weggeflogen und ich ueberlege ob ich unser
Client-Server System fuer lokale Dateisysteme und Zielsystem Windows
einsetze. Windows deshalb, da es unter Linux Dank der evolutorischen
Instabilitaet keine Treiber fuer die Hardware gibt die ich gerne
einsetzen moechte und ich mir nicht die Muehe mache potentiell
fuer jedes Major-Release den Treiber anzupassen. Das habe ich einmal
im Falle eines PCMCIA Moduls gemacht - nie wieder. Die Maschine
rennt mit 2.0.38 bzw. jetzt 2.0.40, das muss reichen.

Fuer b) brauchst Du entweder Treiber fuer die Devices, damit der
gesamte Datenstrom vorher durch den Cryptoprozessor geleitet wird
oder das Ganze versteckt sich fertig hinter einem IEEE1394 SBP2
Device. Ersteres ist leistungsmaessig etwas eingeschraenkt, da viel
geschauffelt werden muss, damit geht auch eine merkliche Latenz
einher. Fuer den Desktop Einsatz OK, fuer den Serverbetrieb machbar
aber unangenehm.
Der Firewire-Controller hat ein paar multi-purpose I/Os mit denen
er an einen Cryptocontroller angebunden ist.
Im Wesentlichen bedeutet dies sich zu ueberlegen alle wieviel MByte
man den Key wechseln moechte und wie man die Keys generiert. Ueber
die Adressierung in den SBP2 (Vgl. zu SCSI) Kommandos bei Blocksize
512 Byte kann man dann entscheiden ob man einen neuen Key will oder
nicht.
Der Cryptocontroller leitet vom internen Master-Key den Session-Key
ab, den der ATA-Controller dann ueber seinen Sector-Buffer drueber-
laufen laesst. Die Variante ist richtig fix, da vieles in Hardware
als Coprozessoren implementiert ist.
Mit speziellen Treibern kann man auf die erweiterten Funktionen
zugreifen und dann auch Keys initialisieren, wechseln, den
Cryptocontroller blockieren, freigeben, etc.

>>Wobei mir OE wie gesagt egal ist und auf meinem Rechner nichtmal mehr
>>existiert. Fuer den OP waere entscheidend wie die Implementation seines
>>Moduls aussieht und inwiefern sein OE und die moeglichen Loecher einen
>>Angriff auf seine Karte ermoeglichen.

> Die möglichen Löcher ermöglichen das Einspielen von Malware und damit
> Auslesen des RAMs des x86er, Manipulation der Verschlüsselungssoftware

Klar.

> etc... und ich bezweifle daß man mit einer SmartCard effizient jeden
> einzelnen Key/IV jedes einzelnen Festplattensektors mit einer
> Geschwindigkeit von >10MByte/s berechnen kann, der Master Key für die

Siehe oben. Meist bist Du auf 9600 Baud festgenagelt.
Neuere kannst Du via Protocol Type Selection auf 38400,
57600 oder 115200 hochschrauben. Oder Schlumberger
Cyberflex eGate mit USB1.1 lowspeed Interface on-chip.
Wobei die Schlumberger Hardware aus Austin/Texas stammt.

> Plattenverschlüsselung liegt also mit an Sicherheit grenzender
> Wahrscheinlichkeit im RAM.

NACK. Das ist eine Theorie die nur gilt wenn man das Schlangenoel
vom Markt kauft.

Gruss,
Christian

Richard W. Könning

unread,
Nov 15, 2004, 11:11:29 PM11/15/04
to
Sebastian Gottschalk <se...@seppig.de> wrote:

>Richard W. Könning wrote:
>
>>>Timing-Angriffe sind so ziemlich gegen jeden AES-Endkandidaten relativ
>>>wirkungsvoll. AES/Rindjael dürfte sogar der resistenteste sein.
>>
>> Timing-Angriffe richten sich nicht gegen Algorithmen, sondern gegen
>> Implementierungen derselben. Man kann jede Implementierung immun
>> machen, wenn man zu Beginn einen Timer mit der maximal benötigten Zeit
>> aufzieht und das Ergebnis erst nach Ablauf des Timers zurückliefert.
>

>Und eine einfache timing-angriff-resistene Implementierung des Algorithmus,
>die eben nicht auf benanntes hianusläuft, war eine der Grundanforderungen
>für die AES-Kandidatur.

Nach den Informationen aus sci.crypt scheinen die Ergebnisse deutlich
CPU-abhängig zu sein, was auch nicht weiter verwunderlich ist; es
dürfte also alles andere als trivial sein, eine Implementierung zu
finden, die ohne Timer auf jeder CPU timing-Angriff-resistent ist,
insbesondere für CPUs, die zum Zeitpunkt der Auswahl noch nicht
existierten.

>> Und wo ist dann der Beweis, daß es keine anderen, noch unbekannte
>> Angrifsmechanismen gibt?
>

>Bei OTP trivial, aber im Falle von RSA, ElGamal etc. kann man Äquivalenz zu
>schon sehr lange analysierten Problemen aufzeigen.
>Mit einer vollständigen Lösung kann man wahrscheinlich nicht rechnen, denn
>letztendlich läuft es wohl alles auf P?=NP hinaus, wo es wiederum gute
>Indizien dafür gibt daß es formal unabhängig ist.

Hint: Im OP geht es um symmetrische Verfahren (siehe Subject), da
hilft der Verweis auf asymmetrische Verfahren wenig.

Message has been deleted

Christian Forler

unread,
Nov 15, 2004, 11:35:00 AM11/15/04
to
Lutz Donnerhacke <lu...@iks-jena.de> wrote:

>> Da der berühmte Informationstechnsiche Ansatz einen Energieverbrauch
>> bedingt der auf der Erde nicht zu leisten ist würde ich mich zur
>> ersten Gruppe zaehlen und kann mir vorstellen dass es nicht möglich
>> ist.

> Dieser Ansatz funktioniert nur unter der Annahme eines in jedem
> Schritt thermodynamisch stabilen Computers. Dieser Computertyp
> scheint mehr und mehr der Vergangenheit anzugehören.

Welchem Computertyp gehört die Zukunft?
Es es doch möglich mit Hilfe der Sonnenenergie einen 256-Bitzähler zu
betreiben, der sämtliche Zustände einmal durchläuft?
Braucht man dazu nicht mehr die Energie von mind. 64-Milliarden
(typischen) Supernoven?


lutz -v --please --cite

--
Den Server habe ich nicht konfiguriert. Sonst gäbe es weder Dienste noch
ICMP. -Halunk in dcsm-

Lutz Donnerhacke

unread,
Nov 16, 2004, 8:53:00 AM11/16/04
to
* Christian Forler wrote:
> Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>> Da der berühmte Informationstechnsiche Ansatz einen Energieverbrauch
>
>> Dieser Ansatz funktioniert nur unter der Annahme eines in jedem
>> Schritt thermodynamisch stabilen Computers. Dieser Computertyp
>> scheint mehr und mehr der Vergangenheit anzugehören.
>
> Welchem Computertyp gehört die Zukunft?

Unbekannt.

> Es es doch möglich mit Hilfe der Sonnenenergie einen 256-Bitzähler zu
> betreiben, der sämtliche Zustände einmal durchläuft?

Für einen thermodynamisch stabilen Zähler hinsichtlich der
Zwischenergebnisse reichen die Brennstoffressourcen der Sonne nicht.

Für einen Zähler, der nicht zwischen thermodynamisch stabilen Zuständen
umschaltet (unter Aufwendung von minimal k*T (bei 3K)), sondern zwischen den
Zuständen reversibel schalten kann, entfällt die Argumentationskette aus
Schneier.

Florian Weimer

unread,
Nov 16, 2004, 8:58:10 AM11/16/04
to
* Lutz Donnerhacke:

> Für einen Zähler, der nicht zwischen thermodynamisch stabilen Zuständen
> umschaltet (unter Aufwendung von minimal k*T (bei 3K)), sondern zwischen den
> Zuständen reversibel schalten kann, entfällt die Argumentationskette aus
> Schneier.

Diese Argumentationsweise findet sich nicht nur bei Schneier. Es gibt
auch Leute, die noch immer versuchen, so etwas bei den etablierten
Journalen einzureichen. 8-( Hendrik weiß vielleicht, was daraus
geworden ist.

Lutz Donnerhacke

unread,
Nov 16, 2004, 9:03:20 AM11/16/04
to
* Florian Weimer wrote:
> * Lutz Donnerhacke:
>> Für einen Zähler, der nicht zwischen thermodynamisch stabilen Zuständen
>> umschaltet (unter Aufwendung von minimal k*T (bei 3K)), sondern zwischen den
>> Zuständen reversibel schalten kann, entfällt die Argumentationskette aus
>> Schneier.
>
> Diese Argumentationsweise findet sich nicht nur bei Schneier. Es gibt
> auch Leute, die noch immer versuchen, so etwas bei den etablierten
> Journalen einzureichen. 8-(

Ich habe Jahre gebraucht, bis ich das Argument von Schneier gegen exakt
diese Argumentation von Weimer geistig austauschen konnte.

Richard W. Könning

unread,
Nov 16, 2004, 9:48:54 PM11/16/04
to
Sebastian Gottschalk <se...@seppig.de> wrote:

>Richard W. Könning wrote:
>
>>>Und eine einfache timing-angriff-resistene Implementierung des Algorithmus,
>>>die eben nicht auf benanntes hianusläuft, war eine der Grundanforderungen
>>>für die AES-Kandidatur.
>>
>> Nach den Informationen aus sci.crypt scheinen die Ergebnisse deutlich
>> CPU-abhängig zu sein, was auch nicht weiter verwunderlich ist; es
>> dürfte also alles andere als trivial sein, eine Implementierung zu
>> finden, die ohne Timer auf jeder CPU timing-Angriff-resistent ist,
>> insbesondere für CPUs, die zum Zeitpunkt der Auswahl noch nicht
>> existierten.
>

>Nochmal: Es soll möglichst einfach sein, eine Implementierung auf eine
>_spezifische_ CPU anzupassen. Sowas kann man im Entwurf zum einen für die
>bekannten CPUs als auch für Architekturen generell berücksichtigen.

Ich bezweifle, daß dies in einfacher Weise geht, ich laß mich aber
gerne durch die Nennung einer Referenz vom Gegenteil überzeugen. Ich
vermute eher, daß die Verfahren nicht schon bei unproblematischem
CPU-Verhalten starke Zeitabhängigkeiten zeigen sollten.

Iirc werden die von DJB berichteten Effekte durch das Cache-Verhalten
verursacht. Bei anderen CPUs (insbesondere 8-Bit-CPUs) kommen
Zeit-Abweichungen dadurch herein, daß die Dauer von Shift-Operationen
von der Shift-Länge abhängt.

>> Hint: Im OP geht es um symmetrische Verfahren (siehe Subject), da
>> hilft der Verweis auf asymmetrische Verfahren wenig.
>

>Nun ja, bei AES ist es eine Quasi-Äquivalenz zu einem arithmetischen
>Problem, das als schwierig betrachtet wird und wo jetzt Angriffe für dieses
>airhtmetische Problem gesucht werden (z.B. XSL).

Davon unabhängig können durchaus noch unbekannte Angriffsverfahren
möglich sein; deren Abwesenheit zu beweisen dürfte schwierig sein ;-).

Richard W. Könning

unread,
Nov 16, 2004, 10:32:53 PM11/16/04
to
Sebastian Gottschalk <se...@seppig.de> wrote:

>[X] Du erzählst teilweise Unsinn. Quantencomputer haben dank ihrer
>Wellennatur eine zur Größe und Energie der Quantenobjekte äquivalente
>Frequenz.

Berechne mal die entsprechende Frequenz der Holzperlen eines Abakus
und staune :-).

Message has been deleted

Christian Forler

unread,
Nov 18, 2004, 5:32:00 AM11/18/04
to
Lutz Donnerhacke <lu...@iks-jena.de> wrote:

>> Es es doch möglich mit Hilfe der Sonnenenergie einen 256-Bitzähler
>> zu betreiben, der sämtliche Zustände einmal durchläuft?

> Für einen thermodynamisch stabilen Zähler hinsichtlich der
> Zwischenergebnisse reichen die Brennstoffressourcen der Sonne nicht.

> Für einen Zähler, der nicht zwischen thermodynamisch stabilen
> Zuständen umschaltet (unter Aufwendung von minimal k*T (bei 3K)),
> sondern zwischen den Zuständen reversibel schalten kann, entfällt die
> Argumentationskette aus Schneier.

Stimmt. Aber ein "Perpetuum Mobile 256-Bitzählers" ist IMHO fast schon
so futuristisch wie Konstruktion eienr Energiequelle eines 256-
Bitzählers.

Ausserdem kann man immer noch damit argumentieren, das man 1 Bit nicht
in Nullzeit verändern kann. Wenn man ein Bit in 1 ZE ändert benötigt man
2^256 ZE damit der Zähler sämtliche Zustände einmal annimmt. Selbst wenn
ZE= 2^-100 Sek., benötigt der Zähler immer noch 2^156 Sekunden. Das
sind locker ein paar Eiszeiten.

Wenn man ein Bit doch in Nullzeit ändern kann, dann kann beliebig viele
Bits in Nullzeit verändern und damit wäre man in der Lage sämtliche NP-
Probleme in Nullzeit zu lösen.

--
Der Verstand und die Fähigkeit, ihn zu gebrauchen, sind zwei
verschiedene Gaben. - Franz Grillparzer-

Jochen Maier

unread,
Dec 26, 2004, 12:00:52 PM12/26/04
to
Hallo Sebastian,

Sebastian Gottschalk <se...@seppig.de> wrote:

>Bei AES lassen sich Resistenzen gegen viele bekannte Angriffe sogar
>beweisen, bei *Fish nur gegen reltiv wenige. Schlecht ist an den anderen
>deshalb nichts, aber AES ist dadurch vertrauensmäßig bessergestellt. Und es
>ist ziemlich effizient.

Ich habe auf einem Seminar gehört das effektiv AES mit 128 Bit
effektiv 'nur' ca. 2^100 verschluesselt. Ich hab gerade keinen Link
zur Hand.

Sowas hab ich vom Blowfish noch nicht gehört und ich traue dem im
Moment mehr.

Obwohl natuerlich 2^100 schon recht brauchbar sind ;-)

Jochen

Message has been deleted
0 new messages