Bitte um Kommentare zu GnuPG Key Policy
Marc Haber
schon seit Jahren mache ich mir Gedanken, wie ich vernünftig und auf
sichere Art und Weise GPG verwenden kann.
jetziger Status:
Ich verwende GPG nur, um meine Debian-Packages zu signieren und auf
den Debian-Server zu laden. Hierzu habe ich einen GPG-Key
|pub 1024D/6BBA3C84 2000-02-15 Marc Haber <debian-...@marc-haber.de>
|uid Marc Haber <mh+debian...@zugschlus.de>
|uid Marc Haber <zugs...@debian.org>
|sub 1024g/6E71EEF2 2000-02-15
Dieser Key hat genau eine Signatur auf einer der Mailadressen, und ich
habe mit diesem Key einige andere Keys (<10) signiert. Der secret key
liegt auf meinem Arbeitsplatzrechner im Büro; die Maschine ist im
firmenweiten Backup, und einige wenige vertrauenswürdige Kollegen
haben einen Account auf dieser Kiste.
Ich hätte gerne eine Key-Infrastruktur, die so aussieht:
(1) einen "Master-Key".
- Lagerung offline (CD-RW, weggeschlossen).
- expired nicht.
- Wird zum Signieren anderer Keys verwendet.
- Signaturen anderer Leute kommen auf diesen Key
- Revocation Certificate an anderem sicheren Ort auf Medium und
ausgedruckt.
(2) einen privaten Key
- Lagerung auf einem privaten Rechner, auf dem niemand anders einen
Account hat, und dessen Backups unter meiner persönlichen Kontrolle
liegen.
- Laufzeit sechs Monate
- Wird nur zum Signieren und Verschlüsseln aktueller Kommunikation
verwendet.
- Hat nur die Signatur des Master-Keys
- Revocation Certificate beim Master-Key
(3) einen "geschäftlichen" Key für Signaturen
- Lagerung auf einem geschäftlichen Rechner
- Laufzeit sechs Monate
- Wird nur zum Signieren aktueller Kommunikation verwendet.
- Hat die Signatur meines Master-Keys und zukünftig die Signatur des
Firmen-Master-Keys.
- Revocation Certificate beim Master-Key und beim Chef.
(3) einen "geschäftlichen" Key für Verschlüsselung
- Lagerung auf einem geschäftlichen Rechner
- Laufzeit sechs Monate
- ist zusammen mit der Passphrase versiegelt bei der Geschäftsleitung
hinterlegt.
- Hat die Signatur meines Master-Keys und zukünftig die Signatur des
Firmen-Master-Keys.
- Revocation Certificate beim Master-Key und beim Chef.
Ich frage mich nun:
- Ist diese Policy sinnvoll?
- Was für eine Rolle wird mein existierender Key in dieser Policy
spielen? Taugt dieser Key als Master-Key?
- Welche Parameter verwendet man heute am geschicktesten für die
Schlüsselerzeugung?
- Kann man das Ablaufdatum verlängern? Gilt das dann auch für die
Signaturen, die man mit dem Schlüssel gemacht hat?
- Kann ich verschlüsselte Daten nach Ablauf des Schlüssels noch wieder
entschlüsseln?
- Kann ich bei Schlüsseln Bemerkungen wie "this key is only used to
encrypt. Don't trust signatures done with this key" hinterlegen?
Ich hoffe, dass ich hiermit eine gute Diskussionsgrundlage geliefert
habe und freue mich auf Eure Meinungen.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Rainer Sokoll
[Subject geändert, da es dem OP um etwas anderes ging]
> Marc Haber <mh+use...@zugschlus.de> wrote:
[private key auf einer Multiuser-Kiste]
> IMHO ein böser Fehler. Für wichtige Sache würde ich den Schlüssel nicht
> mehr benutzen (eigentlich würde ich den in so einem Fall gar nicht mehr
> benutzen, um genau zu sein).
Auch, wenn die passphrase ausreichend lang und kompliziert ist?
> > - Was für eine Rolle wird mein existierender Key in dieser Policy
> > spielen? Taugt dieser Key als Master-Key?
>
> Keine und Nein. Da Du nicht weißt wer diesen Key alles hat ist der IMHO
> wertlos. So gut kann keine Passphrase sein das man sich nur darauf als
> Schutz verlassen kann.
Warum nicht?
Gruß,
Rainer
Markus Hippeli
> Thus Carsten Eilers wrote:
> > IMHO ein böser Fehler. Für wichtige Sache würde ich den Schlüssel nicht
> > mehr benutzen (eigentlich würde ich den in so einem Fall gar nicht mehr
> > benutzen, um genau zu sein).
>
> Auch, wenn die passphrase ausreichend lang und kompliziert ist?
Ja.
> > Keine und Nein. Da Du nicht weißt wer diesen Key alles hat ist der IMHO
> > wertlos. So gut kann keine Passphrase sein das man sich nur darauf als
> > Schutz verlassen kann.
>
> Warum nicht?
Weil man einen bekannten Key bruteforcen kann [1] und du aktuell nicht
weisst, ob der private Key noch private ist. Die Kombination Schlüssel +
Key hingegen - also das "Umdrehen" es public Key - ist ungleich schwerer
zu knacken (-> distributed.net, rc5-project da, auch wenn's nicht so
ganz passt). Den private Key unzugänglich für andere aufzubewahren mag
manchen Komfortnachteil bringen, ist aber IMHO für das Konzept von
PGP/GPG unabdingbar.
In dem Moment, wo der private Key anderen leicht zugänglich ist, ist er
prinzipiell nicht mehr vertrauenswürdig - das ist schon aus der Doku zu
PGP eindeutig ableitbar.
Natürlich ist die Frage immer, wie paranoid Du bist - prinzipiell kann
$Spion auch in dein Wohnung einsteigen und die Backup-CD kopieren, ohne
dass Du es merkst - die Ideallösung wäre wohl ein Chip unter der Haut,
der den Key in sich trägt. ;-)
*Leichte* (aber interessante) Lektüre zu dem Thema ist btw z.B. Simon
Singh: Geheime Botschaften - Die Kunst der Verschlüsselung von der
Antike bis in die Zeiten des Internet. Die schwerere kann in dieser NG
denke ich als bekannt vorausgestezt werden.
cu
Markus
[1] auch wenn das FBI dafür offenbar zu faul war, vgl:
http://www.heise.de/newsticker/result.xhtml?url=/newsticker/data/wst-01.
03.02-003/default.shtml&words=PGP
--
PGPkey available via Keyserver or at http://www.hipology.de/markus.asc
Fingerprint : 9AC7 A44E C68F 15F8 7A0B E0E6 284F D0C7 C80D E04D
0190-Dialerfaq: -> <http://www.hipology.de/usenet/dialerfaq>
---ceterum censeo microsoft esse delendam---
Florian Weimer
> [private key auf einer Multiuser-Kiste]
>
>> IMHO ein böser Fehler. Für wichtige Sache würde ich den Schlüssel nicht
>> mehr benutzen (eigentlich würde ich den in so einem Fall gar nicht mehr
>> benutzen, um genau zu sein).
>
> Auch, wenn die passphrase ausreichend lang und kompliziert ist?
Ja. Es gibt kaum Systeme mit ausreichender lokaler Sicherheit.
Florian Weimer
>> - Kann man das Ablaufdatum verlängern? Gilt das dann auch für die
>> Signaturen, die man mit dem Schlüssel gemacht hat?
>
> Das Ablaufdatum des Schlüssels hat ja nichts mit der Signatur zu tun,
> die bleibt weiterhin gültig.
Das ist implementierungsdefiniert. Man weiß also nicht, was der
gegnerische Client macht.
Florian Weimer
> Ich frage mich nun:
> - Ist diese Policy sinnvoll?
Ja. Ein alternatives Modell wäre, die Schlüssel nach der geschätzten
Sicherheit des Einsatzes zu differenzieren.
> - Was für eine Rolle wird mein existierender Key in dieser Policy
> spielen? Taugt dieser Key als Master-Key?
Nein.
> - Kann man das Ablaufdatum verlängern?
Ist implementierungsdefiniert. Mit GnuPG geht es.
> Gilt das dann auch für die Signaturen, die man mit dem Schlüssel
> gemacht hat?
Implementierungsdefiniert. Bei GnuPG AFAIK ja.
> - Kann ich verschlüsselte Daten nach Ablauf des Schlüssels noch
> wieder entschlüsseln?
Ja.
> - Kann ich bei Schlüsseln Bemerkungen wie "this key is only used to
> encrypt. Don't trust signatures done with this key" hinterlegen?
Ja, kann man auch im OpenPGP-Protokoll ausdrücken (Sign Only Keys;
Encrypt Only gibt es aus verständlichen Gründen nur als Subkey).
Marc Haber
>Marc Haber <mh+use...@zugschlus.de> wrote:
>> Dieser Key hat genau eine Signatur auf einer der Mailadressen, und ich
>> habe mit diesem Key einige andere Keys (<10) signiert. Der secret key
>> liegt auf meinem Arbeitsplatzrechner im Büro; die Maschine ist im
>> firmenweiten Backup, und einige wenige vertrauenswürdige Kollegen
>> haben einen Account auf dieser Kiste.
>
>mehr benutzen (eigentlich würde ich den in so einem Fall gar nicht mehr
>benutzen, um genau zu sein).
>nicht weil es ein so schöner Name ist der auch gut als Gegenstück zum
>Public Key paßt. ;-)
Was aber nichts daran ändert, dass ich einen Key brauche, der
zumindest tagsüber auf meinem Arbeitsplatzrechner online sein muss.
Wenn man mutt nutzt und nicht für jede Mail die Passphrase eintippen
möchte, muss nicht nur der Key online, sondern auch die Passphrase im
Speicher sein.
Und auch tagsüber können Kollegen auf meinen Arbeitsplatzrechner
ssh'en.
Ausserdem ist es im Moment wohl nichttrivial, einen neuen Key in den
Debian-Keyring zu bekommen :-(
>> (3) einen "geschäftlichen" Key für Signaturen
>> - Lagerung auf einem geschäftlichen Rechner
>
>Was heißt das genau, d.h. wie viele Leute haben da Zugriff?
Die Kollegen.
>Wie vertrauenswürdig sind die?
Von "würde ihm nicht glauben, wenn er mir den Wochentag erzählt" bis
"hat die PIN meiner EC-Karte" ist da alles dabei.
>Ich würde den Key aif jedem Fall auf eine CD
>packen und die wenn ich sie nicht brauche wegschließen.
Für diesen Key ist "ich brauche ihn nicht" mit "bin nicht im Büro"
gleichzusetzen.
>> - Revocation Certificate beim Master-Key und beim Chef.
>
>Gesplittet, so daß nur beide Teile gemeinsam zur revocation berechtigen
>oder komplett?
Komplett.
>Hat beides Vor- und Nachteile:
>2. Komplett:
> + Das "-" von oben existiert nicht, dafür
> - Chef kann gegen Deinen Willen den Key revoken (gilt auch andersrum,
> macht dann aber wohl weniger Ärger)
So ist es gedacht.
>> (3) einen "geschäftlichen" Key für Verschlüsselung
>> - ist zusammen mit der Passphrase versiegelt bei der Geschäftsleitung
>> hinterlegt.
>
>Sehr sinnvoll.
>
>> - Was für eine Rolle wird mein existierender Key in dieser Policy
>> spielen? Taugt dieser Key als Master-Key?
>
>Keine und Nein. Da Du nicht weißt wer diesen Key alles hat ist der IMHO
>wertlos. So gut kann keine Passphrase sein das man sich nur darauf als
>Schutz verlassen kann.
Dann sind auch beide geschäftlichen Keys nach dem ersten Tag wertlos.
Security muss ein Kompromiss aus Sicherheit und Benutzbarkeit sein,
und dass der Key, den man zum Signieren seiner E-Mail benutzt, auf
einem Rechner liegt, der nicht mit dem Netz verbunden ist, ist IMO
kein akzeptabler Kompromiss.
>> - Welche Parameter verwendet man heute am geschicktesten für die
>> Schlüsselerzeugung?
>
>Die, die die Leute auf der Gegenseite benutzen können. ;-)
>Spaß beiseite: Was nützt Dir die optimalste Einstellung wenn dann die
>Mehrzahl der Kommunikationspartner nichts mit dem Ergebnis anfangen
>kann?
Das ist der Grund für diese Frage.
>Ich benutze immer noch PGP mit RSA weil ein paar Leute mit DH/DSS bis
>vor kurzem nichts anfangen konnten.
Seit dem Ablauf des RSA-Patents ist es doch wieder erwünscht, RSA zu
benutzen, weil DSA nur für einige wenige Schlüssellängen spezifiziert
ist.
Unsere ssh-key-Policy sagt "RSA-Schlüssel mit 2048 bit", und so würde
ich es auch mit den GPG-Keys halten, wenn mir nicht jemand hier sagt,
dass das Blödsinn ist.
>> - Kann man das Ablaufdatum verlängern? Gilt das dann auch für die
>> Signaturen, die man mit dem Schlüssel gemacht hat?
>
>Das Ablaufdatum des Schlüssels hat ja nichts mit der Signatur zu tun,
>die bleibt weiterhin gültig. Im Prinzip kann der Schlüssel auch eine
>unendliche Gültigkeit haben, aber dann mußt Du gut auf das Revocation
>Certificate aufpassen. Sonst kann es passieren das Du den Schlüssel mal
>irgendwann revoken möchtest/mußt aber die Passphrase nicht mehr weißt...
Verstehe.... Wird einem Key ohne Ablaufdatum in der Regel weniger
trust entgegen gebracht als einem Key mit?
>> - Kann ich bei Schlüsseln Bemerkungen wie "this key is only used to
>> encrypt. Don't trust signatures done with this key" hinterlegen?
>
>Ich habe sowas bei meinen PGP-Schlüsseln immer mit ins Namensfeld
>geschrieben.
|<mh+gpg-key-only...@zugschlus.de> Marc Haber (Don't trust signatures done with this key)
So etwa?
Marc Haber
>Marc Haber <mh+use...@zugschlus.de> writes:
>> Ich frage mich nun:
>> - Ist diese Policy sinnvoll?
>
>Ja. Ein alternatives Modell wäre, die Schlüssel nach der geschätzten
>Sicherheit des Einsatzes zu differenzieren.
--verbose bitte.
>> - Kann ich bei Schlüsseln Bemerkungen wie "this key is only used to
>> encrypt. Don't trust signatures done with this key" hinterlegen?
>
>Ja, kann man auch im OpenPGP-Protokoll ausdrücken (Sign Only Keys;
>Encrypt Only gibt es aus verständlichen Gründen nur als Subkey).
Sind die mit so einem Key erzeugten Nachrichten kompatibel mit älteren
PGP-Versionen?
Marc Haber
>Den private Key unzugänglich für andere aufzubewahren mag
>manchen Komfortnachteil bringen, ist aber IMHO für das Konzept von
>PGP/GPG unabdingbar.
Komfortnachteil halte ich für dezent übertrieben. Es macht die
Benutzung unmöglich.
Markus Schaaf
> Unsere ssh-key-Policy sagt "RSA-Schlüssel mit 2048 bit", und so würde
> ich es auch mit den GPG-Keys halten, wenn mir nicht jemand hier sagt,
> dass das Blödsinn ist.
Blödsinn im Sinne von "unnötig sicher"? Das halte ich wiederum
für Blödsinn. Das einzige, was die Schlüssellänge nach oben
begrenzt, ist sinnvolle Benutzbarkeit. Dabei sind Desktopsysteme
eher unkritisch, wegen ausreichender Rechenpower; also kannst Du
den Masterkey ruhig groß wählen. Etwas schauen muß man im Mobil-
bereich und bei Chipkarten. Wobei selbst da 2048 Bit RSA wohl
inzwischen machbar sind.
Noch kurz zu den Signaturen: Auch wenn man es anders handhaben
kann: Die werden mit dem Schlüssel ungültig. Revoken heißt
nunmal, daß man dem Schlüssel nicht mehr trauen soll. Wenn man
was anderes meint, darf man eben nicht revoken, sondern nur
einen Kommentar am Schlüssel anbringen, daß es einen neuen gibt.
MfG
Florian Weimer
>> > Das Ablaufdatum des Schlüssels hat ja nichts mit der Signatur zu
>> > tun, die bleibt weiterhin gültig.
>>
>> Das ist implementierungsdefiniert. Man weiß also nicht, was der
>> gegnerische Client macht.
>
> Die Ausgabe wird aber immer darauf hinauslaufen das die Signatur gültig
> ist (sollte sie IMHO zumindest).
Das ist nicht klar. Wozu sonst läßt man seine Schlüssel ablaufen, wenn
sie nicht ungültig werden sollen?
> Ein Zusatz wie "Schlüssel ist abgelaufen" ist dann vom jeweiligen
> Benutzer zu interpretieren. Sollte die Ausgabe aber nur lauten
> "Schlüssel ungültig" ist das IMO eine ziemlich dämliche Meldung. Die
> wäre dann M$-reif. ;-)
Nein, aber der umgekehrte Ansatz (das Ignorieren des Verfallsdatums)
ist auch nicht besser. Abgesehen werden Signaturen von Marc auch
automatisch verarbeitet werden.
Florian Weimer
>>Ja. Ein alternatives Modell wäre, die Schlüssel nach der geschätzten
>>Sicherheit des Einsatzes zu differenzieren.
>
> --verbose bitte.
Du hast neben dem Zertifizierungsschlüssel zwei weitere Schlüssel:
Einen, den Du auf Multiuser-Systemen speicherst, und einen den Du
irgendwo gesichert aufbewahrst (i.d.R. auf einem Rechner, auf den man
nicht so leicht remote draufkommt, oder auf Smartcard). Der Absender
kann dann wählen, ob er lieber die erhöhte Sicherheit benötigt und die
längere Bearbeitungszeit in Kauf nimmt oder nicht.
>>Ja, kann man auch im OpenPGP-Protokoll ausdrücken (Sign Only Keys;
>>Encrypt Only gibt es aus verständlichen Gründen nur als Subkey).
>
> Sind die mit so einem Key erzeugten Nachrichten kompatibel mit älteren
> PGP-Versionen?
Welche PGP-Versionen meinst Du?
Florian Weimer
> Noch kurz zu den Signaturen: Auch wenn man es anders handhaben
> kann: Die werden mit dem Schlüssel ungültig. Revoken heißt
> nunmal, daß man dem Schlüssel nicht mehr trauen soll.
Nicht zwangsläufig. Das kommt auf den Grund an.
> Wenn man was anderes meint, darf man eben nicht revoken, sondern nur
> einen Kommentar am Schlüssel anbringen, daß es einen neuen gibt.
Das ist der Stand von PGP 2.x, die Entwicklung geht aber weiter. ;-)
Florian Weimer
> markus...@gmx.de (Markus Hippeli) wrote:
>>Den private Key unzugänglich für andere aufzubewahren mag
>>manchen Komfortnachteil bringen, ist aber IMHO für das Konzept von
>>PGP/GPG unabdingbar.
>
> Komfortnachteil halte ich für dezent übertrieben. Es macht die
> Benutzung unmöglich.
In absehbarer Zeit wird GnuPG Smartcards unterstützten...
Bis dahin ist es in der Tat sehr schwierig, die Forderung zu erfüllen,
insbeonsdere im Firmenumfeld.
Marc Haber
>Marc Haber <mh+use...@zugschlus.de> writes:
>> markus...@gmx.de (Markus Hippeli) wrote:
>>>Den private Key unzugänglich für andere aufzubewahren mag
>>>manchen Komfortnachteil bringen, ist aber IMHO für das Konzept von
>>>PGP/GPG unabdingbar.
>>
>> Komfortnachteil halte ich für dezent übertrieben. Es macht die
>> Benutzung unmöglich.
>
>In absehbarer Zeit wird GnuPG Smartcards unterstützten...
Und so lange die Smartcard im Leser steckt, können auch diejenigen,
die remote auf meinem Arbeitsplatzrechner eingelogged sind, meinen Key
sehen. Sowas bringt nur was, wenn die gesamte Kryptografie auf der
Karte abläuft.
Markus Schaaf
> "Markus Schaaf" <m.schaaf.ex...@gmx.net> writes:
>
> > Noch kurz zu den Signaturen: Auch wenn man es anders handhaben
> > kann: Die werden mit dem Schlüssel ungültig. Revoken heißt
> > nunmal, daß man dem Schlüssel nicht mehr trauen soll.
>
> Nicht zwangsläufig. Das kommt auf den Grund an.
Nun mal ehrlich: Wer möchte denn ernsthaft endlos gültige
Signaturen erstellen? Gerade die Natur einer elektronischen
Unterschrift erfordert doch eine Begrenzung der Gültigkeit.
Selbst Zeitstempel verschieben das Problem nur auf eine
dritte Instanz.
Florian Weimer
>>In absehbarer Zeit wird GnuPG Smartcards unterstützten...
>
> Und so lange die Smartcard im Leser steckt, können auch diejenigen,
> die remote auf meinem Arbeitsplatzrechner eingelogged sind, meinen Key
> sehen. Sowas bringt nur was, wenn die gesamte Kryptografie auf der
> Karte abläuft.
Klar, das wird unterstützt werden. Mit Floppies kann GnuPG schließlich
schon heute umgehen.
Bernd Eckenfels
>> Noch kurz zu den Signaturen: Auch wenn man es anders handhaben
>> nunmal, da? man dem Schl?ssel nicht mehr trauen soll.
> Nicht zwangsl?ufig. Das kommt auf den Grund an.
Eigentlich ist es einfach. Bis zum revoken sind alle Unterschriften gültig,
sonst kann ich mich auf diese ja nicht verlassen. Das PRoblem bei der Sache
ist, einer Signatur anzusehen wann sie erstellt wurde. Das Problem hat aber
auch das SigG nicht begriffen.
Problem ist natuerlich, dass die annahme, dass eine Signatur gueltig ist die
vor dem Revoken erzeugt wurde schraenkt natuerlich die Freiheiten des
Schluiesselbesitzers ein, aber wenn der Schluesselbesitzer diese Freiheit
gelten machen will, so ist seine Unterschrift fuer Abstreitbarkeit nichts
wert.
Gruss
Bernd
Alexander Schreiber
>rechung auf der Smartcard laufen damit der Secret Key diese gar nicht
>verlassen muß.
ACK. Wenn die Smartcard nur als dummer Behaelter fuer den Key genutzt
wird dann kann man auch billiger mit Disketten hantieren. Sinnvoll waere
es, die Verschluesselung des Sessionkeys auf die Smartcard auszulagern,
damit, wie Du schon schriebst, der Key die Smartcard gar nicht erst
verlaesst.
> Eine Floppy hat da beim Berechnen doch einige Schwierig-
>keiten, so intelligente Floppylaufwerke gibt es noch nicht. ;-)
Gibt es - oder gab es. Beim KC85/4 steckte in der Disketteneinheit etwas
mehr CPU-Leistung als in der Basiseinheit. Trotzdem moechte man den U880
nicht unbedingt mit aktueller Kryptographie belasten, das koennte etwas
dauern ;-)
In den Floppyeinheiten des C64 steckte AFAIK ebenfalls eine vollwertige
CPU, die von manchem Programmierer als Zweit-CPU mit herangezogen wurde.
Und man koennte durchaus - z.B. auf Grundlage der bekannten Smartmedia-
Floppyadapter - eine "rechnende Diskette" bauen ;-)
Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
---------------------------------------------------------------------------
Derzeit auf Jobsuche: http://www-user.tu-chemnitz.de/~als/cv.html
Markus Schaaf
> Markus Schaaf <m.schaaf.ex...@gmx.net> wrote:
>
> > Nun mal ehrlich: Wer möchte denn ernsthaft endlos gültige
> > Signaturen erstellen?
>
> Du hast noch nie im Leben irgend etwas unterschrieben?
Falsche Frage. Etwa so: Wenn mir jemand in --sagen wir-- 20 Jahren
eine Signatur, die ich angeblich dieses Jahr erstellt haben soll,
zeigt, wird mich das einen feuchten Kehricht interessieren. Mit
einer Unterschrift "Stift auf Papier" übrigens ähnlich: Ich werde
mir das Dokument ansehen und dann erst eine Gültigkeitserklärung
abgeben. Die Zeit relativiert alles etwas. So wie man den
elektronischen Schlüssel über die Jahre wechseln wird, ändert sich
meine händische Unterschrift übrigens auch hinreichend, als das
einem Nicht-Handschriftexperten bei Vergleich selbiger von vor 10
Jahren mit der jetzigen nicht Zweifel kämen.
Auch amtliche Dokumente haben ein Verfallsdatum. Und bei Sachen,
die "für die Ewigkeit" gelten, bedarf es einer Person/Institution,
die den Vertrag/was-weiß-ich im Zweifel bestätigt.
Und um Deine Frage zu beantworten: Ich glaube nicht, schonmal eine
Unterschrift geleistet zu haben, die --für sich allein genommen--
irgendwas bestätigt hat, das länger als ca. 6 Monate von Belang war.
> > Gerade die Natur einer elektronischen
> > Unterschrift erfordert doch eine Begrenzung der Gültigkeit.
>
> Wieso?
Weil eine gefälschte nicht zu erkennen ist. Und für welchen
Zeitraum möchtest Du für heutige Kryptographie die Hand ins Feuer
legen? Außerdem ist für wichtige Dokumente, die auch in vielen
Jahren noch Bedeutung haben werden, eine solche Signatur sowieso
unzureichend. Ein mögliches Szenario ist es dann, diese Bestätigung
eben regelmäßig zu erneuern. Dabei halte ich es für sinnvoll, den
Termin der möglicherweise notwendigen Erneuerung im Vorfeld
festzulegen.
Elektronische Unterschrift hebt elektronische Kommukation erstmal
nur auf die Vertrauensebene von Papier, mehr nicht. Ich halte sie
für geeignet, um Kommunikationskanäle zu sichern, nicht, um
langfristige Beglaubigungen abzugeben. Und für ersteres braucht
man Gültigkeiten von Wochen, nicht Jahren. Daß ich den Schlüssel
länger gelten lasse, dient nur dem Komfort.
Rainer Sokoll
> Florian Weimer <f...@deneb.enyo.de> wrote:
> > Klar, das wird unterstützt werden. Mit Floppies kann GnuPG schließlich
> > schon heute umgehen.
>
> Das ist nicht ganz das was gemeint ist. Wenn, dann muß die gesamte Be-
> rechung auf der Smartcard laufen damit der Secret Key diese gar nicht
> verlassen muß.
Momang, das geht mir zu schnell.
Der Key /muß/ doch sein Speichermedium verlassen, um von Gnupg gelesen
werden zu können?! Oder würde Gnupg direkt mit der Smartcard reden?
Angenommen, letzteres ist der Fall: Da ich die Karte "am Mann" haben
sollte - wie ginge das, wenn ich remote auf genau dem Rechner eingeloogt
bin, der mir mein Gnupg zu Verfügung stellt? Auf unixoiden Systemen mag
es technisch möglich sein, im Userspace auch remote Filesysteme zu
mounten; es wäre dennoch unzumutbar. Auf anderen Systemen hätte man wohl
von vornherein verloren.
Rainer
Rolf Kutz
> Thus Carsten Eilers wrote:
>
> Momang, das geht mir zu schnell.
> Der Key /muß/ doch sein Speichermedium verlassen, um von Gnupg gelesen
> werden zu können?! Oder würde Gnupg direkt mit der Smartcard reden?
> Angenommen, letzteres ist der Fall: Da ich die Karte "am Mann" haben
> sollte - wie ginge das, wenn ich remote auf genau dem Rechner eingeloogt
> bin, der mir mein Gnupg zu Verfügung stellt? Auf unixoiden Systemen mag
> es technisch möglich sein, im Userspace auch remote Filesysteme zu
> mounten; es wäre dennoch unzumutbar. Auf anderen Systemen hätte man wohl
> von vornherein verloren.
Die Smartcard rechnet mit eigenem Prozessor. Der
Key verläßt also die Karte nie. Die Karte muß
dabei vermutlich nur den symetrischen Key
asymetrisch verschlüsseln.
--
Rolf
Florian Weimer
> Der Key /muß/ doch sein Speichermedium verlassen, um von Gnupg gelesen
> werden zu können?!
Ja, aber das ist nicht nötig. Offenbar sind die Formate auf unterster
Ebene hinreichend kompatibel zu S/MIME.
> Oder würde Gnupg direkt mit der Smartcard reden?
Ja, die S/MIME-Version verwendet bereits einen Dämon, der mit
der Smartcard kommuniziert (über die OpenSC-Bibliothek) und dort
Krypto-Operationen anstößt.
> Angenommen, letzteres ist der Fall: Da ich die Karte "am Mann" haben
> sollte - wie ginge das, wenn ich remote auf genau dem Rechner eingeloogt
> bin, der mir mein Gnupg zu Verfügung stellt?
So wie Agent Forwarding bei SSH könnte man das z.B. realisieren. Die
Frage des vertrauenswürdigen Terminals bleibt natürlich bestehen.
Markus Hippeli
> Und um Deine Frage zu beantworten: Ich glaube nicht, schonmal eine
> Unterschrift geleistet zu haben, die --für sich allein genommen--
> irgendwas bestätigt hat, das länger als ca. 6 Monate von Belang war.
- Mietvertrag
- Pass / Personalausweis (ok, da gibts auch ein Foto)
- Arbeitsvertrag
- Bausparvertrag
- Lebensversicherung
- Auto- / Motorradversicherung
- Steuererklärung
- Führerschein (auch mit Foto)
- Kreditkarte
- Krankenkassenkarte
- Darlehensvertrag
...
cu
Markus
Markus Schaaf
> Markus Schaaf <m.schaaf.ex...@gmx.net> wrote:
> > Falsche Frage. Etwa so: Wenn mir jemand in --sagen wir-- 20 Jahren
> > eine Signatur, die ich angeblich dieses Jahr erstellt haben soll,
> > zeigt, wird mich das einen feuchten Kehricht interessieren. Mit
> > einer Unterschrift "Stift auf Papier" übrigens ähnlich: Ich werde
> > mir das Dokument ansehen und dann erst eine Gültigkeitserklärung
> > abgeben. Die Zeit relativiert alles etwas.
>
> Das spricht aber nicht gegen eine unbeschränkte Gültigkeit. Im
> Zweifellsfall ist es egal ob geklagt wird weil die Signatur zwar
> gültig ist, Du aber die Gültigkeit abstreitest oder ob die Signatur
> abgelaufen ist, der Gegner aber die Gültigkeit behauptet.
Tja siehst Du, mein Leben besteht aber nicht aus Streitigkeiten
mit Gegnern, sondern aus Kommunikation mit Partnern. Und die lasse
ich nicht im Unklaren darüber, worauf sie sich verlassen können
und worauf nicht.
> > Auch amtliche Dokumente haben ein Verfallsdatum. Und bei Sachen,
> > die "für die Ewigkeit" gelten, bedarf es einer Person/Institution,
> > die den Vertrag/was-weiß-ich im Zweifel bestätigt.
>
> Das ist prinzipiell erstmal unabhängig vom verwendeten Speichermaterial,
Das ist egal. Ich wollte aufzeigen, daß schon das nackte Papier
geduldig ist. Also kann die digitale Variante nicht wertvoller sein.
> > Und um Deine Frage zu beantworten: Ich glaube nicht, schonmal eine
> > Unterschrift geleistet zu haben, die --für sich allein genommen--
> > irgendwas bestätigt hat, das länger als ca. 6 Monate von Belang war.
>
> Mietvertrag, Arbeitsvertrag, ... ;-)
Die Unterschrift allein bewirkt und beweist nicht viel. Für die
Verbindlichkeit bestimmter Regelungen sind andere Faktoren
entscheidend. Deswegen werden solche Verträge auch immer irgendwie
von natürlichen Personen abgemacht.
> > Weil eine gefälschte nicht zu erkennen ist.
>
> Das gilt für alle guten Fälschungen, egal was es ist. Auch eine hand-
> schriftliche Unterschrift läßt sich exakt fälschen, ebenso Siegel etc.,
> daß ist alles nur eine Frage des betriebenen Aufwandes.
Nein. Im analogen Leben gibt es nicht schwarz und weiß, sondern
verschiedene Grautöne.
> Schon heute ist es unmöglich zu beweisen etwas nicht signiert zu haben
> wenn die Signatur korrekt ist.
Und? Wen interessiert das? Darum geht es nicht. Es geht um Vertrauen
und Anschein.
> Das hat nichts damit zu tun wie lange
> die Verfahren sicher sind.
Oh doch. Mein Vertrauen zu einer Signatur von einem 20 Jahre alten
Schlüssel ist nahe Null. Im Gegensatz zu der eines frischen. Das
liegt nicht unbedingt daran, daß die Mathematik in zwanzig Jahren
soweit voran sein wird, sondern daß man Rechenleistung durch Zeit
ersetzen kann. Und, daß die Benutzung eines Schlüssels das Risiko
der Kompromittierung zwangsläufig erhöht.
> Mit der Pistole an der Stirn signierst Du
> alles was man Dir vorlegt. Gilt analog auch für handschriftliche Unter-
> schriften
Du schweifst ins Lächerliche ab.
> Das wirft aber das Problem auf was passiert wenn Du einfach sagst "Nö,
> das signiere ich nicht neu!". Was dann?
Das kann Dir jeden Tag passieren, wenn Dein Partner den Schlüssel
revoken muß, weil er kompromittiert wurde. Versteh' doch einfach:
Mit einer digitalen Unterschrift kann man nichts beweisen. Sie
ist nur ein Mittel sicherer Kommunikation. Speziell kann sie nicht
Vertrauen ersetzen.
> Und dann hast Du das gleiche Problem das Du mit der Begrenzung der
> Gültigkeit umgehen wolltest in Grün.
Ich habe kein Problem.
MfG
Marc Haber
>Marc Haber <mh+use...@zugschlus.de> wrote:
>> Was aber nichts daran ändert, dass ich einen Key brauche, der
>> zumindest tagsüber auf meinem Arbeitsplatzrechner online sein muss.
>> Wenn man mutt nutzt und nicht für jede Mail die Passphrase eintippen
>> möchte, muss nicht nur der Key online, sondern auch die Passphrase im
>> Speicher sein.
>
>brauchbare Sicherheit haben willst.
Ich will einen Kompromiss aus Sicherheit und Machbarkeit.
>Ein Zwischending wäre ein verschlüsseltes Device auf dem der Secret
>Key gespeichert ist (habe ich eine Zeitlang mit PGP-Disk gelöst), aber
>dann mußt Du das für jeden Zugriff auf den Key freigeben. Du hast dann
>also im Prinzip 2 Passphrases einzugeben.
*yuck*
und da wundert sich jemand, dass so gut wie niemand PGP wirklich
einsetzt?
>> Und auch tagsüber können Kollegen auf meinen Arbeitsplatzrechner
>> ssh'en.
>
>Dann hat da per definitionem ein Secret Key nichts darauf verloren. ;-)
>Das die Realität anders aussieht (aussehen muß) steht auf einem anderen
>Blatt.
Du sagst es. Und ich versuche hier gerade mir ein Bild darüber zu
machen, welche Kompromisse sinnvoll erscheinen und welche nicht.
>Aber da es ja in dem Fall nur den einen, im Prinzip ja "zweckgebundenen"
>Schlüssel betrifft spricht doch nichts dagegen ihn ausschließlich für
>diesen Zweck weiter zu benutzen, oder?
Ich müsste für zwei Keys Signatures sammeln.
>> >Wie vertrauenswürdig sind die?
>>
>> Von "würde ihm nicht glauben, wenn er mir den Wochentag erzählt" bis
>> "hat die PIN meiner EC-Karte" ist da alles dabei.
>
>Dann hat der Key nichts auf diesem Rechner zu suchen. Ich weiß das
>Dir das nichts hilft, aber wenn es Sicher sein soll geht es nicht
>anders.
Es soll sicher und machbar sein. Beides zusammen maximal geht nicht.
>> >Ich würde den Key auf jedem Fall auf eine CD
>> >packen und die wenn ich sie nicht brauche wegschließen.
>>
>> Für diesen Key ist "ich brauche ihn nicht" mit "bin nicht im Büro"
>> gleichzusetzen.
>
>Macht immer noch ca. 12 Stunden pro Tag die die CD im Tresor liegt. :-)
Du weisst nicht, wie viel ich arbeite. Ausserdem könnte ich mich dann
nicht von daheim rein-ssh'en und Mails bearbeiten.
>> >> [Revocation Certificate komplett beim Chef]
>> >
>> >Hat beides Vor- und Nachteile:
>> >2. Komplett:
>> > + Das "-" von oben existiert nicht, dafür
>> > - Chef kann gegen Deinen Willen den Key revoken (gilt auch andersrum,
>> > macht dann aber wohl weniger Ärger)
>>
>> So ist es gedacht.
>
>Ist problemlos solange der Chef Dich nicht ärgern will. Wenn doch dürfte
>ein gegen Deinen Willen gesperrter Schlüssel sowies eines der geringeren
>Probleme sein. :-)
Du sagst es. Ausserdem wäre es dann nur ein gegen meinen Willen
gesperrter "offizieller" Schlüsse, und die Firma schiesst sich ggf.
selbst in den Fuss. Die privaten Kommunikationsbeziehungen bleiben
unbeeinflusst.
>> Dann sind auch beide geschäftlichen Keys nach dem ersten Tag wertlos.
>
>Sieht so aus.
Dann brauche ich ja gar nicht erst mit PGP anzufangen, es ist ja eh
unsicher.
>Es verlangt ja keiner das der Rechner nicht mit dem Netz verbunden ist.
>Es ist ein Unterschied zwischen "mit dem Netz verbunden" und "andere
>haben Zugriff". Wenn ein Secret Key auf einem Rechner gespeichert ist
>sollten eben Dritte keinen Zugriff auf diesen Rechner haben. Und das
>geht ja auch wenn der Rechner am Netz hängt.
Kollegen sind aber keine "Dritten". Ich kann meinen
Arbeitsplatzrechner, der immerhin der Firma gehört, die auch dann
weiter funktionieren muss, wenn ich im Urlaub oder krank bin, nicht
vernageln, da müssen die Kollegen auch drauf können.
Wenn ich längerfristig krank bin, kann es übrigens sogar sein, dass
ein Vertreter wirklich an meinem Arbeitsplatz arbeiten muss.
>> Das ist der Grund für diese Frage.
>
>Dann frag die Kommunikationspartner, soweit das möglich ist.
Ich kenne ja meine Kommunikationspartner noch nicht.
> Bei mir
>kam dabei damals raus das einige Leute nur RSA verarbeiten können, alle
>anderen RSA und DH/DSS. Also habe ich RSA genommen (außerdem war es mir
>sowieso lieber, solange es keinen zwingenden Grund gegeben hätte was
>anderes zu nehmen hätte ich es wohl sowieso genommen).
Bei mir sieht das im Moment auch nach RSA aus, also brauche ich eh'
neue Keys, da der jetzige Key ein DSA-Key ist.
>> Unsere ssh-key-Policy sagt "RSA-Schlüssel mit 2048 bit", und so würde
>> ich es auch mit den GPG-Keys halten, wenn mir nicht jemand hier sagt,
>> dass das Blödsinn ist.
>
>Ich wüßte nicht was dagegen spricht. Evtl. würde ich für den Master-Key
>die Bit-Anzahl noch mal verdoppeln damit es für ein Leben reicht, aber
>auch 2048 Bit sollten noch ziemlich lange sicher genug sein.
Der lange Master-Key ist eine gute Idee.
>> Verstehe.... Wird einem Key ohne Ablaufdatum in der Regel weniger
>> trust entgegen gebracht als einem Key mit?
>
>Keine Ahnung, mir persönlich ist das egal. Ich vertraue einem Schlüssel
>um so mehr je "geprüfter" er ist, unabhängig davon ob er ein Verfalls-
>datum hat oder nicht.
Würdest Du einen Schlüssel A auch dann als "geprüft" bezeichnen, wenn
er nur eine Signatur hat, die mit einem Schlüssel B erstellt wurde,
der demselben Menschen gehört wie A und der vom halben Netz signiert
ist?
>Der Nachteil bei "unsterblichen" Keys ist halt das sie auch dann noch
>gültig sind wenn man die Passphrase längst vergessen hat oder den Secret
>Key zerstört wurde. Aber für solche Fälle ist ja vorher das Revocation
>Certificate erzeugt, wenn man das nicht hat: Pech gehabt.
Revocation Certificate ersetzt also das Verfallsdatum.
Michael Gebetsroither
> Bei mir sieht das im Moment auch nach RSA aus, also brauche ich
> eh' neue Keys, da der jetzige Key ein DSA-Key ist.
Was würde man heutzutage eigentlich sinnvollerweise als symetrisches
Verfahren verwenden, AES oder IDEA?
Für meine cryptoHD verwende ich derzeit IDEA und in Teilen 256bit AES,
das dürfte mit guter Passphrase wohl für einige Zeit genügen.
mfg michael
--
/*you can point a person the way TO learn
but you cant 'teach' a person to 'learn'*/
Florian Weimer
> Was würde man heutzutage eigentlich sinnvollerweise als symetrisches
> Verfahren verwenden, AES oder IDEA?
AES wegen der Patentproblematik.
Helmut Zeisel
>
> In absehbarer Zeit wird GnuPG Smartcards unterstützten...
>
Gibts dazu wo genauere Info?
Helmut
Stefan Bellon
http://www.gnupg.org/aegypten/development.en.html
--
Stefan Bellon * <mailto:sbe...@sbellon.de> * <http://www.sbellon.de/>
PGP 2 and OpenPGP keys available from my home page
VirusScan Message: Windows 3.1 found: Remove it? (Y/n)
Michael Gebetsroither
> Michael Gebetsroither <micha...@gmx.at> writes:
Ok, ist ein Argument.
Aber wurde AES nicht gebrochen (in dem Sinn das sie von 2e256 auf
~2e205 möglichkeiten reduziert haben)?
Gegen IDEA ist doch IMHO bis jetzt noch kein Angriff erfolgreich
unternommen worden, oder habe ich da in letzter Zeit was überlesen?
Fairerweise muss man auch sagen, dass AES sicher sehr viel härter und
von viel mehr Leuten getestet wurde als IDEA.
Also ich werd jetzt komplett auf AES mit 256bit umsteigen (welchen
der Kandidaten ich verwende werd ich mir noch genauer anschauen).
Helmut Zeisel
> Helmut Zeisel wrote:
> > Florian Weimer wrote:
>
> > > In absehbarer Zeit wird GnuPG Smartcards unterstützten...
>
> > Gibts dazu wo genauere Info?
>
> http://www.gnupg.org/aegypten/development.en.html
Klingt vielversprechend;
ist aber anscheinend leider nur fuer Unix;
insbesondere also nichts fuer zu Outlook gezwungene ;-(
Helmut
Florian Weimer
> insbesondere also nichts fuer zu Outlook gezwungene ;-(
Niemand wird zum Einsatz von Outlook gezwungen.
Ralf Huels
> zei...@liwest.at (Helmut Zeisel) writes:
>
> > insbesondere also nichts fuer zu Outlook gezwungene ;-(
>
> Niemand wird zum Einsatz von Outlook gezwungen.
Blablabla. Ein hirntoter MUA am Arbeitsplatz erzeugt nun wirklich nicht die
Sorte Leidensdruck, die mich selbigen wechseln läßt...
Tschüß,
Ralf
PS: F'up2
--
Ralf Hüls | The only way to get rid of a
spa...@strg-alt-entf.org | temptation is to yield to it.
|
http://www.teleute.ping.de/ | Oscar Wilde
Marc Haber
Frag' mal einen beliebigen Tiscali-Mitarbeiter.
Florian Weimer
> Florian Weimer <f...@deneb.enyo.de> wrote:
>>zei...@liwest.at (Helmut Zeisel) writes:
>>> insbesondere also nichts fuer zu Outlook gezwungene ;-(
>>
>>Niemand wird zum Einsatz von Outlook gezwungen.
>
> Frag' mal einen beliebigen Tiscali-Mitarbeiter.
Niemand wird zum Arbeiten bei Tiscali gezwungen.
In unserer heutigen Spaßgesellschaft scheinen die meisten Leute die
Bedeutung des Wortes "Zwang" verlernt zu haben.
Jens Hoffmann
Marc Haber <mh+use...@zugschlus.de> wrote:
>>Niemand wird zum Einsatz von Outlook gezwungen.
>
>Frag' mal einen beliebigen Tiscali-Mitarbeiter.
Nene. IMAP und IMAPS funktionieren auch.
Nur das mit dem Kalendar gestaltet sich schwierig, aber Evolution mit passendem
Plugin geht auch.
Gruss,
Jens
Florian Laws
> Hi,
>
> Marc Haber <mh+use...@zugschlus.de> wrote:
>>>Niemand wird zum Einsatz von Outlook gezwungen.
>>
>>Frag' mal einen beliebigen Tiscali-Mitarbeiter.
>
> Nene. IMAP und IMAPS funktionieren auch.
Zum Lesen. Zum Schreiben nur solange, bis der Admin den
Registrierungs-Schlüssel für "Relay Control" gefunden hat.
>
> Nur das mit dem Kalendar gestaltet sich schwierig, aber Evolution mit
> passendem Plugin geht auch.
Hat das mal jemand getestet?
Ist es sein Geld wert?
Grüße,
Florian
Marc Haber
>Marc Haber <mh+use...@zugschlus.de> writes:
>> Florian Weimer <f...@deneb.enyo.de> wrote:
>>>zei...@liwest.at (Helmut Zeisel) writes:
>>>> insbesondere also nichts fuer zu Outlook gezwungene ;-(
>>>
>>>Niemand wird zum Einsatz von Outlook gezwungen.
>>
>> Frag' mal einen beliebigen Tiscali-Mitarbeiter.
>
>Niemand wird zum Arbeiten bei Tiscali gezwungen.
Du kennst den Arbeitsmarkt.
Marc Haber
>Marc Haber <mh+use...@zugschlus.de> wrote:
>>>Niemand wird zum Einsatz von Outlook gezwungen.
>>
>>Frag' mal einen beliebigen Tiscali-Mitarbeiter.
>
>Nene. IMAP und IMAPS funktionieren auch.
Und das ist erlaubt?
Marc Haber
>Marc Haber <mh+use...@zugschlus.de> wrote:
>> Ich will einen Kompromiss aus Sicherheit und Machbarkeit.
>
>gessen.
:-(
>> >Ein Zwischending wäre ein verschlüsseltes Device auf dem der Secret
>> >Key gespeichert ist (habe ich eine Zeitlang mit PGP-Disk gelöst), aber
>> >dann mußt Du das für jeden Zugriff auf den Key freigeben. Du hast dann
>> >also im Prinzip 2 Passphrases einzugeben.
>>
>> *yuck*
>>
>> und da wundert sich jemand, dass so gut wie niemand PGP wirklich
>> einsetzt?
>
>Es gibt genug die PGP einsetzen, die Daten aber ständig auf dem Rechner
>haben. Mit Sicherheit hat das dann eigentlich wenig zu tun.
Es ist -etwas- besser als unverschlüsselt.
>Jedenfalls in der Theorie. Wenn man davon ausgeht das "die Bösen" nur
>außerhalb der eigenen 4 (Büro-/Firmen-)Wände sitzen ist es dann immer
>noch sicher.
>
>Ist halt alles Definitionssache: Was will ich wo gegen was schützen.
Wird also dazu führen, dass die Key-Policy dokumentiert und öffentlich
niedergelegt wird, damit wir immer noch sagen können, dass die
Gegenseite die Policy nicht gelesen hat.
>> Du sagst es. Und ich versuche hier gerade mir ein Bild darüber zu
>> machen, welche Kompromisse sinnvoll erscheinen und welche nicht.
>
>Wie gesagt - zumindest auf die Passphraseeingabe würde ich nicht ver-
>zichten.
Dann doch lieber nur die wirklich wichtigen Mails signieren.
>> Ich müsste für zwei Keys Signatures sammeln.
>
>Nein. Der "Debia-Key" kann doch bleiben wie er ist, evtl. zusätzlich mit
>Deinem Master-Key signiert.
Gefällt mir nicht wirklich, ist aber denkbar.
>> Es soll sicher und machbar sein. Beides zusammen maximal geht nicht.
>
>Sicher ist ein ausgeschalteter Rechner, eingeschweißt in einen Tresor
>aus 5 Meter starken bestem Stahl, an der tiefsten Stelle aller Meere
>versenkt und mit 500 Metern Stahlbeton übergossen. ;-)
Alter Spruch. Aber nette neue Beschreibung ;)
>Sicherheit ist immer eine Abwägung zwischen "Wünschenswert" "Machbar"
>und "Praktikabel".
Meine Rede.
>In Deinem Fall wird es wohl darauf hinauslaufen den
>Secret Key auf dem Arbeitsplatzrechner zu speichern und damit die
>Sicherheit des ganzen von der Passphrase abhängig zu machen.
Das fürchte ich auch.
>> Du weisst nicht, wie viel ich arbeite.
>
>Evtl. zu viel? ;-)
Das musst Du meine Freundin fragen.
>> Ausserdem könnte ich mich dann
>> nicht von daheim rein-ssh'en und Mails bearbeiten.
>
>Also hängt alles an der Passphrase.
Hängt es sowieso, weil auf dem Rechner auch einige ssh-keys liegen,
die Zugang zu interessanteren Rechnern erlauben.
>Hat eigentlich schon mal jemand
>untersucht wie eine maximal sichere Passphrase aussieht? Eigentlich
>könnte man ja die Regeln für Passwörter anwenden, auf Anhieb fällt mir
>jedenfalls nichts ein was dagegen spricht.
Das sehe ich genauso.
>Wenn Du den Key jedes Mal mit der Passphrase freischaltest hängt die
>Sicherheit allein von der Passphrase ab (wenn man mal davon ausgeht das
>keiner der Kollegen einen Angriff auf den freigeschalteten Schlüssel
>startet), wenn der Key ständig freigeschaltet ist kann jeder der Zugriff
>auf Deinen Rechner hat munter in Deinen Namen signieren und an Dich
>geschickte Mails entschüsseln.
Hält mutt nicht die Passphrase im Speicher und gibt die Passphrase nur
bei Bedarf an den gespawnten gpg-Prozess weiter?
>Wobei ich nicht weiß ob GPG da eine Zeitbeschränkung drin hat, bei PGP
>kann man eine zweistellige Stundenzahl für die Dauer der Freigabe ein-
>geben (Format ist hh:mm:ss).
Dafür müsste aber doch die ganze Zeit ein gpg-Prozess laufen, oder?
>> Kollegen sind aber keine "Dritten". Ich kann meinen
>> Arbeitsplatzrechner, der immerhin der Firma gehört, die auch dann
>> weiter funktionieren muss, wenn ich im Urlaub oder krank bin, nicht
>> vernageln, da müssen die Kollegen auch drauf können.
>
>Das ist aber Firmenabhängig, wenn jeder einen eigenen Arbeitsplatz hat
>besteht IMHO keine Notwendigkeit noch auf anderen Rechnern zu arbeiten
>solange diese jeweils anderen Arbeitsplätze belegt sind.
Mal kurz per ssh beim Kollegen zu gucken, wenn er um Unterstützung
bittet, ist bei uns ganz alltäglich. Und manche Kollegen arbeiten mit
der Entwickler-Version unserer Distribution, da ist es ganz nett,
gleich gucken zu können, wie irgendwas denn in Zukunft gehandhabt
wird.
>Und wenn Du
>nicht da bist muß Dein Secret Key ja auch nicht da sein. Wenn Du natür-
>lich wie oben geschrieben auch von außen auf den Secret Key zugreifen
>mußt/willst sieht das dann schlecht aus.
Dieses Erforderniss kann ich mir selbst vielleicht noch
wegdiskutieren.
>> Wenn ich längerfristig krank bin, kann es übrigens sogar sein, dass
>> ein Vertreter wirklich an meinem Arbeitsplatz arbeiten muss.
>
>Dann kann aber der Secret Key vorher entfernt werden, denn braucht ein
>Vertreter ja nicht.
Das müsste dann ein vertrauenswürdiger Kollege machen, weil ich bin
dann ja krank. Hilfsweise ein Cronjob, der die Keys löscht, wenn ich
länger als drei Tage nicht eingelogged war.
>> Ich kenne ja meine Kommunikationspartner noch nicht.
>
>Das ist dann natürlich schlecht. Also einfach dem Firmenstandard folgen,
>wenn dann wer meckert ist die Firma schuld. ;-)
Ich bin gerade dabei, einen Standard für mich zu setzen, der nach
einer Bewährungszeit sehr wahrscheinlich Firmenstandard werden wird,
da ich für das Setzen dieser Standards verantwortlich bin. Einen in
diesen Dingen weniger inkompetenten Mitarbeiter als mich gibt es bei
uns nicht.
>> >> Unsere ssh-key-Policy sagt "RSA-Schlüssel mit 2048 bit", und so würde
>> >> ich es auch mit den GPG-Keys halten, wenn mir nicht jemand hier sagt,
>> >> dass das Blödsinn ist.
>> >
>> >Ich wüßte nicht was dagegen spricht.
Dagegen spricht zum Beispiel, dass RSA-Keys nicht für Verschlüsselung
taugen, wie mir gpg --gen-key gerade verrät. Bleibt für den encryption
key "DSA and ElGamal" oder "ElGamal". Was nimmt man da?
>Im Prinzip kannst Du da ans Maximum gehen, der wird ja nicht sehr oft
>gebraucht und wenn dann das Rechnen etwas länger dauert machts ja
>nichts.
4096 bit ist maximum? Ich bin erstaunt.
>> Würdest Du einen Schlüssel A auch dann als "geprüft" bezeichnen, wenn
>> er nur eine Signatur hat, die mit einem Schlüssel B erstellt wurde,
>> der demselben Menschen gehört wie A und der vom halben Netz signiert
>> ist?
>
>Kommt auf den Menschen an. :-)
Wie so oft.
>Das Web-of-Thrust basiert ja auf dem "Ich vertraue jemandem dem jemand
>vertraut dem ich vertraue", wer also Schlüssel B in Deinem Beispiel voll
>vertraut dürfte auf Schlüssel A vertrauen. Ich gehe davon aus daß Du mit
>B Deinen Master-Key und mit A die speziellen Keys meinst, richtig?
Genau.
>Dann
>kannst Du den Leuten ja auch gleich sagen das Dein Master-Key eine Art
>"Mini-CA" für Deine Keys ist, dann werden die das auch entsprechend be-
>rücksichtigen.
OK. Das kann ja auch in den Comment rein.
So langsam bekomme ich ein Gefühl für die technischen und
gesellschaftlichen Zusammenhänge, die hinter GPG und dem Web Of Trust
stecken - wenn auch dieses Gefühl auf den Äusserungen sehr weniger
Leute basiert.
Danke dafür, dass Du mich an Deinen Gedanken teilhaben lässt, I really
appreciate that.
Greetings
Marc Haber
>>>Sicherheit des Einsatzes zu differenzieren.
>>
>> --verbose bitte.
>
>Du hast neben dem Zertifizierungsschlüssel zwei weitere Schlüssel:
>Einen, den Du auf Multiuser-Systemen speicherst, und einen den Du
>irgendwo gesichert aufbewahrst (i.d.R. auf einem Rechner, auf den man
>nicht so leicht remote draufkommt, oder auf Smartcard). Der Absender
>kann dann wählen, ob er lieber die erhöhte Sicherheit benötigt und die
>längere Bearbeitungszeit in Kauf nimmt oder nicht.
Das ist eine nette Idee.
>>>Ja, kann man auch im OpenPGP-Protokoll ausdrücken (Sign Only Keys;
>>>Encrypt Only gibt es aus verständlichen Gründen nur als Subkey).
>>
>> Sind die mit so einem Key erzeugten Nachrichten kompatibel mit älteren
>> PGP-Versionen?
>
>Welche PGP-Versionen meinst Du?
Hauptsächlich die weit verbreitete 2.6.3i.
Grüße
Florian Weimer
> Ohne jedes Mal die Passphrase einzugeben kannst Du die Sicherheit ver-
> gessen.
Das stimmt so nicht. Manche Angriffe werden durch das häufige Eingeben
der Passphrase verhindert, manche ermöglicht (z.B. Timing-Angriffe, im
Labor wohl recht erfolgreich).
Florian Weimer
>>>>Ja, kann man auch im OpenPGP-Protokoll ausdrücken (Sign Only Keys;
>>>>Encrypt Only gibt es aus verständlichen Gründen nur als Subkey).
>>>
>>> Sind die mit so einem Key erzeugten Nachrichten kompatibel mit älteren
>>> PGP-Versionen?
>>
>>Welche PGP-Versionen meinst Du?
>
> Hauptsächlich die weit verbreitete 2.6.3i.
Keine Chance. Es gibt wohl auch Konventionen, das in V3-Schlüsseln
(die PGP 2.6.3i verwendet) auszudrücken, aber ich habe dafür nie
Ergebnisse von Kompatibilitätstests gesehen.
Michael Gebetsroither
> Ohne jedes Mal die Passphrase einzugeben kannst Du die Sicherheit
> ver- gessen.
Auch mit jedem Mal die Passphrase eingeben kannst du die Sicherheit
vergessen!
Das ist auch nur dann sicher wenn du in einem abgeschirmten und
"sicheren" Raum arbeitest und das tun die wenigsten.
Wenn einer deine Passphrase haben will, dann bekommt er sie, zwar mit
meist großem Aufwand, aber doch, und zwar ohne das du es mitbekommst
oder sie ihm gibts.
Eine Frage dazu:
Wie stehts eigentlich damit, dass man aus dem Public Key + der
Passphrase den Private Key zurückrechnen kann?
Markus Schaaf
> Wie stehts eigentlich damit, dass man aus dem Public Key + der
> Passphrase den Private Key zurückrechnen kann?
Da besteht normalerweise kein Zusammenhang.
Christian Thöing
> Ok, ist ein Argument.
> Aber wurde AES nicht gebrochen (in dem Sinn das sie von 2e256 auf
> ~2e205 möglichkeiten reduziert haben)?
Nein. Es gibt _keine_ Sicherheits-Angriffe gegen AES aka Rijndael (vgl.
AES-Report: "Rijndael has no known security attacks"), genauso wenig wie
es welche gegen MARS, RC6, Twofish und Serpent gibt. Serpent ist
übrigens zwar der langsamste der fünf Finalisten, dafür aber der sicherste.
Es existieren Angriffe gegen Rijndael mit reduzierter Rundenzahl. Das
beeinträchtigt jedoch nicht die Sicherheit von Standard-Rijndael mit
variabler Rundenzahl.
Kann auch sein, dass ich nicht richtig informiert bin. Bitte dann
Quellen angeben, die anderes belegen.
> Gegen IDEA ist doch IMHO bis jetzt noch kein Angriff erfolgreich
> unternommen worden, oder habe ich da in letzter Zeit was überlesen?
Bisher gibt es -- CMIIW -- keine Angriffe (besser als Brute Force) auf
8-Runden-IDEA. IDEA mit reduzierter Rundenzahl (IIRC 4 und 6) wurde
gebrochen.
> Fairerweise muss man auch sagen, dass AES sicher sehr viel härter und
> von viel mehr Leuten getestet wurde als IDEA.
Ja. AES ist IDEA auf jeden Fall vorzuziehen. Auch auf Triple-DES sollte
jetzt verzichtet werden können, da das Verfahren von seiner Performance
her wirklich schlecht ist und heutigen Anforderungen nicht mehr genügt.
> Also ich werd jetzt komplett auf AES mit 256bit umsteigen (welchen
> der Kandidaten ich verwende werd ich mir noch genauer anschauen).
Rijndael _ist_ AES. Es spricht natürlich nichts dagegen, einen der
anderen 4 Finalisten zu verwenden. Aber Rijndael ist nun einmal der
beste Kompromiss aus Sicherheit und Performance.
--
MfG, Christian Thöing +++ http://cryptolounge.cjb.net
Kommt, reden wir zusammen
Wer redet, ist nicht tot.
(Gottfried Benn)
Christian Thöing
> Wenn einer deine Passphrase haben will, dann bekommt er sie, zwar mit
> meist großem Aufwand, aber doch, und zwar ohne das du es mitbekommst
> oder sie ihm gibts.
Nicht jeder, der eine haben will, bekommt auch eine Passphrase. _So_
einfach ist das nun auch wieder nicht.
Natürlich, es gibt 1.000 Wege, an eine Passwort heranzukommen. Das
reicht von Spionage bis Natrium-Pentothal(R). (SCNR)
Es gibt aber auch einige Wege, sich dagegen zu schützen. Überschreiben
von freiem Speicherplatz und Vernichten von temporären Dateien gehört
z.B. dazu. Aber dann bitte mit 35x-SFS-SuperClean-Wiping[tm]. :-)
> Eine Frage dazu:
> Wie stehts eigentlich damit, dass man aus dem Public Key + der
> Passphrase den Private Key zurückrechnen kann?
Das ist nicht möglich.
Ralf Wildenhues
> Marc Haber <mh+use...@zugschlus.de> wrote:
> > cei...@gmx.de (Carsten Eilers) wrote:
> > >Marc Haber <mh+use...@zugschlus.de> wrote:
>
> > >> >> Unsere ssh-key-Policy sagt "RSA-Schlüssel mit 2048 bit", und so würde
> > >> >> ich es auch mit den GPG-Keys halten, wenn mir nicht jemand hier sagt,
> > >> >> dass das Blödsinn ist.
> > >> >
> > >> >Ich wüßte nicht was dagegen spricht.
> >
> > Dagegen spricht zum Beispiel, dass RSA-Keys nicht für Verschlüsselung
> > taugen, wie mir gpg --gen-key gerade verrät. Bleibt für den encryption
> > key "DSA and ElGamal" oder "ElGamal". Was nimmt man da?
>
> dem eigenen Key verschlüsselt sondern mit einem symmetrischen Verfahren
> dessen Session Key dann mit dem eigenen Key verschlüsselt mitgeschickt
> wird. Was GPG da genau meint weiß ich aber nicht.
Ich denke, daß er etwas anderes meint: gpg vergibt (per default) zwei
Schlüsselpaare: einen Master zum Signieren (DSA oder ElGamal), einen
Subkey zum Verschlüsseln (ElGamal). Wenn ich das GNU Privacy Handbook
richtig verstehe, wird der DSA-Schlüssel nicht zum Verschlüsseln
verwendet. gpg erlaubt das spätere Hinzufügen weiterer Subkeys. Diese
sind jeweils mit dem Master-Key signiert.
Natürlich wird bei Kommunikation nur der symmetrische Session key mit
einem "Verschlüsselungs-Schlüsselpaar" verschlüsselt.
Hoffentlich habe ich das jetzt richtig erklärt, sonst möge mich bitte
jemand aufklären.
Gruß
Ralf
Ralf Wildenhues
> Marc Haber <mh+use...@zugschlus.de> wrote:
> > cei...@gmx.de (Carsten Eilers) wrote:
> > >Marc Haber <mh+use...@zugschlus.de> wrote:
>
> > >> >> Unsere ssh-key-Policy sagt "RSA-Schlüssel mit 2048 bit", und so würde
> > >> >> ich es auch mit den GPG-Keys halten, wenn mir nicht jemand hier sagt,
> > >> >> dass das Blödsinn ist.
> > >> >
> > >> >Ich wüßte nicht was dagegen spricht.
> >
> > Dagegen spricht zum Beispiel, dass RSA-Keys nicht für Verschlüsselung
> > taugen, wie mir gpg --gen-key gerade verrät. Bleibt für den encryption
> > key "DSA and ElGamal" oder "ElGamal". Was nimmt man da?
>
> dem eigenen Key verschlüsselt sondern mit einem symmetrischen Verfahren
> dessen Session Key dann mit dem eigenen Key verschlüsselt mitgeschickt
> wird. Was GPG da genau meint weiß ich aber nicht.
Ich denke, daß er etwas anderes meint: gpg vergibt (per default) zwei
Schlüsselpaare: einen Master zum Signieren (DSA oder ElGamal), einen
Subkey zum Verschlüsseln (ElGamal). Wenn ich das GNU Privacy Handbook
richtig verstehe, wird der DSA-Schlüssel nicht zum Verschlüsseln
verwendet. gpg erlaubt das spätere Hinzufügen weiterer Subkeys. Diese
sind jeweils mit dem Master-Key signiert.
Natürlich wird bei Kommunikation nur der symmetrische Session key mit
einem "Verschlüsselungs-Schlüsselpaar" verschlüsselt.
Hoffentlich habe ich das jetzt richtig erklärt.
Gruß
Ralf
Michael Gebetsroither
> Serpent ist übrigens zwar der langsamste der fünf
> Finalisten, dafür aber der sicherste.
zitat aus der hp von serpent "Serpent and Rijndael are in fact
somewhat similar; the main difference is that Rijndael is faster
(having fewer rounds) but Serpent is more secure."
Und wegen der Geschwindigkeit von Serpent, Serpent schafft
~45Mbit/sec auf einem Pentium mit 200MHz, ich glaub in diesem Fall
dürfte die Geschwindigkeit für einen Desktoprechner keinen Ausschlag
geben.
> Kann auch sein, dass ich nicht richtig informiert bin. Bitte dann
> Quellen angeben, die anderes belegen.
Bin am Suchen... ;)
> Es spricht natürlich nichts dagegen, einen der
> anderen 4 Finalisten zu verwenden.
Ich werde ziehmlich sicher Serpent verwenden.
> Aber Rijndael ist nun einmal der beste Kompromiss aus Sicherheit
> und Performance.
Die Performance ist mir auf einem Desktoprechner für die
Verschlüsselung einer Festplatte egal, da die Geschwindigkeit doch
_sehr_ hoch ist, egal ob man jetzt Serpent oder AES nimmt.
Wie ich das allerdings mit meiner Passphrase machen werde bin ich
gerade dabei zu überlegen, ich hatte mir da was mit usb storage in
die Richtung überlegt.
Michael Gebetsroither
> Nicht jeder, der eine haben will, bekommt auch eine Passphrase.
> _So_ einfach ist das nun auch wieder nicht.
Hab ja eh geschrieben mit sehr hohem Aufwand.
> Es gibt aber auch einige Wege, sich dagegen zu schützen.
> Überschreiben von freiem Speicherplatz und Vernichten von
> temporären Dateien gehört z.B. dazu. Aber dann bitte mit
> 35x-SFS-SuperClean-Wiping[tm]. :-)
Also bei mir hat sich mein Keyboard ausgerüstet mit einem 8051 und
etwas ram sehr bewährt ;).
Ralf Huels
> Wie stehts eigentlich damit, dass man aus dem Public Key + der
> Passphrase den Private Key zurückrechnen kann?
Die Passphrase hat nichts mit dem Schlüsselpaar zu tun.
Der Secret Key wird, solange er nicht gebraucht wird, mit einem Schlüssel
verschlüsselt, der auf der Passphrase beruht.
Die Passphrase ist gewissermaßen nur der Schlüssel zum Schlüsselkasten ;-)
Tschüß,
Ralf
Bernd Eckenfels
> es welche gegen MARS, RC6, Twofish und Serpent gibt. Serpent ist
Diese Aussage kann man nicht treffen. (Also das langsam schon, das sicher
nicht :)
Gruss
Bernd
Peter J. Holzer
> Marc Haber <mh+use...@zugschlus.de> wrote:
>
>> cei...@gmx.de (Carsten Eilers) wrote:
>> >Marc Haber <mh+use...@zugschlus.de> wrote:
>> >> zumindest tagsüber auf meinem Arbeitsplatzrechner online sein muss.
>> >> Wenn man mutt nutzt und nicht für jede Mail die Passphrase eintippen
>> >> möchte, muss nicht nur der Key online, sondern auch die Passphrase im
>> >> Speicher sein.
>> >
>> >Das mit der Passphrase läßt sich nicht vermeiden wenn Du eine halbwegs
>> >brauchbare Sicherheit haben willst.
>> Ich will einen Kompromiss aus Sicherheit und Machbarkeit.
>
> gessen.
Ich glaube, Du legst zuviel Wert auf die Passphrase.
Marc hat offensichtlich einen Unix-Rechner als Arbeitsplatzrechner
(zumindest schließe ich das aus den Stichworten "mutt", "ssh" und
"debian"). Da hat nicht jeder User automatisch Leseberechtigung auf
jedes File. Insbesondere sollte der Secret Key nur für Marcs Account
und Root lesbar sein. Gleiches gilt für die im RAM befindliche
Passphrase. Das Root-Passwort haben hoffentlich nur vertrauenswürdige
Personen. Bleibt also als Bedrohungsszenario, dass sich ein
nicht-vertrauenswürdiger Kollege Root-Privilegien auf illegale Weise[1]
beschafft. In dem Fall kann er sich den verschlüsselten Secret Key
kopieren, er kann aber auch ein trojanisches Pferd installieren, das die
Passphrase beim nächsten Mal mitschreibt und ihm zugänglich macht.
Wenn also jemand auf dem Rechner selbst den Secret-Key-Ring lesen kann,
hilft die Passphrase auch nichts mehr. Sie hilft aber zum Beispiel, wenn
jemand die Backup-Bänder stiehlt.
hp
[1] Über remote oder lokale Exploits oder über direkten Zugriff auf die
Hardware. Ich weiß nicht, wie das in Marcs Firma aussieht, aber hier
würde ich mir wesentlich mehr Gedanken über den Zugriff auf die Hardware
machen als über Exploits. Security-kritische Updates mache ich meistens
ziemlich rasch, aber der Rechner steht in einem nichtabgesperrten Büro.
Wenn mir ein Kollege böses will, wird er also nicht lange nach Exploits
suchen, sondern (am besten frühmorgens) einfach die Platte kurzfristig
aus dem PC entnehmen. Die Schuld am Reboot lässt sich dann einem
Stromausfall oder der Putzfrau zuschieben.
--
_ | Peter J. Holzer | Schlagfertigkeit ist das, was einem
|_|_) | Sysadmin WSR | auf dem Nachhauseweg einfällt.
| | | h...@hjp.at | -- Lars 'Cebewee' Noschinski in dasr.
__/ | http://www.hjp.at/ |
Florian Weimer
> Marc hat offensichtlich einen Unix-Rechner als Arbeitsplatzrechner
> (zumindest schließe ich das aus den Stichworten "mutt", "ssh" und
> "debian"). Da hat nicht jeder User automatisch Leseberechtigung auf
> jedes File.
De facto schon, leider.
Marc Haber
>Marc Haber <mh+use...@zugschlus.de> wrote:
>> Das müsste dann ein vertrauenswürdiger Kollege machen, weil ich bin
>> dann ja krank.
>
>Secret Key?
Das kann der nicht. Zugriff der Geschäftsleitung auf den Key würde so
aussehen, dass einer der anderen Techniker den Schlüssel in die Hand
gedrückt bekommt: "Mach mal".
>Was GPG da genau meint weiß ich aber nicht.
Das merkt man ;)
Bei einem reinen RSA-Key steht schon bei der Erzeugung dabei, dass man
mit diesem Key nur signieren, nicht aber verschlüsseln wird können.
Nach der Erzeugung sagt er das dann ganz deutlich nochmal, und das
scheint auch zu stimmen.
Wie intern verschlüsselt wird, ist mir schon klar ;)
Grüße
Marc Haber
>Marc wollte den Secret Key immer aktiviert lassen, auf einem Rechner
>auf dem auch andere Zugriff haben. Dann braucht man keinen Angriff auf
>seinen Key mehr zu starten, man benutzt einfach sein System auf seinem
>Rechner.
Ich glaube nicht, dass das mit GPG unter einem unixoiden System so
einfach geht.
Marc Haber
Ausserdem kann man mir gut per Fernglas auf die Tastatur gucken.
Marc Haber
>
>Keine Chance. Es gibt wohl auch Konventionen, das in V3-Schlüsseln
>(die PGP 2.6.3i verwendet) auszudrücken, aber ich habe dafür nie
>Ergebnisse von Kompatibilitätstests gesehen.
Kann man inzwischen einem 2.6.3i-Benutzer sagen, dass er doch bitte
auf gpg umsteigen soll, ohne dass er mir den Schädel einschlägt?
Sebastian Bork
> Kann man inzwischen einem 2.6.3i-Benutzer sagen, dass er doch bitte
> auf gpg umsteigen soll, ohne dass er mir den Schädel einschlägt?
Ich denke schon. Es gibt das ja jetzt auch schön bunt für alle
Betriebssysteme, also warum nicht. Ich bin komplett umgestiegen.
Christian Thöing
[Serpent vs. Rijndael]
> zitat aus der hp von serpent "Serpent and Rijndael are in fact
> somewhat similar; the main difference is that Rijndael is faster
> (having fewer rounds) but Serpent is more secure."
> Und wegen der Geschwindigkeit von Serpent, Serpent schafft
> ~45Mbit/sec auf einem Pentium mit 200MHz, ich glaub in diesem Fall
> dürfte die Geschwindigkeit für einen Desktoprechner keinen Ausschlag
> geben.
Da wäre ich nicht so voreilig: Rijndael ist in der Tat _ziemlich_
schnell, ich war selbst überrascht; Serpent dagegen ist gerade mal etwas
schneller als DES (in Software) und nur knapp halb so schnell wie
Rijndael. Du kannst es selbst z.B. mit Blowfish Advanced CS testen.
RC6 ist in Software auf 32-Bit-Prozessoren übrigens sehr schnell. Der
klare Vorteil von Rijndael ist allerdings, dass seine Performance in
Implementationen für verschiedenste Prozessoren beachtlich ist.
Ich würde Rijndael benutzen, da es Sicherheit und Geschwindigkeit
gleichermaßen bietet.
>>Kann auch sein, dass ich nicht richtig informiert bin. Bitte dann
>>Quellen angeben, die anderes belegen.
>
> Bin am Suchen... ;)
Na, hoffentlich findest Du nichts ;-)
>>Es spricht natürlich nichts dagegen, einen der
>>anderen 4 Finalisten zu verwenden.
>
> Ich werde ziehmlich sicher Serpent verwenden.
Denk an die Performance! :-P
> Die Performance ist mir auf einem Desktoprechner für die
> Verschlüsselung einer Festplatte egal, da die Geschwindigkeit doch
> _sehr_ hoch ist, egal ob man jetzt Serpent oder AES nimmt.
Nun ja, _sehr_ hoch ist Serpents Geschwindigkeit immer noch nicht. Und
wenn Du ständig Dateien >10 MB ver-/entschlüsseln musst, dann macht sich
die Geschwindigkeit doch bemerkbar.
Allerdings verschlüsselt Serpent bei mir eine >20MB-Datei immerhin schon
in ~5 Sekunden. Rijndael tut's in ~2.
Christian Thöing
>>es welche gegen MARS, RC6, Twofish und Serpent gibt. Serpent ist
>>übrigens zwar der langsamste der fünf Finalisten, dafür aber der sicherste.
>
> Diese Aussage kann man nicht treffen. (Also das langsam schon, das sicher
> nicht :)
Na ja, _theoretisch_ ist Serpent schon sicherer (32[!] Runden); außerdem
beruht das Verfahren auf anerkannten und lange bewährten Methoden, die
schon bei DES erfolgreich eingesetzt wurden. Ich würde allerdings den
AES vorziehen, denn ... Performance rulzzz! ;-) Und hoffentlich werden
wir auch endlich auf das leidige Triple-DES mit seiner unsäglichen
Geschwindigkeit verzichten können. Es gibt genug schnellere Alternativen.
Marc Haber
>Marc hat offensichtlich einen Unix-Rechner als Arbeitsplatzrechner
>(zumindest schließe ich das aus den Stichworten "mutt", "ssh" und
>"debian").
Richtig.
>Da hat nicht jeder User automatisch Leseberechtigung auf
>jedes File. Insbesondere sollte der Secret Key nur für Marcs Account
>und Root lesbar sein. Gleiches gilt für die im RAM befindliche
>Passphrase. Das Root-Passwort haben hoffentlich nur vertrauenswürdige
>Personen.
Mein Rechner läuft im Accountprofil "security workstation". Somit
haben nur die technische Leitung und die Mitarbeiter im Bereich
Security überhaupt einen Account. Wer allerdings einen Account hat,
steht auch mit ALL=(ALL) ALL in der /etc/sudoers, darf also jegliche
Befehle als root ausführen. Das root-Passwort selbst ist eklig, und
liegt im versiegelten Umschlag dort, wo niemand rankommt.
>[1] Über remote oder lokale Exploits oder über direkten Zugriff auf die
>Hardware. Ich weiß nicht, wie das in Marcs Firma aussieht, aber hier
>würde ich mir wesentlich mehr Gedanken über den Zugriff auf die Hardware
>machen als über Exploits. Security-kritische Updates mache ich meistens
>ziemlich rasch, aber der Rechner steht in einem nichtabgesperrten Büro.
Genauso hier.
>Wenn mir ein Kollege böses will, wird er also nicht lange nach Exploits
>suchen, sondern (am besten frühmorgens) einfach die Platte kurzfristig
>aus dem PC entnehmen. Die Schuld am Reboot lässt sich dann einem
>Stromausfall oder der Putzfrau zuschieben.
ACK.
Hilfsweise bootet man einfach mal kurz mit Linuxcare BBC oder Knoppix.
Marc Haber
OK. Ich bin da etwas betriebsblind.
Grüße
Ma "if it works on Debian, it is good enough to use" rc
Sebastian Bork
>>> [Kann man PGP-2.6.3i-User auf GnuPG verweisen?]
>> Ich denke schon. Es gibt das ja jetzt auch schön bunt für alle
>> Betriebssysteme, also warum nicht. Ich bin komplett umgestiegen.
>
> OK. Ich bin da etwas betriebsblind.
Naja, in der Hinsicht bin ich nicht anders ... wenn ich was
benutze, dann muß es auch auf Debian laufen ... *g*
Aber auch Windows-User können mit GnuPP (http://www.gnupp.de/)
ganz komfortabel GnuPG nutzen, mindestens so gut wie PGP 2.6.3in
mit PGPClick32 damals benutzbar war, als ich noch mit Windows
gearbeitet habe. Wenn nicht gar komfortabler.
--
Support the ban on Dihydrogen Monoxide: http://www.dhmo.org/
*encrypted e-mail preferred* | use saft://saft.sebi.org/sebi
Michael Gebetsroither
> Serpent dagegen ist gerade mal etwas schneller als DES (in
> Software) und nur knapp halb so schnell wie Rijndael.
Woher hast du diese Werte.
Laut der HP von Serpent (www.cl.cam.ac.uk/~rja14/serpent.html)
erreicht Serpent auf einem P200 ~45Mbit/sec, DES erreicht aber nur
15Mbit/sec.
Zitat: "Despite these exacting design constraints, Serpent is much
faster than DES. Its design supports a very efficient bitslice
implementation, and the current fastest version runs at over 45
Mbit/sec on a 200MHz Pentium (compared with about 15 Mbit/sec for
DES). "
> Ich würde Rijndael benutzen, da es Sicherheit und Geschwindigkeit
> gleichermaßen bietet.
Wie gesagt, Geschwindigkeit tut bei mir nichts zu Sache ;),
Rechenleistung habe ich ja genug.
> Na, hoffentlich findest Du nichts ;-)
Werma schon sehen ;).
> Denk an die Performance! :-P
*hehe*, nicht immer muss alles nur schnell gehen so wie bei dir :P!
In der Ruhe liegt die Kraft :D.
> Allerdings verschlüsselt Serpent bei mir eine >20MB-Datei immerhin
> schon in ~5 Sekunden. Rijndael tut's in ~2.
Was hast du für einen Computer?
Eigentlich sollte mein Computer für eine 20MB Datei doch deutlich
unter 1s brauchen falls die 45Mbit für einen P200 stimmen.
Bernd Eckenfels
> Na ja, _theoretisch_ ist Serpent schon sicherer (32[!] Runden);
Die anzahl der Runden ist keine theoretische sicherheit, hoechstens eine
gefuehlsmaessige.
Gruss
Bernd
Florian Weimer
> Kann man inzwischen einem 2.6.3i-Benutzer sagen, dass er doch bitte
> auf gpg umsteigen soll, ohne dass er mir den Schädel einschlägt?
Die entsprechende Webseite (mit der OpenPGP Implementation
Vulnerability Matrix) ist leider immer noch nicht ganz fertig. :-/
M.E. kann man durchaus.
Marc Haber
>Marc Haber <mh+use...@zugschlus.de> wrote:
>> Ausserdem kann man mir gut per Fernglas auf die Tastatur gucken.
>
>Jalousien?
Nein. Mein Büro ist auf der Nordseite, und der Architekt ist der
Meinung, dass von Norden keine Sonne kommt.
Er hat wohl nicht berücksichtigt, dass das Haus gegenüber die
Morgensonne hervorragend reflektiert, und dass im Sommer abends die
Sonne schonmal weit genug rüberkommt, um mir direkt in die Augen zu
knallen.
Marc Haber
>Peter J. Holzer <hjp-u...@hjp.at> wrote:
>> Wenn also jemand auf dem Rechner selbst den Secret-Key-Ring lesen kann,
>> hilft die Passphrase auch nichts mehr. Sie hilft aber zum Beispiel, wenn
>> jemand die Backup-Bänder stiehlt.
>
>nebenbei am gerade unbeobachteten Rechner Dummheiten macht. Nicht immer
>sichert man den Rechner wenn man nur mal kurz aus dem Büro geht.
Ich tue das schon. Bin da ziemlich paranoid. Schon alleine, weil ich
nicht abkann, wenn jemand meine Mail liest.
Christian Thöing
> Woher hast du diese Werte.
Zum einen aus Tests mit eigenen Programmen, zum anderen aus Erfahrungen
mit Blowfish Advanced CS.
> Laut der HP von Serpent (www.cl.cam.ac.uk/~rja14/serpent.html)
> erreicht Serpent auf einem P200 ~45Mbit/sec, DES erreicht aber nur
> 15Mbit/sec.
Das mag ja sein, nur muss man berücksichtigen, dass in
Verschlüsselungs-Programmen ein Algorithmus niemals diese Werte
erreichen wird, da teilweise enorm viel Performance durch
Callback-Funktionen etc. eingebüßt wird.
Ich habe damals u.a. Serpent und Rijndael für CryptPak, basierend auf
Implementationen von Brian Gladman und Wei Dai, implementiert; die
relativ schlechten Performance-Werte für Serpent könnten auf eine wenig
optimierte Implementation zurückzuführen sein. Interessant sind in
diesem Zusammenhang auch die Geschwindigkeits-Tabellen von Brian Gladman
selbst:
http://fp.gladman.plus.com/cryptography_technology/aes2/index.htm
Auf einem P200 verschlüsselt Serpent demnach nur mit ~27 MB/s, während
DES mit 30,5 MB/s verschlüsselt (wobei allerdings zu beachten ist, dass
Serpent eine Blocklänge von 128 Bit hat, im Gegensatz zu 64 Bit bei DES).
>>Ich würde Rijndael benutzen, da es Sicherheit und Geschwindigkeit
>>gleichermaßen bietet.
>
> Wie gesagt, Geschwindigkeit tut bei mir nichts zu Sache ;),
Wenn Du meinst ... Immerhin ist Serpent ja auch "Vize-AES".
> *hehe*, nicht immer muss alles nur schnell gehen so wie bei dir :P!
> In der Ruhe liegt die Kraft :D.
Wirst schon sehen, bei 100-MB-Dateien wird's sicher unangenehm ...
> Was hast du für einen Computer?
PIII 900 MHz. Man muss aber wie gesagt auch beachten, dass ich mit
Blowfish Advanced CS getestet habe und die Implementationen womöglich
nicht optimal sind.
> Eigentlich sollte mein Computer für eine 20MB Datei doch deutlich
> unter 1s brauchen falls die 45Mbit für einen P200 stimmen.
Probier's doch selbst mit bfaCS oder CryptPak aus:
Christian Thöing
[Rundenzahl von Serpent => mehr Sicherheit?]
>>Die anzahl der Runden ist keine theoretische sicherheit, hoechstens eine
>>gefuehlsmaessige.
>
> Alte Weisheit: Viel hilft viel. ;-)
In der Kryptographie (meistens) schon.
> Es gibt ja auch Leute die ihre Mails standardmäßig immer 2 Mal mit Rot13
> kodieren, ich mache es sogar immer 10 Mal, sicher ist sicher. ;-)
Ja ... Triple-ROT13 now! Unpatentiert und öffentlich zugänglich, und
sogar exzellente Performance-Werte! Und, noch viel besser, nicht mal ein
Schlüssel ist nötig! Vielleicht sollte man diesen wirklich
bahnbrechenden Vorschlag mal an diverse Snake-Oil-Firmen, die ja in
letzter Zeit wie Pilze aus dem Boden sprießen, schicken ... Einen guten
Aufhänger bräuchte man allerdings ...
(SCNR)
Christian Thöing
> Die anzahl der Runden ist keine theoretische sicherheit, hoechstens eine
> gefuehlsmaessige.
Nein. Eine höhere Rundenzahl bedeutet in den meisten Fällen mehr
Sicherheit gegenüber eine Variante mit weniger Runden. Das ist auch
insofern einleuchtend, als Varianten eines Algorithmus mit einer
Rundenzahl, die im Nachhinein als zu gering angesehen werden muss,
irgendwann durch neue Angriffe gebrochen werden könnten. Ein Beispiel
dafür ist Khufu von Ralph Merkle.
Wenn Du allerdings "theoretisch" im Sinne von "mathematisch streng
beweisbar" definierst, hast Du Recht. Die Sicherheit eines Verfahrens
lässt sich in den seltensten Fällen _beweisen_, da ihr Design zu komplex
ist. Allerdings haftet der Kryptographie an sich schon immer etwas
"Gefühlsmäßiges" an. Beispielsweise vertrauen PGP-Benutzer auch darauf,
dass die einzige Möglichkeit, RSA zu brechen, im Faktorisieren liegt,
oder dass Algorithmus X (z.B. IDEA) sicher ist.
Ralf Huels
> Ja ... Triple-ROT13 now! Unpatentiert und öffentlich zugänglich, und
> sogar exzellente Performance-Werte! Und, noch viel besser, nicht mal ein
> Schlüssel ist nötig! Vielleicht sollte man diesen wirklich
> bahnbrechenden Vorschlag mal an diverse Snake-Oil-Firmen, die ja in
> letzter Zeit wie Pilze aus dem Boden sprießen, schicken ... Einen guten
> Aufhänger bräuchte man allerdings ...
Untauglich. Man kann nicht mit nichtssagenden Schlüssel-Bitlängen protzen.
Vielleicht, wenn Du alle 24 Byte zwischen Triple-ROT13 und Quintuple-ROT13
wechselst. das ist dann nämlich 192-Bit-Sicherheit.
Michael Gebetsroither
> Das mag ja sein, nur muss man berücksichtigen, dass in
> Verschlüsselungs-Programmen ein Algorithmus niemals diese Werte
> erreichen wird, da teilweise enorm viel Performance durch
> Callback-Funktionen etc. eingebüßt wird.
Kommt immer darauf an wie er getestet hat. Ich hoffe mal das er es in
einem "echten" Programm getestet hat, oder auch im Kernel.
> Wenn Du meinst ... Immerhin ist Serpent ja auch "Vize-AES".
Und von der Sicherheit her wäre er 1., also ist es mir das Bisschen
Geschwindigkeit wert ;).
> Wirst schon sehen, bei 100-MB-Dateien wird's sicher unangenehm ...
Könnte einige Zeit dauer, aber auf meinen Verschlüsselten Dateien
liegen nur kleiner Textfiles herum, die aber _absolut_ geschützt
werden sollten.
Sie liegen sowieso auf einer Wechselfestplatte, die nur dann in den
Computer kommt wenn ich sie brauche.
> Probier's doch selbst mit bfaCS oder CryptPak aus:
Ob diese Programme wohl viel über die Verschlüsselungsgeschwindigkeit
im Kernel aussagen? Ich werds auf jedenfall mal testen ;).
Ich habe meine Entscheidung wohl schon getroffen ;), ich werde
Serpent mit 256bit verwende..., danke für eure ganzen Anregungen :)!
Peter J. Holzer
> Marc Haber <mh+use...@zugschlus.de> wrote:
>
>> >Wenn Du den Key jedes Mal mit der Passphrase freischaltest hängt die
>> >Sicherheit allein von der Passphrase ab (wenn man mal davon ausgeht das
>> >keiner der Kollegen einen Angriff auf den freigeschalteten Schlüssel
>> >startet), wenn der Key ständig freigeschaltet ist kann jeder der Zugriff
>> >auf Deinen Rechner hat munter in Deinen Namen signieren und an Dich
>> >geschickte Mails entschüsseln.
>>
>> Hält mutt nicht die Passphrase im Speicher und gibt die Passphrase nur
>> bei Bedarf an den gespawnten gpg-Prozess weiter?
>
> Keine Ahnung, bei meiner PGP-Version hier auf dem Mac ist das Sache von
> PGP. Ich vermute aber mal das es Sache von gpg ist, was haben andere
> Programme mit dessen Passphrase zu tun? Es kann natürlich auch sein daß
> mutt sich da einfach zwischenhängt.
Unter Unix wird PGP/GnuPG zum Bearbeiten jeweils einer Nachricht
aufgerufen und beendet sich danach wieder. Es kann also nirgends den Key
cachen. Programme, die es dem User ersparen wollen, dauernd die
Passphrase einzutippen (z.B. mutt), cachen also die Passphrase und
übergeben diese bei bei jedem Aufruf an PGP. Nach einiger Zeit vergessen
sie die Passphrase wieder und der User muss sie neu eingeben (beim Mutt
ist das per Default nach 10 Minuten, IIRC).
hp
Peter J. Holzer
> Und Mac-Nutzer sind ja auch eher nicht gewalttätig.
http://joyoftech.com/joyoftech/joyarchives/364.html
SCNR,
Tilman Schmidt
>Bernd Eckenfels wrote:
>
>> Die anzahl der Runden ist keine theoretische sicherheit, hoechstens eine
>> gefuehlsmaessige.
>
>Nein. Eine höhere Rundenzahl bedeutet in den meisten Fällen mehr
>Sicherheit gegenüber eine Variante mit weniger Runden.
Für Varianten ein und desselben Algorithmus ja. Aber dafür, die
Rundenzahl unterschiedlicher Algorithmen als Vergleichskriterium zu
verwenden, sehe ich keine Basis.
--
Tilman Schmidt E-Mail: Tilman....@ePost.de
Bonn, Germany
- In theory, there is no difference between theory and practice.
In practice, there is.
Christian Thöing
>>Nein. Eine höhere Rundenzahl bedeutet in den meisten Fällen mehr
>>Sicherheit gegenüber eine Variante mit weniger Runden.
>
> Für Varianten ein und desselben Algorithmus ja. Aber dafür, die
> Rundenzahl unterschiedlicher Algorithmen als Vergleichskriterium zu
> verwenden, sehe ich keine Basis.
Das ist richtig. Es ist natürlich unsinnig, die Rundenzahl von z.B. DES
und IDEA zu vergleichen. Allerdings sind sich Rijndael und Serpent in
ihrem Design sehr ähnlich, was einen vagen Vergleich zuließe. Immerhin
sind dann auch beide unter den Top 2 gelandet.
--
MfG, Christian Thöing http://cryptolounge.cjb.net
Wer ist Jesus von Nazaret? -- Gewiss kein Gott. Vielleicht ein Mensch.
In der Bibel einmal, in der Geschichte der Kirche aber unaufhörlich
gekreuzigt. (Karlheinz Deschner) http://www.kirchenopfer.de
Michael Gebetsroither
> Immerhin sind dann auch beide unter den Top 2
> gelandet.
Wobei eben Rijndael gewonnen hat, weil er schneller ist, nicht
sicherer, und weil Rijndael auf µC besser implementiert ist und
vorallem dort schneller läuft.
Florian Weimer
> Allerdings sind sich Rijndael und Serpent in ihrem Design sehr
> ähnlich, was einen vagen Vergleich zuließe.
Wirklich? Immerhin ist Serpent eventuell von diesem Hitachi-Patent
betroffen und Rijndael nicht. ;-)
Marc Haber
>> aussehen, dass einer der anderen Techniker den Schlüssel in die Hand
>> gedrückt bekommt: "Mach mal".
>
>Na dann ist es wirklich einfacher gleich selber den richtigen Kollegen
>dafür auszusuchen, bevor der Chef es gerade dem ungeeignetsten machen
>läßt. ;-)
Der Chef kann schon beurteilen, wen man am besten an solche Dinge
heranlässt.
>> >Was GPG da genau meint weiß ich aber nicht.
>>
>> Das merkt man ;)
>
>Du hast nicht zufällig Lust gpg auf MacOS 8 oder 9 zu portieren? ;-)
Zeit und Expertise sind die wirklichen Probleme.
Marc Haber
>Marc Haber <mh+use...@zugschlus.de> wrote:
>> Nein. Mein Büro ist auf der Nordseite, und der Architekt ist der
>> Meinung, dass von Norden keine Sonne kommt.
>
>
>> Er hat wohl nicht berücksichtigt, dass das Haus gegenüber die
>> Morgensonne hervorragend reflektiert, und dass im Sommer abends die
>> Sonne schonmal weit genug rüberkommt, um mir direkt in die Augen zu
>> knallen.
>
>geblieben. ;-)
>
>Ist jedenfalls eine geniale Planung, mein Beileid!
Typischer Billig-Bürobau des frühen 21sten Jahrhunderts. Die Art, wie
die Heizungsrohre zwischen Wand und Kabelkanal in der Fussleiste
verlaufen, habe ich zuletzt bei der Sanierung von Altbauten der
letzten Jahrhundertwende gesehen, aber nicht bei einem Neubau.
Immerhin sind die Trockenbauwände leidlich wavelan-freundlich, bis auf
mein Büro, das drei massive Wände aus Stahlbeton hat.
Grüße
Marc, f'uppend
Ralph J.Mayer
> appreciate that.
Von ganz anderer Seite mal ein Dankeschön für diese Diskussion!
rm