Re: [Cryptojim-devel] Planung

[Arnd H. <ar...@ar...>]

Thilo Hannemann wrote:

>
> 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=20
>>>> nicht 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 J=
ava=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 komplizier=
t=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.

Ja deswegen w=FCrde ich zumindest nicht die Kommandozeilenversion
benutzen, vielleicht h=F6chstens die Library aber auch das wird
wahrscheinlich ziemlich aufwendig sein.

>
> 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 Kommandozei=
le=20
> zu verwenden.

Ehrlich gesagt ist es mir noch nicht ersichtlich welcher Vorteil der
Schl=FCsselaustausch mit PGP/GPG bringen soll. Es wird meiner Meinung nac=
h
dadurch nur unn=F6tig kompiliziert, dann k=F6nnte man f=FCr das verschl=FC=
sselte
senden von Nachrichten lieber SSL benutzen, welches soweit ich wei=DF
schon in Java implementiert ist.

>
> Das h=E4tte dann auch zur Folge, dass die History f=FCr eine Session mi=
t=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.

Ja das sollte schon so sein. Ein symmetrischer Schl=FCssel pro "Session."

>
>
>>>>
>>>> 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 =FCbe=
r=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 Numme=
r=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 gu=
te=20
> Idee.

Hmm werden nicht sowieso nur Identit=E4ten von anderen Leute unterschiebe=
n
und nicht der Key selber?

>
>>>> Eine zentrale Speicherung der History ist eigentlich kein Problem,=20
>>>> wenn der Server nur die verschl=FCsselten Nachrichten speichert. Abe=
r=20
>>>> vielleicht geht das auch P2P:
>>>> - Jeder Client speichert alle Nachrichten, die er mit anderen=20
>>>> Leuten ausgetauscht hat
>>>> - Falls sich jemand von den "anderen" anmeldet, kann dieser andere=20
>>>> anfragen, welche Nachrichten von ihm in der History sind. Falls=20
>>>> dort 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 Use=
r zu=20
>>>> speichern, damit du nicht darauf angewiesen bist, dass *dieser*=20
>>>> User online kommt, aber ich glaube auch so ist es schon ganz=20
>>>> 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=20
>> komme ich nicht an meine History, wenn ich an einem neuen Rechner=20
>> sitze und 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.

Das ist ein guter Punkt. Wie verhindert man das andere Leute wissen mit
wem man Kontakt hatte? Um die Nachrichten effizient anzufragen muss ja
auch soetwas wie ein Indexschl=FCssel vorhanden sein. Man k=F6nnte einen
Hash bilden und danach suchen lassen:
hash(Empf=E4nger ICQ# + Schl=FCssel den nur der User wei=DF) Er selber we=
i=DF
dann wie die Hashwerte der gesuchten nachrichten aussehen. Und dann muss=20
man die Speicherung der Daten auf anderen Clients irgendwie zuf=E4llig=20
verteilen, so dass keine R=FCckschl=FCsse darauf gezogen werden k=F6nnen =
mit
wem ich kommuniziert habe.
Aber da die ICQ Kontaktliste eh auf dem ICQ Server liegt, wissen die=20
b=F6sen sowieso schon ungef=E4hr mit wem ich kommuniziere....

>
> 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=20
> einen diff der History (nat=FCrlich verschl=FCsselt) hochladen, wo ein=20
> anderer Client die Sachen dann abrufen kann.

Evtl. auch eine Idee: ein PHP Frontend zu einer MySQL Datenbank
schreiben, wo nutzer ihre daten reinpumpen k=F6nnen....

>
> Oder eine andere Idee: Ich schicke mir die Historie via Mail =FCber=20
> einen daf=FCr eingerichteten Mail-Account bei einem Freemailer. Der=20
> Client k=F6nnte jede Stunde oder beim Beenden ein diff der History=20
> erzeugen, verschl=FCsseln und an einen Mail-Account schicken.=20
> Gleichzeitig ruft er diesen Mail-Account beim Starten und dann=20
> zyklissch ab, aber bel=E4sst die Mails auf dem Server. Wenn ich dann de=
n=20
> Client woanders starte, sieht er dass auf dem Mail-Account Nachrichten=20
> sind, die er noch nicht kennt und f=FCgt diese in die History ein.
>
Das h=F6rt sich sehr abenteuerlich an und f=FChrt unter Umst=E4nden zu ei=
nem
hohen Mailaufkommen. Ausserdem ist die Frage wie sehr mir ein diff
=FCberhaupt hilft. Wenn ich mich an einen neuen Rechner setze wo keine
(oder nur eine sehr alte Version meiner History liegt) habe ich keine
chance an meinen neuen Nachrichten zu bekommen.


Bis denn Arnd