#LyX 2.0 created this file. For more info see http://www.lyx.org/
\lyxformat 413
\begin_document
\begin_header
\textclass beamer
\begin_preamble
\usetheme{lankton-keynote}

\setbeamercovered{transparent}
% or whatever (possibly just delete it)
\usepackage{fontspec}
%\newfontface\cjk{ShanHeiSun-Uni}
%\newfontface\cjk{BousungEG-Light-GB}
\newfontface\cjk{GBZenKai-Medium}
%\newfontface\cjk{ZenKai-Medium}
%\newfontface\cjk{ShanHeiSun-Light}
%\newfontface\cjk{ZenKai-Uni}
\end_preamble
\options aspectratio=169
\use_default_options false
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding utf8x
\fontencoding global
\font_roman default
\font_sans default
\font_typewriter default
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100

\graphics default
\default_output_format pdf5
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\spacing single
\use_hyperref false
\papersize default
\use_geometry true
\use_amsmath 2
\use_esint 0
\use_mhchem 1
\use_mathdots 1
\cite_engine basic
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\use_refstyle 0
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 2
\tocdepth 2
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout Title
net
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
kern-.8ex
\backslash
lower1.8ex
\backslash
hbox{
\end_layout

\end_inset


\begin_inset Graphics
	filename net2o-logo.pdf
	lyxscale 10
	scale 10

\end_inset


\begin_inset ERT
status open

\begin_layout Plain Layout

}
\backslash
kern-.5ex
\end_layout

\end_inset

: Reinventing the Internet
\begin_inset Argument
status open

\begin_layout Plain Layout
net2o
\end_layout

\end_inset


\end_layout

\begin_layout Author
Bernd Paysan (forthy)
\end_layout

\begin_layout Date
YBTI in depth session, 30C3, Hamburg 
\emph on
(later added stuff in italics)
\end_layout

\begin_layout Standard
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
addtobeamertemplate{headline}{}{
\backslash
vbox{
\backslash
vspace{3ex}
\backslash
hbox to
\backslash
paperwidth{
\backslash
hfill
\end_layout

\end_inset


\begin_inset Graphics
	filename net2o-logo.pdf
	lyxscale 5
	scale 5

\end_inset


\begin_inset ERT
status open

\begin_layout Plain Layout

~~~}}}
\end_layout

\end_inset


\end_layout

\begin_layout BeginFrame
Outline
\end_layout

\begin_layout Standard
\begin_inset CommandInset toc
LatexCommand tableofcontents

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Section
Motivation
\end_layout

\begin_layout Subsection
Somebody Broke the Internet\SpecialChar \ldots{}

\end_layout

\begin_layout BeginFrame
Somebody Broke the Internet\SpecialChar \ldots{}

\end_layout

\begin_layout Itemize
My thoughts about reinventing the Internet started in 2005.
 Yes, in 2005.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Things broken in 2005: IE6 won the browser war, Windows XP 
\begin_inset Quotes eld
\end_inset

naked
\begin_inset Quotes erd
\end_inset

 on the Internet was infected within 30 seconds with Sasser\SpecialChar \ldots{}

\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Back then I had a new responsibility: do the IT of my (former) employer
 on top of the IC design duties.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
1000 competing protocols and standards for 100 things, none of them really
 good\SpecialChar \ldots{}

\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Then we got Facebook and Cloud computing\SpecialChar \ldots{}

\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Fast forward: in June 2013 
\noun on
Edward Snowden
\noun default
 revealed that it's worse than the worst conspiracy theory
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
The Problem of 1000 Standards
\end_layout

\begin_layout Standard
\align center
\begin_inset Graphics
	filename standards.png
	width 80text%

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Solution: Start from Scratch
\end_layout

\begin_layout FrameSubtitle
Pretty radical step
\end_layout

\begin_layout Standard
What to keep from the current Internet, and what to throw away:
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Description
The
\begin_inset space ~
\end_inset

Good Packet--oriented protocol, open and free standards, connect everybody
 with everybody else
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Description
The
\begin_inset space ~
\end_inset

Bad Unencrypted by default, not enough addresses in IPv4, very slow adaption
 of IPv6, Postel principle leads to pretty bad implementations
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Description
The
\begin_inset space ~
\end_inset

Ugly Complex protocol stacks requires lots of resources to be fast, layering
 violations e.g.
 in encryption, many protocols doing similar stuff
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Subsection
Requirements
\end_layout

\begin_layout BeginFrame
Requirements
\end_layout

\begin_layout Description
Scalability Must work well with low and high bandwidths, loose and tightly
 coupled systems, few and many hosts connected together over short to far
 distances.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Description
Easy
\begin_inset space ~
\end_inset

to
\begin_inset space ~
\end_inset

implement Must work with a minimum of effort, must allow small and cheap
 devices to connect.
 One idea is to replace 
\begin_inset Quotes eld
\end_inset

busses
\begin_inset Quotes erd
\end_inset

 like USB or even Display Port with LAN links.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Description
Security Users want authentication and authorization, but also anonymity
 and privacy.
 Firewalls and similar gatekeepers (load balancers, etc.) are common.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Description
Media
\begin_inset space ~
\end_inset

capable This requires real--time capabilities, maybe pre--allocated bandwidth
 and other QoS features, end-to-end.
 
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Description
Transparency Must be able to work together with other networks (especially
 Internet 1.0, using UDP).
 
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
My Background
\end_layout

\begin_layout Itemize
I've done hardware development from analog to digital, and software development
 from embedded control, compilers to GUIs
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
I therefore think I can comprehend an network stack from top to bottom
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
I hate bloated, complex solutions, and I like simple, elegant ones
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The rule #1 of empowering the strong is 
\begin_inset Quotes eld
\end_inset

If you want it done right, you have to do it yourself
\begin_inset Quotes erd
\end_inset


\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Avoid unnecessary abstractions: Abstractions serve a purpose, they are not
 a value of their own
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
I like to program in Forth, as this is simple, elegant, malleable, and close
 to hardware
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
This is a lot of Research
\end_layout

\begin_layout Standard
My usual approach is:
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Enumerate
Look at what's out there
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Evaluate or at least judge it
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Conclude that it is broken
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Go back to rule #1: 
\begin_inset Quotes eld
\end_inset

If you want it done right, you have to do it yourself
\begin_inset Quotes erd
\end_inset


\end_layout

\begin_layout Pause

\end_layout

\begin_layout Standard
Sometimes, there's something out there that does work, though.
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Abstractions
\end_layout

\begin_layout Itemize
Network: Lines connected by switches
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Nodes: shared memory buffers --- remote write, local read (of course, the
 network stack can only access the memory that it is assigned to!)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Separation of commands and (bulk) data packets
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Every
\emph on
thing
\emph default
 is a file --- with metadata (
\begin_inset Quotes eld
\end_inset

tags
\begin_inset Quotes erd
\end_inset

) in a hash table, every
\emph on
one
\emph default
 is a key (with metadata)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Event--driven design: command packets are executed remotely and drive the
 protocol
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
P2P: all nodes are equal, no client--server distinction, content--oriented
 file 
\begin_inset Quotes eld
\end_inset

objects
\begin_inset Quotes erd
\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Subsection
In a Nutshell
\end_layout

\begin_layout BeginFrame
net2o in a nutshell
\end_layout

\begin_layout Standard
net2o consists of the following 6 layers:
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Enumerate
\begin_inset ERT
status open

\begin_layout Plain Layout

[
\backslash
setcounter{enumi}{2}
\backslash
usebeamertemplate{enumerate item}]
\end_layout

\end_inset

Path switched packets with 
\begin_inset Formula $2^{n}$
\end_inset

 size writing into shared memory buffers
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Ephemeral key exchange and signatures with Ed25519, symmetric authenticated
 encryption+hash+prng with Keccak
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Timing driven delay minimizing flow control
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Stack--oriented tokenized command language
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Distributed data (files) and distributed metadata (prefix hash trie)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Apps in a sandboxed environment for displaying content
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Section
Topology
\end_layout

\begin_layout BeginFrame
Switching Packets, Routing Connections
\end_layout

\begin_layout Itemize
Switches are faster and easier to implement than routers --- LANs (Ethernet)
 and backbones (MPLS) already use switching; use the concept of MPLS label
 stacks to use switching everywhere
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Routing then is a combination of DNS--like destination resolution and routing
 calculation (destination path lookup)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Block
\begin_inset ERT
status collapsed

\begin_layout Plain Layout

{
\end_layout

\end_inset

Path Switching
\begin_inset ERT
status collapsed

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_deeper
\begin_layout Itemize
Take first 
\begin_inset Formula $n$
\end_inset

 bits of path field and select destination
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Shift target address by 
\begin_inset Formula $n$
\end_inset


\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Insert bit-reversed source into the rear end of the path field to mark the
 way back
\end_layout

\end_deeper
\begin_layout Pause

\end_layout

\begin_layout Itemize
The receiver bit--flips the path field, and gets the return address
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Subsection
Low--Overhead Packet Format
\end_layout

\begin_layout BeginFrame
Packet Format
\end_layout

\begin_layout Standard
\align center
\begin_inset Tabular
<lyxtabular version="3" rows="6" columns="3">
<features tabularvalignment="middle">
<column alignment="center" valignment="top" width="0">
<column alignment="center" valignment="top" width="0">
<column alignment="left" valignment="top" width="0">
<row>
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\end_layout

\end_inset
</cell>
<cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\emph on
Bytes
\end_layout

\end_inset
</cell>
<cell alignment="left" valignment="top" topline="true" bottomline="true" leftline="true" rightline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\emph on
Comment
\end_layout

\end_inset
</cell>
</row>
<row>
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\emph on
Flags
\end_layout

\end_inset
</cell>
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout
2
\end_layout

\end_inset
</cell>
<cell alignment="left" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout
priority, length, flow control flags
\end_layout

\end_inset
</cell>
</row>
<row>
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\emph on
Path
\end_layout

\end_inset
</cell>
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout
16
\end_layout

\end_inset
</cell>
<cell alignment="left" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout
Internet 1.0 terminology: 
\begin_inset Quotes eld
\end_inset

address
\begin_inset Quotes erd
\end_inset


\end_layout

\end_inset
</cell>
</row>
<row>
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\emph on
Address
\end_layout

\end_inset
</cell>
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout
8
\end_layout

\end_inset
</cell>
<cell alignment="left" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout
address in memory, 
\begin_inset Formula $\approx$
\end_inset

port+sequence number
\end_layout

\end_inset
</cell>
</row>
<row>
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\emph on
Data
\end_layout

\end_inset
</cell>
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout
\begin_inset Formula $64*2^{0..15}$
\end_inset


\end_layout

\end_inset
</cell>
<cell alignment="left" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout
up to 2MB packet size, enough for the next 40 years
\end_layout

\end_inset
</cell>
</row>
<row>
<cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\emph on
Chksum
\end_layout

\end_inset
</cell>
<cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout
16
\end_layout

\end_inset
</cell>
<cell alignment="left" valignment="top" topline="true" bottomline="true" leftline="true" rightline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout
cryptographic checksum
\end_layout

\end_inset
</cell>
</row>
</lyxtabular>

\end_inset


\end_layout

\begin_layout Standard
\align center
\begin_inset Graphics
	filename header64.fig
	lyxscale 50
	scale 40

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Handover
\end_layout

\begin_layout Itemize
Typical problem in our mobile world: Devices hop from one network into another
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
To avoid connection loss, you need a handover
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
net2o handover works with the assumption that properly authenticated packets
 are ok, and then accepts a change in the return path
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The remaining problem are two simultaneous handovers, and the suggestion
 therefore is: Keep using both networks for the transition period.
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Routing Example 
\emph on
(added for cjdns)
\end_layout

\begin_layout Standard
Assumption: Somewhat hierarchical structure: backbones, ISPs, LANs.
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Itemize
My symbolic path to a backbone: laptop.net2o.1und1.level3
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Destination's path to a backbone: foobar.webhoster.bay-net.alter-net
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Connect paths together (reverse second): laptop.net2o.1und1.level3.alter-net.bay-net.w
ebhoster.foobar
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Neighboring entities know the path from one to the other, e.g.
 
\begin_inset Quotes eld
\end_inset

1und1
\begin_inset Quotes erd
\end_inset

 knows how to connect 
\begin_inset Quotes eld
\end_inset

net2o
\begin_inset Quotes erd
\end_inset

 to 
\begin_inset Quotes eld
\end_inset

level3
\begin_inset Quotes erd
\end_inset

, so you ask them (and cache the result in the DHT)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Splice the labels together, and you get a path: 
\begin_inset Newline newline
\end_inset


\size scriptsize
1010 || 1101.0001.0101.1000.1011.0011 || 0110.1010 || 0111.1010 || 1010.0010.0001.1001.1010.
0100 || 0110.1011.0111
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame

\emph on
Why Source Routing
\end_layout

\begin_layout ExampleBlock
\begin_inset ERT
status open

\begin_layout Plain Layout

{
\end_layout

\end_inset

Three possible schemes
\begin_inset ERT
status open

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_deeper
\begin_layout Enumerate
switched circuit (POTS, virtual: ATM, MPLS)
\end_layout

\begin_layout Enumerate
unique identifier (IP)
\end_layout

\begin_layout Enumerate
source routing
\end_layout

\end_deeper
\begin_layout Pause

\end_layout

\begin_layout Itemize
Separation of network gear and computers: Fast, dumb, stateless equipment
 for routing/switching
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The hierarchical topology is a derived 
\begin_inset Quotes eld
\end_inset

law of nature
\begin_inset Quotes erd
\end_inset

: people cluster together and connect clusters
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Attack vector is only bandwidth--based, and this can be mitigated (see 
\begin_inset Quotes eld
\end_inset

fair routing
\begin_inset Quotes erd
\end_inset

 below)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Routing slice is an implementation detail of each network segment (i.e.
 is a unique identifier within each subnet)
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Section
Encryption
\end_layout

\begin_layout BeginFrame
Security: Indirect Attacks are Cheaper
\end_layout

\begin_layout Standard
\align center
\begin_inset Graphics
	filename cryptonerd.png
	width 80text%

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Subsection
Key Exchange
\end_layout

\begin_layout BeginFrame
Key Exchange
\end_layout

\begin_layout FrameSubtitle
Evaluation of encryption algorithms
\end_layout

\begin_layout Description
RSA Pubkeys for reasonable strength are 4kbit or more; factoring is no longer
 
\begin_inset Quotes eld
\end_inset

that hard
\begin_inset Quotes erd
\end_inset

; further breakthroughs can be expected (RSA challenge withdrew the prices).
 
\emph on
See 
\begin_inset Quotes eld
\end_inset

the year on crypto
\begin_inset Quotes erd
\end_inset

 presentation from djb et al for more worrying stuff.

\emph default
 4kbit is 512 bytes, for the session invocation protocol this is above the
 
\begin_inset Formula $\sim$
\end_inset

1kB limit I've on current Internet.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Description
Diffie--Hellman Key strength to length relation is about the same as with
 RSA, so the same problem applies.
 Breakthroughs require non--linear expansion of key size; archived encryption
 can be decrypted later
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Description
ECC Elliptic Curve Cryptography has still only a generic attack (i.e.
 can be considered 
\begin_inset Quotes eld
\end_inset

unscratched
\begin_inset Quotes erd
\end_inset

, as the attack uses a fundamental property of the problem), and therefore
 256 bit keys (32 bytes) have a strength of 128 bits
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Standard
Therefore the choice now is Ed25519, a variant of Curve25519 from 
\noun on
Dan Bernstein
\noun default
 that supports signatures, too.
 This is a curve where the parameters are of high quality.
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Ephemeral Key Exchange+Validation
\end_layout

\begin_layout Standard
\align center
\begin_inset Graphics
	filename connection-setup.fig
	lyxscale 50
	height 80theight%

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Challenge: Side--Channel Attacks
\end_layout

\begin_layout Itemize
ECC Diffie--Hellman key exchange formula is 
\begin_inset Formula $s_{1}=pk_{1}*[sk_{2}]=pk_{2}*[sk_{1}]$
\end_inset


\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Operations with secret constants and variables under control of the attacker
 may leak information, especially if they are lengthy operations.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Constant time and no data dependent operation mitigates computational side--chan
nel attacks; Ed25519's pre--computed base 16 exponentiation helps further,
 current--measuring side--channel attacks still maybe possible
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Phase 1 (ephemeral key exchange) is not a big problem, as we choose a random
 secret for each connection
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Phase 2 is modified to use the shared secret 
\begin_inset Formula $s_{1}$
\end_inset

 to dilute the operation: 
\begin_inset Formula $s_{2}=pk_{a}*[sk_{b}*s_{1}]=pk_{b}*[sk_{a}*s_{1}]$
\end_inset


\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The secret ring multiplication is a short operation (multiplication mod
 
\begin_inset Formula $l$
\end_inset

 instead of curve point by scalar) with much less leakage impact
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
DH is faster and transmits less data than signature+verification
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Achieved: 3--Way Handshake
\end_layout

\begin_layout Itemize
The setup for an encrypted communication is done with three packets exchanged,
 no latency overhead to TCP
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The identifying pubkeys are encrypted, so they don't reveal the identity
 of Alice and Bob to Eve
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
All state for Bob is 
\begin_inset Quotes eld
\end_inset

stored
\begin_inset Quotes erd
\end_inset

 in packets on the net, so the third packet is the one that actually opens
 the connection at Bob.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The third packet also contains a random initialization vector, so if you
 want to continue a communication with Bob, a single packet is sufficient.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The time window for re--connecting is currently set to 10s, but can be made
 significantly longer
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Both sides use 
\begin_inset Quotes eld
\end_inset

tickets
\begin_inset Quotes erd
\end_inset

 with self--encrypted messages to store state in the network
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The key for self--encryption is rotated frequently (the mentioned 10s) to
 invalidate old tickets
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Subsection
Trust&PKI
\end_layout

\begin_layout BeginFrame
Trust&PKI
\end_layout

\begin_layout Itemize
Certification Authorities are a broken PKI and trust model
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The simple 
\begin_inset Quotes eld
\end_inset

remember the key
\begin_inset Quotes erd
\end_inset

 strategy of SSH is actually better
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
First connection requires more attention, e.g.
 ask the other side to solve a captcha to prove human
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Social networks can provide a network of trust: Trust your friends, and
 use them to connect you further
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Pubkeys don't need (nor should) to be public if you only want to be connected
 with your friends or peers
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Use the pubkey authentication for logins and alike, instead of passwords
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize

\emph on
Shared secrets (e.g.
 for Socialist Millionaire Protocol) are usually not available: If you have
 a shared secret, please use symmetric crypto directly.
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Subsection
Symmetric Crypto
\end_layout

\begin_layout BeginFrame
Symmetric Crypto
\end_layout

\begin_layout FrameSubtitle
Evaluation of encryption algorithms
\end_layout

\begin_layout Itemize
Must do AEAD encryption --- authenticate and encrypt/decrypt together
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Widely used candidate: AES in GCM
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Caveats: Galois counter is not a secure hash, but 
\begin_inset Quotes eld
\end_inset

only
\begin_inset Quotes erd
\end_inset

 a polynom checksum, which is known to be fragile 
\begin_inset CommandInset citation
LatexCommand cite
key "aescgm"

\end_inset

, and security is 
\begin_inset Formula $\le64$
\end_inset

 bits 
\begin_inset CommandInset citation
LatexCommand cite
key "gcm"

\end_inset

, that paper suggests using GF(p) with 
\begin_inset Formula $p=2^{128}+12451$
\end_inset

 to improve the weak key situation
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
AES uses a constant key --- makes side channel attacks more feasible
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Counter mode is actually a stream cipher, suggests using other steam ciphers
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Compare 
\noun on
Dan Bernstein
\noun default
's xsalsa+poly1305: uses a prime field for the polynome, so this would be
 a better candidate.
 Poly1305 still relies on the encryption for security.
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Keccak
\end_layout

\begin_layout Itemize
Suggestion: Use a strong hash for authentication instead
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Obvious candidate is the SHA--3 winner, Keccak, as this has a very good
 cryptanalysis
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Even better: Keccak in duplex mode can encrypt while computing the hash
 (at almost no cost)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
There's no constant key, either: Perfect side--channel protected AEAD operation
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Strength >256 bits, whereas AES--256 suffers from related--key attacks:
 very good security margin
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Keccak is a universal crypto primitive, with AES in GCM we need three primitives
: hash+AES+GHASH
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Keccak is both NIST--approved and (still) NSA--independent.
 I use Keccak with 
\begin_inset Formula $r=1024$
\end_inset

 and capacity 
\begin_inset Formula $c=576$
\end_inset

 as suggested by the Keccak authors.
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Cipher Algorithm Replacement
\end_layout

\begin_layout Standard
General idea: Have a selection of cipher suits and replace weak or broken
 when identified.
 But this has problems:
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Enumerate
All encrypted communication is stored away in Utah --- if the NSA finds
 a weakness, they can decrypt the history
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
People are lazy and only implement the easiest and fastest cipher --- this
 is the one broken first
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Hardware accelerators and even software is often very difficult to update
 due to the 
\begin_inset Quotes eld
\end_inset

never change a running system
\begin_inset Quotes erd
\end_inset

 principle
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
The operator or the end user does not have the know--how to make the right
 choice of a cipher algorithm --- this is guru level
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Standard
Therefore, the chosen cipher algorithm must last for a long time, and all
 systems must have an upgrade path
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Key Usage
\end_layout

\begin_layout FrameSubtitle
All keys are one--time--use only!
\end_layout

\begin_layout Standard
\align center
\begin_inset Graphics
	filename keyusage.fig
	lyxscale 50
	width 80text%

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Section
Flow Control
\end_layout

\begin_layout BeginFrame
Flow Control (Broken)
\end_layout

\begin_layout Itemize
TCP fills the buffer, until a packet has to be dropped, instead of reducing
 rate before.
 Name of the symptom: 
\begin_inset Quotes eld
\end_inset

Buffer bloat
\begin_inset Quotes erd
\end_inset

.
 But buffering is essential for good network performance.
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\begin_inset Graphics
	filename bufferbloat.fig
	width 100text%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
Buffer Bloat
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Alternatives?
\end_layout

\begin_layout Itemize
LEDBAT tries to achieve a low, constant delay: Works, but not good on fairness
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
CurveCP's flow control is still 
\begin_inset Quotes eld
\end_inset

a lot of research
\begin_inset Quotes erd
\end_inset


\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Therefore, something new has to be done
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\begin_inset Graphics
	filename bufferused.fig
	width 100text%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
That's how proper flow control should look like
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
\begin_inset Quotes gld
\end_inset

Buffer Bloat
\begin_inset Quotes grd
\end_inset


\end_layout

\begin_layout Itemize
Retransmits are making the situation worse in case of congestions and therefore
 should be avoided
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Riddle: How big should the buffer be, under the assumption that the bandwidth
 is used optimally, the bottleneck is on the other side of the connection,
 and a second data stream is opened up?
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Answer: about half the round trip delay, which are inevitably filled before
 any reaction is possible
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Buffers are good, but you shouldn't fill them up to the brim
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The problem is inherent in the TCP protocol, but since Windows XP did not
 provide window scaling, the per--connection buffer limit was 64k for most
 connections on the Internet for quite a long time.
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
net2o Flow Control
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\begin_inset Graphics
	filename flowcontrol.fig
	width 100text%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
Measure the bottleneck using a burst of packets
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Client Measures, Server Sets Rate
\end_layout

\begin_layout Description
Client recores the 
\emph on
time
\emph default
 of the first and last packet in a burst, and calculates the achieved rate
 for received packets, extrapolating to the achievable rate including the
 dropped packets.
 This results in the requested 
\emph on
rate
\emph default
.
\end_layout

\begin_deeper
\begin_layout Standard
\begin_inset Formula 
\[
rate:=\Delta t*\frac{burstlen}{packets}
\]

\end_inset


\end_layout

\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Description
Server would simply use this rate
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Fairness
\end_layout

\begin_layout Standard
Fairness means that concurrent connections achieve about the same data rate,
 sharing the same line in a fair way.
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Itemize
Ideally, a router/switch would schedule buffered packets round--robin, giving
 each connection a fair share of the bandwidth.
 That would change the calculated rate appropriately, and also be a big
 relief for current TCP buffer bloat symptoms, as each connection would
 have its private buffer to fill up.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Unfortunately, routers use a single FIFO policy for all connections
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Finding a sufficiently stable algorithm to provide fairness
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
We want to adopt to new situations as fast as possible, there's no point
 in anything slow.
 Especially on wireless connections, achievable rate changes are not only
 related to traffic.
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
net2o Flow Control --- Fair Router
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\begin_inset Graphics
	filename flowcontrol-fair.fig
	width 100text%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
Fair queuing results in correct measurement of available bandwidth
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
net2o Flow Control --- FIFO Router
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\begin_inset Graphics
	filename flowcontrol-unfair.fig
	width 100text%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
Unfair FIFO queuing results in twice the available bandwidth calculated
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Fairness I
\end_layout

\begin_layout Itemize
To improve stability of unfair queued packets, we need to improve that P
 regulator (proportional to measured rate) to a full PID regulator
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The integral part is the accumulated slack (in the buffer), which we want
 to keep low, and the D part is growing/reducing this slack from one measurement
 to the next
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
We use both parts to decrease the sending rate, and thereby achieve better
 fairness
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The I part is used to exponentially lengthen the rate 
\begin_inset Formula $\Delta t$
\end_inset

 with increasing slack up to a maximum factor of 16.
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Standard
\begin_inset Formula 
\[
s_{exp}=2^{\frac{slack}{T}}\quad\mathrm{where\,}T=\max(10ms,\max(slacks))
\]

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Fairness D
\end_layout

\begin_layout Itemize
To measure the differential term, we measure how much the slack grows (a
 
\begin_inset Formula $\Delta t$
\end_inset

 value) from the first to the last burst we do for one measurement cycle
 (4 bursts by default, first packet to first packet of each burst)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
This is multiplied by the total packets in flight (head of the sender queue
 vs.
 acknowledged packet), divided by the packets within the measured interval
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
A low--pass filter is applied to the obtained D to prevent from speeding
 up too fast, with one round trip delay as time constant
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
\begin_inset Formula $\max(slacks)/10ms$
\end_inset

 is used to determine how aggressive this algorithm is
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Add the obtained 
\begin_inset Formula $\Delta t$
\end_inset

 both to the rate's 
\begin_inset Formula $\Delta t$
\end_inset

 for one burst sequence and wait that time before starting the next burst
 sequence.
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
VDSL
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\align center
\begin_inset Graphics
	filename 30c3-1.png
	lyxscale 50
	width 80text%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
One connection on a VDSL--50 line
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
VDSL, Congestion
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\align center
\begin_inset Graphics
	filename 30c3-2.png
	lyxscale 50
	width 80text%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
One of four connections on a VDSL--50 line
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Unreliable Air Cable (WLAN)
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\align center
\begin_inset Graphics
	filename 30c3-3.png
	lyxscale 50
	width 80text%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
Single connection using WLAN
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Unreliable Air Cable, Congestion
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\align center
\begin_inset Graphics
	filename 30c3-4.png
	lyxscale 50
	width 80text%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
One of four connections using WLAN
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
LAN, 1GBE
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\align center
\begin_inset Graphics
	filename 30c3-5.png
	lyxscale 50
	width 80text%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
Single connection using 1GBE
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
LAN 1GBE, Congestion (4 servers)
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\align center
\begin_inset Graphics
	filename 30c3-6.png
	lyxscale 50
	width 80text%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
One of four connections using 1GBE
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
LAN 1GBE, Congestion (1 server)
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\align center
\begin_inset Graphics
	filename 30c3-7.png
	lyxscale 50
	width 80text%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
One of four connections using 1GBE, fair queuing
\end_layout

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Flow Control Conclusion
\end_layout

\begin_layout Itemize
Flow control works, but a change in the router FIFO policy can help things
 a lot
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The primary flow control approach is completely different from other approaches:
 Measure the available bandwidth!
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Scalability to very slow connections is still lacking: bursts are 8 packets
 long.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Congested traffic without fair queuing not satisfying
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame

\emph on
Why change the FIFO policy?
\end_layout

\begin_layout Itemize
Pushing the problem to the place where it occurs --- the router/switch ---
 makes the solution much easier
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Fair queuing solves the problem of TCP buffer bloat 
\emph on
now
\emph default
 (for connections competing with the bloated TCP connection) 
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Mitigates DoS attacks (flooding a node with traffic)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Not essential to deployment, but this result help people who work on improving
 router algorithms
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Section
Commands
\end_layout

\begin_layout BeginFrame
Data and Commands
\end_layout

\begin_layout Itemize
Data of several files/streams can be transferred interleaving, so a single
 connection can do multiple things in parallel
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Commands are send in command blocks, i.e.
 there is not just one command per block, but a sequence of commands!
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Commands are encoded like protobuf, i.e.
 7 bits per byte, and if the MSB of the byte is 1, there's another byte
 to follow (allowing arbitrary many commands)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The command 
\begin_inset Quotes eld
\end_inset

machine
\begin_inset Quotes erd
\end_inset

 is a stack architecture.
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Example: Connection Request
\end_layout

\begin_layout LyX-Code

\emph on
"pk1"
\emph default
 $, receive-tmpkey
\end_layout

\begin_layout LyX-Code
nest[
\emph on
 timestamp1
\emph default
 lit, set-rtdelay gen-reply request-done ]nest $,
\end_layout

\begin_layout LyX-Code
push-$ push' nest
\end_layout

\begin_layout LyX-Code
tmpkey-request key-request
\end_layout

\begin_layout LyX-Code

\emph on
base
\emph default
 lit, 
\emph on
csize
\emph default
 lit, 
\emph on
dsize
\emph default
 lit, map-request
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Example: Download three files
\end_layout

\begin_layout LyX-Code
net2o-code
\end_layout

\begin_layout LyX-Code
"Download test" $, type cr ( see-me )
\end_layout

\begin_layout LyX-Code
get-ip $400 blocksize! $400 blockalign! stat( request-stats )
\end_layout

\begin_layout LyX-Code
"net2o.fs" 0 lit, 0 lit, open-tracked-file
\end_layout

\begin_layout LyX-Code
"data/2011-05-13_11-26-57-small.jpg" 0 lit, 1 lit, open-tracked-file
\end_layout

\begin_layout LyX-Code
"data/2011-05-20_17-01-12-small.jpg" 0 lit, 2 lit, open-tracked-file
\end_layout

\begin_layout LyX-Code
gen-total slurp-all-tracked-blocks send-chunks
\end_layout

\begin_layout LyX-Code
0 lit, tag-reply
\end_layout

\begin_layout LyX-Code
end-code 
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Example: Answer to this request
\end_layout

\begin_layout LyX-Code
net2o-code
\end_layout

\begin_layout LyX-Code
x" 36000000000000000000000000000000019ED2" $, set-ip
\end_layout

\begin_layout LyX-Code
 $E373 lit, 0 lit, track-size
\end_layout

\begin_layout LyX-Code
$134299FF6F829E62 lit, $1A4 lit, 0 lit, set-stat
\end_layout

\begin_layout LyX-Code
$9C65C lit, 1 lit, track-size
\end_layout

\begin_layout LyX-Code
$130AFDAE900C649E lit, $1A4 lit, 1 lit, set-stat
\end_layout

\begin_layout LyX-Code
$9D240 lit, 2 lit, track-size
\end_layout

\begin_layout LyX-Code
$130AFDAE92CA4E25 lit, $1A4 lit, 2 lit, set-stat
\end_layout

\begin_layout LyX-Code
$148000 lit, set-total
\end_layout

\begin_layout LyX-Code
 $E373 lit, 0 lit, track-seek
\end_layout

\begin_layout LyX-Code
$79000 lit, 1 lit, track-seek 
\end_layout

\begin_layout LyX-Code
$78C00 lit, 2 lit, track-seek
\end_layout

\begin_layout LyX-Code
0 lit, ack-reply
\end_layout

\begin_layout LyX-Code
end-code
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Section
Distributed Data
\end_layout

\begin_layout BeginFrame
Distributed Data
\end_layout

\begin_layout Itemize
Following the 
\begin_inset Quotes eld
\end_inset

everything is a file
\begin_inset Quotes erd
\end_inset

 principle, every data object is a file
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Data objects are accessed by their hash.
 The associated metadata are 
\begin_inset Quotes eld
\end_inset

tags
\begin_inset Quotes erd
\end_inset


\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Metadata is organized as a distributed prefix hash tree
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Efficient distribution of data is important!
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Efficient Data Distribution
\end_layout

\begin_layout Standard
Puzzle: How efficient can you distribute data (e.g.
 a video stream) in a P2P network? Assume all peers are equal, and have
 the capacity to upload one stream in realtime.
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Itemize
Obvious topology: The bucket chain --- this shows that each node feeds the
 data through --- a 1:1 relation of what you get to what you send
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
bucket chain: 
\begin_inset Formula $O(n)$
\end_inset

 latency, 
\begin_inset Formula $O\left(\frac{1}{n}\right)$
\end_inset

 robustness (each node can break the chain)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Suggestion: Tree structure instead of chain, e.g.
 a quad--tree.
 The root divides the data into four parts, each going down one branch of
 the tree.
 The leafs distribute the data to the other three branches of the tree
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
For the quad--tree case, each node has only 8 neighbors: 4 sources and 4
 sinks
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Tree Distribution Network
\end_layout

\begin_layout Standard
\begin_inset Float figure
wide false
sideways false
status open

\begin_layout Plain Layout
\align center
\begin_inset Graphics
	filename avalanche.fig
	width 100text%

\end_inset


\end_layout

\begin_layout Plain Layout
\begin_inset Caption

\begin_layout Plain Layout
Avalanche distribution with quad--tree of depth 2
\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Possible Performance
\end_layout

\begin_layout Itemize
Trees with a bigger base reduce latency.
 Example: To transfer a Justin Bieber tweet to 50 million followers, a binary
 tree needs 25.5 hops on average, a quad--tree 12.8 hops, and an oct--tree
 8.5 hops.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
A typical domestic (inside e.g.
 Germany) hop--to--hop time is just 20ms.
 International hops can be in the order of 250ms.
 Assuming there is only one international hop in the chain, the latency
 to distribute Justin Bieber's babbling is typically just 500ms in a quad--tree.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Rule of thumb: 
\begin_inset Formula $bandwidth=latency$
\end_inset

, i.e.
 if it takes 20ms from hop to hop, each node should replicate data for 20ms
 --- if we make the tree wider, the linear effort of replicating data will
 dominate transfer time, if we make the tree more narrow, the hop--to--hop
 time will dominate.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The tree--like graph greatly reduces the number of nodes to know
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Distributed Prefix Hash Tree
\end_layout

\begin_layout Itemize
Most DHT approaches have poor performanc
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Prefix Hash Trees use a quite large base
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Only a few queries necessary to query an extremely large data base
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Suggestion: Active instantaneous replication of all changed data using the
 avalanche tree mentioned above
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Metadata Privacy
\end_layout

\begin_layout Itemize
A global distributed hash tree is 100% observable by anybody with enough
 money
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Private trees shared only between a group of people: 
\begin_inset Quotes eld
\end_inset

dark trees in a dark forrest
\begin_inset Quotes erd
\end_inset


\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Use different identities for distinct groups (one for your friends, one
 for your work, one for sharing pr0n), each one only known to that group:
 
\begin_inset Quotes eld
\end_inset

dark social graph
\begin_inset Quotes erd
\end_inset


\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Your public ID is only for first contacts and the things you want to publish
 (i.e.
 PR)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Use neighborhood relationships to limit spread of data --- e.g.
 a node participating in a data distribution tree may only be known to the
 peer nodes in that tree
\end_layout

\begin_layout Section
Applications
\end_layout

\begin_layout Subsection
Apps in a Sandbox
\end_layout

\begin_layout BeginFrame
Content or Apps?
\end_layout

\begin_layout Itemize
The current web is defined by content --- web apps (JavaScript) are an afterthou
gh
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Therefore, the application logic is usually on the server side
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
This doesn't work for a P2P network!
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Content is structured text, images, videos, music, etc.
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
App--Centric World
\end_layout

\begin_layout Itemize
There's a phenomenon I call 
\begin_inset Quotes eld
\end_inset

Turing creep
\begin_inset Quotes erd
\end_inset

: Every sufficiently complex system contains a user--accessible Turing--complete
 language
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Corollary: Every efficient sufficiently complex system can execute native
 machine code
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The application logic is to present the data; data itself is as above: structure
d text, images, videos, music, etc.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Executing (especially efficient) code from the net raises obvious questions
 about security
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
How to securely execute code?
\end_layout

\begin_layout Standard
There are several options tried; as usual, things are broken:
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Enumerate
Execute code in a controlled secure VM, see for example Java.
 This is broken by design, as securing something from the inside doesn't
 work.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Execute code in a sandbox.
 This has shown as more robust, depending on how complex the outside of
 the sandbox is.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Public inspection of code.
 This is how the open source world works, but the underhanded C contest
 shows that inspection is tricky.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Scan for known evil code.
 This is the security industry's approach, and it is not working.
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Code signing can work together with public inspection --- but using it for
 accountability doesn't work
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Standard
Therefore the choice is to sandbox public inspected code.
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Subsection
API Basics
\end_layout

\begin_layout BeginFrame
Formats&Requirements
\end_layout

\begin_layout FrameSubtitle
How to display things
\end_layout

\begin_layout Standard
\align center
\begin_inset Graphics
	filename formats+io.fig
	scale 36

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Why OpenGL?
\end_layout

\begin_layout FrameSubtitle
OpenGL can do everything
\end_layout

\begin_layout Standard
OpenGL renders:
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Enumerate
Triangles, lines, points --- simple components
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Textures and gradients
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
and uses shader programs --- the most powerful thing in OpenGL from 2.0.
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Standard
Real requirement: visualization of 
\emph on
any 
\emph default
data.
 OpenGL can do that.
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
How to connect the media?
\end_layout

\begin_layout FrameSubtitle
Lemma: every glue logic will become Turing complete
\end_layout

\begin_layout Itemize
currently used glue: HTML+CSS+JavaScript
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
containers with Flash, Java, ActiveX, PDF, Google's NaCl\SpecialChar \ldots{}

\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
conclusion: use a powerful tool right from start!
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
browser: run--time and development tool for applications
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Frameworks
\end_layout

\begin_layout Itemize
libsoil for images (PNG+JPEG loading into a texture)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
freetype-gl for fonts (TrueType/OpenType into a texture)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
OpenMAX on Android, gstreamer on Linux: videos into a texture
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
MINOΣ2: Lightweight OpenGL--based widget library in Forth (still a lot of
 work in progress)
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Section
Use Cases, Funding&Law, Adoption
\end_layout

\begin_layout BeginFrame
Use Cases, Funding&Law
\end_layout

\begin_layout Standard
\begin_inset Quotes eld
\end_inset

Layer 8
\begin_inset Quotes erd
\end_inset

 is the human in front of the screen.
 What will people use this for?
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Enumerate
Sharing photos and videos
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Chat & video telephony
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
News, opinions, scientific papers, sharing knowledge
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Online shopping
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
What's the problem with those?
\end_layout

\begin_layout Standard
From the point of view of Hans--Peter Uhl
\end_layout

\begin_layout Pause

\end_layout

\begin_layout Enumerate
\begin_inset Quotes eld
\end_inset

Pirated
\begin_inset Quotes erd
\end_inset

 videos and music (Hollywood will sue me), child porn+terrorism
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Molested children
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Dissident opinions, leaks
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Enumerate
Sex, Drugs & Weapons (Rock'n'Roll see 1.)
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
What to do about it?
\end_layout

\begin_layout Itemize
I don't want to know what my users want to do, nor do they want me to know
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Public shared stuff is possible to track down --- copyright is a political
 problem, the technology we build is there for making copies, primarily
 for cat videos and duck--face selfies
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
net2o is not primarily targeted at people who have 
\begin_inset Quotes eld
\end_inset

something to hide
\begin_inset Quotes erd
\end_inset

, it is intended to offer state--of--the--art privacy protection to everybody
 without performance and usability drawbacks
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Normal criminal investigation has still a very good chance to catch criminals
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
How to fund it
\end_layout

\begin_layout Itemize
Companies are not very trustworthy: If the NSA pays the bill, they do whatever
 the NSA wants.
 However, this problem also exists for FOSS projects to some extent (e.g.
 Dual_EC_DRBG was implemented in OpenSSL after receiving funding from an
 unnamed company).
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Kickstarter funding looks a lot more interesting, and can work for FOSS
 projects, too
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Ad--based funding is pretty problematic if you don't want to sell customer's
 data one way or another
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Storage space 
\begin_inset Quotes eld
\end_inset

in the cloud
\begin_inset Quotes erd
\end_inset

 comes with the responsibility to take copyright violations down
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
The whole economy behind such a network is huge; the cost for developing
 are tiny compared to that
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout BeginFrame
Adoption
\end_layout

\begin_layout Itemize
People have nothing to hide, so security is 
\emph on
not
\emph default
 a primary feature
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Ease of use is a key for success
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Adoption rate usually is exponential with a quite constant replication factor,
 i.e.
 people will complain about 
\begin_inset Quotes eld
\end_inset

empty wasteland
\begin_inset Quotes erd
\end_inset


\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
People like to feel good --- that's why Facebook has only a 
\begin_inset Quotes eld
\end_inset

like
\begin_inset Quotes erd
\end_inset

 button
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Censorship is not liked: Platforms like Facebook&Co.
 take down sexual content and copyrighted stuff.
 I won't (because I can't, by design)
\end_layout

\begin_deeper
\begin_layout Pause

\end_layout

\end_deeper
\begin_layout Itemize
Filter bubble instead of censorship: Don't be friend with people who share
 things you don't like
\end_layout

\begin_layout EndFrame

\end_layout

\begin_layout Section*
\start_of_appendix
Appendix
\end_layout

\begin_layout Subsection*
For Further Reading
\end_layout

\begin_layout BeginFrame
\begin_inset ERT
status open

\begin_layout Plain Layout

[allowframebreaks]
\end_layout

\end_inset

For Further Reading
\end_layout

\begin_layout Bibliography
\begin_inset CommandInset bibitem
LatexCommand bibitem
key "In20"

\end_inset


\noun on
Bernd Paysan 
\noun default

\begin_inset ERT
status collapsed

\begin_layout Plain Layout


\backslash
newblock
\end_layout

\end_inset


\emph on
net2o source repository 
\emph default

\begin_inset ERT
status collapsed

\begin_layout Plain Layout


\backslash
newblock
\end_layout

\end_inset

 
\begin_inset Flex URL
status open

\begin_layout Plain Layout

http://fossil.net2o.de/net2o
\end_layout

\end_inset


\end_layout

\begin_layout Bibliography
\begin_inset CommandInset bibitem
LatexCommand bibitem
key "aescgm"

\end_inset


\noun on
Shay Gueron, Vlad Krasnov
\noun default

\begin_inset ERT
status collapsed

\begin_layout Plain Layout


\backslash
newblock
\end_layout

\end_inset


\emph on
The fragility of AES-GCM authentication algorithm
\emph default

\begin_inset ERT
status collapsed

\begin_layout Plain Layout


\backslash
newblock
\end_layout

\end_inset


\begin_inset Flex URL
status collapsed

\begin_layout Plain Layout

http://eprint.iacr.org/2013/157.pdf
\end_layout

\end_inset


\end_layout

\begin_layout Bibliography
\begin_inset CommandInset bibitem
LatexCommand bibitem
key "gcm"

\end_inset


\noun on
Markku-Juhani O.
 Saarinen 
\noun default

\begin_inset ERT
status collapsed

\begin_layout Plain Layout


\backslash
newblock
\end_layout

\end_inset


\emph on
GCM, GHASH and Weak Keys
\emph default

\begin_inset ERT
status collapsed

\begin_layout Plain Layout


\backslash
newblock
\end_layout

\end_inset

 
\begin_inset Flex URL
status collapsed

\begin_layout Plain Layout

http://www.ecrypt.eu.org/hash2011/proceedings/hash2011_03.pdf
\end_layout

\end_inset


\end_layout

\begin_layout EndFrame

\end_layout

\end_body
\end_document
