cryptojim-devel Mailing List for CryptoJIM (Java Instant Messenger)
Status: Planning
Brought to you by:
arndh
Menu
▾
▴
cryptojim-devel — List to discuss development and design issues
You can subscribe to this list here.
| 2005 |
Jan
(8) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Lars H. <la...@ho...> - 2005-02-12 13:18:16
|
Moin, auf http://www.secos.net/ gibt es einen IM der all seine Nachrichten verschl=FCsselt =FCbertr=E4gt. Er ist nicht zu ICQ oder anderen Protokoll= en kompatibel. Mit drin ist auch noch eine Mailapplikation. Den Client gibt es f=FCr Linux, Windows, Mac, ... und er ist schnell, w=FCrde mal tippen = der ist in Qt geschrieben oder so was. Auf jeden Fall w=FCrde ich den gern ma= l ausprobieren. Meine ID ist lars@@secos.org Gefunden habe ich das Programm durch die Mailingliste vom LuFG i4 http://www-i4.informatik.rwth-aachen.de/lufg/ --=20 Some operating systems are called `user friendly', Linux however is `expert friendly'. mfG Lars |
|
From: Arnd H. <ar...@ar...> - 2005-01-30 12:25:39
|
Hallo, ich habe mich am Wochenende mal ein bisschen nach existierenden ICQ=20 Implementierungen umgesehen und bin auf drei Alternativen gesto=DFen: 1.) modifizierte libfaim[2] aus GAIM[1] Diese implementiert das Oscar Protokoll welches sowohl von AIM als auch=20 von ICQ benutzt wird. Diese Library ist in C geschrieben, kompiliert=20 aber sowohl unter Windows als auch unter Linux. Es ist zwar m=F6glich in=20 Java solche Librarys mit Hilfe vom JNI (Java Native Interface)=20 einzubinden blo=DF ist es gerade bei libfaim sehr sehr schwierig. Man=20 m=FCsste Versuchen die Datenstrukturen die libfaim benutzt unter Java=20 abzubilden. Die Datenstrukturen in libfaim sind allerdings alles andere=20 als sauber, so werden unter anderem interne (void *) pointer benutzt=20 *grusel. Vorteil w=E4re allerdings das GAIM sehr aktiv gepflegt wird und so evtl.=20 =C4nderungen am Oscar Protokoll sehr schnell eingepflegt werden k=F6nnten= .=20 Andererseits glaube ich, dass es f=FCr ein Java Applet nahezu unm=F6glich= =20 sein wird native Bibliotheken zu laden. Und evtl wollen wir ja auch mal=20 eine Applet Version von CryptoJIM erstellen. 2.) wiederverwenden von Code aus JIMM[3] JIMM ist ein mobiler java ICQ Client f=FCr Handys. Er besitzt zwar sehr=20 eingeschr=E4nkte Funktionalit=E4t allerdings scheint auch JIMM gut gepfle= gt=20 zu werden, so dass kritische Bugs relativ schnell gefixt werden sollten. 3.) Verwendung von ooimlib[4] alias JOscarLib Das ist eine in Java implementierte ICQ-Library. Allerdings scheinen=20 Bugs schon lange nicht mehr gefixt zu werden, und in der momentanten=20 Fassung lassen sich keine Kontaktlisten vom ICQ Server laden.... :-/ Das=20 letzte Release ist vom 19.07.2003. Fazit: Also davon libfaim zu benutzen bin ich eigentlich schon wieder ab, es=20 bedeutet extremes Gefrickel und das macht glaube ich nicht sonderlich=20 Spa=DF. Bleiben also JIMM oder JOscarLib. Der Code in JIMM scheint sehr=20 schlank zu sein, was mir irgendwie gef=E4llt. Vielleicht solten wir mit=20 der schlanken Implementierung von JIMM anfangen und dann Funktionen die=20 wir ben=F6tigen selber implementieren, was meint ihr? URLs: [1] http://gaim.sourceforge.net [2] http://cvs.sourceforge.net/viewcvs.py/gaim/gaim/src/protocols/oscar/ [3] http://jimm.sourceforge.net/ [4] http://sourceforge.net/projects/ooimlib/ |
|
From: Arnd H. <ar...@ar...> - 2005-01-30 11:54:59
|
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 |
|
From: Thilo H. <thi...@we...> - 2005-01-29 12:34:06
|
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 |
|
From: Lars <la...@ho...> - 2005-01-29 11:53:26
|
Moin, arnd schrieb: > Thilo Hannemann wrote: >=20 >> Hallo Arnd, >> >> 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. >=20 >=20 > Im Prinzip w=FCrde ich das zwar gerne tun, allerdings vermute ich das e= s=20 > 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 mach= t=20 Enigmail das so meine ich. Das d=FCrfte auch nicht zu kompliziert sein da= =20 einen Wrapper drum zu schreiben. >=20 >=20 >> >> Eine Zuordnung von ICQ# und Key ist nicht n=F6tig! Anhand des Keys wei= ss=20 >> man doch, wer die Nachricht geschrieben hat, egal unter welcher ICQ#=20 >> er es gemacht hat. Das einzige was wirklich interessiert ist die=20 >> Zuordnung Key <-> Name und die kriegst du =FCber die PGP-Infrastruktur= . >=20 >=20 > 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 = und=20 > deswegen muss es meiner Meinung nach eine feste Zuordnung Key <-> ICQ#= =20 > geben. >=20 Also ich hab das so verstanden das man bei PGP IDs einf=FCgen kann. Diese= =20 IDs k=F6nnen Emailadressen sein aber auch halt ICQ#. Warum also nicht so=20 eine ID in den PGP-Key einf=FCgen und dann danach suchen. >> >> 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 anderen=20 >> Client f=FCr den selben User abgeschickt worden sind), dann fordert er= =20 >> [...] >> 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 denkbar= =20 das man einstellt: "Lager meine History bei 10 meiner Kontakte", das=20 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 es=20 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. >> >> So, das w=E4rs f=FCrs erste, >> machs gut, >> Thilo=20 >=20 >=20 > Bis denn Arnd mfG Lars |
|
From: Thilo H. <thi...@we...> - 2005-01-28 20:03:01
|
Am 28.01.2005 um 17:57 schrieb arnd: > 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 = es=20 > schwer zu implementieren ist. Wei=DF jemand ob es f=FCr gpg eine Java=20= > library gibt? Wahrscheinlich nicht, oder? Das k=F6nnte in der Tat ein Problem darstellen. Wobei die Alternative,=20= alles noch einmal zu programmieren auch nicht so doll ist. Man k=F6nnte=20= vielleicht versuchen, die entsprechenden Teile von GPG in Java=20 umzuschreiben - obwohl das sicher auch ein gewaltiger Aufwand ist und=20 nur von einem Studenten zu bew=E4ltigen ist :-). >> >> Eine Zuordnung von ICQ# und Key ist nicht n=F6tig! Anhand des Keys=20 >> weiss man doch, wer die Nachricht geschrieben hat, egal unter welcher=20= >> ICQ# er es gemacht hat. Das einzige was wirklich interessiert ist die=20= >> Zuordnung Key <-> Name und die kriegst du =FCber die = PGP-Infrastruktur. > > Meiner Meinung ist eine solche Zuordnung doch wichtig um die=20 > Verschl=FCsselung nahtlos in so einen Clienten zu integrieren. > Nehmen wir an ich will jemanden aus meiner ICQ Liste eine ICQ=20 > Nachricht schicken: > daf=FCr brauche ich SEINEN public key. Den muss ich also irgendwie=20 > bekommen. Du schl=E4gst vor den PGP Keyserver zu fragen, oki aber = wonach=20 > soll ich suchen? Nach dem Namen? Woher soll ich den wissen? Ganz=20 > abgesehen davon das es Leute mit gleichem Namen gibt. Nach der Email=20= > adresse? Woher soll ich die wissen? > > 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. Auch bei ICQ gibt es doch die Autorisierung. Da sollte man den=20 Schl=FCsseltausch doch integrieren k=F6nnen. Und wenn ich einmal einen=20= Schl=FCssel ausgetauscht habe kann ich das a la ssh l=F6sen: meckern, = falls=20 dieselbe ICQ# pl=F6tzlich mit einem anderen Key ankommt. Die Zuordnung=20= Key <-> ICQ# wird dann nur im jeweiligen Client vorgenommen. Andere L=F6sung w=E4re: Wenn der Client eine ICQ message an jemanden=20 schickt, dessen Schl=FCssel er noch nicht hat, schickt er erstmal eine=20= Zeile a la "Your're contact by xxxClient and your ICQ client doesn't=20 support the crypto protocoll. Please ignore this line." Der Client am=20 anderen Ende erkennt daran, dass ihn da jemand kontaktiert, der den=20 Schl=FCssel haben will und antwortet mit dem - wie auch immer gearteten=20= Schl=FCssel. Dann hast du den Schl=FCssel. Und dass es der Schl=FCssel = vom=20 entsprechenden User ist weiss du auch schon - immerhin hast du mit dem=20= gerade geredet. Falls der andere User einen anderen Client benutzt kriegt er als erste=20= Nachricht diese Zeile, was ihn hoffentlich nicht zu sehr verwirrt und=20 ausserdem Werbung f=FCr den Client macht :-). Evtl. gibt es auch eine=20 M=F6glichkeit rauszufinden welchen Client die Gegenseite benutzt, ohne=20= eine Nachricht zu schreiben. Der einzige Nachteil ist, dass du jemanden keine verschl=FCsselte=20 Nachricht schreiben kannst wenn du noch nie mit ihm geredet hast und er=20= nicht online ist wenn du die Nachricht schickst. Das sollte aber zu=20 verschmerzen sein. Man k=F6nnte nat=FCrlich die Clients auch mit anderen=20= Clients Schl=FCssel mit dazugeh=F6rigen ICQ#ern austauschen lassen. = Obwohl=20 man dann nat=FCrlich mitkriegen w=FCrde, welcher Client mit welchen = Nummern=20 Kontakt hatte - das ist vielleicht nicht so gut. Gr=FC=DFe, Thilo |
|
From: arnd <ar...@ar...> - 2005-01-28 16:58:29
|
Thilo Hannemann wrote: > Hallo Arnd, > > 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 es=20 schwer zu implementieren ist. Wei=DF jemand ob es f=FCr gpg eine Java=20 library gibt? Wahrscheinlich nicht, oder? > Das w=FCrde dann auch bedeuten, dass du f=FCr den Schl=FCsselaustausch=20 > keinen Server aufsetzen brauchst, sondern die f=FCr PGP/GPG benutzen=20 > kannst. Das w=E4re eine =DCberlegung wert. > > Eine Zuordnung von ICQ# und Key ist nicht n=F6tig! Anhand des Keys weis= s=20 > man doch, wer die Nachricht geschrieben hat, egal unter welcher ICQ#=20 > er es gemacht hat. Das einzige was wirklich interessiert ist die=20 > Zuordnung Key <-> Name und die kriegst du =FCber die PGP-Infrastruktur. Meiner Meinung ist eine solche Zuordnung doch wichtig um die=20 Verschl=FCsselung nahtlos in so einen Clienten zu integrieren. Nehmen wir an ich will jemanden aus meiner ICQ Liste eine ICQ Nachricht=20 schicken: daf=FCr brauche ich SEINEN public key. Den muss ich also irgendwie=20 bekommen. Du schl=E4gst vor den PGP Keyserver zu fragen, oki aber wonach=20 soll ich suchen? Nach dem Namen? Woher soll ich den wissen? Ganz=20 abgesehen davon das es Leute mit gleichem Namen gibt. Nach der Email=20 adresse? Woher soll ich die wissen? Das einzige was ich von dem anderen Benutzer wei=DF ist die ICQ Nummer un= d=20 deswegen muss es meiner Meinung nach eine feste Zuordnung Key <-> ICQ#=20 geben.=20 > > Und falls das nicht geht, dann weisst du einfach nicht, wer an der=20 > anderen Seite sitzt, da hilft die ICQ# auch nicht viel.=20 Ich will ja auch gar nicht 100% wissen welche physikalische Person am=20 anderen Ende sitzt. Das kann ich sowieso nicht. Auch bei PGP nicht. Was=20 hilft es dir das du wei=DFt das ein "Key" von Michael Mueller ist, wenn e= s=20 auf der Welt 200 Leute mit dem Namen Michael Mueller gibt? Ich will nur das ich den Key bekomme von demjenigen der die Kontrolle=20 =FCber diese ICQ# hat. (Im Fall von PGP-globaldirectory ist es halt die=20 Email adresse.) > > 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 anderen=20 > Client f=FCr den selben User abgeschickt worden sind), dann fordert er=20 > sie an und vervollst=E4ndigt sein Archiv. In den Archiven stehen nur=20 > verschl=FCsselte Nachrichten, sodass nur der Autor und der Addressat di= e=20 > Nachricht aus der History entschl=FCsseln k=F6nnen, selbst wenn das Sys= tem=20 > irgendwie kompromittiert werden k=F6nnte. > - Das ganze liesse sich =FCber spezielle "Escape-Sequenzen" auf das=20 > normale ICQ-Protokoll draufsetzen. > > 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 z= u=20 > speichern, damit du nicht darauf angewiesen bist, dass *dieser* User=20 > online kommt, aber ich glaube auch so ist es schon ganz brauchbar. > > In einer weiteren Version k=F6nntest du dann "freigeben", dass auch=20 > bestimmte andere User deine History speichern. Da k=F6nnte man dann ein= =20 > Protokoll =FCberlegen, dass der Client die History an andere Clients nu= r=20 > dann rausr=FCckt, wenn sie vom Autor der Nachricht dazu autorisiert sin= d=20 > (damit niemand einfach die History aller User an Land ziehen kann -=20 > auch wenn die verschl=FCsselt ist und er sie nicht entschl=FCsseln kann= =20 > ist das ja unn=F6tig). > > Das Nette an diesem Protokoll w=E4re, dass es sehr "lokal" bleibt und=20 > daher wohl wenig Probleme bei der Skalierung macht. Und in der=20 > Version, wo du nur die History zwischen Autor und Adressat abgleichst=20 > ist es auch ohne Verschl=FCsselung sinnvoll machbar. Joah ganz gute Idee. > > So, das w=E4rs f=FCrs erste, > machs gut, > Thilo=20 Bis denn Arnd |
|
From: Arnd H. <ar...@ar...> - 2005-01-27 20:11:03
|
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?
|
|
From: Arnd H. <ar...@ar...> - 2005-01-27 17:01:28
|
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?
|
