[Cryptojim-devel] Planung

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

Hallo Allerseits,
ich denke es wird ok sein in dieser Maillingliste deutsch zu schreiben....

Hatte leider in in letzter Zeit ziemlich viel mit meinem Seminar zu tun.=20
Morgen werde ich es halten und dann habe ich wieder ein bisschen mehr=20
Zeit mich um dieses Projekt zu k=FCmmern.
Wie ist also der Status? Ich will einmal versuchen aufzuschreiben was=20
wir uns bist jetzt so f=FCr Gedanken gemacht haben

Public Key Infrastruktur:
- Jeder User braucht mindestens einen Public und Private key
- Wie Verkn=FCpfung von Key und UID (z.B. ICQ#)?
- F=FCr jedes IM System einen eigenes Schl=FCsselpaar?
- M=F6glichkeit zu einem vorhanden Key neue UID hinzuzuf=FCgen?
- Verschl=FCsselung des Private Key mit einem Passwort / Speicherung loka=
l=20
auf Rechner / USBstick
- Das einzig sichere ist die Schl=FCsselerzeugung beim Client selber
  -> es darf nicht m=F6glich sein das ein Schl=FCssel generiert wird zu=20
einer ICQ# die dem erzeugenden User gar nicht geh=F6rt
  -> ein Validierungssystem: der CryptoJIM Server stellt sicher das der=20
erzeugende User Zugriff auf die ICQ# hat und unterschreibt den erzeugten=20
key vom User mit seinem eigenem Private Key
  -> Client braucht also einen Public Key vom CryptoJIM Server um diese=20
Unterschrift bei anderen Key zu =FCberpr=FCfen
  -> Das sollte evtl. austauschbar sein ( jedes Jahr einen Neuen general=20
key?)
- Woher bekommt ein Client einen Public Key von einem anderen User? Den=20
Client des anderes User fragen (P2P) oder einen zentralen Keyserver?

Netzinfrastruktur:
- zentrale Server:
   -> ganz um einen Server herumkommen wird man wohl nicht, denn=20
irgendwer muss ja zum Beispiel die Public Key <-> UID Zuordnung verifzier=
en
   -> Allerdings sollte in jedem Fall der Client trotzdem benutzbar sein=20
falls dieser Server ausf=E4llt (anlegen von neuen Schl=FCsseln funktionie=
rt=20
dann halt nicht)
   -> Cool w=E4re wenn die clienten auch dann noch miteinander reden=20
k=F6nnten wenn sie keinen Zugriff aufs ICQ Netzwerk mehr haben....
   -> Soll die Speicherung der History zentral erfolgen?
     -> Es w=E4r definitiv viel einfacher zu implementieren

- P2P:
   -> die Public Keys dezentral zu verteilen sollte eigentlich kein=20
Problem sein (wenn sie denn von einer Zentralen Instanz unterschrieben=20
werden)
   -> damit ein Client an einem P2P Netz teilnehmen kann muss er andere=20
Teilnehmer finden man braucht also so etwas wie einen Hostcache=20
(entweder zentraler Server oder =FCber ICQ / anderes Message Protokoll)?
   -> dezentrale Speicherung der History: tja das w=E4re was sehr sehr=20
feines, allerdings wird es relativ schwierig sein es zu implementieren
       -> Fragen dazu: wie lange sollen history nachrichten im Netz=20
gespeichert bleiben? Timestamp?
       -> Die eingesetzte Verschl=FCsselung muss besonders sicher sein
       -> Selbstheilung: es muss m=F6glich sein history nachrichten zu=20
rekonstruieren und sie erneut ins P2P netz einzuspeisen, falls welche=20
verloren gehen...
   -> Welches Protokoll f=FCr P2P ?


ICQ-Protokoll:
  -> eine Quick und Dirty l=F6sung w=E4re es eine vorhandene Implementier=
ung=20
zu nehmen und erstmal einen Wrapper drumherum zu schreiben
  -> gaim benutzt eine eigen Version von libfaim, (ich glaube in C++=20
implementiert) sie sollte unter Windows und Linux kompilieren, evtl=20
werde ich mal versuchen daf=FCr ein Java Wrapper zu schreiben, oder hat=20
jemand andere Vorschl=E4ge?
  -> fr=FCher oder sp=E4ter sollten wir das ICQ Protokoll allerdings=20
vollst=E4ndig in JAVA implementieren, alleine schon wegen der=20
Plattformunabh=E4ngigkeit, kenn vielleicht jemand einen Opensource ICQ=20
Java client (auch wenn es nur f=FCrs handy ist)

Oki die Frage ist wie packen wir es an?
ICQ:
Mein Vorschlag: Wir fangen an einen Wrapper f=FCr eine ICQ Library (z.B.=20
libfaim zu schreiben) damit wir schon mal Zugriff auf das ICQ-Netzwerk=20
bekommen sp=E4ter k=F6nnen wir das dann durch unsere eigene Implementieru=
ng=20
ersetzen. Hat vielleicht irgendwer schonmal eine C++ Library in Java=20
eingebettet?

Verschl=FCsselung:
seeehr viel zu kl=E4ren, was benutzen wir f=FCr Schl=FCssel? Sollen wir=20
vielleicht sogar versuchen zu pgp oder sowas kompatibel zu werden?=20
Marcel kannst du vielleicht dazu was schreiben?

Netzwerk:
Mein Vorschlag: wir beginnen mit einer zentralen Speicherung der History=20
und behalten im Auge sp=E4ter auf eine P2P L=F6sung umzusteigen, andere=20
Vorschl=E4ge?

GUI:
Die muss gut einerseits gut geplant werden, andererseits brauchen wir=20
auch ziemlich bald irgendetwas mit dem wir Testen k=F6nnen. Wir sollten=20
versuchen Engine und GUI m=F6glichst gut zu trennen um evtl. erst eine=20
einfach GUI zu implementieren und diese nachher durch eine sch=F6nere=20
bessere auszutauschen. Marius, wie sieht deine Energie aus, hast du Lust=20
die Planung daf=FCr in Gang zu bringen?

Bis denn
Arnd


P.S.: wir k=F6nnten uns evtl. auch alle mal Treffen um ein Brainstorming=20
zu betreiben,  wie sieht es bei euch mit der Zeit aus? Noch vor=20
Semesterende? in den Semesterferien? oder eher danach?