OpenPGP bzw. GnuPG unsicher?

Hi

Das wollte ich schon länger mal fragen Erstmal kurz überfliegen.
http://www.schneier.com/paper-pgp.html

Was heißt das eigentlich? Das heißt, daß wenn man einen komprimierten Anhnag mitverschickt - und 95% der Dateiformate komprimieren die Inhalte (OpenOffice, Ms Office, Jpeg, Tiff/lzw) + komprimierte Archive - GPG broken by design ist oder wie?

Laut dem Papier geht das bis/mit 1.0.6 nicht, weil das schaut es nicht nach, ob es sich zu komprimieren lohnt, sondern tut es immer.

edit:
Ähnlich wäre das dann ohne Anhänge, aber mit sehr kurzem Nachrichtentext. Soweit ich weiß passiert die Überprüfung - ob die Komprimierung lohnenswert ist - auch im Bezug auf die allgemeine Länge der Nachricht.
D.h. ich bin mir grad ebenfalls nicht sicher, ob es unabhängig vom Anhang auch nicht komprimiert wird, wenn ich jemanden nur "Hi, wie läufts?" schreibe.

Nun ist das Papier von 2002. Steinalt also. Trotzdem finde ich nicht wirklich viel darüber in der Scene. Auch diesbezügliche Änderungen in GPG nach 2002 kann ich momentan nicht ausmachen.

Ich sehe da übrigens noch ein sehr großes generelles Problem, das möchte ich aber erst ansprechen, wenn das obige geklärt ist

(Ich werde wahrscheinlich doch wenig Zeiut haben die tage. Mach es also doch gleich mit)
Ah ja. Ich beschreibe hier Probleme die ich als solche vermute. Deswegen frag ich mich ja auch erst durch. Den schuh des ahnungslosen Laien zieh ich mir gerne an. Kein Problem

Das andere wäre GCC selbst. Bzw. der Optimiser. Im Gegensatz zu den Leuten von ICC oder MSVC erscheinen mir einige GGC maintainer leicht stumpfsinnig oder rechthaberisch oder sturr, was Definitionen angeht. MS kann glaub ich bis heute C99 nicht komplett korrekt, was Optimierungen angeht sind sie aber immer ziemlich vorsichtig.

Der Gedankengang fing damit an, daß seit ungefähr GCC 4 Leute angefangen haben sich zu beschweren, einige ihrer overflow checks werden vom Optimiser einfach wegoptimiert. Völlig. Da ist garnichts mehr von da. U.a. fefe hat da mal eine richtige Welle geschoben

Daher haben code auditors schonmal Listen mit unzulässigen cflags für solche Fälle. Oder mit welchen die unbedingt gesetzt werden sollten. Die herauszufinden ist ja nicht schwer. Man sieht direkt, es funktioniert sonst nicht.

Wer disassembliert aber einen crypto code um zu gucken ob das noch wirklich 100% mit den Anweisungen im C Quelltext übereinstimmt? Hat das schonmal das gnupg-project selbst gemacht? Solche Infos hab ich nicht.
Und um den Output eines weaked und eines supoerben RNGs zu vergleichen braucht man direkt crypto highend knowhow und skills.

Ich hab mir Anfang des Monats paar Namen rausgepickt und mich treudoof bei paar wirklich Großen der crypto scene diesbezüglich durchgefragt. Sagen wir mal, sie sind Teil des Top20 Clubs der mit Namen bekannten Kryptoanalytiker. Und ich bekam von jedem Antworten.

Der vorsichtige O-Ton wäre, es liegt im Rahmen des Möglichen und völlig abwegig ist es nicht. D.h. wenn jemand sich GPG mit

-O3 -m32 -march=pentium-m -mtune=core2 -mmmx -mfpmath=both -fivopts -ftree-loop-distribution -minline-all-stringops -fforce-addr -funroll-loops -maccumulate-outgoing-args

kompiliert, weil er meint ein Zahntel Sekunde pro Mail sparen zu können, dann funktioniert das nach Außen wie "nur" mit -O2. Ob aber z.B. das RNG Teil dann in beiden Fällen seine Arbeit 100% so verrichtet wie die Quelltexte es vorgeben, wollte mir keiner von denen garantieren

Das geht nur wenn man das Kompilat disassembliert und vs. Quelltext auditiert. Und das würde nur gelten für die eine genutzte GCC-Version/-Build.
Eine Liste mit kryptogefährlichen Cflags gibt es nicht. Eine Studie darüber kennt man nicht. Einige der Leute fanden das aber garnicht so uninteressant.

Ich wette, Brain Snow weiß es

Das erste Prob läßt sich "umgehen". Man muß nur lesen können

Der Angriff funzt nur, wenn Kompression und MDC aus ist. Enigmail forced das aber eh. Sonst "force-mdc" in der gpg.conf (1.4.x).

Ich fände das aber nicht verkehrt, wenn ins OpenPGP/GnuPG beim detect von Sachen die sich angeblich nicht zu packen lohnt, trotzdem packen, aber auf Kompressionsrate 1 schalten würden.
Bei den Tests hier verkleinert das die meisten bereits komprimierten Formate um Nuancen und vergrößert wenige (7z z.B.) unterhalb 1%. Würde aber trotzdem gegenwirken. Die Zeiten bei zlib compress ratio 1 gegenüber dem Auslassen der Kompression sind marginal.

Das zweite Prob besteht aber, theoretisch. Am schönsten fand ichs bei Peter Gutmann. Wenn man den auf GCC anspricht, dreht er voll auf