diff --git a/README.md b/README.md
index 794d8d5..eb5cdfc 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,7 @@
Jabit [](https://travis-ci.org/Dissem/Jabit)
=====
-A Java implementation for the Bitmessage protocol. To build, use command `gradle build`. Note that for some tests to run, a standard Bitmessage client needs to run on the same system, using port 8444 (the default port).
+A Java implementation for the Bitmessage protocol. To build, use command `gradle build` or `./gradlew build`.
Please note that development is still heavily in progress, and I will break the database a lot until it's ready for prime time.
@@ -12,6 +12,7 @@ There are most probably some security issues, me programming this thing all by m
Project Status
--------------
+
Basically, everything needed for a working Bitmessage client is there:
* Creating new identities (private addresses)
* Adding contracts and subscriptions
@@ -22,3 +23,59 @@ Basically, everything needed for a working Bitmessage client is there:
* Initialise and manage a registry of Bitmessage network nodes
* An easy to use API
* A command line demo application built using the API
+
+Setup
+-----
+
+Add Jabit as Gradle dependency:
+```Gradle
+compile 'ch.dissem.jabit:jabit-domain:0.2.0'
+```
+Unless you want to implement your own, also add the following:
+```Gradle
+compile 'ch.dissem.jabit:jabit-networking:0.2.0'
+compile 'ch.dissem.jabit:jabit-repositories:0.2.0'
+```
+And if you want to import from or export to the Wallet Import Format (used by PyBitmessage) you might also want to add:
+```Gradle
+compile 'ch.dissem.jabit:jabit-wif:0.2.0'
+```
+
+Usage
+-----
+
+First, you'll need to create a `BitmessageContext`:
+```Java
+JdbcConfig jdbcConfig = new JdbcConfig();
+BitmessageContext ctx = new BitmessageContext.Builder()
+ .addressRepo(new JdbcAddressRepository(jdbcConfig))
+ .inventory(new JdbcInventory(jdbcConfig))
+ .messageRepo(new JdbcMessageRepository(jdbcConfig))
+ .nodeRegistry(new MemoryNodeRegistry())
+ .networkHandler(new NetworkNode())
+ .build();
+```
+This creates a simple context using a H2 database that will be created in the user's home directory. Next you'll need to
+start the context and decide what happens if a message arrives:
+```Java
+ctx.startup(new BitmessageContext.Listener() {
+ @Override
+ public void receive(Plaintext plaintext) {
+ // TODO: Notify the user
+ }
+});
+```
+Then you might want to create an identity
+```Java
+BitmessageAddress identity = ctx.createIdentity(false, Pubkey.Feature.DOES_ACK);
+```
+or add some contacts
+```Java
+BitmessageAddress contact = new BitmessageAddress("BM-2cTarrmjMdRicKZ4qQ8A13JhoR3Uq6Zh5j");
+address.setAlias("Chris");
+ctx.addContact(contact);
+```
+to which you can send some messages
+```Java
+ctx.send(identity, contact, "Test", "Hello Chris, this is a message.");
+```
diff --git a/build.gradle b/build.gradle
index da8e3ef..7bf5c3f 100644
--- a/build.gradle
+++ b/build.gradle
@@ -1,11 +1,13 @@
-allprojects {
+subprojects {
apply plugin: 'java'
apply plugin: 'maven'
apply plugin: 'signing'
sourceCompatibility = 1.7
group = 'ch.dissem.jabit'
- version = '0.1.2'
+ version = '0.2.0'
+
+ ext.isReleaseVersion = !version.endsWith("SNAPSHOT")
repositories {
mavenCentral()
@@ -25,7 +27,55 @@ allprojects {
archives javadocJar, sourcesJar
}
-// signing {
-// sign configurations.archives
-// }
+ signing {
+ required { isReleaseVersion && gradle.taskGraph.hasTask("uploadArchives") }
+ sign configurations.archives
+ }
+
+ uploadArchives {
+ repositories {
+ mavenDeployer {
+ beforeDeployment { MavenDeployment deployment -> signing.signPom(deployment) }
+
+ if (!hasProperty('ossrhUsername')) {
+ ext.ossrhUsername = 'dummy'
+ ext.ossrhPassword = 'dummy'
+ }
+
+ repository(url: "https://oss.sonatype.org/service/local/staging/deploy/maven2/") {
+ authentication(userName: ossrhUsername, password: ossrhPassword)
+ }
+
+ snapshotRepository(url: "https://oss.sonatype.org/content/repositories/snapshots/") {
+ authentication(userName: ossrhUsername, password: ossrhPassword)
+ }
+
+ pom.project {
+ name 'Jabit'
+ packaging 'jar'
+ url 'https://github.com/Dissem/Jabit'
+
+ scm {
+ connection 'scm:git:https://github.com/Dissem/Jabit.git'
+ developerConnection 'scm:git:git@github.com:Dissem/Jabit.git'
+ url 'https://github.com/Dissem/Jabit.git'
+ }
+
+ licenses {
+ license {
+ name 'The Apache License, Version 2.0'
+ url 'http://www.apache.org/licenses/LICENSE-2.0.txt'
+ }
+ }
+
+ developers {
+ developer {
+ name 'Christian Basler'
+ email 'chrigu.meyer@gmail.com'
+ }
+ }
+ }
+ }
+ }
+ }
}
\ No newline at end of file
diff --git a/demo/build.gradle b/demo/build.gradle
index ae7579e..8d6414c 100644
--- a/demo/build.gradle
+++ b/demo/build.gradle
@@ -2,6 +2,18 @@ plugins {
id "us.kirchmeier.capsule" version "1.0-rc1"
}
+uploadArchives {
+ repositories {
+ mavenDeployer {
+ pom.project {
+ name 'Jabit Demo'
+ artifactId = 'jabit-demo'
+ description 'An example Bitmessage client using Jabit.'
+ }
+ }
+ }
+}
+
task fatCapsule(type: FatCapsule) {
applicationClass 'ch.dissem.bitmessage.demo.Main'
}
@@ -10,6 +22,7 @@ dependencies {
compile project(':domain')
compile project(':networking')
compile project(':repositories')
+ compile project(':wif')
compile 'org.slf4j:slf4j-simple:1.7.12'
compile 'args4j:args4j:2.32'
testCompile 'junit:junit:4.11'
diff --git a/demo/src/main/java/ch/dissem/bitmessage/demo/Application.java b/demo/src/main/java/ch/dissem/bitmessage/demo/Application.java
index 1497425..0e03880 100644
--- a/demo/src/main/java/ch/dissem/bitmessage/demo/Application.java
+++ b/demo/src/main/java/ch/dissem/bitmessage/demo/Application.java
@@ -43,11 +43,10 @@ public class Application {
ctx = new BitmessageContext.Builder()
.addressRepo(new JdbcAddressRepository(jdbcConfig))
.inventory(new JdbcInventory(jdbcConfig))
- .nodeRegistry(new JdbcNodeRegistry(jdbcConfig))
+ .nodeRegistry(new MemoryNodeRegistry())
.messageRepo(new JdbcMessageRepository(jdbcConfig))
.networkHandler(new NetworkNode())
.port(48444)
- .streams(1)
.build();
ctx.startup(new BitmessageContext.Listener() {
diff --git a/demo/src/main/java/ch/dissem/bitmessage/demo/Main.java b/demo/src/main/java/ch/dissem/bitmessage/demo/Main.java
index cf29110..4ba8fa7 100644
--- a/demo/src/main/java/ch/dissem/bitmessage/demo/Main.java
+++ b/demo/src/main/java/ch/dissem/bitmessage/demo/Main.java
@@ -16,6 +16,16 @@
package ch.dissem.bitmessage.demo;
+import ch.dissem.bitmessage.BitmessageContext;
+import ch.dissem.bitmessage.networking.NetworkNode;
+import ch.dissem.bitmessage.repository.*;
+import ch.dissem.bitmessage.wif.WifExporter;
+import ch.dissem.bitmessage.wif.WifImporter;
+import org.kohsuke.args4j.CmdLineException;
+import org.kohsuke.args4j.CmdLineParser;
+import org.kohsuke.args4j.Option;
+
+import java.io.File;
import java.io.IOException;
public class Main {
@@ -25,6 +35,40 @@ public class Main {
if (System.getProperty("org.slf4j.simpleLogger.logFile") == null)
System.setProperty("org.slf4j.simpleLogger.logFile", "./jabit.log");
- new Application();
+ CmdLineOptions options = new CmdLineOptions();
+ CmdLineParser parser = new CmdLineParser(options);
+ try {
+ parser.parseArgument(args);
+ } catch (CmdLineException e) {
+ parser.printUsage(System.err);
+ }
+ if (options.exportWIF != null || options.importWIF != null) {
+ JdbcConfig jdbcConfig = new JdbcConfig();
+ BitmessageContext ctx = new BitmessageContext.Builder()
+ .addressRepo(new JdbcAddressRepository(jdbcConfig))
+ .inventory(new JdbcInventory(jdbcConfig))
+ .nodeRegistry(new MemoryNodeRegistry())
+ .messageRepo(new JdbcMessageRepository(jdbcConfig))
+ .networkHandler(new NetworkNode())
+ .port(48444)
+ .build();
+
+ if (options.exportWIF != null) {
+ new WifExporter(ctx).addAll().write(options.exportWIF);
+ }
+ if (options.importWIF != null) {
+ new WifImporter(ctx, options.importWIF).importAll();
+ }
+ } else {
+ new Application();
+ }
+ }
+
+ private static class CmdLineOptions {
+ @Option(name = "-import", usage = "Import from keys.dat or other WIF file.")
+ private File importWIF;
+
+ @Option(name = "-export", usage = "Export to WIF file.")
+ private File exportWIF;
}
}
diff --git a/docs-de/.gitignore b/docs-de/.gitignore
deleted file mode 100644
index b812b07..0000000
--- a/docs-de/.gitignore
+++ /dev/null
@@ -1,38 +0,0 @@
-# Created by https://www.gitignore.io
-
-### LaTeX ###
-*.acn
-*.acr
-*.alg
-*.aux
-*.bbl
-*.bcf
-*.blg
-*.dvi
-*.fdb_latexmk
-*.glg
-*.glo
-*.gls
-*.idx
-*.ilg
-*.ind
-*.ist
-*.lof
-*.log
-*.lot
-*.maf
-*.mtc
-*.mtc0
-*.nav
-*.nlo
-*.out
-*.pdfsync
-*.ps
-*.run.xml
-*.snm
-*.synctex.gz
-*.toc
-*.vrb
-*.xdy
-*.tdo
-
diff --git a/docs-de/basics.tex b/docs-de/basics.tex
deleted file mode 100644
index 5c2853b..0000000
--- a/docs-de/basics.tex
+++ /dev/null
@@ -1,15 +0,0 @@
- \section{Einführung}
-
- \subsection{Was sind Metadaten?}
-
- Metadaten sind informationen, welche als Nebeneffekte der eigentlichen Kommunikation auftreten. Wer schreibt wem? Wann? Über welchen Kanal?
-
- 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.
-
- 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.}
-
- 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.
\ No newline at end of file
diff --git a/docs-de/bfh.cls b/docs-de/bfh.cls
deleted file mode 100644
index 1ab60c7..0000000
--- a/docs-de/bfh.cls
+++ /dev/null
@@ -1,279 +0,0 @@
-\NeedsTeXFormat{LaTeX2e}
-\ProvidesClass{bfh}[2015/04/21 Atricle Class for my BFH reports]
-
-\DeclareOption{a4paper}{\PassOptionsToClass{\CurrentOption}{scrartcl}}
-\DeclareOption{11pt}{\PassOptionsToClass{\CurrentOption}{scrartcl}}
-\DeclareOption{oneside}{\PassOptionsToClass{\CurrentOption}{scrartcl}}
-\DeclareOption{titlepage}{\PassOptionsToClass{\CurrentOption}{scrartcl}}
-\DeclareOption*{\PassOptionsToClass{\CurrentOption}{scrartcl}}
-\ExecuteOptions{a4paper,11pt,oneside}
-\ProcessOptions
-
-%\RequirePackage{cite}
-%\RequirePackage[backend=bibtex]{biblatex}
-% Literatur- und Bilderquellen trennen
-%\defbibheading{lit}{\section*{Literature}}
-%\defbibheading{pic}{\section*{Pictures}}
-
-\LoadClass{scrartcl}
-\RequirePackage{remreset}
-
-\RequirePackage[utf8]{inputenc}
-\RequirePackage{graphicx}
-\RequirePackage{color}
-\RequirePackage{lmodern}
-\RequirePackage{url}
-\RequirePackage{lastpage}
-
-\RequirePackage{mathtools}
-\RequirePackage{amsfonts}
-%\RequirePackage{float}
-\RequirePackage{textgreek}
-%\RequirePackage{centernot}
-\RequirePackage{hyphenat}
-
-\RequirePackage[T1]{fontenc}
-\RequirePackage[scaled]{helvet}
-
-\RequirePackage{textcomp}
-\RequirePackage{eurosym}
-\RequirePackage{fancyhdr}
-\RequirePackage{alltt}
-\RequirePackage{verbatim}
-\RequirePackage{aeguill}
-%\RequirePackage{underscore}
-\RequirePackage{ctable}
-\RequirePackage[english,ngerman]{babel}
-
-\RequirePackage{tabularx}
-\RequirePackage{wrapfig}
-\RequirePackage{ifthen}
-\RequirePackage[usenames,dvipsnames,svgnames]{xcolor}
-\RequirePackage{hyperref}
-\RequirePackage{listings}
-\RequirePackage{attachfile}
-
-\RequirePackage{enumitem}
-\RequirePackage{wasysym}
-
-\RequirePackage[absolute]{textpos}
-
-\definecolor{bfhblue}{rgb}{0.396,0.49,0.56} % Blue
-\definecolor{bfhorange}{rgb}{0.961,0.753,0.196} % Orange
-\definecolor{bfhorangelight}{RGB}{246,216,136} % Orange Light
-
-\hypersetup{
- linkcolor=blue, % color of internal links
- citecolor=green, % color of links to bibliography
- filecolor=blue, % color of file links
- urlcolor=blue, % color of external links
- colorlinks=true
-}
-\urlstyle{same}
-
-\typearea{12}
-%\bibliographystyle{alpha}
-\setcounter{secnumdepth}{4}
-\setlength{\parskip}{12pt}
-\setlength{\parindent}{0pt}
-
-\renewcommand{\familydefault}{\sfdefault}
-
-%\let\oldtoc\tableofcontents
-%\renewcommand{\tableofcontents} {
-% \oldtoc
-% \newpage
-%}
-\newcommand*{\tutor}[1]{\gdef\@tutor{#1}}
-\renewcommand{\maketitle} {
- \begin{titlepage}
- \newlength{\unitlengthtmp}
- \setlength{\unitlengthtmp}{\unitlength}
- \setlength{\unitlength}{1mm}
- \setlength{\TPHorizModule}{\textwidth}
- \setlength{\TPVertModule}{\textheight}
- %
- % BFH Logo
- \includegraphics[scale=1.25]{images/logo.pdf}
- %
- % Linien
- \begin{textblock}{1}[0,0](0,0)
- \begin{picture}(0,130)
- \put(20,0){\color{bfhblue}\rule{\textwidth}{1.2mm}}
- \put(20,40){\color{bfhblue}\rule{\textwidth}{1.2mm}} %28.5
- \end{picture}
- \end{textblock}
- %
- %Zentrierte Titel
- \begin{flushleft}
- \vspace*{4.08cm}
- \textsf{\textbf{\noindent{\Huge{\textcolor{bfhblue}{\@title}}}}}\\[0.4cm]
- \textsf{\huge{\textcolor{bfhblue}{\@subtitle}}}
- %
- %Angaben zum Dokument
- \begin{vfill}
- \begin{tabularx}{\textwidth}{lX}
- \textsf{Autor} & \@author\\
- \textsf{Betreuer} & \@tutor\\
-% \textsf{Expert} & \textsf\DozentA\\
-% \textsf{Studiengang} & \textsf{\Studiengang}\vspace{5pt}\\
-% \textsf{Autoren} & \textsf\AutorA\\
-% & \textsf\AutorB\vspace{5pt}\\
-% \textsf{Betreuer} & \textsf\DozentA\\
-% & \textsf\DozentB\vspace{5pt}\\
-% \textsf{Experten} & \textsf\ExpertA\\
-% & \textsf\ExpertB\vspace{5pt}\\
- \textsf{Datum} & \textsf{\@date}\vspace{5pt}\\
-% &\\
-% &\\
-% \multicolumn{2}{p{\columnwidth-\tabcolsep}}{\textsf{\input{titlepage/titlepage_info}}}\\
- \end{tabularx}
- \end{vfill}
- \end{flushleft}
- \setlength{\unitlength}{\unitlengthtmp}
- \end{titlepage}
-}
-
-\pagestyle{fancy}
-\fancyhf{}
-\fancyfoot[R]{\hrule\thepage/\pageref{LastPage}}
-\fancyfoot[L]{\hrule\today}
-\fancyhead[L]{\@title}
-
-\fancyhead[R]{
- \includegraphics[height=1.5\baselineskip]{images/logo.png}
- }
-\addtolength{\headheight}{2\baselineskip}
-\addtolength{\headheight}{0.61pt}
-
-\lstset{
-language=XML, % Code langugage
-basicstyle=\ttfamily\scriptsize,
-keywordstyle=\color{OliveGreen}, % Keywords font ('*' = uppercase)
-stringstyle=\color{blue}, % String font
-commentstyle=\color{gray}, % Comments font
-numbers=left, % Line nums position
-numberstyle=\tiny, % Line-numbers fonts
-stepnumber=1, % Step between two line-numbers
-numbersep=10pt, % How far are line-numbers from code
-backgroundcolor=\color{BackgroundBlue}, % Choose background color
-frame=none, % A frame around the code
-tabsize=4, % Default tab size
-captionpos=b, % Caption-position = bottom
-breaklines=true, % Automatic line breaking?
-breakatwhitespace=false, % Automatic breaks only at whitespace?
-%showspaces=false, % Dont make spaces visible
-%showtabs=false, % Dont make tabls visible
-columns=fixed, % Column format
-morekeywords={Server, Listener, GlobalNamingResources,
- Resource, ResourceLink, Service, Connector, Engine,
- Host, Context, Environment,
- beans, bean, broker, destinationPolicy, policyMap,
- policyEntries, policyEntry, dispatchPolicy,
- strictOrderDispatchPolicy, subscriptionRecoveryPolicy,
- lastImageSubscriptionRecoveryPolicy, managementContext,
- persistenceAdapter, systemUsage, memoryUsage,
- storeUsage, tempUsage, transportConnectors,
- transportConnector, property, jetty, connectors,
- nioConnector, handlers, webAppContext},
-}
-% Shows a listing and creates an attachment with the source
-\newcommand{\attachlisting}[2][]{
- \hspace{0.95\textwidth}
- \attachfile[icon=Paperclip]{#2}
- \vspace{-5ex}
- \lstinputlisting[#1]{#2}
-}
-% 1 line number(s)
-% 2 variable name
-% 3 description
-% 4 example values
-\newcommand{\listinginfo}[4]{
- \colorbox{WhiteSmoke}{
- \parbox[t]{0.25\textwidth}{
- \printifnotempty{#1}{\texttt{#1:}\\}
- \textit{#2}
- }
- \parbox[t]{0.715\textwidth}{
- \printifnotempty{#3}{#3
- }
- \printifnotempty{#4}{
- \par
- \vspace{1ex}
- \colorbox{BackgroundBlue}{
- \parbox{0.69\textwidth}{
- \vspace{-2ex}
- \ttfamily
- \flushleft{#4}
- }
- }
- \par
- \vspace{0.5ex}
- }
- }
- }
- \par
- \vspace{-1.7ex}
-}
-\newcommand{\printifnotempty}[2]{
- \ifthenelse{\equal{#1}{}}{}{#2}
-}
-
-% Makes a red box that highlights errors or very important warnings
-\newcommand{\errorbox}[1]{
- \fcolorbox{Red}{LightPink}{
- \parbox{0.972\textwidth}{
- \begin{wrapfigure}[2]{l}{0.05\textwidth}
- \vspace{-12pt}
- \includegraphics[width=0.05\textwidth]{images/error.pdf}
- \vspace{12pt}
- \end{wrapfigure}
- #1
- }
- }
-}
-
-% Makes a yellow box that highlights warnings
-\newcommand{\warningbox}[1]{
- \fcolorbox{Goldenrod}{LightYellow}{
- \parbox{0.972\textwidth}{
- \begin{wrapfigure}[2]{l}{0.05\textwidth}
- \vspace{-12pt}
- \includegraphics[width=0.05\textwidth]{images/warning.pdf}
- \vspace{12pt}
- \end{wrapfigure}
- #1
- }
- }
-}
-
-% Makes a blue box that highlights special information
-\newcommand{\infobox}[1]{
- \fcolorbox{CornflowerBlue}{AliceBlue}{
- \parbox{0.972\textwidth}{
- \begin{wrapfigure}[2]{l}{0.05\textwidth}
- \vspace{-12pt}
- \includegraphics[width=0.05\textwidth]{images/info.pdf}
- \end{wrapfigure}
- #1
- }
- }
-}
-
-\RequirePackage{listings}
-\definecolor{BackgroundBlue}{cmyk}{0.05,0,0,0}
-
-\let\olditemize=\itemize
-\def\itemize{
- \olditemize
- \setlength{\itemsep}{-1.5ex}
-}
-
-\newcommand{\leadingzero}[1]{\ifnum #1<10 0\the#1\else\the#1\fi}
-%YYYY-MM-DD
-\newcommand{\todayI}{\the\year-\leadingzero{\month}-\leadingzero{\day}}
-
-\endinput
-
-
-
diff --git a/docs-de/bibliography.bib b/docs-de/bibliography.bib
deleted file mode 100644
index 3aa2603..0000000
--- a/docs-de/bibliography.bib
+++ /dev/null
@@ -1,48 +0,0 @@
-@ONLINE{wiki:protocol,
- url = {https://bitmessage.org/wiki/Protocol_specification},
- title = {Bitmessage Wiki: Protocol Specification},
- publisher = {Bitmessage Wiki},
- urldate = {2015-04-24},
- author = {Warren, Jonathan 'Atheros' and Coe, Jonathan},
- note = {\\ \url{https://bitmessage.org/wiki/Protocol_specification}},
- year = {2015},
-}
-
-@ONLINE{wiki:prefixfilter,
- url = {https://bitmessage.org/wiki/Scalability_through_Prefix_Filtering},
- title = {Bitmessage Wiki: Scalability through Prefix Filtering},
- publisher = {Bitmessage Wiki},
- urldate = {2015-05-22},
- author = {Coe, Jonathan},
- note = {\\ \url{https://bitmessage.org/wiki/Scalability_through_Prefix_Filtering}},
- year = {2015},
-}
-
-@ONLINE{forum:msg7871,
- url = {https://bitmessage.org/forum/index.php?topic=3725.msg7871},
- title = {A tweak to enable trust-less BM relay servers (and lightweight mobile clients)},
- publisher = {Bitmessage Forum},
- urldate = {2015-05-25},
- author = {Dan Smith},
- note = {\\ \url{https://bitmessage.org/forum/index.php?topic=3725.msg7871}},
- year = {2014}
-}
-
-@ONLINE{issue:112,
- url = {https://github.com/Bitmessage/PyBitmessage/issues/112},
- title = {BigInv and ping/pong},
- publisher = {github.com},
- urldate = {2015-05-22},
- 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/}}
-}
\ No newline at end of file
diff --git a/docs-de/diagram.svg b/docs-de/diagram.svg
deleted file mode 100644
index 5ef0521..0000000
--- a/docs-de/diagram.svg
+++ /dev/null
@@ -1,5844 +0,0 @@
-
-
diff --git a/docs-de/images/PyBitmessage-Broadcasts.png b/docs-de/images/PyBitmessage-Broadcasts.png
deleted file mode 100644
index b4d2c7e..0000000
Binary files a/docs-de/images/PyBitmessage-Broadcasts.png and /dev/null differ
diff --git a/docs-de/images/PyBitmessage-Inbox.png b/docs-de/images/PyBitmessage-Inbox.png
deleted file mode 100644
index 1f3a4bd..0000000
Binary files a/docs-de/images/PyBitmessage-Inbox.png and /dev/null differ
diff --git a/docs-de/images/PyBitmessage-Send.png b/docs-de/images/PyBitmessage-Send.png
deleted file mode 100644
index 3a71fc6..0000000
Binary files a/docs-de/images/PyBitmessage-Send.png and /dev/null differ
diff --git a/docs-de/images/logo-de.svg b/docs-de/images/logo-de.svg
deleted file mode 100644
index d771314..0000000
--- a/docs-de/images/logo-de.svg
+++ /dev/null
@@ -1,123 +0,0 @@
-
-
-
-
\ No newline at end of file
diff --git a/docs-de/images/logo-en.svg b/docs-de/images/logo-en.svg
deleted file mode 100644
index 9def4ad..0000000
--- a/docs-de/images/logo-en.svg
+++ /dev/null
@@ -1,84 +0,0 @@
-
-
-
-
\ No newline at end of file
diff --git a/docs-de/images/logo.pdf b/docs-de/images/logo.pdf
deleted file mode 100644
index d15a8f7..0000000
Binary files a/docs-de/images/logo.pdf and /dev/null differ
diff --git a/docs-de/images/logo.png b/docs-de/images/logo.png
deleted file mode 100644
index 4342156..0000000
Binary files a/docs-de/images/logo.png and /dev/null differ
diff --git a/docs-de/images/ports_and_adapters.pdf b/docs-de/images/ports_and_adapters.pdf
deleted file mode 100644
index 37fde20..0000000
Binary files a/docs-de/images/ports_and_adapters.pdf and /dev/null differ
diff --git a/docs-de/images/ports_and_adapters.svg b/docs-de/images/ports_and_adapters.svg
deleted file mode 100644
index aa67312..0000000
--- a/docs-de/images/ports_and_adapters.svg
+++ /dev/null
@@ -1,172 +0,0 @@
-
-
-
-
diff --git a/docs-de/images/prefix-filter-binary-tree.pdf b/docs-de/images/prefix-filter-binary-tree.pdf
deleted file mode 100644
index c49aab5..0000000
Binary files a/docs-de/images/prefix-filter-binary-tree.pdf and /dev/null differ
diff --git a/docs-de/images/prefix-filter-binary-tree.svg b/docs-de/images/prefix-filter-binary-tree.svg
deleted file mode 100644
index 90f95db..0000000
--- a/docs-de/images/prefix-filter-binary-tree.svg
+++ /dev/null
@@ -1,1252 +0,0 @@
-
-
-
-
diff --git a/docs-de/images/signature.pdf b/docs-de/images/signature.pdf
deleted file mode 100644
index 94ae1dc..0000000
Binary files a/docs-de/images/signature.pdf and /dev/null differ
diff --git a/docs-de/images/signature.svg b/docs-de/images/signature.svg
deleted file mode 100644
index f02ba31..0000000
--- a/docs-de/images/signature.svg
+++ /dev/null
@@ -1,188 +0,0 @@
-
-
-
-
diff --git a/docs-de/images/xkcd-security.png b/docs-de/images/xkcd-security.png
deleted file mode 100644
index d05d29d..0000000
Binary files a/docs-de/images/xkcd-security.png and /dev/null differ
diff --git a/docs-de/logo.png b/docs-de/logo.png
deleted file mode 100644
index 1b0996f..0000000
Binary files a/docs-de/logo.png and /dev/null differ
diff --git a/docs-de/project2.pdf b/docs-de/project2.pdf
deleted file mode 100644
index b016d81..0000000
Binary files a/docs-de/project2.pdf and /dev/null differ
diff --git a/docs-de/project2.tex b/docs-de/project2.tex
deleted file mode 100644
index 9063647..0000000
--- a/docs-de/project2.tex
+++ /dev/null
@@ -1,78 +0,0 @@
-\documentclass{bfh}
-
-\title{Project 2}
-\subtitle{Bitmessage -- Communication Without Metadata}
-\author{Christian Basler}
-\tutor{Kai Brünnler}
-\date{\today}
-
-\begin{document}
- \maketitle
-
- \tableofcontents
-
- \section{Synopsis}
-
- TODO
-
-
- % Section basics
- \input{basics}
-
- The protocol is described in detail in my Seminar paper.
-
-
- \section{Goal}
-
- At the moment, there aren't many implementations apart from the official clients. Especially two things are missing: a multi purpose Java library and a usable mobile client. My goal for my \textit{Project 2} is to create the library, to be used next semester as a starting point for an Android\textsuperscript{\texttrademark} client in my Bachelor Thesis.
-
-
- \section{Issues}
-
- TODO
-
-
- \subsection{Unsigned Numbers}
-
- Java doesn't support unsigned number types. While Java 8 has some helper classes to address this issue, my goal is to support Java 7, which is needed for Android development, so I wasn't able to leverage them.
-
- \subsection{Proof of Work}
-
- Proof of work is needed for a message to be distributed within the Bitmessage network. This is to protect both the network itself from denial of service attacks and the users from spam.
-
-
- \section{Architecture}
-
- \subsection{Ports and Adapters}
-
- The library uses a ports and adapters architecture, which allows us to easily replace some implementations that might be platform dependent, such as storage or proof of work calculation.
-
- \includegraphics[width=\textwidth]{images/ports_and_adapters.pdf}
-
- The big advantage of this approach is that it's easy to test the core as well as each adapter by itself.
-
-
- \subsection{Network Management}
-
-
- \section{Usage}
-
- TODO
-
-
- \section{Discussion}
-
-
- \appendix
- \addcontentsline{toc}{section}{Appendix}
- \section*{Appendix}
- \renewcommand{\thesubsection}{\Alph{subsection}}
-
-
- \subsection{JavaDoc Documentation}
-
-
- \subsection{Literature}
-
-
-\end{document}
\ No newline at end of file
diff --git a/docs-de/seminar-blx.bib b/docs-de/seminar-blx.bib
deleted file mode 100644
index f1ead3e..0000000
--- a/docs-de/seminar-blx.bib
+++ /dev/null
@@ -1,11 +0,0 @@
-@Comment{$ biblatex control file $}
-@Comment{$ biblatex version 1.7 $}
-Do not modify this file!
-
-This is an auxiliary file used by the 'biblatex' package.
-This file may safely be deleted. It will be recreated as
-required.
-
-@Control{biblatex-control,
- options = {1.7:0:0:1:0:0:1:1:0:0:0:0:1:1:3:1:79:+},
-}
diff --git a/docs-de/seminar.pdf b/docs-de/seminar.pdf
deleted file mode 100644
index 4bedabb..0000000
Binary files a/docs-de/seminar.pdf and /dev/null differ
diff --git a/docs-de/seminar.tex b/docs-de/seminar.tex
deleted file mode 100644
index a468bc5..0000000
--- a/docs-de/seminar.tex
+++ /dev/null
@@ -1,257 +0,0 @@
-\documentclass{bfh}
-
-\usepackage[numbers]{natbib}
-\usepackage{xfrac}
-
-\title{Informatikseminar}
-\subtitle{Bitmessage -- Kommunikation ohne Metadaten}
-\author{Christian Basler}
-\tutor{Kai Brünnler}
-\date{\today}
-
-\newcommand{\msg}[1]{\textit{\textcolor{RedOrange}{#1}}}
-\newcommand{\obj}[1]{\textbf{\textcolor{OliveGreen}{#1}}}
-\newcommand{\node}[1]{\textbf{\textcolor{MidnightBlue}{#1}}}
-
-\begin{document}
- \maketitle
-
- \tableofcontents
-
- \newpage
- % Section basics
- \input{basics}
-
- \newpage
- \section{PyBitmessage}
-
- PyBitmessage ist der Standard Bitmessage Client und, wie der Name andeutet, in Python implementiert. Der Client bietet zwar alle Funktionen von Bitmessage, die User Experience ist allerdings nicht ganz optimal. Insbesondere lassen sich Nachrichten nicht in Ordner verschieben oder mit Labels versehen.
-
- \begin{figure}[h]
- \centering
- \includegraphics[width=0.8\textwidth]{images/PyBitmessage-Inbox.png}
- \caption[PyBitmessage: Inbox]{Der Posteingang von PyBitmessage.}
- \label{fig:inbox}
- \end{figure}
-
- Der Client ist ausserdem ziemlich langsam im Berechnen des Proof of Work. Auf einem MacBook Pro von 2012 kann es durchaus einige Minuten dauern bis eine Nachricht gesendet werden kann.
-
-% \begin{figure}[h]
- \begin{wrapfigure}{r}{0.5\textwidth}
- \centering
- \includegraphics[width=0.5\textwidth]{images/PyBitmessage-Send.png}
- \caption[PyBitmessage: Senden]{Eine neue Nachricht erfassen.}
- \label{fig:inbox}
- \end{wrapfigure}
-
- 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}
-
- Wir benutzen die folgende Konvention um zwischen verschiedenen Bestandteilen der Protokolls zu unterscheiden:
-
- \begin{tabular}{@{}>{$}l<{$}l@{}}
- \msg{version} & für Meldungen zwischen Netzwerkknoten \\
- \obj{pubkey} & für Objekte welche im Netzwerk verteilt werden \\
- \node{A} & für einzelne Netzwerkknoten \\
- \end{tabular}
-
-
- \subsection{Nomenklatur}
-
- Es gibt einige Begriffe welche schnell verwechselt werden können. Es folgt eine Liste der verwirrendsten.
-
- \subsubsection{message, msg}
- Eine Nachricht oder \msg{message} wird von einem Netzwerkknoten zum anderen geschickt, z.B. um neue Objekte anzukündigen oder um die Verbindung aufzubauen.
-
- Ein \obj{msg}-Objekt andererseits enthält die verschlüsselte Nachricht von einem Benutzer an einen anderen.
-
- \subsubsection{payload}
- Payload werden die Nutzdaten eines Protokolls genannt. Es gibt drei Arten von Payload:
- \begin{enumerate}
- \item Der Payload von Meldungen, z.B. \textit{Inventory Vectors}.
- \item Der Payload von Objekten. Dieser wird im Netzwerk verteilt.\footnote{Und ist Teil vom Meldungs-Payload.}
- \item Verschlüsselter Payload, der Chiffretext mit einigen Zusatzinformationen welche für die Entschlüsselung benötigt werden.\footnote{Dieser wiederum ist Teil vom Objekt-Payload.}
- \end{enumerate}
-
- \subsubsection{object}
- 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} 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{getdata}-Meldung für die noch fehlenden Objekte gesendet.
-
- 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.
-
- \subsection{Meldungen}
-
- 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 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}
- 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}
- Die Meldung \msg{getdata} kann bis zu 50000 Objekte anfordern, indem es deren Hashes sendet.
-
- \subsubsection{object}
- 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 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. \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.}
-
- \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 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\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üsseln erstellt er das temporäre Schlüsselpaar
-$$r$$
-und
-$$R = G r$$
-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
-$$K r = G k r = G r k = R k$$
-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}).
-
- \subsubsection{Signatur}
-
- 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 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.} 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, 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 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 kostet mehr beim Senden.
-$$ d = \frac{2^{64}}{n (l + \frac{t l}{2^{16}})} $$
-\begin{tabular}{@{}>{$}l<{$}l@{}}
- 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 \\
-\end{tabular}
-
- Um den Proof of Work durchzuführen, muss ein Nonce\footnote{Number used once.} gefunden werden, so dass die ersten acht Bytes vom Hash des Objekts (inklusive Nonce) eine kleinere Zahl repräsentieren als die Zielschwierigkeit.
-
- \subsubsection{Beschränkung der Meldungsgrösse}
- 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 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ä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, erlaubt aber eine viel genauere Kontrolle darüber, wie viel Traffic ein Knoten verarbeiten soll.\cite{wiki:prefixfilter}
-
- \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.
-
- 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.}
-
- 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. 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}
-
- Es gibt zwar inzwischen einen Client für Android,\footnote{Bitseal: \url{https://play.google.com/store/apps/details?id=com.github.bitseal}} dieser benötigt jedoch sehr viel Traffic, der Proof of Work dauert ewig und die Batterie hält nicht sehr lange.
-
- 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 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 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.
-
- 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. 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}
- \bibliography{bibliography}
- \listoffigures
-
-\end{document}
\ No newline at end of file
diff --git a/docs/.gitignore b/docs/.gitignore
deleted file mode 100644
index b812b07..0000000
--- a/docs/.gitignore
+++ /dev/null
@@ -1,38 +0,0 @@
-# Created by https://www.gitignore.io
-
-### LaTeX ###
-*.acn
-*.acr
-*.alg
-*.aux
-*.bbl
-*.bcf
-*.blg
-*.dvi
-*.fdb_latexmk
-*.glg
-*.glo
-*.gls
-*.idx
-*.ilg
-*.ind
-*.ist
-*.lof
-*.log
-*.lot
-*.maf
-*.mtc
-*.mtc0
-*.nav
-*.nlo
-*.out
-*.pdfsync
-*.ps
-*.run.xml
-*.snm
-*.synctex.gz
-*.toc
-*.vrb
-*.xdy
-*.tdo
-
diff --git a/docs/basics.tex b/docs/basics.tex
deleted file mode 100644
index b2cd463..0000000
--- a/docs/basics.tex
+++ /dev/null
@@ -1,15 +0,0 @@
- \section{Introduction}
-
- \subsection{What is Metadata?}
-
- While encryption technology like PGP or S/MIME provides a secure way to protect content from prying eyes, ever since Edward Snowdens whistleblowing we learned that metadata --- most notably information about who communicates with whom --- is equally interesting and much easier to analyze.
-
- There are a few examples where meta data might be enough to get you in trouble. If you write to someoune in the IS, you might not be able to fly the next time you want to visit the U.S. The no-fly list doesn't care if you're a journalist, or had no clue that this person was a terrorist.
-
- If Samsung knows Apple talks excessively with the sole producer of this nifty little sensor, they don't need the details --- the S7 will sport one of those, too. (Failing to see that Apple used it to build a car.)
-
- \subsection{How Can We Hide Metadata?}
-
- With e-mail, we can only prevent this by encrypting the connection to the server as well as between servers. Therefore we can only hope that both our and the recipient's e-mail provider are both trustworthy as well as competent.\footnote{Of course they should be free as well.}
-
- With Bitmessage we send a message to a sufficiently large number of participants, with the intended recipient among them. Content is encrypted such as only the person in possesion of the private key can decrypt it. All participants try to do this in order to find their messages.
\ No newline at end of file
diff --git a/docs/bfh.cls b/docs/bfh.cls
deleted file mode 100644
index 00961d3..0000000
--- a/docs/bfh.cls
+++ /dev/null
@@ -1,279 +0,0 @@
-\NeedsTeXFormat{LaTeX2e}
-\ProvidesClass{bfh}[2015/04/21 Atricle Class for my BFH reports]
-
-\DeclareOption{a4paper}{\PassOptionsToClass{\CurrentOption}{scrartcl}}
-\DeclareOption{11pt}{\PassOptionsToClass{\CurrentOption}{scrartcl}}
-\DeclareOption{oneside}{\PassOptionsToClass{\CurrentOption}{scrartcl}}
-\DeclareOption{titlepage}{\PassOptionsToClass{\CurrentOption}{scrartcl}}
-\DeclareOption*{\PassOptionsToClass{\CurrentOption}{scrartcl}}
-\ExecuteOptions{a4paper,11pt,oneside}
-\ProcessOptions
-
-%\RequirePackage{cite}
-%\RequirePackage[backend=bibtex]{biblatex}
-% Literatur- und Bilderquellen trennen
-%\defbibheading{lit}{\section*{Literature}}
-%\defbibheading{pic}{\section*{Pictures}}
-
-\LoadClass{scrartcl}
-\RequirePackage{remreset}
-
-\RequirePackage[utf8]{inputenc}
-\RequirePackage{graphicx}
-\RequirePackage{color}
-\RequirePackage{lmodern}
-\RequirePackage{url}
-\RequirePackage{lastpage}
-
-\RequirePackage{mathtools}
-\RequirePackage{amsfonts}
-%\RequirePackage{float}
-\RequirePackage{textgreek}
-%\RequirePackage{centernot}
-\RequirePackage{hyphenat}
-
-\RequirePackage[T1]{fontenc}
-\RequirePackage[scaled]{helvet}
-
-\RequirePackage{textcomp}
-\RequirePackage{eurosym}
-\RequirePackage{fancyhdr}
-\RequirePackage{alltt}
-\RequirePackage{verbatim}
-\RequirePackage{aeguill}
-%\RequirePackage{underscore}
-\RequirePackage{ctable}
-\RequirePackage[english]{babel}
-
-\RequirePackage{tabularx}
-\RequirePackage{wrapfig}
-\RequirePackage{ifthen}
-\RequirePackage[usenames,dvipsnames,svgnames]{xcolor}
-\RequirePackage{hyperref}
-\RequirePackage{listings}
-\RequirePackage{attachfile}
-
-\RequirePackage{enumitem}
-\RequirePackage{wasysym}
-
-\RequirePackage[absolute]{textpos}
-
-\definecolor{bfhblue}{rgb}{0.396,0.49,0.56} % Blue
-\definecolor{bfhorange}{rgb}{0.961,0.753,0.196} % Orange
-\definecolor{bfhorangelight}{RGB}{246,216,136} % Orange Light
-
-\hypersetup{
- linkcolor=blue, % color of internal links
- citecolor=green, % color of links to bibliography
- filecolor=blue, % color of file links
- urlcolor=blue, % color of external links
- colorlinks=true
-}
-\urlstyle{same}
-
-\typearea{12}
-%\bibliographystyle{alpha}
-\setcounter{secnumdepth}{4}
-\setlength{\parskip}{12pt}
-\setlength{\parindent}{0pt}
-
-\renewcommand{\familydefault}{\sfdefault}
-
-%\let\oldtoc\tableofcontents
-%\renewcommand{\tableofcontents} {
-% \oldtoc
-% \newpage
-%}
-\newcommand*{\tutor}[1]{\gdef\@tutor{#1}}
-\renewcommand{\maketitle} {
- \begin{titlepage}
- \newlength{\unitlengthtmp}
- \setlength{\unitlengthtmp}{\unitlength}
- \setlength{\unitlength}{1mm}
- \setlength{\TPHorizModule}{\textwidth}
- \setlength{\TPVertModule}{\textheight}
- %
- % BFH Logo
- \includegraphics[scale=1.25]{images/logo.pdf}
- %
- % Linien
- \begin{textblock}{1}[0,0](0,0)
- \begin{picture}(0,130)
- \put(20,0){\color{bfhblue}\rule{\textwidth}{1.2mm}}
- \put(20,40){\color{bfhblue}\rule{\textwidth}{1.2mm}} %28.5
- \end{picture}
- \end{textblock}
- %
- %Zentrierte Titel
- \begin{flushleft}
- \vspace*{4.08cm}
- \textsf{\textbf{\noindent{\Huge{\textcolor{bfhblue}{\@title}}}}}\\[0.4cm]
- \textsf{\huge{\textcolor{bfhblue}{\@subtitle}}}
- %
- %Angaben zum Dokument
- \begin{vfill}
- \begin{tabularx}{\textwidth}{lX}
- \textsf{Author} & \@author\\
- \textsf{Tutor} & \@tutor\\
-% \textsf{Expert} & \textsf\DozentA\\
-% \textsf{Studiengang} & \textsf{\Studiengang}\vspace{5pt}\\
-% \textsf{Autoren} & \textsf\AutorA\\
-% & \textsf\AutorB\vspace{5pt}\\
-% \textsf{Betreuer} & \textsf\DozentA\\
-% & \textsf\DozentB\vspace{5pt}\\
-% \textsf{Experten} & \textsf\ExpertA\\
-% & \textsf\ExpertB\vspace{5pt}\\
- \textsf{Date} & \textsf{\@date}\vspace{5pt}\\
-% &\\
-% &\\
-% \multicolumn{2}{p{\columnwidth-\tabcolsep}}{\textsf{\input{titlepage/titlepage_info}}}\\
- \end{tabularx}
- \end{vfill}
- \end{flushleft}
- \setlength{\unitlength}{\unitlengthtmp}
- \end{titlepage}
-}
-
-\pagestyle{fancy}
-\fancyhf{}
-\fancyfoot[R]{\hrule\thepage/\pageref{LastPage}}
-\fancyfoot[L]{\hrule\today}
-\fancyhead[L]{\@title}
-
-\fancyhead[R]{
- \includegraphics[height=1.5\baselineskip]{images/logo.png}
- }
-\addtolength{\headheight}{2\baselineskip}
-\addtolength{\headheight}{0.61pt}
-
-\lstset{
-language=XML, % Code langugage
-basicstyle=\ttfamily\scriptsize,
-keywordstyle=\color{OliveGreen}, % Keywords font ('*' = uppercase)
-stringstyle=\color{blue}, % String font
-commentstyle=\color{gray}, % Comments font
-numbers=left, % Line nums position
-numberstyle=\tiny, % Line-numbers fonts
-stepnumber=1, % Step between two line-numbers
-numbersep=10pt, % How far are line-numbers from code
-backgroundcolor=\color{BackgroundBlue}, % Choose background color
-frame=none, % A frame around the code
-tabsize=4, % Default tab size
-captionpos=b, % Caption-position = bottom
-breaklines=true, % Automatic line breaking?
-breakatwhitespace=false, % Automatic breaks only at whitespace?
-%showspaces=false, % Dont make spaces visible
-%showtabs=false, % Dont make tabls visible
-columns=fixed, % Column format
-morekeywords={Server, Listener, GlobalNamingResources,
- Resource, ResourceLink, Service, Connector, Engine,
- Host, Context, Environment,
- beans, bean, broker, destinationPolicy, policyMap,
- policyEntries, policyEntry, dispatchPolicy,
- strictOrderDispatchPolicy, subscriptionRecoveryPolicy,
- lastImageSubscriptionRecoveryPolicy, managementContext,
- persistenceAdapter, systemUsage, memoryUsage,
- storeUsage, tempUsage, transportConnectors,
- transportConnector, property, jetty, connectors,
- nioConnector, handlers, webAppContext},
-}
-% Shows a listing and creates an attachment with the source
-\newcommand{\attachlisting}[2][]{
- \hspace{0.95\textwidth}
- \attachfile[icon=Paperclip]{#2}
- \vspace{-5ex}
- \lstinputlisting[#1]{#2}
-}
-% 1 line number(s)
-% 2 variable name
-% 3 description
-% 4 example values
-\newcommand{\listinginfo}[4]{
- \colorbox{WhiteSmoke}{
- \parbox[t]{0.25\textwidth}{
- \printifnotempty{#1}{\texttt{#1:}\\}
- \textit{#2}
- }
- \parbox[t]{0.715\textwidth}{
- \printifnotempty{#3}{#3
- }
- \printifnotempty{#4}{
- \par
- \vspace{1ex}
- \colorbox{BackgroundBlue}{
- \parbox{0.69\textwidth}{
- \vspace{-2ex}
- \ttfamily
- \flushleft{#4}
- }
- }
- \par
- \vspace{0.5ex}
- }
- }
- }
- \par
- \vspace{-1.7ex}
-}
-\newcommand{\printifnotempty}[2]{
- \ifthenelse{\equal{#1}{}}{}{#2}
-}
-
-% Makes a red box that highlights errors or very important warnings
-\newcommand{\errorbox}[1]{
- \fcolorbox{Red}{LightPink}{
- \parbox{0.972\textwidth}{
- \begin{wrapfigure}[2]{l}{0.05\textwidth}
- \vspace{-12pt}
- \includegraphics[width=0.05\textwidth]{images/error.pdf}
- \vspace{12pt}
- \end{wrapfigure}
- #1
- }
- }
-}
-
-% Makes a yellow box that highlights warnings
-\newcommand{\warningbox}[1]{
- \fcolorbox{Goldenrod}{LightYellow}{
- \parbox{0.972\textwidth}{
- \begin{wrapfigure}[2]{l}{0.05\textwidth}
- \vspace{-12pt}
- \includegraphics[width=0.05\textwidth]{images/warning.pdf}
- \vspace{12pt}
- \end{wrapfigure}
- #1
- }
- }
-}
-
-% Makes a blue box that highlights special information
-\newcommand{\infobox}[1]{
- \fcolorbox{CornflowerBlue}{AliceBlue}{
- \parbox{0.972\textwidth}{
- \begin{wrapfigure}[2]{l}{0.05\textwidth}
- \vspace{-12pt}
- \includegraphics[width=0.05\textwidth]{images/info.pdf}
- \end{wrapfigure}
- #1
- }
- }
-}
-
-\RequirePackage{listings}
-\definecolor{BackgroundBlue}{cmyk}{0.05,0,0,0}
-
-\let\olditemize=\itemize
-\def\itemize{
- \olditemize
- \setlength{\itemsep}{-1.5ex}
-}
-
-\newcommand{\leadingzero}[1]{\ifnum #1<10 0\the#1\else\the#1\fi}
-%YYYY-MM-DD
-\newcommand{\todayI}{\the\year-\leadingzero{\month}-\leadingzero{\day}}
-
-\endinput
-
-
-
diff --git a/docs/bibliography.bib b/docs/bibliography.bib
deleted file mode 100644
index 431e3d2..0000000
--- a/docs/bibliography.bib
+++ /dev/null
@@ -1,29 +0,0 @@
-@ONLINE{wiki:protocol,
- url = {https://bitmessage.org/wiki/Protocol_specification},
- title = {Bitmessage Wiki: Protocol Specification},
- publisher = {Bitmessage Wiki},
- urldate = {2015-04-24},
- author = {Warren, Jonathan 'Atheros' and Coe, Jonathan},
- note = {\url{https://bitmessage.org/wiki/Protocol_specification}},
- year = {2015},
-}
-
-@ONLINE{wiki:prefixfilter,
- url = {https://bitmessage.org/wiki/Scalability_through_Prefix_Filtering},
- title = {Bitmessage Wiki: Scalability through Prefix Filtering},
- publisher = {Bitmessage Wiki},
- urldate = {2015-05-22},
- author = {Coe, Jonathan},
- note = {\url{https://bitmessage.org/wiki/Scalability_through_Prefix_Filtering}},
- year = {2015},
-}
-
-@ONLINE{issue:112,
- url = {https://github.com/Bitmessage/PyBitmessage/issues/112},
- title = {BigInv and ping/pong},
- publisher = {github.com},
- urldate = {2015-05-22},
- author = {Warren, Jonathan 'Atheros' and ISibbol},
- note = {\url{https://github.com/Bitmessage/PyBitmessage/issues/112}},
- year = {2015},
-}
\ No newline at end of file
diff --git a/docs/diagram.svg b/docs/diagram.svg
deleted file mode 100644
index 5ef0521..0000000
--- a/docs/diagram.svg
+++ /dev/null
@@ -1,5844 +0,0 @@
-
-
diff --git a/docs/images/logo-de.svg b/docs/images/logo-de.svg
deleted file mode 100644
index d771314..0000000
--- a/docs/images/logo-de.svg
+++ /dev/null
@@ -1,123 +0,0 @@
-
-
-
-
\ No newline at end of file
diff --git a/docs/images/logo-en.svg b/docs/images/logo-en.svg
deleted file mode 100644
index 9def4ad..0000000
--- a/docs/images/logo-en.svg
+++ /dev/null
@@ -1,84 +0,0 @@
-
-
-
-
\ No newline at end of file
diff --git a/docs/images/logo.pdf b/docs/images/logo.pdf
deleted file mode 100644
index 7e73e5d..0000000
Binary files a/docs/images/logo.pdf and /dev/null differ
diff --git a/docs/images/logo.png b/docs/images/logo.png
deleted file mode 100644
index 4342156..0000000
Binary files a/docs/images/logo.png and /dev/null differ
diff --git a/docs/images/ports_and_adapters.pdf b/docs/images/ports_and_adapters.pdf
deleted file mode 100644
index 37fde20..0000000
Binary files a/docs/images/ports_and_adapters.pdf and /dev/null differ
diff --git a/docs/images/ports_and_adapters.svg b/docs/images/ports_and_adapters.svg
deleted file mode 100644
index aa67312..0000000
--- a/docs/images/ports_and_adapters.svg
+++ /dev/null
@@ -1,172 +0,0 @@
-
-
-
-
diff --git a/docs/images/prefix-filter-binary-tree.pdf b/docs/images/prefix-filter-binary-tree.pdf
deleted file mode 100644
index f719777..0000000
Binary files a/docs/images/prefix-filter-binary-tree.pdf and /dev/null differ
diff --git a/docs/images/prefix-filter-binary-tree.svg b/docs/images/prefix-filter-binary-tree.svg
deleted file mode 100644
index 1fee1a9..0000000
--- a/docs/images/prefix-filter-binary-tree.svg
+++ /dev/null
@@ -1,1252 +0,0 @@
-
-
-
-
diff --git a/docs/logo.png b/docs/logo.png
deleted file mode 100644
index 1b0996f..0000000
Binary files a/docs/logo.png and /dev/null differ
diff --git a/docs/project2.pdf b/docs/project2.pdf
deleted file mode 100644
index b016d81..0000000
Binary files a/docs/project2.pdf and /dev/null differ
diff --git a/docs/project2.tex b/docs/project2.tex
deleted file mode 100644
index 9063647..0000000
--- a/docs/project2.tex
+++ /dev/null
@@ -1,78 +0,0 @@
-\documentclass{bfh}
-
-\title{Project 2}
-\subtitle{Bitmessage -- Communication Without Metadata}
-\author{Christian Basler}
-\tutor{Kai Brünnler}
-\date{\today}
-
-\begin{document}
- \maketitle
-
- \tableofcontents
-
- \section{Synopsis}
-
- TODO
-
-
- % Section basics
- \input{basics}
-
- The protocol is described in detail in my Seminar paper.
-
-
- \section{Goal}
-
- At the moment, there aren't many implementations apart from the official clients. Especially two things are missing: a multi purpose Java library and a usable mobile client. My goal for my \textit{Project 2} is to create the library, to be used next semester as a starting point for an Android\textsuperscript{\texttrademark} client in my Bachelor Thesis.
-
-
- \section{Issues}
-
- TODO
-
-
- \subsection{Unsigned Numbers}
-
- Java doesn't support unsigned number types. While Java 8 has some helper classes to address this issue, my goal is to support Java 7, which is needed for Android development, so I wasn't able to leverage them.
-
- \subsection{Proof of Work}
-
- Proof of work is needed for a message to be distributed within the Bitmessage network. This is to protect both the network itself from denial of service attacks and the users from spam.
-
-
- \section{Architecture}
-
- \subsection{Ports and Adapters}
-
- The library uses a ports and adapters architecture, which allows us to easily replace some implementations that might be platform dependent, such as storage or proof of work calculation.
-
- \includegraphics[width=\textwidth]{images/ports_and_adapters.pdf}
-
- The big advantage of this approach is that it's easy to test the core as well as each adapter by itself.
-
-
- \subsection{Network Management}
-
-
- \section{Usage}
-
- TODO
-
-
- \section{Discussion}
-
-
- \appendix
- \addcontentsline{toc}{section}{Appendix}
- \section*{Appendix}
- \renewcommand{\thesubsection}{\Alph{subsection}}
-
-
- \subsection{JavaDoc Documentation}
-
-
- \subsection{Literature}
-
-
-\end{document}
\ No newline at end of file
diff --git a/docs/seminar-blx.bib b/docs/seminar-blx.bib
deleted file mode 100644
index f1ead3e..0000000
--- a/docs/seminar-blx.bib
+++ /dev/null
@@ -1,11 +0,0 @@
-@Comment{$ biblatex control file $}
-@Comment{$ biblatex version 1.7 $}
-Do not modify this file!
-
-This is an auxiliary file used by the 'biblatex' package.
-This file may safely be deleted. It will be recreated as
-required.
-
-@Control{biblatex-control,
- options = {1.7:0:0:1:0:0:1:1:0:0:0:0:1:1:3:1:79:+},
-}
diff --git a/docs/seminar.pdf b/docs/seminar.pdf
deleted file mode 100644
index 2424342..0000000
Binary files a/docs/seminar.pdf and /dev/null differ
diff --git a/docs/seminar.tex b/docs/seminar.tex
deleted file mode 100644
index 778559a..0000000
--- a/docs/seminar.tex
+++ /dev/null
@@ -1,255 +0,0 @@
-\documentclass{bfh}
-
-\usepackage[numbers]{natbib}
-\usepackage{xfrac}
-
-\title{Informatikseminar}
-\subtitle{Bitmessage -- Communication Without Metadata}
-\author{Christian Basler}
-\tutor{Kai Brünnler}
-\date{\today}
-
-\newcommand{\msg}[1]{\textit{\textcolor{RedOrange}{#1}}}
-\newcommand{\obj}[1]{\textbf{\textcolor{OliveGreen}{#1}}}
-\newcommand{\node}[1]{\textbf{\textcolor{MidnightBlue}{#1}}}
-
-\begin{document}
- \maketitle
-
- \tableofcontents
-
- \listoffigures
-
- \newpage
- \section*{Abstract}
-
- Even if we use encryption, we reveal a lot about ourselves in the metadata we produce. Bitmessage prevents this by distributing a message in a way that it's not possible to find out which was the intended recipient.
-
- \newpage
- % Section basics
- \input{basics}
-
- \newpage
- \section{PyBitmessage}
-
- TODO
-
- \newpage
- \section{Protocol}
-
- We use the following convention to distinguish different parts of the protocol:
-
- \begin{tabular}{@{}>{$}l<{$}l@{}}
- \msg{version} & for messages between nodes \\
- \obj{pubkey} & for objects that are spread throughout the network \\
- \node{A} & for individual nodes \\
- \end{tabular}
-
-
- \subsection{Nomenclature}
-
- There are a few terms that are easily mixed up. Here's a list of the most confusing ones:
-
- \subsubsection{message, msg}
- A \msg{message} is sent from one node to another, i.e. to announce new objects or to initialize the network connection.
-
- An \obj{msg} on the other hand is the object payload containing content written by a user.
-
- In the protocol section, the term 'message' is never used to describe information exchange between users.
-
- \subsubsection{payload}
- There are three kinds of payload:
- \begin{enumerate}
- \item Message payload for message types, e.g. containing inventory vectors.
- \item Object payload, which is distributed throughout the network.\footnote{And part of the message payload.}
- \item Encrypted payload, which is the ciphertext with some metadata needed for decryption.\footnote{Which, again, is part of the object payload.}
- \end{enumerate}
-
- \subsubsection{object}
- An object is a kind of message whose payload is distributed among all nodes. Somtimes just the payload is meant. To send an object, proof of work is required.
-
- \subsection{Process Flow}
-
- The newly started node \node{A} connects to a random node \node{B} from its node registry and sends a \msg{version} message, announcing the latest supported protocol version. If \node{B} accepts the version,\footnote{A version is accepted by default if it is higher or equal to a nodes latest supported version. Nodes supporting experimental protocol versions might accept older versions.} it responds with a \msg{verack} message, followed by a \msg{version} message announcing its own latest supported protocol version. Node \node{A} then decides whether it supports \node{B}'s version and sends its \msg{verack} message.
-
- If both nodes accept the connection, they both send an \msg{addr} message containing up to 1000 of its known nodes, followed by one or more \msg{inv} messages announcing all valid objects they are aware of. They then send \msg{getobject} request for all objects still missing from their inventory.
-
- \msg{Getobject} requests are answered by \msg{object} messages containing the requested objects.
-
- A node actively connects to eight other nodes, allowing any number of incoming connections. If a user creates a new object on node \node{A}, it is offered via \msg{inv} to eight of the connected nodes. They will get the object and distribute it to up to eight of their connections, and so on, until all nodes have it in their inventory.
-
- \subsection{Messages}
-
- The messages, objects and binary format are very well discribed in the Bitmessage wiki \cite{wiki:protocol}, the message description is therefore narrowed down to a description of what they do and when they're used.
-
- \subsubsection{version / verack}
- A \msg{version} message contains the latest protocol version supported by a node, as well as the streams it is interested in and which features it supports. If the other node accepts, it acknowledges with a \msg{verack} message. The connection is initialized when both nodes sent a \msg{verack} message.
-
- \subsubsection{addr}
- Contains up to 1000 known nodes with their IP addresses, ports, streams and supported features.
-
- \subsubsection{inv}
- One \msg{inv} message contains the hashes of up to 50000 valid objects. If your inventory is larger, several messages can be sent.
-
- \subsubsection{getdata}
- Can request up to 50000 objects by sending their hashes.
-
- \subsubsection{object}
- Contains one requested object, which might be one of:
-
- \listinginfo{}{getpubkey}{A request for a public key, which is needed to encrypt a message to a specific user.}{}
- \listinginfo{}{pubkey}{A public key. See \ref{subsec:addr} \nameref{subsec:addr}}{}
- \listinginfo{}{msg}{Content intended to be received by one user.}{}
- \listinginfo{}{broadcast}{Content sent in a way that the Addresses public key can be used to decrypt it, allowing any subscriber who knows the address to receive the such a message}{}
-
- \subsubsection{ping / pong / getbiginv}
- People looking at the PyBitmessage's source code might be irritated by some other messages that seem to be implemented, but aren't mentioned in the official protocol specification. \msg{ping} does actually cause the node that implements this to send a \msg{pong} message, but this feature isn't actually used anywhere. \msg{getbiginv} seems to be thought for requesting the inventory, but as I understand it can't be used. \cite{issue:112}
-
- \subsection{Addresses}
- \label{subsec:addr}
-
- \textit{BM-2cXxfcSetKnbHJX2Y85rSkaVpsdNUZ5q9h}: Addresses start with "BM-" and are, like Bitcoin addresses, Base58 encoded.\footnote{Which uses characters 1-9, A-Z and a-z without the easily confused characters I, l, 0 and O.}
-
- \listinginfo{}{version}{Address version.}{}
- \listinginfo{}{stream}{Stream number.}{}
- \listinginfo{}{ripe}{Hash of both public signing and encryption key. Please note that the keys are sent without the leading 0x04 in \obj{pubkey} objects, but for creating the ripe it must be prepended. This is also necessary for most other applications, so it's a good idea to do it by default.}{ripemd160(sha512(pubSigKey + pubEncKey))}
- \listinginfo{}{checksum}{First four bytes of a double SHA-512 hash of the above.}{sha512(sha512(version + stream + ripe))}
-
- \subsection{Encryption}
-
- Bitmessage uses Elliptic Curve Cryptography for both signing and encryption. While the mathematics behind elliptic curves is even harder to understand than the older approach of multiplying huge primes, it's based on the same principle of doing some mathematical operation that can be done fast one way but is very hard to reverse. Instead of two very large primes, we multiply a point on the elliptic curve by a very large number.\footnote{Please don't ask me how to do it. If you really want to know, start at \url{http://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication} and \url{http://en.wikipedia.org/wiki/Elliptic_curve_cryptography}. If you want to make something that works, use a library like Bouncy Casle that does the heavy lifting for you.}
-
- The user, let's call her Alice, needs a key pair, consisting of a private key
-$$k$$
-which represents a huge random number, and a public key
-$$K = G k$$
-which represents a point on the agreed on curve.\footnote{Bitmessage uses a curve called \textit{secp256k1}.} Please note that this is not a simple multiplication, but the multiplication of a point along an elliptic curve. $G$ is the starting point for all operations on a specific curve.
-
- Another user, Bob, knows the public key. To encrypt a message, Bob creates a temporary key pair
-$$r$$
-and
-$$R = G r$$
-He then calculates
-$$K r$$
-uses the resulting Point to encrypt the message\footnote{A double SHA-512 hash over the x-coordinate is used to create the actual key.} and sends $K$ along with the message.
-
- When Alice receives the message, she uses the fact that
-$$K r = G k r = G r k = R k$$
-so she just uses $R k$ to decrypt the message.
-
- The exact method used in Bitmessage is called Elliptic Curve Integrated Encryption Scheme or ECIES, which is described in detail on Wikipedia (\url{http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme}).
-
- \subsubsection{Signature}
-
- To sign objects, Bitmessage uses Elliptic Curve Digital Signature Algorithm or ECDSA. This is slightly more complicated, if you want the details, Wikipedia is once again a fine starting point: \url{http://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm}.
-
- A detail that's interesting for people who want to implement a Bitmessage client, particularly if they do it using some object oriented approach: the signature covers everything from the object header sans nonce, and everything from the object payload except for the signature itself. Of course, not all objects are signed.\footnote{My approach was: think first, do it wrong, then refactor a lot.}
-
- \newpage
- \section{Issues}
-
- \subsection{Scalability}
-
- Bitmessage doen't scale.\footnote{Yet.} If there are very few users, anonymity isn't given anymore. With just a handful users, it's easy (for, let's say the NSA) to analyse traffic between nodes to find out who they might be writing to. Or let's just put them all under surveilance.
-
- With many users, traffic and storage use grows quadratically. This, because with more users there are more people who write messages as well as more users to write to for existing users.
-
- \subsubsection{Proof of Work}
- Proof of work has two uses. It helps to protect the network by preventing single nodes from flooding it with objects, and to protect users from spam. There's minimal proof of work required for the network to distribute objects, but users can define higher requirements for their addresses if they get spammed with cheap Viagra\texttrademark{} offers. The proof of work required for an address is defined in the \obj{pubkey}, and senders that are in a user's contacts should not be required to do the higher proof of work.
-
- The difficulty is calculated from both message size as well as time to live, meaning that a message that is larger or stored longer in the network will be more expensive to send.
-$$ d = \frac{2^{64}}{n (l + \frac{t l}{2^{16}})} $$
-\begin{tabular}{@{}>{$}l<{$}l@{}}
- d & target difficulty \\
- n & required trials per byte \\
- l & payload length + extra bytes (in order to not make it too easy to send a lot of tiny messages) \\
- t & time to live \\
-\end{tabular}
-
- To do the proof of work, a nonce must be found such that the first eight bytes of the hash of the object (including the nonce) represent a lower number than the target difficulty.
-
- \subsubsection{Message Size Limitation}
- To prevent malicious users from clogging individual nodes, messages must not be larger than 256 KiB. Because of the proof of work, large objects arent' practical for normal use, but might be used to occupy nodes by sending them garbage.
-
- \subsubsection{Streams}
- The intended solution for this problem is splitting traffic -- addresses, more precisely -- into streams. A node listens only on the streams that concern its addresses. If it wants to send an object to another stream, it just connects to a node in this stream to send the object, then disconnects. When all active streams are full, a new one is created which should be used for new addresses.
-
- The unsolved problem is to determine when a stream is full. Another issue is the fact that, as the overall network grows, traffic on full streams still grows, as there are more users who might wanto to write someone on the full stream.
-
- \subsubsection{Prefix Filtering}
- Jonathan Coe proposed this interesting way of handling traffic. This would need an update to the protocol, but allows for much finer grained control of how much traffic a node wants to handle.\cite{wiki:prefixfilter}
-
- Instead of streams, we imagine an address as a leave of a binary tree of height 65. The position is defined by the first 64 bits of the address' ripe. A prefix value $n$ defines the node at wich we start to listen. A client sending a message sets a 64 bit nonce where the first $n$ bits are copied from the recipient's ripe, and the rest is set randomly.
-
- \begin{figure}[htp]
- \centering
- \includegraphics[width=\textwidth]{images/prefix-filter-binary-tree.pdf}
- \caption[prefix filter: binary tree]{Note that the prefix value goes up to 64, i.e. each yellow triangle is itself a subtree of height 61.}
- \label{fig:bintree}
- \end{figure}
-
- Now let's assume Bob's address' ripe starts with \texttt{00101001\ldots} and his prefix value is 3. Alice sends a message tagged with \texttt{00110100\ldots}. The first three bits must be the same, but the rest is random. Bob's client now gets only objects that match his prefix, meaning he must only handle \sfrac{1}{8} of the overall traffic.\footnote{At the moment, the overall traffic is around 1 GiB per month.}
-
- As Bitmessage might get more popular, it would produce more and more traffic. Bob therefore might want to raise his prefix value to 4, further reducing the traffic he handles to \sfrac{1}{16} of the overall traffic. To do this, he simply publishes his \obj{pubkey} with the updated prefix value. This means of course that either must there always be a pubkey published, or Alice needs to be online at least once while the pubkey is published. Otherwise there's a 50\% chance (in our scenario) that the message won't reach Bob.
-
- While this would allow for a mobile client to only process messages meant for its addresses,\footnote{Choosing a prefix value of 64 would most certainly mean that it's alone on this stream.} this would mean to give up anonymity almost completely.
-
- TODO
-
- .
-
- .
-
- .
-
- .
-
- .
-
- .
-
- \subsection{Forward Secrecy}
-
- Obviously it's trivial for an attacker to collect all (encrypted) objects distributed through the Bitmessage network -- as long as disk space is not an issue. If this attacker can somehow get the private key of a user, they can decrypt all stored messages intended for that user, as well as impersonate said user.\footnote{The latter might be more difficult if they got the key through a brute force attack.}
-
- Plausible deniability can, in some scenarios, help against this. This action, called "nuking an address", is done by anonymously publishing the private keys somewhere publicly accessible.\footnote{See \url{https://bitmessage.ch/nuked/} for an example.}
-
- Perfect forward secrecy seems impractical to implement, as it requires to exchange messages prior to sending encrypted content. That would in turn need proof of work to protect the network, resulting in twice the work for the sender and three times longer to send --- that is, if both clients are online. Exchanging messages would be all but impossible if both users are online sporadically.
-
- \newpage
- \section{Discussion}
-
- Anonymity has its price. With Bitmessage it's traffic and disk space, with E-Mail it's trust. If we can't trust our e-mail providers (who can?), Bitmessage is a very interesting alternative, albeit not fully matured.
-
- I find the idea of trustless protocols, and peer to peer networks that typically leverage them, intriguing. In the beginning, the internet was a huge network of equal participants, but nowadays it all seems to end up at google or facebook. P2P and trustless protocols give us back some of that freedom that got lost in the cloud.
-
- That there is now a p2p e-mail replacement I think is absolutely amazing.
-
- Yes, it doen't scale as well as e-mail. But as I don't think we'll have the spamming problem with Bitmessage, thanks to Proof of Work, it might not have to.
-
- TODO
-
- .
-
- .
-
- .
-
- .
-
- .
-
- .
-
-
- \bibliographystyle{plain}
- \bibliography{bibliography}
-
- \appendix
- \addcontentsline{toc}{section}{Appendix}
- \section*{Appendix}
- \renewcommand{\thesubsection}{\Alph{subsection}}
-
- \subsection{TODO}
-
-\end{document}
\ No newline at end of file
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
deleted file mode 100644
index 19d7c12..0000000
Binary files a/docs/thesis.pdf and /dev/null differ
diff --git a/docs/thesis.tex b/docs/thesis.tex
deleted file mode 100644
index c338e45..0000000
--- a/docs/thesis.tex
+++ /dev/null
@@ -1,44 +0,0 @@
-\documentclass{bfh}
-
-\title{Bachelor Thesis}
-\subtitle{Android Client for Bitmessage}
-\author{Christian Basler}
-\tutor{Kai Brünnler}
-\date{\today}
-
-\begin{document}
- \maketitle
-
- \tableofcontents
- \newpage
-
- \section{Project Setup}
-
- \subsection{Current state -- why is it bad?}
- Until recently there was not mobile client for the Bitmessage protocol, and the client that turned up since is very wasteful to the devices resources, draining the battery in no time.
-
- \subsection{How should it be?}
- We need mobile Bitmessage clients that allows the user to choose the levels of convenience, privacy and resource hunger.
-
- \subsection{Why is it hard to do?}
- Bitmessage is very wasteful with resources by design. All messages are being sent to and stored on all nodes, and to protect the network a proof of work (POW) is required for all objects that are distributed.
-
- \subsection{How do I intend to do it?}
- As I developed Jabit, a Java implementation of the Bitmessage client, as my last project, I have great knowledge about the Bitmessage protocol. There are a few optimisations that I intend to do;
- \begin{itemize}
- \item Connect to only one reliable node instead of eight random nodes
- \item Don't save objects we can't decrypt
- \item Only connect to the network if we're on Wi-Fi and charging
- \end{itemize}
- Of course every option has its own drawbacks, so they will be configurable. As for the POW: Jabit highly optimises its calculation, which might be enough for modern smartphones.
-
- Further optimisations might introduce a server component that might do
- \begin{itemize}
- \item POW
- \item Request public keys, requiring us to give up some anonymity towards the server.
- \item Inform the client about new messages sent to its addresses. This would mean to give up our anonymity towards the server in the best case (which isn't supported by the protocol yet), towards the whole network (which is somewhat supported), or give up the private key to the server (which is just a big NOPE).
- \end{itemize}
-
-
-
-\end{document}
\ No newline at end of file
diff --git a/domain/build.gradle b/domain/build.gradle
index 215798a..eb83499 100644
--- a/domain/build.gradle
+++ b/domain/build.gradle
@@ -1,3 +1,15 @@
+uploadArchives {
+ repositories {
+ mavenDeployer {
+ pom.project {
+ name 'Jabit Domain'
+ artifactId = 'jabit-domain'
+ description 'A Java implementation of the Bitmessage protocol. This is the core part. You\'ll either need the networking and repositories modules, too, or implement your own.'
+ }
+ }
+ }
+}
+
dependencies {
compile 'org.slf4j:slf4j-api:1.7.12'
compile 'org.bouncycastle:bcprov-jdk15on:1.52'
diff --git a/domain/src/main/java/ch/dissem/bitmessage/BitmessageContext.java b/domain/src/main/java/ch/dissem/bitmessage/BitmessageContext.java
index 5414836..7878ada 100644
--- a/domain/src/main/java/ch/dissem/bitmessage/BitmessageContext.java
+++ b/domain/src/main/java/ch/dissem/bitmessage/BitmessageContext.java
@@ -32,10 +32,7 @@ import ch.dissem.bitmessage.utils.UnixTime;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
-import java.io.IOException;
import java.util.Arrays;
-import java.util.Collection;
-import java.util.TreeSet;
import static ch.dissem.bitmessage.entity.Plaintext.Status.*;
import static ch.dissem.bitmessage.entity.Plaintext.Type.BROADCAST;
@@ -43,8 +40,7 @@ import static ch.dissem.bitmessage.entity.Plaintext.Type.MSG;
import static ch.dissem.bitmessage.utils.UnixTime.DAY;
/**
- * Use this class if you want to create a Bitmessage client.
- *
+ *
Use this class if you want to create a Bitmessage client.
* You'll need the Builder to create a BitmessageContext, and set the following properties:
*