[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.
Morgen werde ich es halten und dann habe ich wieder ein bisschen mehr
Zeit mich um dieses Projekt zu k=FCmmern.
Wie ist also der Status? Ich will einmal versuchen aufzuschreiben was
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
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
einer ICQ# die dem erzeugenden User gar nicht geh=F6rt
  -> ein Validierungssystem: der CryptoJIM Server stellt sicher das der
erzeugende User Zugriff auf die ICQ# hat und unterschreibt den erzeugten
key vom User mit seinem eigenem Private Key
  -> Client braucht also einen Public Key vom CryptoJIM Server um diese
Unterschrift bei anderen Key zu =FCberpr=FCfen
  -> Das sollte evtl. austauschbar sein ( jedes Jahr einen Neuen general
key?)
- Woher bekommt ein Client einen Public Key von einem anderen User? Den
Client des anderes User fragen (P2P) oder einen zentralen Keyserver?

Netzinfrastruktur:
- zentrale Server:
   -> ganz um einen Server herumkommen wird man wohl nicht, denn
irgendwer muss ja zum Beispiel die Public Key <-> UID Zuordnung verifzier=
en
   -> Allerdings sollte in jedem Fall der Client trotzdem benutzbar sein
falls dieser Server ausf=E4llt (anlegen von neuen Schl=FCsseln funktionie=
rt
dann halt nicht)
   -> Cool w=E4re wenn die clienten auch dann noch miteinander reden
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
Problem sein (wenn sie denn von einer Zentralen Instanz unterschrieben
werden)
   -> damit ein Client an einem P2P Netz teilnehmen kann muss er andere
Teilnehmer finden man braucht also so etwas wie einen Hostcache
(entweder zentraler Server oder =FCber ICQ / anderes Message Protokoll)?
   -> dezentrale Speicherung der History: tja das w=E4re was sehr sehr
feines, allerdings wird es relativ schwierig sein es zu implementieren
       -> Fragen dazu: wie lange sollen history nachrichten im Netz
gespeichert bleiben? Timestamp?
       -> Die eingesetzte Verschl=FCsselung muss besonders sicher sein
       -> Selbstheilung: es muss m=F6glich sein history nachrichten zu
rekonstruieren und sie erneut ins P2P netz einzuspeisen, falls welche
verloren gehen...
   -> Welches Protokoll f=FCr P2P ?


ICQ-Protokoll:
  -> eine Quick und Dirty l=F6sung w=E4re es eine vorhandene Implementier=
ung
zu nehmen und erstmal einen Wrapper drumherum zu schreiben
  -> gaim benutzt eine eigen Version von libfaim, (ich glaube in C++
implementiert) sie sollte unter Windows und Linux kompilieren, evtl
werde ich mal versuchen daf=FCr ein Java Wrapper zu schreiben, oder hat
jemand andere Vorschl=E4ge?
  -> fr=FCher oder sp=E4ter sollten wir das ICQ Protokoll allerdings
vollst=E4ndig in JAVA implementieren, alleine schon wegen der
Plattformunabh=E4ngigkeit, kenn vielleicht jemand einen Opensource ICQ
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.
libfaim zu schreiben) damit wir schon mal Zugriff auf das ICQ-Netzwerk
bekommen sp=E4ter k=F6nnen wir das dann durch unsere eigene Implementieru=
ng
ersetzen. Hat vielleicht irgendwer schonmal eine C++ Library in Java
eingebettet?

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

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

GUI:
Die muss gut einerseits gut geplant werden, andererseits brauchen wir
auch ziemlich bald irgendetwas mit dem wir Testen k=F6nnen. Wir sollten
versuchen Engine und GUI m=F6glichst gut zu trennen um evtl. erst eine
einfach GUI zu implementieren und diese nachher durch eine sch=F6nere
bessere auszutauschen. Marius, wie sieht deine Energie aus, hast du Lust
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
zu betreiben,  wie sieht es bei euch mit der Zeit aus? Noch vor
Semesterende? in den Semesterferien? oder eher danach?