Re: [Cryptojim-devel] Planung

[arnd <ar...@ar...>]

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