Schon klar, aber wir sind halt bei dem Fall es auf einen "USB-Stick" auszulagern.
Beiträge von BeeHaa
-
-
Zitat von "ostkiez"
Du hast das Thema falsch erfasst und hast die Frage, die ich hatte nicht beantwortet.
Warum erzählst du mir Sachen die ich gar nicht wissen will.
Aber so ist das leider in vielen Foren.
Leider muss man sich allzu oft für Frage rechtfertigen. Das habe ich häufig satt.Das gibt es in der Tat. Manchmal fragt man aber auch etwas und weiß nicht genau was.
Du kommst mit deinem Oldtimer-Cabrio und fragst, welchen Helm du dir kaufen solltest, weil das Cabrio noch keine Überrollbügel hat.
Darauf antwortet Peter, daß es mit dem Helm egal wäre, weil wenn du bei einem Überschlag irgendwo mit dem Kopf dran kommst, schützt dich ein Helm nicht vor dem sicheren Genickbruch.Wenn du meinst er hätte das Thema nicht verstanden, meine ich, du kannst kein Auto lenken. Womit mir deine Frage nicht sinnvoller erscheint als dem hilfsbereiten Peter.
-
Zitat von "ostkiez"
Die beste Variante wäre zudem, wenn der private Schlüsseln nicht auf dem System abgelegt würde. Also extern (Karte/USB ect.) und mit einem Kennwort geschützt.
Ich glaub darüber hab ich noch garnicht nachgedacht Wogegen schützt man sich, wenn man den privaten Schlüssel auf einen USB-Stick auslagert?
-
Hi euch
Ich verstehe nicht was jetzt an der ganzen Geschichte kompliziert ist und warum das unkomfortabel ist. Aus der heutigen Sicht ist auch die Disku auf Bugzilla nur zum Schiessen. Zum Facepalmieren, sozusagen.
Zum Thema zurück.Als ich meinen Eltern den PC hingestellt habe, haben die nichtmal den Einschaltknopf gefunden.
Als mein Vater Windows sah, dann wußte er nicht, daß wenn in so einem weißen rechteckigen Feld ein Strich blinkt, man dadrin was eingeben kann.
Als meine Mutter mal wieder ins Netz wollte, hat sie dabei die Tasta bequemer hingestellt und dabei eine Taste gedrückt. Und versuchte in der Windowssuche zu googeln.
Jetzt habe ich selbst gegoogelt und die Leute gesucht die behaupten, wenn die PC-Gehäuse nicht einfacher werden, werden die Leute noch in 10 Jahren keine PCs einschalten können. Wenn die Betriebssysteme nicht einfacher werden, kommt auch in 10 Jahren keiner benutzen. Wenn die Browser nicht besser strukturiert werden, geht auch in 10 Jahren keiner ins Netz.
Was hier im ersten Beitrag gefordert wurde, sind Autos mit welchen die Leute fahren können, ohne einen Führerschein zu machen. D.h. wenn Autos bald nicht einfacher zu bedienen werden, wird auch in 10 Jahren keiner mehr Auto fahren?
Es wird kein PGP in Thunderbird geben. Sie setzen alle auf Kommerz-S/MIME und wir wissen nun warum. Wussten bzw. vermuteten mit großer Sicherheit früher auch schon einige von uns, aber da wurde man wegen sowas noch für einen Alufolienhut-Träger gehalten. Nun ist das alles offiziell.
Wir können froh sein, wenn sie uns keine kaum wahrnehmbaren extra Böcke in die Sources reinhauen. Und ihr wollt, daß sie OpenPGP einbauen und meint das wird dann so sicher wie Kochs Bemühungen seit 1998?
EhrlichEs wird kein OpenPGP in Thunderbird geben. Und selbst wenn dem so wäre, würde ich der Lösung schon aus qualitativer Sicht mind. die ersten 2 Jahre nicht trauen. Oder sie INTEGRIEREN GPG1.x und Enigmail 1.6x direkt in die Soruce. Dann vielleicht.
Vielleicht? Nach Jahren haben wir einen einfachen Bock im Zufallszahlengenerator von GnuPG gefunden. gpg4win hat über 3 Milionen Zeilen Kode (!) Ob da 10 verstreute Zeilen malicious sind kann keine Sau mehr sagen. Das ist einfach nicht mehr überblickbar und besteht dazu auch noch aus einigen schon vorkompilierten Teilen.Einige Vorschläge aus dem ersten Beitrag vergrößern auch die Zahl der Angriffsmöglichkeiten. Ich halte Änderungen die in diese Richtung gehen zwar für kontraproduktiv, aber sowieso auch nur einer rein theoretischen Natur.
Aus der heutigen Sicht der Dinge fällt es schwierig eine derartige Lösung als vertrauenswürdig einzustufen. Weiß jemand wieviele Zeilen Kode Tb 17 hat?
Sonst macht man sich hier Gedanken über die falschen Produkte. Wieviel Zeilen Code hat eine Linux-Distribution? Was ist nochmal die Tage OpenX widerfahren? Was passiert überhaupt in Windows?
"Isn't it like protecting the gate to your town with barbed wire and expensive locks but hiring the Daltons to guard the fence?"
p.s.:
Wenn man Datensicherheit so gestaltet, daß sie auch für Ahnungslose problemlos handhabbar wird, droht das System schnell Gefahr zu laufen seine Kerneigenschaft zu verlieren. -
An mich selbst... Nö, nichts im Spam gewesen. Kam JETZT wieder zurück. Bin raus, als ich es hier schrieb. 12:07 also.
Jetzt kamen sie alle nacheinander an. Mit 11:39, 11:47, 11:54, 11:56. Kann man da irgendwas im Header sehen?
Das passiert ja nicht ständig. Eigentlich eher selten, aber so, daß man sixch an das letzte Mal noch erinnert. Und WENN SCHON, dann nur mit GPG-Mails... -
Thunderbird-Version: 170.3
Betriebssystem + Version: Win7 64
Kontenart (POP / IMAP): POP
Postfachanbieter (z.B. GMX): GMX
SMIME oder PGP: GPG1, Enigmail 1.5 und grad letzte 1.6preHallo
Vorab: Mails landen in Gesendet sauber drin.
Ich hab grad, da ich auf 17.0.3 umgestellt habe, paar Testmails an mich selbst geschickt. Mit "Test xx" Betreffs.
Zuerst mit einem Ulk-jpg namens "Schmiergeld.jpg" Das war vor 20 Minuten. Mail kam nicht an.
Dann eine Testmail ohne Anhang. Kam an.
Dann eine Testmail mit Anhnag (PDF bezüglich eines Polierprodukts). Kam nicht an.
Dann eine Testmail ohne Anhnag. Kam nicht an.Enigmail auf 1.6pre geupdatet. Das gleiche. Kommt nichts mehr an.
Wilder Westen?
-
Ich muß sagen, daß nur Geschäfte die vom Ladengeschäft bzw. Telefongeschäft/Briegeschäft auf Internet umgestiegen sind, HMTL-Mails verschicken.
Wenn ich irgendwelche Brocken selbst bei den großen der jeweiligen Branche bestelle, die aber "erst" mit dem Netz angefangen haben, bekomme ich von denen nur "Reintext". Und ich bin auch immer sehr zufrieden, daß dem so ist.
Andererseits wie Peter schon bemerkt hat, hat das Signieren selbst geschäftlich nur einen Sinn, wenn es rechtskräftig ist. Und da muß man sich auch erst um einige andere Sachen kümmern als um Tb und GnuPG
-
Auf was steht display-charset bei gpg selbst? Nur, mit gpg4win ich nix Ahnung. Wenn man eh Tb/Enigmail fährt, warum nimmt man nicht die 1.xx Version?
Steht für OpenPGP und Tb alles auf UTF-8? Ist das problemloseste.
Autodetect auf universal? -
Und DAS ist mal richtig gru-se-lig
http://code.google.com/p/go/source/br…9/verify.go#128 -
Das ist richtig. Es geht ja nicht um das Design der Zertifikate. Ok, ich hätte eher "das SSL-System" schreiben sollen
-
SSL ist nunmal broken by design.
-
Das Prob ist halt grundsätzlich. Ich weiß nicht welche FIPS-cert und ob überhaupt eine Outlook hat.
OpenPGP/Enigmail funktionieren momentan auch nicht anders.Der Vater des Gedanken ist, daß die Inhalte nur temporär für die Anzeige oder zum Zitieren halt entschlüsselt werden. D.h. es gibt keinen "realen" Ort wo sie entschlüsselt rumliegen. Wenn es den nicht gibt, kann man in Nichts halt schlecht suchen.
Ich würde mir das gelegentlich aber auch wünschen, daß die Lösung sich eben bei verschlüsselten Mails auch beim Suchen dazwischen klinkt und diese für die Suchfunktion temporär entschlüsselt. Dann ist es aber auch sinnvoll, daß die Soft das Password behält
Die Suche wäre zwar trotzdem quälen langsam bei solchen Mails, im Vergleich mit nicht verschlüsselten, aber sie wäre wenigstens eine.
Wenn ich in 200 Verschlüsslten Mails das Ergebnis nach 2min. habe, und in nicht verschlüsselten nach 2s, dann sind die 2min. immernoch besser als kein Ergebnis. Das müßte man wegen der Verschlüsselung in Kauf nehmen.Wenn etwas FIPS oder FURZ cert hat, dann sind das für mich Fähigkeiten der Soft und ihre Voreinstellung. Nicht aber die Unmöglichkeit einer mir besser liegenden Rekonfiguration.
Es freut mich zwar wenn die Entwickler auf ein fIPS hinarbeiten und es auch schaffen, aber da ich hier kein goverment betreibe (das macht meine Frau :D) möchte ich am Ende selbst entscheiden KÖNNEN was ich von dem was ein cert ausmacht, hier auch selbst fahren will.
Idioten entscheiden idiotisch und haben dann das Nachsehen. Eine Soft zu machen die Idoten rigoros vor sich selbst schützt ist aber keine Option. Erstmal nervt man damit nur die Nichtidioten und zweitens bekommen Idioten eh auf einem anderen Weg ihr idiotische Verhalten fortzuführen.
Solche zugeschweißten Lösungen bringen also überhaupt garnichts. Außer gelegentlich forks...
-
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
-
Das ist nicht der Beweis. Der Beweis ist, wen aus "Outlook 2010 sucht übrigens IMHO im S/MIME Mails ganz wunderbar" das imho verschwindet
-
(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 ProblemDas 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
-
Hi
Das wollte ich schon länger mal fragen Erstmal kurz überfliegen.
http://www.schneier.com/paper-pgp.htmlWas 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
-
Ist zwar erledigt, aber Verwertung ist jetzt eh schwer In. Habs ja eh grad OnT kompiliert
GPG 1.4.13 sources sind raus. w32 install auch
ftp://ftp.gnupg.org/gcrypt/binary/Das Dickste wäre vielleicht der Bug (gewesen), daß man sich mit der Aufnahme von technisch kaputten Keys gleich den ganzen Keyring crashen konnte.
http://git.gnupg.org/cgi-bin/gitweb…ABLE-BRANCH-1-4p.s.:
IDEA ist wieder da -
Imho ist eine Theorie. Bestenfalls These...
-
Das hab ich aber sehr klassich verkackt...
GPG1 installiert sich nach c:\Program Files (x86)\ Und so wollte das hier warum auch immer unter Win7sp1 64bit NICHT funktionieren.
Da man für Thunderbird/Enigmail aber keine Umgebunsvariablen braucht, hab ich da auch nicht lange geforscht und den kompletten Installdir nach c:\Program Files\ verschoben. Da wo normalerweise 64bit Anwendungen installiert werden.
Und von DA aus funktioniert 1.4.12 völlig sorgenfrei. Enigmail den Pfad mitgeteilt und fertig.Gegenüber dem Gehacke mit gpg4win bzw. GPG2, falls man es nur für Tb braucht, würde ich eher das als "normal" bezeichnen und gpg2 bzw. eher gpg4win für den Zweifelsfall. Aus der Tb/Enigmail-Sicht, wie gesagt.
Auch selbst kompilierte Versuche (mingw32, -m32) funktionieren genauso problemlos wie das originale Kompilat von gnupg.org.
-
Ich hol dafür mein Denglish raus
Gefühlte 95% der Kryptosoft failen wegen der Implementierung. Selbst GPG hatte einige Stolpersteine zu nehmen. Man erinnert sich an das mistake mit der random number generierung, die nur zufällig einem zufällig vorbeischauenden und kurz interessiertem Progger auffiel.
Koch "traut sich" ja seit Urzeiten noch nichtmal originalerweise die zlib aufzufrischen...
Selbst 2er PGP war weniger gepimpt, sondern mehrere Male schlicht nur zugeflickt.
Neustes Beispiel für sowas waren ja die Abertausenden RSA-Keys aus Mikro- und Minidevices, die waked Keys generierten. Übrigens wegen der random numbers collection.
Deswegen ist für mich eine Implementierung die kein GPG nutzt, theoretisch gesehen, wertlos.
Praktisch gesehen wird das Kauderwelsch, was dabei rauskommt, wahrscheinlich gegen gewöhnliche Kommerz sicher.Im Gründe sind wir aber auch keine Terroristen, Kriminelle oder Geheimdienstmitarbeiter, sondern nutzen das Zeug eher aus Prinzip. Und prinzipiell gesehen ist so eine Implementierung erstmal völlig weaked, bevor sie 1-2 Jahre lang durch die Kryptos in die Mängel genommen wird. Und die interessieren sich ja auch nicht für jeden Pups.
Andererseits ist im Gegensatz zum irgendwohin eingeschobenen AES-Getöse in z.B. WinRAR (wackelte auch schonmal!) die Analyse von public key Verfahren leider nichts was das dritte Semester ernsthaft erledigen kann. Dazu hat es bis jetzt immer nur TOP Namen gebraucht.Ohne den Kode gesehen zu haben: Nutzt die Implementierung auch noch viele/einige Funktionen der Js-Engine, hängt die theoretsiche Sicherheit auch noch vom Browser selbst ab. Da läßt sich von Version zur Versionen des Brwosers - also auch der Js-Engine - einiges versemmeln aka optimieren, wie man auch bereits weiß.
Theoretisch gesehen ist das also alles SEHR SEHR wackelig. Praktisch gesehen wird es wahrscheinlich egal sein