Updated documentation
This commit is contained in:
parent
a9081a8240
commit
4883d8072e
@ -2,14 +2,14 @@
|
||||
|
||||
\subsection{Was sind Metadaten?}
|
||||
|
||||
Verschlüsselungstechnologie wie PGP oder S/MIME ermöglicht es zwar auf sichere Art und Weise Nachrichten vor neugierigen Augen zu schützen, doch seit Edward Snowden den NSA-Skandal aufgedeckt hat wissen wir dass Metadaten --- vor allem Informationen darüber wer mit wem kommuniziert -- genauso interessant und viel einfacher zu analysieren sind.
|
||||
Metadaten sind informationen, welche als Nebeneffekte der eigentlichen Kommunikation auftreten. Wer schreibt wem? Wann? Über welchen Kanal?
|
||||
|
||||
Es gibt einige Beispiele wie Sie durch Metadaten in Schwierigkeiten kommen können. Wenn Sie jemandem schreiben der in der IS ist, kann es durchaus sein dass Sie das nächste mal nicht in die USA fliegen können. Die No-Fly-Liste kümmert sich nicht darum dass Sie Journalist sind, oder keine Ahnung hatten dass diese Person ein Terrorist war.
|
||||
Verschlüsselungstechnologien wie PGP oder S/MIME ermöglichen uns auf sichere Art und Weise Nachrichten vor neugierigen Augen zu schützen. Doch seit Edward Snowden den NSA-Skandal aufgedeckt hat wissen wir, dass Metadaten --- vor allem Informationen darüber wer mit wem kommuniziert -- genauso interessant und viel einfacher zu analysieren sind.
|
||||
|
||||
Wenn Samsung erfährt, dass Apple ergiebig mit dem einzigen Produzent eines raffinierten kleinen Sensors ist, brauchen sie keine Details --- das S7 wird ebenfalls einen solchen enthalten. (Dass Apple ihn braucht um ein Auto zu bauen haben sie dabei übersehen.)
|
||||
Es gibt einige Beispiele wie Sie durch Metadaten in Schwierigkeiten kommen können. Wenn Sie jemandem schreiben der in der IS ist, kann es durchaus sein, dass Sie das nächste mal nicht in die USA fliegen können. Die No-Fly-Liste kümmert sich dabei nicht darum dass Sie Journalist sind oder keine Ahnung hatten dass diese Person ein Terrorist war.
|
||||
|
||||
\subsection{Wie können wir Metadaten verstecken?}
|
||||
|
||||
Mit E-Mail können wir die Verbindung zu unserem Mail-Provider verschlüsseln, und dieser wiederum die Verbindung mit dem Provider unseres Gesprächspartners. Dabei können wir nur hoffen dass unser Anbieter und derjenige des Empfängers sowohl vertrauenswürdig als auch kompetent sind.\footnote{Gratis sollte er natürlich auch noch sein.}
|
||||
Mit E-Mail können wir die Verbindung zu unserem Mail-Provider verschlüsseln und dieser wiederum die Verbindung mit dem Provider unseres Gesprächspartners. Dabei können wir nur hoffen, dass unser Anbieter und derjenige des Empfängers sowohl vertrauenswürdig als auch kompetent sind.\footnote{Gratis sollte er natürlich auch noch sein.}
|
||||
|
||||
Bei Bitmessage senden wir eine Nachricht and eine grosse Anzahl Teilnehmer, darunter den eigentlichen Empfänger. Die Nachricht ist dabei so verschlüsselt, dass nur die Person welche den privaten Schlüssel besitzt diese entschlüsseln kann. Alle Teilnehmer versuchen dies um die für sie bestimmten Nachrichten zu finden.
|
||||
Bei Bitmessage senden wir eine Nachricht an eine grosse Anzahl Teilnehmer, darunter den eigentlichen Empfänger. Die Nachricht ist dabei so verschlüsselt, dass nur der Besitzer des privaten Schlüssels diese lesen kann. Alle Teilnehmer versuchen nun, alle Meldungen zu entschlüsseln, um so die für sie bestimmten Nachrichten zu finden.
|
||||
@ -36,4 +36,13 @@
|
||||
author = {Warren, Jonathan 'Atheros' and ISibbol},
|
||||
note = {\\ \url{https://github.com/Bitmessage/PyBitmessage/issues/112}},
|
||||
year = {2015},
|
||||
}
|
||||
|
||||
@ONLINE{xkcd:538,
|
||||
url = {http://xkcd.com/538/},
|
||||
title = {Security},
|
||||
publisher = {xkcd.com},
|
||||
urldate = {2015-05-25},
|
||||
author = {Randall Munroe},
|
||||
note = {\\ \url{http://xkcd.com/538/}}
|
||||
}
|
||||
BIN
docs-de/images/signature.pdf
Normal file
BIN
docs-de/images/signature.pdf
Normal file
Binary file not shown.
188
docs-de/images/signature.svg
Normal file
188
docs-de/images/signature.svg
Normal file
@ -0,0 +1,188 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
width="432.34531"
|
||||
height="100.50558"
|
||||
id="svg2"
|
||||
version="1.1"
|
||||
inkscape:version="0.48.5 r10040"
|
||||
sodipodi:docname="signature.svg">
|
||||
<defs
|
||||
id="defs4" />
|
||||
<sodipodi:namedview
|
||||
id="base"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1.0"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:zoom="1.979899"
|
||||
inkscape:cx="252.2677"
|
||||
inkscape:cy="-17.844674"
|
||||
inkscape:document-units="px"
|
||||
inkscape:current-layer="layer1"
|
||||
showgrid="false"
|
||||
inkscape:window-width="1632"
|
||||
inkscape:window-height="1005"
|
||||
inkscape:window-x="48"
|
||||
inkscape:window-y="0"
|
||||
inkscape:window-maximized="1"
|
||||
fit-margin-top="0"
|
||||
fit-margin-left="0"
|
||||
fit-margin-right="0"
|
||||
fit-margin-bottom="0" />
|
||||
<metadata
|
||||
id="metadata7">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title></dc:title>
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<g
|
||||
inkscape:label="Ebene 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(-110.35921,-353.40277)">
|
||||
<rect
|
||||
y="399.45847"
|
||||
x="185.46117"
|
||||
height="31.314728"
|
||||
width="253.52907"
|
||||
id="rect3031"
|
||||
style="fill:none;stroke:#000000" />
|
||||
<rect
|
||||
style="fill:none;stroke:#000000"
|
||||
id="rect3029"
|
||||
width="228.88622"
|
||||
height="31.314728"
|
||||
x="313.3183"
|
||||
y="373.45847" />
|
||||
<g
|
||||
id="g3024"
|
||||
transform="translate(-2.777866,0)">
|
||||
<rect
|
||||
y="387.68179"
|
||||
x="113.13708"
|
||||
height="30.304565"
|
||||
width="74.751282"
|
||||
id="rect2985"
|
||||
style="fill:#467d97;fill-opacity:1;stroke:none" />
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text2987"
|
||||
y="407.88486"
|
||||
x="125.55178"
|
||||
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#ffffff;fill-opacity:1;stroke:none;font-family:Constantia;-inkscape-font-specification:Constantia"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;fill:#ffffff;font-family:Consolas;-inkscape-font-specification:Consolas"
|
||||
y="407.88486"
|
||||
x="125.55178"
|
||||
id="tspan2989"
|
||||
sodipodi:role="line">nonce</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
id="g3019"
|
||||
transform="translate(-1.7677265,0)">
|
||||
<rect
|
||||
style="fill:#aa0000;fill-opacity:1;stroke:none"
|
||||
id="rect2991"
|
||||
width="127.27923"
|
||||
height="30.304565"
|
||||
x="186.87822"
|
||||
y="387.68179" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#ffffff;fill-opacity:1;stroke:none;font-family:Constantia;-inkscape-font-specification:Constantia"
|
||||
x="220.4944"
|
||||
y="407.88486"
|
||||
id="text2993"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan2995"
|
||||
x="220.4944"
|
||||
y="407.88486"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;fill:#ffffff;font-family:Consolas;-inkscape-font-specification:Consolas">header</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
id="g3014"
|
||||
transform="translate(1.2627377,0)">
|
||||
<rect
|
||||
y="387.68179"
|
||||
x="311.12698"
|
||||
height="30.304565"
|
||||
width="127.27923"
|
||||
id="rect2997"
|
||||
style="fill:#660080;fill-opacity:1;stroke:none" />
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text2999"
|
||||
y="407.88486"
|
||||
x="340.09814"
|
||||
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#ffffff;fill-opacity:1;stroke:none;font-family:Constantia;-inkscape-font-specification:Constantia"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;fill:#ffffff;font-family:Consolas;-inkscape-font-specification:Consolas"
|
||||
y="407.88486"
|
||||
x="340.09814"
|
||||
id="tspan3001"
|
||||
sodipodi:role="line">payload</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
id="g3009"
|
||||
transform="translate(3.2830548,0)">
|
||||
<rect
|
||||
style="fill:#217821;fill-opacity:1;stroke:none"
|
||||
id="rect3003"
|
||||
width="103.03555"
|
||||
height="30.304565"
|
||||
x="436.38589"
|
||||
y="387.68179" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#ffffff;fill-opacity:1;stroke:none;font-family:Constantia;-inkscape-font-specification:Constantia"
|
||||
x="447.86951"
|
||||
y="407.88486"
|
||||
id="text3005"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3007"
|
||||
x="447.86951"
|
||||
y="407.88486"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;fill:#ffffff;font-family:Consolas;-inkscape-font-specification:Consolas">signatur</tspan></text>
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Constantia;-inkscape-font-specification:Constantia"
|
||||
x="378.20868"
|
||||
y="366.64789"
|
||||
id="text3033"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3035"
|
||||
x="378.20868"
|
||||
y="366.64789">verschlüsselt</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Constantia;-inkscape-font-specification:Constantia"
|
||||
x="282.60217"
|
||||
y="449.50504"
|
||||
id="text3037"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3039"
|
||||
x="282.60217"
|
||||
y="449.50504">signiert</tspan></text>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 6.9 KiB |
BIN
docs-de/images/xkcd-security.png
Normal file
BIN
docs-de/images/xkcd-security.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
Binary file not shown.
@ -44,7 +44,7 @@
|
||||
\label{fig:inbox}
|
||||
\end{wrapfigure}
|
||||
|
||||
Man braucht natürlich nur schon die Idee des Protokolls, um auf die Idee zu kommen Meldungen an mehrere Empfänger gleichzeitig zu senden. Dies geht so, dass die Adresse selbst in einen privaten Schlüssel umgewandelt wird und so zum \textit{entschlüsseln} der Broadcasts benutzt werden kann. Entsprechend kann man beim Erfassen einer Nachricht wählen ob sie an einen bestimmten Empfänger gehen soll, oder an alle, die unsere Broadcasts abonniert haben. Jeder, der die Adresse kennt kann dabei allerdings ihre Broadcasts lesen.
|
||||
Wenn man die Funktionsweise des Protokolls sieht, liegt die Idee natürlich nicht weit Meldungen an mehrere Empfänger gleichzeitig senden zu wollen. Dies geht so, dass die Adresse selbst in einen privaten Schlüssel umgewandelt wird und so zum \textit{entschlüsseln} der Broadcasts benutzt werden kann. Entsprechend kann man beim Erfassen einer Nachricht wählen ob sie an einen bestimmten Empfänger gehen soll oder an alle, die unsere Broadcasts abonniert haben. Jeder, der die Adresse kennt kann dabei allerdings die darüber gesendeten Broadcasts lesen.
|
||||
|
||||
\newpage
|
||||
\section{Protokoll}
|
||||
@ -76,66 +76,70 @@
|
||||
\end{enumerate}
|
||||
|
||||
\subsubsection{object}
|
||||
Ein Objekt ist einer Art von Meldung, deren Payload zwischen allen Netzwerkknoten verteilt wird. Manchmal wird auch nur der Payload gemeint. Um ein Objekt zu senden, wird ein \textit{Proof of Work} benötigt.
|
||||
Ein Objekt ist eine Art Meldung, deren Payload zwischen allen Netzwerkknoten verteilt wird. Manchmal wird auch nur der Payload gemeint. Um ein Objekt zu senden, wird ein \textit{Proof of Work} benötigt.
|
||||
|
||||
\subsection{Ablauf}
|
||||
|
||||
Der neu gestartete Netzwerkknoten \node{A} stellt die Verbindung zu einem zufälligen Knoten \node{B} ais seinem Knotenverzeichnis her und sendet eine \msg{version}-Meldung, die die aktuellste unterstützte Protokollversion ankündigt. Falls \node{B} die Version akzeptiert,\footnote{Eine Version wird normalerweise akzeptiert, wenn sie höher oder gleich der eigenen höchsten unterstützten Version ist. Knoten welche eine experimentelle Protokollversion implementieren können auch ältere Versionen akzeptieren.} antwerted er mit einer \msg{verack}-Meldung, gefolgt von der eigenen \msg{version} mit ihrer neusten unterstützten Protokollversion. Knoten \node{A} entscheidet nun ob er die Version von \node{B} akzeptiert und sendet in diesem Fall seine \msg{verack}-Meldung.
|
||||
Der neu gestartete Netzwerkknoten \node{A} stellt die Verbindung zu einem zufälligen Knoten \node{B} aus seinem Knotenverzeichnis her und sendet eine \msg{version}-Meldung, die die aktuellste unterstützte Protokollversion ankündigt. Falls \node{B} die Version akzeptiert,\footnote{Eine Version wird normalerweise akzeptiert, wenn sie höher oder gleich der eigenen höchsten unterstützten Version ist. Knoten, welche eine experimentelle Protokollversion implementieren, können auch ältere Versionen akzeptieren.} antwortet er mit einer \msg{verack}-Meldung, gefolgt von der eigenen \msg{version} mit ihrer neusten unterstützten Protokollversion. Knoten \node{A} entscheidet nun ob er die Version von \node{B} akzeptiert und sendet in diesem Fall seine \msg{verack}-Meldung.
|
||||
|
||||
Wenn beide Knoten die Verbindung akzeptieren, senden sie je eine \msg{addr}-Meldung mit bis zu 1000 bekannten Knoten, gefolgt von einer oder mehreren \msg{inv}-Meldungen, welche alle bekannten gültigen Objekte mitteilt. Danach wird eine \msg{getobject}-Meldung für jedes noch fehlende Objekt gesendet.
|
||||
Wenn beide Knoten die Verbindung akzeptieren, senden sie je eine \msg{addr}-Meldung mit bis zu 1000 bekannten Knoten, gefolgt von einer oder mehreren \msg{inv}-Meldungen, welche alle bekannten gültigen Objekte mitteilt. Danach wird eine \msg{getdata}-Meldung für die noch fehlenden Objekte gesendet.
|
||||
|
||||
Auf \msg{getobject} antwortet der Knoten mit einer \msg{object}-Meldung, welche dann das angeforderte Objekt enthält.
|
||||
Auf \msg{getdata} antwortet der Knoten mit einer \msg{object}-Meldung, welche dann das angeforderte Objekt enthält.
|
||||
|
||||
Ein Knoten verbindet sich aktiv mit acht anderen knoten und erlaubt beliebig viele eingehende Verbindungen. Wenn ein Benutzer an Knoten \node{A} ein neues Objekt erzeugt, wird es mittels \msg{inv}-Meldung bei acht der angebundenen Knoten angeboten. Diese fordern es an und bieten es wiederum bei acht Nachbarknoten an, bis es an alle Knoten verteilt ist.
|
||||
Ein Knoten verbindet sich aktiv mit acht anderen Knoten und erlaubt beliebig viele eingehende Verbindungen. Wenn ein Benutzer an Knoten \node{A} ein neues Objekt erzeugt, wird es mittels \msg{inv}-Meldung bei acht der angebundenen Knoten angeboten. Diese fordern es an und bieten es wiederum bei acht Nachbarknoten an, bis es an alle Knoten verteilt ist.
|
||||
|
||||
\subsection{Meldungen}
|
||||
|
||||
Die Meldungen, Objekte und das Binärformat sind im Bitmessage-Wiki gut dokumentiert\cite{wiki:protocol}, die Beschreibungen hier sind deshalb darauf konzentriert um was es geht und wie man sie benutzt.
|
||||
Die Meldungen, Objekte und das Binärformat sind im Bitmessage-Wiki gut dokumentiert, die Beschreibungen hier sind deshalb darauf konzentriert um was es geht und wie man sie benutzt.\cite{wiki:protocol}
|
||||
|
||||
\subsubsection{version / verack}
|
||||
Die \msg{version}-Meldung enthält die aktuellste vom Knoten unterstützte Protokollversion, die Streams für die er sich interessiert und die unterstützten Features. Falls der andere Knoten akzeptiert, bestätigt er mitels \msg{verack}. Die Verbindung gilt als initialisiert wenn beide Knoten eine \msg{verack}-Meldung gesendet haben.
|
||||
Die \msg{version}-Meldung enthält die aktuellste vom Knoten unterstützte Protokollversion, die Streams für welche er sich interessiert und die unterstützten Features. Falls der andere Knoten akzeptiert, bestätigt er mittels \msg{verack}. Die Verbindung gilt als initialisiert wenn beide Knoten eine \msg{verack}-Meldung gesendet haben.
|
||||
|
||||
\subsubsection{addr}
|
||||
Enthält bis zu 1000 bekannte Knoten mit deren IP-Adresse, Port, Stream und unterstützten Features.
|
||||
Eine \msg{addr}-Meldung enthält bis zu 1000 bekannte Knoten mit deren IP-Adresse, Port, Stream und unterstützten Features. Die IP-Adressen werden dabei im IPv6-Format dargestellt, für IPv4-Adressen also 12 Bytes \texttt{00 00 00 00 00 00 00 00 00 00 FF FF}, gefolgt von den vier Bytes der IPv4-Adresse.
|
||||
|
||||
\subsubsection{inv}
|
||||
Eine \msg{inv}-Meldung enthält die Hashes von bis zu 50000 gültigen Objekten. Falls das Inventar mehr Objekte enthält können mehrere Meldungen gesendet werden.
|
||||
|
||||
\subsubsection{getdata}
|
||||
Kann bis zu 50000 Objekte anfordern, indem es deren Hashes sendet.
|
||||
Die Meldung \msg{getdata} kann bis zu 50000 Objekte anfordern, indem es deren Hashes sendet.
|
||||
|
||||
\subsubsection{object}
|
||||
Enthält ein angefordertes Objekt, das eines von folgenden sein kann:
|
||||
Die \msg{object}-Meldung enthält ein angefordertes Objekt, das eines von folgenden sein kann:
|
||||
|
||||
\listinginfo{}{getpubkey}{Eine Aufforderung an eine Adresse, deren öffentlichen Schlüssel zu senden. Dieser wird benötigt um die Meldung an diese Adressen zu verschlüsseln.}{}
|
||||
\listinginfo{}{pubkey}{Ein öffentlicher Schlüssel. Siehe \ref{subsec:addr} \nameref{subsec:addr}}{}
|
||||
\listinginfo{}{msg}{Eine Nachricht an einen bestimmten Benutzer.}{}
|
||||
\listinginfo{}{broadcast}{Eine Nachricht welche so verschlüsselt wird, dass jeder, der die Adresse kennt, sie entschlüsseln kann.}{}
|
||||
\listinginfo{}{broadcast}{Eine Nachricht, welche auf eine spezielle Art verschlüsselt wird. So kann jeder, der die sendende Adresse kennt, sie entschlüsseln.}{}
|
||||
|
||||
\subsubsection{ping / pong / getbiginv}
|
||||
Wer den Source Code von PyBitmessage untersucht, ist vielleicht über einige Meldungen irritiert welche implementiert zu sein scheinen, aber nirgends in der offiziellen Spezifikation zu finden sind. \msg{Ping} bringt einen Knoten (sofern implementiert) dazu ein \msg{pong} zurückzusenden. Verwendet wird das Feature jedoch nirgends. \msg{Getbiginv} scheint dafür gedacht zu sein das ganze Inventar abzufragen, aber soweit ich es verstehe wird es nirgends verwendet.\cite{issue:112}
|
||||
Wer den Source Code von PyBitmessage untersucht, ist vielleicht über einige Meldungen irritiert, welche implementiert zu sein scheinen, aber nirgends in der offiziellen Spezifikation zu finden sind. \msg{Ping} bringt einen Knoten (sofern implementiert) dazu ein \msg{pong} zurückzusenden. \msg{Getbiginv} scheint dafür gedacht zu sein das ganze Inventar abzufragen. Verwendet werden diese Meldungen jedoch nirgends.\cite{issue:112}
|
||||
|
||||
\subsection{Adressen}
|
||||
\label{subsec:addr}
|
||||
|
||||
\textit{BM-2cXxfcSetKnbHJX2Y85rSkaVpsdNUZ5q9h}: Adressen beginnen mit "BM-" und sind, genau wie Bitcoin-Adressen, Base58 codiert.\footnote{Dieses verwendet die Zeichen 1-9, A-Z und a-z ohne die leicht verwechselbaren Zeichen I, l, 0 and O.}
|
||||
\textit{BM-2cXxfcSetKnbHJX2Y85rSkaVpsdNUZ5q9h}: Adressen beginnen mit "BM-"{} und sind, genau wie Bitcoin-Adressen, Base58 codiert.\footnote{Dieses verwendet die Zeichen 1-9, A-Z und a-z ohne die leicht verwechselbaren Zeichen I, l, 0 and O.}
|
||||
|
||||
\listinginfo{}{version}{Adressversion.}{}
|
||||
\listinginfo{}{stream}{Stream-Nummer.}{}
|
||||
\listinginfo{}{ripe}{Hash der aneinandergefügten öffentlichen Schlüssel zum signieren und verschlüsseln. Wichtig: in \obj{pubkey}-Objekten werden die Schlüssel ohne führendes 0x04 gesendet, doch um den Ripe zu berechnen muss dieses Byte vorangestellt werden. Da dies für fast alle Verwendungszwecke der Schlüssel nötig ist, lohnt es sich dies gleich beim erstellen des Objekts zu machen.}{ripemd160(sha512(pubSigKey + pubEncKey))}
|
||||
\listinginfo{}{version}{Adressversion. Version 1 wird vom Netzwerk nicht mehr unterstützt.}{0x02, 0x03 oder 0x04}
|
||||
\listinginfo{}{stream}{Stream-Nummer. Im Moment wird praktisch nur Stream 1 verwendet.}{0x01}
|
||||
\listinginfo{}{ripe}{Hash der aneinandergefügten öffentlichen Schlüssel zum Signieren und Verschlüsseln. Wichtig: in \obj{pubkey}-Objekten werden die Schlüssel ohne führendes 0x04 gesendet, doch um den Ripe zu berechnen muss dieses Byte vorangestellt werden. Da dies für fast alle Verwendungszwecke der Schlüssel nötig ist, lohnt es sich dies gleich beim Erstellen des Objekts zu machen.
|
||||
|
||||
Führende Nullen werden dabei weggelassen. Es wird ausserdem ein Schlüsselpaar gesucht, dessen Ripe mindestens eine führende Null hat.}{ripemd160(sha512(pubSigKey + pubEncKey))}
|
||||
\listinginfo{}{checksum}{Die ersten vier Bytes eines doppelten SHA-512-Hashs der vorangehenden Daten.}{sha512(sha512(version + stream + ripe))}
|
||||
|
||||
\subsection{Verschlüsselung}
|
||||
|
||||
Bitmessage benutzt Elliptische-Kurven-Kryptographie zum signieren als auch zum verschlüsseln. Während die Matematik hinter elliptischen Korven sogar noch komplizierter zu verstehen ist all der ältere Ansatz, riesige Primzalen zu multiplizieren, so basiert es doch auf dem gleichen Prinzip, eine Mathematische Operation durchzuführen welche in eine Richtung sehr schnell, jedoch sehr schwierig umzukehren ist. An Stelle von zwei grossen Primzahlen werden hier ein Punkt auf der elliptischen Kurve mit einer sehr grossen Zahl multipliziert.\footnote{Bitte fragen Sie mich nicht wie das genau geht. Falls Sie es wirklich wissen möchten, beginnen Sie auf \url{http://de.wikipedia.org/wiki/Elliptische_Kurve} und \url{http://de.wikipedia.org/wiki/Elliptic_Curve_Cryptography}. Falls Sie etwas machen möchten das funktioniert, verwenden Sie lieber eine Bibliothek wie Bouncy Casle welche die harte Arbeit übernimmt.}
|
||||
Bitmessage benutzt Elliptische-Kurven-Kryptographie sowohl zum Signieren als auch zum Verschlüsseln. Die Mathematik dahinter ist ziemlich kompliziert. Sie basiert jedoch auf dem bewährten Prinzip, eine mathematische Operation durchzuführen, welche in eine Richtung relativ einfach, jedoch sehr schwierig umzukehren ist. An Stelle der sonst üblichen zwei grossen Primzahlen werden hier ein Punkt auf der elliptischen Kurve mit einer sehr grossen Zahl multipliziert.\footnote{Falls Sie wissen möchten wie das genau geht, beginnen Sie auf \url{http://de.wikipedia.org/wiki/Elliptische_Kurve} und \url{http://de.wikipedia.org/wiki/Elliptic_Curve_Cryptography}. Falls Sie etwas machen möchten das funktioniert, verwenden Sie aber lieber eine Bibliothek wie Bouncy Casle, welche die harte Arbeit übernimmt.}
|
||||
|
||||
Der Vorteil von elliptischen Kurven ist einerseits, dass man keine grossen Primzahlen suchen muss, andererseits aber auch, dass die Schlüssel bei gleicher Verschlüsselungsstärke viel kürzer sein können.
|
||||
|
||||
Die Benutzerin, nennen wir sie Alice, benötigt ein Schlüsselpaar, welches aus dem privaten Schlüssel
|
||||
$$k$$
|
||||
besteht, der eine riesige Zufallszahl darstellt, und einem öffentlichen Schlüssel
|
||||
besteht, der eine riesige\footnote{32 Bytes} Zufallszahl darstellt, und einem öffentlichen Schlüssel
|
||||
$$K = G k$$
|
||||
der einen Punkt auf der vorher definierten Kurve repräsentiert.\footnote{Bitmessage benutzt eine Kurve namens \textit{secp256k1}.} Beachten Sie bitte dass dies keine einfache Multiplikation ist, sondern die skalare Multiplikation eines Punktes auf der elliptischen Kurve. $G$ ist der Startpunkt für alle Operationen auf einer spezifischen Kurve.
|
||||
|
||||
Ein anderer Benutzer, Bob, kennt den öffentlichen Schlüssel. Um eine Nachricht zu verschlüsselt erstellt er das temporäre Schlüsselpaar
|
||||
Ein anderer Benutzer, Bob, kennt den öffentlichen Schlüssel. Um eine Nachricht zu verschlüsseln erstellt er das temporäre Schlüsselpaar
|
||||
$$r$$
|
||||
und
|
||||
$$R = G r$$
|
||||
@ -143,9 +147,9 @@ Danach berechnet er
|
||||
$$K r$$
|
||||
benutzt den daraus folgenden Punkt um die Meldung zu verschlüsseln\footnote{Genaugenommen wird ein doppelter SHA-512-Hash über der X-Koordinate benutzt um den symmetrischen Schlüssel zu erzeugen.} und sendet $K$ zusammen mit der verschlüsselten Nachricht.
|
||||
|
||||
Wenn Alice die Meldung empfängt, benutzt Sie die Tatsache dass
|
||||
Wenn Alice die Meldung empfängt, benutzt sie die Tatsache dass
|
||||
$$K r = G k r = G r k = R k$$
|
||||
alse berechnet sie einfach $R k$ um die Meldung zu entschlüsseln.
|
||||
also berechnet sie einfach $R k$ um die Meldung zu entschlüsseln.
|
||||
|
||||
Die genaue von Bitmessage verwendete Methode wird Elliptic Curve Integrated Encryption Scheme oder ECIES genannt, welche auf Wikipedia detailliert beschrieben wird (\url{http://de.wikipedia.org/wiki/Elliptic_Curve_Integrated_Encryption_Scheme}).
|
||||
|
||||
@ -153,24 +157,31 @@ alse berechnet sie einfach $R k$ um die Meldung zu entschlüsseln.
|
||||
|
||||
Um Objekte zu signieren verwendet Bitmessage Elliptic Curve Digital Signature Algorithm oder ECDSA. Dies ist etwas komplizierter als ECIES. Wenn Sie Details wissen möchten ist Wikipedia einmal mehr eine gute Anlaufstelle: \url{http://de.wikipedia.org/wiki/Elliptic_Curve_DSA}.
|
||||
|
||||
Ein interessantes Detail für potentielle Entwickler von Bitmessage-Clients --- vor allem wenn sie es mit einem objektorientierten Ansatz machen möchten: die Signatur geht über alles aus dem Objekt-Header ohne das Nonce und alles aus dem Objekt-Payload ohne die Signatur selbst. Natürlich sind nicht alle Objekte signiert.\footnote{Mein Ansatz: zuerst denken, dann falsch implementieren, dann viel umschreiben.}
|
||||
Ein interessantes Detail für potentielle Entwickler von Bitmessage-Clients --- vor allem wenn Sie es mit einem objektorientierten Ansatz machen möchten: die Signatur geht über alles aus dem Objekt-Header ohne das Nonce und alles aus dem Objekt-Payload ohne die Signatur selbst. Natürlich sind nicht alle Objekte signiert und die Signatur befindet sich im verschlüsselten Teil des Objekt-Payloads.\footnote{Mein Ansatz: zuerst denken, dann falsch implementieren, dann viel umschreiben.}
|
||||
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.7\textwidth]{images/signature.pdf}
|
||||
\caption[Signatur: Datenstruktur]{Aufbau von signierten und verschlüsselten Daten}
|
||||
\label{fig:signature}
|
||||
\end{figure}
|
||||
|
||||
\newpage
|
||||
\section{Probleme}
|
||||
|
||||
\subsection{Skalierbarkeit}
|
||||
|
||||
Bitmessage skaliert nicht.\footnote{Noch nicht.} Gitb es sehr wenige Benutzer, so gibt es auch keine Anonymität. Mit nur einer handvoll Benutzern ist es einfach (beispielsweise für die NSA), den Verkehr zwischen Knoten zu analysieren um herauszufinden wer wem schreiben könnte. Oder man überwacht einfach mal alle.
|
||||
Bitmessage skaliert nicht.\footnote{Noch nicht.} Gibt es sehr wenige Benutzer, so gibt es auch keine Anonymität. Mit einer kleinen Anzahl von Benutzern ist es einfach (beispielsweise für die NSA), den Verkehr zwischen Knoten zu analysieren um herauszufinden wer wem schreiben könnte.
|
||||
|
||||
Mit vielen Benutzern wächst der benötigte Traffic und Speicherplatz quadratisch. Dies geschieht, weil mit mehr Benutzern um eine Nachricht zu schreiben es auch mehr mögliche Gesprächspartner für bestehende Benutzer gibt.
|
||||
Mit vielen Benutzern wächst der benötigte Traffic und Speicherplatz quadratisch. Dies, weil es sowohl mehr Benutzer die eine Nachricht schreiben, als auch mehr mögliche Gesprächspartner für bestehende Benutzer gibt.
|
||||
|
||||
\subsubsection{Proof of Work}
|
||||
Proof of work hat zwei zwecke. Es hilft, das Netzwerk zu schützen indem es verhindert dass einzelne Knoten es mit Objekten fluten, aber auch den einzelnen Benutzer vor Spam zu bewahren. Es gibt einen minimal nötigen Proof of Work um Objekte im Netzwerk zu verteilen, doch der Benutzer kann für seine Adressen höhere Anforderungen stellen, falls er mit Angeboten für billiges Viagra\texttrademark{} zugeschüttet wird. Der für eine Adresse nötige Proof of Work wird im \obj{pubkey}-Objekt mitgeteilt. Absender, welche in der Kontaktliste eines Benutzers sind sollten normalerweise kein höherer Proof of Work machen müssen.
|
||||
Proof of Work erfüllt zwei Zwecke. Es hilft das Netzwerk zu schützen, indem es verhindert, dass einzelne Knoten es mit Objekten fluten. Andererseits schützt es auch den einzelnen Benutzer vor Spam. Es gibt einen minimal nötigen Proof of Work um Objekte im Netzwerk zu verteilen, doch der Benutzer kann für seine Adressen höhere Anforderungen stellen falls er mit Angeboten für billiges Viagra\texttrademark{} zugeschüttet wird. Der für eine Adresse nötige Proof of Work wird im \obj{pubkey}-Objekt mitgeteilt. Absender, welche in der Kontaktliste eines Benutzers sind, sollten keinen höheren Proof of Work machen müssen.
|
||||
|
||||
Die Schwierigkeit wird mittels Nachrichtenlänge und Lebensdauer berechnet, das heisst eine grössere Meldung oder eine welche länger im Netzwerk gespeichert wird ist kostet mehr beim senden.
|
||||
Die Schwierigkeit wird mittels Nachrichtenlänge und Lebensdauer berechnet, das heisst eine grössere Meldung oder eine welche länger im Netzwerk gespeichert wird kostet mehr beim Senden.
|
||||
$$ d = \frac{2^{64}}{n (l + \frac{t l}{2^{16}})} $$
|
||||
\begin{tabular}{@{}>{$}l<{$}l@{}}
|
||||
d & zielschwierigkeit \\
|
||||
d & Zielschwierigkeit \\
|
||||
n & nötige Versuche pro Byte \\
|
||||
l & Payload-Länge + Extra-Bytes (um es nicht zu einfach zu machen viele winzige Meldungen zu versenden) \\
|
||||
t & Lebensdauer \\
|
||||
@ -182,35 +193,35 @@ $$ d = \frac{2^{64}}{n (l + \frac{t l}{2^{16}})} $$
|
||||
Um zu verhindern dass bösarige Benutzer einzelne Knoten blockieren, dürfen Meldungen nicht grösser als 256 KiB sein. Wegen des Proof of Work sind grössere Nachrichten für den Normalgebrauch sowieso nicht praktikabel, aber sie könnten benutzt werden um Knoten mit Müll-Meldungen zu beschäftigen.
|
||||
|
||||
\subsubsection{Streams}
|
||||
Die vorgesehene Lösung für das Skalierungsproblem ist, den Traffic -- genau genommen Adressen -- in Streams aufzuteilen. Ein Knoten liest nur auf den Streams, welche seine Adressen betreffen. Wenn er ein Objekt an einen anderen Stream schicken möchten, verbindet er sich einfach mit einem Knoten im gewünschten Stream, sendet sein Objekt und schliesst die Verbindung wieder. Wenn alle aktiven Streams voll sind, wird für neue Adressen ein neuer Stream verwendet.
|
||||
Die vorgesehene Lösung für das Skalierungsproblem ist, den Traffic -- genau genommen Adressen -- in Streams aufzuteilen. Ein Knoten liest nur auf denjenigen Streams, welche seine Adressen betreffen. Wenn er ein Objekt an einen anderen Stream schicken möchte, verbindet er sich einfach mit einem Knoten im gewünschten Stream, sendet sein Objekt und schliesst die Verbindung wieder. Wenn alle aktiven Streams voll sind, wird für neue Adressen ein neuer Stream verwendet.
|
||||
|
||||
Das ungelöste Problem ist, herauszufinden wann ein Stream voll ist. Ein weiteres Problem ist die Tatsache dass, währen das Netzwerk wächst, der Traffic auf den vollen Streams mitwächst, da es mehr Benutzer gibt welche jemandem auf dem vollen Stream schreiben möchten. Der Traffic auf dem vollen Stream wächst also linear mit der Netzwerkgrösse.
|
||||
Das ungelöste Problem ist herauszufinden, wann ein Stream voll ist. Ein weiteres Problem ist die Tatsache, dass --- während das Netzwerk wächst --- der Traffic auf den vollen Streams mitwächst, da es mehr Benutzer gibt welche jemandem auf dem vollen Stream schreiben möchten. Der Traffic auf dem vollen Stream wächst also linear mit der Netzwerkgrösse.
|
||||
|
||||
\subsubsection{Präfix-Filterung}
|
||||
Jonathan Coe schlägt diesen interessanten Ansatz vor, den Traffic aufzuteilen. Dies würde ein Protokoll-Update erfordern, würde aber eine viel genauere Kontrolle darüber erlauben, wie viel Traffic ein Knoten verarbeiten will.\cite{wiki:prefixfilter}
|
||||
Jonathan Coe schlägt diesen interessanten Ansatz vor, den Traffic aufzuteilen. Dies würde ein Protokoll-Update erfordern, erlaubt aber eine viel genauere Kontrolle darüber, wie viel Traffic ein Knoten verarbeiten soll.\cite{wiki:prefixfilter}
|
||||
|
||||
Anstelle von Streams stellen wir uns eine Adresse als Blatt eines Binärbaums der Höhe 65 vor. Die Position wird über die ersten 64 Bits des Ripe einer Adresse. Eine Präfix-Lenge $n$ definiert den Teilbaum ab welchem wir Meldungen lesen. Ein sendender Client setzt ein 64-Bit-Nonce bei welchem die ersten $n$ Bits vom Ripe der Empfängeradresse kopiert und der Rest zufällig gesetzt wird.
|
||||
|
||||
\begin{figure}[htp]
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{images/prefix-filter-binary-tree.pdf}
|
||||
\caption[Präfix-Filter: Binärbaum]{Die Pefix-Länge geht bis 64, jedes der gelben Dreiecke stellt folglich einen Teilbaum der Höhe 61 dar.}
|
||||
\label{fig:bintree}
|
||||
\end{figure}
|
||||
|
||||
Anstelle von Streams stellen wir uns eine Adresse als Blatt eines Binärbaums der Höhe 65 vor. Die Position wird über die ersten 64 Bits des Ripe einer Adresse bestimmt. Eine Präfix-Lenge $n$ definiert den Teilbaum, ab welchem wir Meldungen lesen. Ein sendender Client setzt ein 64-Bit-Nonce, bei welchem die ersten $n$ Bits vom Ripe der Empfängeradresse kopiert und der Rest zufällig gesetzt wird.
|
||||
|
||||
Nehmen wir nun an, der Ripe von Bobs Adresse starte mit \texttt{00101001\ldots} und hat eine Präfix-Länge von 3. Alice sendet ihre Meldung mit dem Tag \texttt{00110100\ldots}. Die ersten drei Bits müssen gleich sein, aber der Rest ist zufällig gewählt. Bobs Client verarbeitet nun alle Meldungen welche seinem Präfix entsprechen, er muss also nur \sfrac{1}{8} des Gesamttraffics lesen.\footnote{Im Moment ist der Traffic insgesamt etwa 1 GiB im Monat.}
|
||||
|
||||
Wie Bitmessage populärer wird, wird es auch mehr und mehr Traffic generieren. Bob möchte deshalb möglicherweise seine Präfix-Länge auf 4 erhöhen, was den zu verarbeitenden Traffic weiter auf \sfrac{1}{16} des Gesamtvolumens reduziert. Um dies zu tun, publiziert er einfach seinen \obj{pubkey} mit seiner aktualisierten Präfix-Länge. Das heisst natürlich auch dass entweder immer ein \obj{pubkey} publiziert sein muss, oder Alice muss wenigstens einmal online sein während der \obj{pubkey} publiziert ist. Andernfalls gibt es in unserem Szenario eine 50\% Chance dass die Nachricht Bob nicht erreicht.
|
||||
Wie Bitmessage populärer wird, wird es auch mehr und mehr Traffic generieren. Bob möchte deshalb möglicherweise seine Präfix-Länge auf 4 erhöhen, was den zu verarbeitenden Traffic weiter auf \sfrac{1}{16} des Gesamtvolumens reduziert. Um dies zu tun, publiziert er einfach seinen \obj{pubkey} mit seiner aktualisierten Präfix-Länge. Das heisst natürlich auch, dass entweder immer ein \obj{pubkey} publiziert sein muss, oder Alice muss wenigstens einmal online sein während der \obj{pubkey} publiziert ist. Andernfalls gibt es in unserem Szenario eine 50\% Chance dass die Nachricht Bob nicht erreicht.
|
||||
|
||||
Dies würde es zwar einem Smartphone-Client erlauben nur seine eigenen Meldungen zu verarbeiten,\footnote{Ein Präfix von 64 würde höchstwahrscheinlich bedeuten dass man auf dem Stream aleine ist.} aber damit würde man auch seine Anonymität beinahe komplett aufgeben.
|
||||
Die Methode der Präfix-Filterung würde es zwar einem Smartphone-Client erlauben nur seine eigenen Meldungen zu verarbeiten,\footnote{Ein Präfix von 64 würde höchstwahrscheinlich bedeuten dass man auf dem Stream nur seine eigenen Meldungen erhählt.} aber damit würde man auch seine Anonymität beinahe komplett aufgeben.
|
||||
|
||||
\subsection{Forward Secrecy}
|
||||
|
||||
Offensichtlich ist es für einen Angreifer trivial alle (verschlüsselten) Objekte zu sammeln welche durch das Bitmessage-Netzwerk verteilt werden --- sofern Speicherplatz kein Problem ist. Sollte dieser Angreifer irgendwie an den privaten Schlüssel eines Benutzers kommen, kann er alle gespeicherten Meldungen entschlüsseln welche für diesen Benutzer bestimmt sind und sich ausserdem als diesen ausgeben.\footnote{Das letztere ist schwieriger wenn der Schlüssel durch eine Bruteforce-Attacke erworben wurde.}
|
||||
Offensichtlich ist es für einen Angreifer trivial alle (verschlüsselten) Objekte zu sammeln, welche durch das Bitmessage-Netzwerk verteilt werden --- sofern Speicherplatz kein Problem ist. Sollte dieser Angreifer irgendwie an den privaten Schlüssel eines Benutzers kommen, kann er alle gespeicherten Meldungen entschlüsseln, welche für diesen Benutzer bestimmt sind, und sich ausserdem als diesen ausgeben.\footnote{Das Letztere ist schwieriger wenn der Schlüssel durch eine Bruteforce-Attacke erworben wurde.}
|
||||
|
||||
Glaubhafte Abstreitbarkeit (plausible deniability) kann, in einigen Szenarios, dagegen helfen. Bei dieser Aktion, auch "eine Adresse atomisieren"\footnote{"Nuking an address."} genannt, wird der private Schlüssel anonym veröffentlicht.\footnote{Siehe \url{https://bitmessage.ch/nuked/} für ein Beispiel.}
|
||||
Glaubhafte Abstreitbarkeit (plausible deniability) kann in einigen Szenarios dagegen helfen. Bei dieser Aktion --- auch "{}eine Adresse atomisieren"\footnote{"Nuking an address."} genannt --- wird der private Schlüssel anonym veröffentlicht.\footnote{Siehe \url{https://bitmessage.ch/nuked/} für ein Beispiel.}
|
||||
|
||||
Perfect Forward Secrecy scheint nicht praktikabel implementierbar zu sein, da man dazu vor dem Senden der eigentlichen Nachricht Informationen austauschen muss. Diese brauchten wiederum Proof of Work um das Netzwerk zu schützen, was für den Sender die doppelte Arbeit bedeutet und dreimal solange dauert um sie zu senden --- das heisst, falls beide Clients online sind. Der Austausch von Nachrichten würde so gut wie unmöglich wenn beide Benutzer nur sporadisch online sind.
|
||||
Perfect Forward Secrecy scheint nicht praktikabel implementierbar zu sein, da man dazu vor dem Senden der eigentlichen Nachricht Informationen austauschen muss. Dies braucht wiederum Proof of Work um das Netzwerk zu schützen, was für den Sender die doppelte Arbeit bedeutet und die dreifache Zeit eine Nachricht zu senden --- falls beide Clients online sind. Der Austausch von Nachrichten würde so gut wie unmöglich wenn beide Benutzer nur sporadisch online sind.
|
||||
|
||||
\subsection{Mobile Client}
|
||||
|
||||
@ -218,20 +229,25 @@ $$ d = \frac{2^{64}}{n (l + \frac{t l}{2^{16}})} $$
|
||||
|
||||
In PyBitmessage gibt es die Option, den Empfänger eindeutig identifizierbar zu machen. Dies würde es einem Server erlauben nur die relevanten Meldungen weiterzuleiten. Zwar gibt man dabei seine Anonymität auf, aber das ist immer noch besser als die Ansätze der E-Mail-Relays, wo der private Schlüssel gleich beim Server liegt.
|
||||
|
||||
Ein Ansatz, der Anonymität trotz unterstützendem Server erlaubt, schlug Dan Smith vor.\cite{forum:msg7871} Dabei wird ein drittes Schlüsselpaar generiert, mit dem der String "IDENTIFICATION" und einige zufällige Bytes verschlüsselt wird. Der Relay-Server muss dabei den privaten Identifikationsschlüssel erhalten --- soweit muss man ihm also noch vertrauen. Wenn er also mit Hilfe des Identifikationsschlüssels den Text "IDENTIFICATION" extrahieren kann, ist die Meldung für einem bestimmt und wird weitergeleitet.
|
||||
Ein Ansatz, der Anonymität trotz unterstützendem Server erlaubt, schlug Dan Smith vor.\cite{forum:msg7871} Dabei wird ein drittes Schlüsselpaar generiert, mit dem der String "{}IDENTIFICATION"{} und einige zufällige Bytes verschlüsselt wird. Der Relay-Server muss dabei den privaten Identifikationsschlüssel erhalten --- soweit muss man ihm also noch vertrauen. Wenn er also mit Hilfe des Identifikationsschlüssels den Text "{}IDENTIFICATION"{} extrahieren kann, ist die Meldung für mich bestimmt und wird weitergeleitet.
|
||||
|
||||
Der Proof of Work schliesslich lässt sich sehr einfach auf einem Server erledigen. Mit einer optimierten Implementation sollte er aber auf einem modernen Smartphone in vernünftiger Zeit machbar sein. Die Geräte haben inzwischen oftmals mehr als vier Prozessorkerne und einen dedizierten Grafikchip, der sich ausgezeichnet zum parallelen Berechnen von Hashes eignet.
|
||||
Der Proof of Work schliesslich lässt sich sehr einfach auf einem Server erledigen. Mit einer optimierten Implementation sollte er aber auch auf einem modernen Smartphone in vernünftiger Zeit machbar sein. Die Geräte haben inzwischen oftmals mehr als vier Prozessorkerne und einen dedizierten Grafikchip, der sich ausgezeichnet zum parallelen Berechnen von Hashes eignet.
|
||||
|
||||
\newpage
|
||||
\section{Diskussion}
|
||||
|
||||
Anonymität hat ihren Preis. Bei Bitmessage ist es Traffic, Speicherplatz und Rechenpower. Bei E-Mail ist es Vertrauen. Wenn wir unserem E-Mail-Provider nicht vertrauen können (wer kann das?), ist Bitmessage eine alternative, wenn auch nicht vollständig ausgereift.
|
||||
Anonymität hat ihren Preis. Bei Bitmessage ist es Traffic, Speicherplatz und Rechenpower. Bei E-Mail ist es Vertrauen. Wenn wir unserem E-Mail-Provider nicht vertrauen können (wer kann das?), ist Bitmessage eine Alternative, wenn auch nicht vollständig ausgereift.
|
||||
|
||||
Ich finde die Idee eines Trustless-Protokolls\footnote{Ein Protokoll, das kein Vertrauen benötigt.} und Peer-To-Peer Netzwerke die üblicherweise soche Protokolle verwenden äusserst interessant. Zu Beginn war das Internet ein riesiges Netzwerk gleichberechtigter Teilnehmer, aber heutzutage scheint alles zu Google oder Facebook zu führen. P2P und Trustless-Protokolle geben uns ein Stück dieser Freiheit zurück welche in der Cloud verlorengegangen ist.
|
||||
Ich finde die Idee eines Trustless-Protokolls\footnote{Ein Protokoll, das kein Vertrauen benötigt.} und Peer-To-Peer Netzwerke, die üblicherweise soche Protokolle verwenden, äusserst interessant. Zu Beginn war das Internet ein riesiges Netzwerk gleichberechtigter Teilnehmer, doch heutzutage scheint alles zu Google oder Facebook zu führen. P2P und Trustless-Protokolle geben uns ein Stück dieser Freiheit zurück, welche in der Cloud verlorengegangen ist.
|
||||
|
||||
Dass es nun einen P2P E-Mail-Ersatz gibt finde ich absolut grossartig.
|
||||
Dass es nun einen P2P E-Mail-Ersatz gibt finde ich absolut grossartig. Ja, es skaliert nicht so gut wie E-Mail. Aber dank Proof of Work denke ich, dass wir kein mit E-Mail vergleichbares Spam-Problem haben, was den Traffic schon mal gut halbiert. Falls Bitmessage E-Mail jemals ersetzt, würde ein grosser Teil des E-Mail-Verkehrs wohl eher durch Instant-Messaging ersetzt. Vor allem Firmenintern, wo eine eigene Infrastruktur aufgebaut werden kann, muss nicht unbedingt Bitmessage verwendet werden.
|
||||
|
||||
Ja, es skaliert nicht so gut wie E-Mail. Aber dank Proof of Work denke ich, dass wir kein mit E-Mail vergleichbares Spam-Problem haben, was den Traffic schon mal gut halbiert. Falls Bitmessage E-Mail jemals ersetzt, würde ein grosser Teil des E-Mail-Verkehrs wohl eher durch Instant-Messaging ersetzt. Vor allem Firmenintern, wo eine eigene Infrastruktur aufgebaut werden kann, muss nicht unbedingt Bitmessage verwendet werden.
|
||||
\begin{figure}[htp]
|
||||
\centering
|
||||
\includegraphics[width=0.7\textwidth]{images/xkcd-security.png}
|
||||
\caption[XKCD: Security]{\url{http://xkcd.com/538/}\nocite{xkcd:538}}
|
||||
\label{fig:xkcd}
|
||||
\end{figure}
|
||||
|
||||
\newpage
|
||||
\bibliographystyle{plain}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user