Re: [Cryptojim-devel] Planung

[Thilo H. <thi...@we...>]

Am 29.01.2005 um 12:53 schrieb Lars:

> Moin,
>
> arnd schrieb:
>> Thilo Hannemann wrote:
>>> bei der ganzen Key-Geschichte w=FCrde ich die PGP/GPG-Infrastruktur=20=

>>> benutzen. Da gibt es schon alles, was du brauchst und du musst nicht=20=

>>> das Rad neu erfinden. Ausserdem haben viele Leute schon einen=20
>>> PGP/GPG-Key und brauchen dann keinen neuen zu erzeugen.
>> Im Prinzip w=FCrde ich das zwar gerne tun, allerdings vermute ich das=20=

>> es schwer zu implementieren ist. Wei=DF jemand ob es f=FCr gpg eine =
Java=20
>> library gibt? Wahrscheinlich nicht, oder?
>
> Gpg kann man doch komplett =FCber die Commandline steuern, zumindest=20=

> macht Enigmail das so meine ich. Das d=FCrfte auch nicht zu =
kompliziert=20
> sein da einen Wrapper drum zu schreiben.

Das Problem ist eher, dass das ganze in Java geschrieben sein soll und=20=

der Aufruf von Programmen =FCber die Kommandozeile etwas der=20
Java-Philosophie zuwiederl=E4uft.

Ein Gedanke noch zur Verwendung von PGP/GPG: Wir brauchen die=20
Infrastruktur nur zum Schl=FCsseltausch, nicht zur Verschl=FCsselung=20
selber. D.h. beim ersten Aufbau einer Verbindung in einer Session wird=20=

ein gemeinsamer Schl=FCssel via PGP/GPG ausgehandelt und ab dann=20
symmetrisch mit einem geeigneten Verfahren (AES o.=E4.) verschl=FCsselt.=20=

Damit w=E4re es kein Performance-Problem PGP/GPG =FCber die =
Kommandozeile=20
zu verwenden.

Das h=E4tte dann auch zur Folge, dass die History f=FCr eine Session mit=20=

einem Teilnehmer auch nur einen Schl=FCssel hat. Aber da sehe ich kein=20=

Problem, schliesslich muss man nicht f=FCr jedes ":-)" oder ":-p" einen=20=

eigenen Schl=FCssel aushandeln.

>>>
>>> Eine Zuordnung von ICQ# und Key ist nicht n=F6tig! Anhand des Keys=20=

>>> weiss man doch, wer die Nachricht geschrieben hat, egal unter=20
>>> welcher ICQ# er es gemacht hat. Das einzige was wirklich=20
>>> interessiert ist die Zuordnung Key <-> Name und die kriegst du =FCber=20=

>>> die PGP-Infrastruktur.
>> Meiner Meinung ist eine solche Zuordnung doch wichtig um die=20
>> Verschl=FCsselung nahtlos in so einen Clienten zu integrieren.
>> [...]
>> Das einzige was ich von dem anderen Benutzer wei=DF ist die ICQ =
Nummer=20
>> und deswegen muss es meiner Meinung nach eine feste Zuordnung  Key=20
>> <-> ICQ# geben.
> Also ich hab das so verstanden das man bei PGP IDs einf=FCgen kann.=20
> Diese IDs k=F6nnen Emailadressen sein aber auch halt ICQ#. Warum also=20=

> nicht so eine ID in den PGP-Key einf=FCgen und dann danach suchen.

Das kann man ja zus=E4tzlich verwenden. Nur muss es im Key sein, bevor=20=

man ihn von anderen Leuten unterschreiben l=E4sst. D.h. wenn ich schon=20=

einen PGP-Key habe ist diese ID nicht drin. Und ich will vielleicht=20
keinen neuen machen, da der alte schon von hunderten Leuten=20
unterschrieben ist. Aber als zus=E4tzliche M=F6glichkeit ist es eine =
gute=20
Idee.

>>> Eine zentrale Speicherung der History ist eigentlich kein Problem,=20=

>>> wenn der Server nur die verschl=FCsselten Nachrichten speichert. =
Aber=20
>>> vielleicht geht das auch P2P:
>>> - Jeder Client speichert alle Nachrichten, die er mit anderen Leuten=20=

>>> ausgetauscht hat
>>> - Falls sich jemand von den "anderen" anmeldet, kann dieser andere=20=

>>> anfragen, welche Nachrichten von ihm in der History sind. Falls dort=20=

>>> neue sind, die er selber noch nicht kennt (weil sie von einem=20
>>> anderen Client f=FCr den selben User abgeschickt worden sind), dann=20=

>>> fordert er [...]
>>> Die Funktionsweise ist dann so, dass deine History mit einem User=20
>>> aktualisiert wird, sobald dieser online kommt. Man kann jetzt=20
>>> nat=FCrlich auch noch =FCberlegen, auch Nachrichten f=FCr andere =
User zu=20
>>> speichern, damit du nicht darauf angewiesen bist, dass *dieser* User=20=

>>> online kommt, aber ich glaube auch so ist es schon ganz brauchbar.
> Wenn wir das nach der Methode machen funktioniert aber folgendes=20
> Szenario nicht:
> - Zuhause hat A mir einen Link geschickt.
> - Ich gehe in die UNI und will mir den Link mal ansehn.
> -!Ich gehe online aber A ist nicht mehr online
>  --> ich bekomme den Link nicht

> Die Alternative P2P L=F6sung die mir da einf=E4llt w=E4re einfach alle=20=

> Historys bei allen Kontakten zu speichern. Aber ich glaube das werden=20=

> dann doch zu viele (exponentiell viele) Daten. Es ist nat=FCrlich=20
> denkbar das man einstellt: "Lager meine History bei 10 meiner=20
> Kontakte", das w=FCrde die Datenmenke reduzieren.
> Aber auch wenn alle meine Kontakte meine komplette History haben komme=20=

> ich nicht an meine History, wenn ich an einem neuen Rechner sitze und=20=

> es ist 4:53 Uhr und niemand ist online.
> Ich f=E4nde eine P2P L=F6sung sehr gut, aber die bringt immer die=20
> Unsicherheit mit, das es mal nicht funktioniert, die Frage ist ob man=20=

> immer und =FCberall auf seine History zugreifen muss/will/soll.

Die History bei anderen Kontakten zu speichern ist nicht so toll, da=20
man nicht f=FCr jeden die History speichern kann (exponentielle Daten)=20=

und es schwierig werden k=F6nnte zu verhindern, dass andere Leute=20
rausfinden k=F6nnen mit wem ich Kontakt hatte. Zumindestens wenn die=20
Clients Histories anderer User miteinander austauschen.

Vielleicht w=E4re da die M=F6glichkeit interessant, die eigene Historie=20=

*irgendwo* hochladen zu k=F6nnen (via ftp z.B.). Wenn ich dann irgendwo=20=

Zugang zu webspace habe kann mein Client automatisch beim Beenden einen=20=

diff der History (nat=FCrlich verschl=FCsselt) hochladen, wo ein anderer=20=

Client die Sachen dann abrufen kann.

Oder eine andere Idee: Ich schicke mir die Historie via Mail =FCber =
einen=20
daf=FCr eingerichteten Mail-Account bei einem Freemailer. Der Client=20
k=F6nnte jede Stunde oder beim Beenden ein diff der History erzeugen,=20
verschl=FCsseln und an einen Mail-Account schicken. Gleichzeitig ruft er=20=

diesen Mail-Account beim Starten und dann zyklissch ab, aber bel=E4sst=20=

die Mails auf dem Server. Wenn ich dann den Client woanders starte,=20
sieht er dass auf dem Mail-Account Nachrichten sind, die er noch nicht=20=

kennt und f=FCgt diese in die History ein.

Diese Sache liesse sich auch unabh=E4ngig von der Verschl=FCsselung der=20=

Kommunikation der Clients untereinander realisieren.

Man kann ausserdem seinen normalen Mail-Account benutzen, wenn die=20
Nachrichten Subjects bekommen, die ich in meinem normalen Mail-Client=20
einfach ausfiltern kann und deshalb dort nicht zu sehen bekomme.

Gr=FC=DFe,
Thilo