Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/465 Thanks!
So we'll have a very special
session today called the extended
lightning talk session under
the name of No, I sprinkled thee with
crypto dust, basically
the Internet reengineering session where
the talkers are going to present the
latest developments and new approaches
on applying cryptography to
make the Internet safe again.
And a happy place for everyone.
So please let me introduce the first
speaker, Mr. Ryan Lecky from CloudFlare.
Hello, everyone.
I'm going to talk about trusting servers
you can't touch.
So just a quick background.
I've been interested in trusted computing
technology for about two
decades now.
And then back when this first became
commercial, the Palladium stuff
from Intel and Microsoft,
I thought it was a huge threat to
individual freedom that you wouldn't be
able to run software on desktop
general-purpose computers.
They would lock you out.
And then I realized a few years ago that
system and I was really against it.
And then I realized system security is so
weak that it's already impossible to run
applications safely on general purpose.
Computers and the people are already
using completely locked down platforms
like cell phones all the time.
So the battle's already lost, so we might
as well get the benefit of trusted
computing.
So I started a company about three years
ago to try to build this for servers
and I sold it to CloudFlare in twenty.
And I've been working for CloudFlare
since then, working on interesting stuff
like this.
So why should you care about that?
About trusting anything that you can't
touch? Like if you're if it's your server
and you've got physical custody of it,
it's pretty easy to at least know
that that's the server you're talking to
by connecting to it directly and things
like that. There's a lot of good reasons
you might not want to have your server in
your house.
Good reasons to use culo.
You have lots of reasons
you might want to run a legally
challenging application.
I ran a remailer for a long time around
9/11 and that was a very challenging
thing. I ran a remailer while I was
working in Iraq and I got all sorts
of exciting people contacting me that
were actually like 30 feet away from me.
So it was it was very interesting.
You might want to have something where
you've got multisite redundancy
applications on multiple coasts of a
country or around the world and
you're only in one place at one time.
And then there's, of course, CDMS.
There's big companies that have lots of
servers around the world.
Any of the big consumer web apps have
servers all around the world.
And then, of course, there's a cloud
where everyone wants to host their
applications these days.
This is a really hard problem.
There isn't a single solution is going to
solve it. And nobody has solved the
really hard case of this problem.
They've only solved some easy cases
and some adjacent domain cases.
But I believe there are some ways to
solve it in a more thorough and
general-purpose way.
So there's two forms of this problem.
There's the protecting application on
a server that you have at one time and
then you want to send out to someplace.
So you have them all in a central depot.
You configure them and you send them out.
That's a very hard problem.
And then you have the extremely hard
version of this where you never had
access to the server and you're just
signing up to some cloud service that
you've never actually had direct physical
access to.
And you have to then trust the servers.
There's a variety of solutions to this,
and they range on the spectrum
ranging from reasonably good
security and really expensive, down to
reasonably good security sometimes, too.
Not so great security, but very cheap.
The government solution to this is to
build some crazy infrastructure with
multiple sites where you've got security
guards at each site and policies and
everything else. You've got multi parties
at each site and
we've seen how well with Snowden this
really works. So like there's
a lot of industries that use the same
model that are very regulated, that are
almost governmental.
But this isn't really an interesting
technique. It's not really scalable.
It's not going to work for new applications.
It's not really terribly exciting.
So we'll sort of gloss over it.
There's the computers and safe technique,
which is the enterprise model where you
have a secure cage in a data center
somewhere and you can trust
the security of the cabinet.
Cabinets are just like chicken wire and
anybody with a lock picking
tools or anybody with the
ability to bribe employees or the ability
to legally compel access has access.
But it's a pretty good model, works
pretty well. It works for most commercial
applications today.
And you can do it anywhere from very lax
all the way to a very secure.
And it's generally what people use today.
It's just very expensive.
It's very hard for me as an individual to
deploy servers in hundreds of sites
around the world like PvP style
servers. So what I could with the same
level security that I get if I co-located
servers myself and dedicated cages.
So it's not so attractive from that
perspective, then there's chip
package level security.
So you've got everything all the way from
smartcards, all the way up to hardware
security module. So from like a dollar up
to thirty thousand dollars, they use
the same kind of security model where
you've got a secure processor element
inside some sort of tamper assistance
package. And the idea being that anybody
tampers with the package, it erases keys
inside.
And there's some way that you can
guarantee that the the attacks on
the package necessarily are detected
and everything else.
As with anything, you can do a very good
job with this. You can do a very bad job
with this. It's one of the better
techniques, but it's hard to develop four
and there's a lot of problems and it's
usually for very, very static
applications where you've got a single
function. So the the probably the most
widespread deployment is GSM Sims
and which is a smart card deployment
where they do a very limited number of
functions.
So this is interesting, but it's not
really so much interesting for general
purpose applications.
Then there was the whole DRM technology
base that was created in the nineties and
they just kept sort of developing the
DRM. This case was to protect the
data from the owner of a system.
So they were. Rights holders of somebody
who wanted to lease out a movie to end
user would know that the user can't copy
the data.
That use case really wasn't very
successful.
It was, in fact, so unsuccessful in such
a big PR fiasco that they killed it
completely, except they kept developing
it and they switched it over to sort of a
more enterprise
world. There's Intel v Pro, which is used
for desktop management, is a direct
outgrowth of this.
There's Intel text on servers.
It's interesting and it's definitely an
area to explore
there. There's a lot of problems.
It's very complicated. It was designed
around like eight bit microcontrollers.
It was designed 20 years ago, basically,
and extended.
So it's not very easy to develop for it's
not very well documented.
And as we've seen with the FBI attacks
and all sorts of other stuff during this
conference and really over the past 20
years, there's really not a high level of
security that you can you can gain from
this technology.
It has the advantage that it's commodity.
It's already in a lot of the hardware out
there. So you can do some interesting
stuff. But as a standalone protection
against a server that someone has custody
of, it's not terribly great protection.
Then there's, of course, hardware security
modules of the embedded version on the
high end and they're so expensive that
they're not really a great solution for
most of these things.
You can pay about five grand for one now,
but usually they're twenty to thirty
thousand dollars. And usually you have to
sign an NDA, you get access to an API.
Very, very expensive and difficult to do
there. They also don't generally work in
the cloud. There is one exception that I
know about the Amazon Cloud
HSM where they charge you five thousand
dollars upfront and then about twelve
hundred dollars a month to rent access to
an HSM.
There's a very limited number of these
vendors and if I were building a
really interesting application, I'd be
really afraid to use one of these because
these things are inherently black boxes.
There's no way that you can easily, as
an end user audit quantity.
One of these things to do a real audit,
you have to tear them down and do all
sorts of destructive analysis.
And there's there's another
interesting problem of using these things
in the cloud that I'll get to in a second.
Plus the really slow, they're usually
like a forty six or a low end
arm inside this envelope for thirty
thousand dollars. So they're slower than
the host they're attached to.
So they're also not really a great
solution. So the best practice
that most people have for applications is
day is it's a segment, their application.
They have an untrusted and a trusted part
of their application.
They allow users to access the the front
end portion of it.
And if you have a system where it's
distributed front end, you might have
lots of front end servers
all around the world that aren't very
highly trusted. Then you have your back
end servers that are highly trusted, that
are in a smaller number of locations
where you can protect them.
It's a pretty good model, splitting
applications across multiple machines,
then actively monitoring them and
responding when an event happens and then
using HSM in a limited number of cases
where it's possible.
So this is really the best thing that
people do today.
However, it's not really terribly it's
not perfect.
And there's some serious pitfalls to the
the model.
So I respect that Amazon was
was first to deploy HSM
in a large commercial cloud environment.
But there were some issues.
The model was generally designed around
someone having direct physical access to
the HSM. So you knew you were talking to
this HSM?
Unfortunately, when you're talking to it
in the cloud, you have never seen this
happen. You don't necessarily know that
it's the same you're talking
to or that you're even talking to any of
them at all. You're just talking to
something over some sort of API.
So in the first version of this, they
didn't have any way you could prove that
you're actually talking to and it could
have been verbalized.
So the obvious solution to that was to
build a key into it at manufacture time
that can do an attestation operation to
prove that you're talking to a real
device.
The problem is now the current model is
to test it from within an Amazon VM,
inside your VPC, so that VM
you could also tamper with at the same
time. So the real lesson here is you have
to build these systems to have external
auditing or auditability.
However, there are some solutions that
are really exciting that might solve
this.
There's a company called Private Corps
that got bought by Facebook earlier
this year that was doing something really
interesting with an extension of Tresser
or try Bizer, where you could run
a hypervisor entirely inside the
L1, L2, L3 cache of an Intel Zeon,
which is maybe 20, 30 megabytes
of storage, and then use the CPU
operations, the crypto operations that
are inside this core.
So you have Asnar and you have some key
operations, everything else.
So this is all within the CPU die and
it's all pinned inside the CPU dy
CPU Die has some
properties of it's much harder to
extract keys from it.
You can't just plug a PCI card in like a
slot screamer and pull memory out
like you could if it was my memory.
So it's pretty cool.
There's a thing called Intel, SGX that's
coming out in probably twenty sixteen.
It's under NDA when the exact date is and
I don't actually know what the date is,
so I can't tell you for two reasons.
And there is an arm equivalent
of it which is basically like an HSM on a
chip, which will be pretty awesome.
However, that's at least a year away,
probably two years away for all the
stuff.
The the other solution to this would be
low end, since there's no fundamental
reason why these HSM have to cost twenty
or thirty thousand dollars. It's just
they only sell like a couple thousand of
them a year, and they're companies that
sell to banks that don't really care how
much they pay.
So.
So, yeah,
OK, so OK,
so that's a solution, and then there's
cloud hosts that are using keys embedded
in the system.
So there are some solutions that are in
the pipeline and we should be optimistic
about them and be working on them.
Well, very much.
So just another announcement
due to this, uh, tightly
packed schedule, we won't have time for
Q&A at the end, but
if you are interested and you are here in
the room, then you will just walk up to
the speakers and ask them if you are from
the Internet and you probably know how to
use the Internet and you can,
uh, look
the contact info up.
So let me just stop the next
talk, then.
Jeez, this makes hardware
so it's like
this and then you have to do
this one.
Oh, there they are.
So where's the
post wanky the home key on the
mic,
so just, uh, you didn't
see anything. So please welcome Andrea
and Daniel Tekla.
Hello, so we are representing
public infrastructure project that would
use a consensus based system to map
usernames to polychaete.
Now, there are good
security solutions out there, some of
which we have already heard are painful
to use for even technical people.
Now, it doesn't have to be like that.
Most of us can manage through that stage.
But do we actually always check
the host fingerprint?
Similarly, you can trust a certificate
authority. These systems tend to be much
more usable.
However, trusting a certificate authority
means you're trusting a certificate
authority, which might not always be a
good idea.
Now, incrementally building on top of
that and improving the station, our
systems like certificate transparency and
its counterpart used
for end to end, which allow
the user to verify what keys have been
reported to be theirs.
Yet when something
is done, the user will not have
proof that something bad happened.
Just reciting that count would have had
the same result.
Now we want to do better than that.
We want to have a verifiable public
mapping from user names to public office,
and we want to do so without having a
central trusted party, without requiring
the user to regularly check in with the
system.
And we want to do this on low end devices
that fit into your pocket.
Right.
So the way we've designed the semantics
of our system name is pretty
comparable to Namecoin.
There's one single global namespace
where users can register names of their
choice first come, first serve.
That does mean that like with any system,
for example, Twitter, if you look up at
NSA, you might not get exactly who you're
looking for.
And crucially,
unlike some systems changing,
the public key associated with a name
that already exists requires a signature
from the old key.
And the way we've implemented this in
name is by storing all of
the state in a
Mercal prefix tree where
the public keys are in the leaves,
that it's a prefix tree means that
the hash of the name
determines what path you take to
find the right leaf like you.
The first bit says whether you go left or
right from the root and you go down the
tree like that and
that it's a Merkle tree means that
every node contains the hashes
of its children.
So the root hash effectively summarizes
the tree.
So if I can have this
collision resistant.
Then there's no way to create
a different mapping with the same root
hash. And the reason this data structure
is nice is because
if a client has somehow gotten the right
root hash, a server can efficiently prove
to them that
a particular mapping is correct.
So the client just has to download the
path, verify that all the hashes
are correct, in particular the root hash,
and verify that that path actually
corresponds to that name.
Now, how we make this data structure
actually represent the state of the world
in the way we want it.
We will have a bunch of servers run
by independent organizations and people
around the world with some of them being
designated leader servers which select
what operations will be applied to the
state.
Not that the servers are not trusted to
verify their operations.
Correct, or to even check
signatures. This will be done
independently by each verifier.
However, the clients will send all
operations they want to perform to that
leader servers, the leaders of the
protest, then the rest of the servers
and the server will, by the end of that
round, sign the new state,
which will
be distributed to clients.
Now, to look up a name, a client can
contact any of the servers, don't
load the signatures, check there's enough
signatures, probably just one server
asserting that a
tree is the current state of the world,
which should not be sufficient, and
then perform that Merkle tree lookup
algorithm that just described to find the
key.
So if clients follow this process, they
get a strong antitrust guarantee
about the correctness of the public that
they found specifically
if two clients except to look up
from overlapping sets of good verifiers.
So that means.
They only need one good verifier
in common then that means
that they see a consistent view of the
mapping where all the semantics have been
preserved correctly.
So in practice, this
means that Laura Patris could upload
her key, verify
that the correct is in the system and
publish her username in her articles.
And we hope that we can make damn good
enough that the next Snowden could
just look up her username and use
that to establish first contact.
That is an ambitious goal.
But given that TOR relies
on nine directory authorities, we hope
that our comparable approach can be made
solid as well.
Now, we have coded up everything
we just talked about three times,
the final version is just
about 2000 lines of code goes in
memory, safe language, and we believe our
code is reasonably readable.
It's on a missing license available
online. And the installation and
set up process is really as simple as the
slides right now describe.
You run the go package manager.
Don't let the client you initialize
your account, which currently requires in
white and white, about which we will
explain later.
And then you upload your fingerprint or
your S.H. publicly now how
somebody would access that well
to create the BGP encrypted message
through the DNA user.
The command is up there.
We also have a group that does this.
DNA can also be used to store
host keys, so instead of clicking
yes to that fingerprint question, every
time you connect on your machine, we
could download those from the name.
Again, you can wrap this command in the
nice thing around us and say
we also experimented with patching porn
to use the same keys for
to initialization, yet Fondas
designed for stronger Nemati.
And even though you wouldn't
need a secret key, it would still need
both users to add each other as a
contact. And that is
appropriate where it is appropriate.
But is not usability as usable as email?
However, we are prototyping a new
application using the same protocol right
now.
Right, so there's lots of work left for
us to do.
First of all, we have several ideas
about how we want to improve the
protocol. For one, we don't really
have a good solution for name hoarding or
spam right now.
Currently, we require email verification
from a really strict white list.
And we also think it should be possible
to run our consensus protocol without
designing designating a particular
set of leaders.
Really, any large quorum
of verifiers should suffice, and
that would lead to better availability
for updates and
be a more egalitarian system.
We also want to integrate more
applications and most
importantly, we need our
code to get reviewed and we need to get
people running independent verifiers.
And that's what you can help with.
So if you if you're interested
in trying out DNA and looking at the code
and maybe even running a server, you can
go to that URL on GitHub or
contact us.
And so we'd like to thank Professor
Nikolais all at MIT for collaborating,
collaborating with us and
Jansma, Adam Langley and
Gallivan Inhofe for their useful
discussion and of course, MIT for paying
us.
Thank you.
Thank you very much.
So we'll just take the next slide,
which is somewhere
over here, a
new development in Otara
all the way here again.
OK, then, please welcome
Bassem.
By the way, that's the best pronunciation
of my name ever by informing people.
Um, so,
yeah, that I'm
so great.
So I would like to talk ten minutes about
Otara, which is all
the fault of Ian Goldberg and Co.,
which helps which have helped
to keep people safe over the last decade
or so.
So my name is you're from.
This is my email address and I confirm
that this is my fingerprints, if
you would like to contact me after.
Um, so.
Let's have a short introduction to
Otara and why it's great that
these things exist so altius, about
a decade young, it's about 10 years old
by now.
Mostly it's political agnostic.
So what we mean by that is that you could
use it of hejab, you could use it of
Yahoo Messenger, you could use it
over Amazon.
If there is still something that exists
and it offers a great amount of security,
there might be some issues because,
you know, it's 10 years old and there are
some things that we have to consider to
consider when we switz, for example,
elliptic curve cryptography or if
we would like to bump the key
sizes of, for example, the DSA session
keys. But, you know, these things are
coming probably with a dash of over the
next year in 2015.
And most of all, it's a peer reviewed
design and it has to withstand
10 years of scrutiny.
And of course, there has been some issues
and these issues have mostly been
been passed.
You know, those crazy things that
you can authenticate somebody by using
the socialist millionaire protocol does
things like
using a shared secret that you can
discuss with people just verifying some
of the other bound by the fingerprint of
another channel like, say, Twitter.
And most of all, it's open source.
So anybody can expect to code.
Anybody can compile it.
And everybody can submit
patches back.
So.
I would like to think of this as an
ecosystem and by having an ecosystem,
I mean that it's much more than just a
protocol, it's much more than a
specification.
And it's also the implementation of this
code and the reference
implementations, like, for example,
in JavaScript or in
Python or go.
So it's
much bigger than that.
And we can't just say that, you know,
OSHA probably isn't
broken by the NSA,
but it's much more
so.
One of these things is that some of the
reference implementations like, say, in
Python or in other languages are
incomplete.
Some of them have only implemented a
certain specification of
how they are like only the first two
and most of all, probably
not sufficient, which is
one of the most up to date recent
versions of out here.
And we would like to really fix this.
So if you are a Python program or if you
are going programmer, I would really
like to ask you to contribute to
this project
so far.
And then there's such a thing as
sometimes you might have heard of pitchin
and purple.
And I see some people laughing
that if it takes
them six months to update all the
windows, libraries that have at least
one remotely exploit
where the oldest one was six years
old, it takes them six months to update.
We might want to reconsider using these
things. And it might be the case that you
are using pitchin and you are probably
not an active target of whatever group,
but it's something to consider.
And then there such a thing as that
crypto is often bypassed and
by meaning that that's, you know, if you
might be using pitchin.
We might want to reconsider that and
maybe write a new clients.
And then there's such a thing as
usability and usability is the name of
the game no matter what.
I've seen a lot of people struggling with
setting about your analogy is probably
one of the simplest products to
do understand. And I've heard a lot of
good things that journalists,
users, activists find
relatively easy to use compared to
something like PGP, for example.
So this is very important and we should
make the clients as easy to use as
possible.
PitchIN or Getsy isn't one of them.
But Cryptococcus, for example, is one of
these projects that makes it more easy
for users to use
and use strong cryptography.
So this is the fourth year we have gone
from desktop clients and we have moved to
such a thing as product call of of,
you know, often online messaging is that
if I send you a message right now, you
know, there will be a message like 10
minutes later from somebody because we
have moved to mobile devices.
So we have kind of moved from the desktop
to the smartphone.
And we have seen, you know, great
like stuff like Tetsuko, which is being
done by the Guardian project.
I think Cryptococcus is also working on
like Android and iPhone
platforms.
And, you know, that is really
great. And we need more Lofthouse.
So this is kind of just
like mostly open source things and some
are better and some are kind of
good use more work.
And I would encourage
you to work on that once again.
So, you know, the kind of the
state of our job that's like a bunch of
reference implementations.
The most popular, one of the most well
known one is probably about Yahweh's is
redundancy.
That's a backtrack these days, which
isn't on Salesforce anymore at some
Burk's dot org chart that I am.
So if you have found any issues recently
that you would like to see fixed lots of
opportunities to present your pettiest
out, please open the back.
If you found something we would like to
see fix and we'll try to fix it as soon
as possible.
There's also things that pop up the note
here, and there have been people
who have come up to me the past few days
and have debunked a few issues and that
some I would really like to thank them
for them, which is pretty awesome because
it was one of the issues where somebody
might be have been dropping plaintext
instead of encrypting.
So these things need a lot more scrutiny.
And that's, you know, Jaffey
implementation, this being a dispatcher
who's just called out for Jafa.
So if you are Gylfi Hakka and you would
like to help unstrung secure crypto, you
should consider helping the ultra
off of Java guys.
Also Golden Girl Jianbai maintained
by Adam Langley.
So I am clients I would really
so we have been bitching about and I
sorry to use that word but we've
been getting a lot about
pitchin and it's time to
take action. It's time to get rid of this
and write something in a more secure
fashion because people have been relying
on this. And you know, I
work on tails as well.
And it bothers me that tale's
ships pitching at the moment because the
user this better.
So we really, really, really have to fix
this as soon as possible with
our support or support by default.
And hopefully also AMP one sec,
which is sort of like group
encryption protocol.
So then you have to kind of like
Chuck Paradigm, as I mentioned before,
that we have to kind of switch them.
You know, we have to deal with low
latency and high latency kind of like
messages. And it gives you a lot more
help.
And, you know, maybe someday
we will implement something like
asynchronous OCR.
So maybe that will be something like a
ratchet, maybe not.
Maybe it will be something different.
We might not implement it now, but
it's something to consider by making new
protocols.
So how can you help
people please work on the I am clients
other than software that we have been
like like working on and the
community has been working around the
ecosystem as we work around for over the
years.
And most of all, donate to these projects
that you you know, if you just
like consider like giving them a few
dollars to buy a coffee, this is really
important.
And these people deserve a lot more love.
So this is the end, but
this is not the end for now, this
is the end of the talk, but it isn't the
end of the year.
So I happily invite you to subscribe
to our mailing list, the development
mailing list, as you can see here.
And there's also no History Channel for
short communication cycles and
apostacy.
And that's my talk.
Thank you very much.
Thank you.
So the next ones
have a more special presentation
style,
so,
uh, I have
to close this one
to ask.
Ask.
Esq is keeping
its escaping, OK, G.
There it is.
Full screen
seems to work, but it always ends up with
something there it is.
So then please welcome
Elijah Sparrow and Christoph Qalandar.
No.
No, you're
I'm sorry I mixed that up.
Are you.
All right, OK, um,
so then please welcome Equinox.
No, no, I'm Elijah.
Elijah.
OK, so it's just
that everyone,
um, my name's Elijah
from the LEAP Encryption Access Project.
I'll talk a little bit about what we're
doing. And then Cristoff, we'll talk a
little bit about a related project called
Pixellated.
Um, the.
Our goals are to bring back the nineteen
nineties, not
all the 90s, but specifically
the part of the 90s that involved
not having all of our communication
right through a couple global
monopolies spent
bent on world domination.
And so.
Specifically, we're looking at
bringing back unencumbered open
protocols among Federated Service
providers.
Now we're kind of looking at,
uh, so sorry, what
is federation?
Typically it's user to provider to
provider to user, like ex MP
or email.
But I think
there's a broader definition that might
include
the way Pond works, where you kind of cut
out one of those providers or
any kind of it's very useful to have
a stable server somewhere that can
act as a gatekeeper that kind of prevents
civil attacks.
So.
These days, the cool kids are
really into peer to peer,
and that's cool.
More power to you with your block chain.
But we think that we can do federation,
right? And there's a lot of specific
cases where federation has certain
advantages.
Our two goals with Federation is that
we need to update it for the twenty first
century. So the federation in the 1990s
had some problems
and most important is that it's
the user should never have to trust
the provider for storing their content
and ideally none of the content in
transit or any of the metadata.
But from a provider's perspective.
So life was started by a lot of people
who have a long history in trying to run
service providers.
It's equally important to not have the
liability of storing their text for users
and to be able to deal with abusive
users. And so there's some tension
between those two, which is a lot
of the work that we try to resolve.
So federation is
not dead.
These are not projects that we're working
on, but these are interesting new
projects that were announced
recently in the last couple of weeks.
So dissent is a
pretty cool, probably anonymous
chat routing protocol that
doesn't necessarily have to be a
traditional service provider model, but
it is
designed with that in mind.
And then context is designed
around.
It's like cert transparency, but
it's designed around having
a service provider model.
So specifically, the activities
of LEEP.
I will go faster.
We have three things we create the
platform for automating sysadmin
drudgery, a bunch of new protocols
to make it so that you don't have to
trust the provider.
You the user doesn't have to trust the
provider and a bit mass client
to try to make the whole experience for
the end user equivalent
to what they might be used to in a
seamless as possible.
This is an example of using the platform
with these commands, you would become
a VPN provider.
Now there's a little bit there's a lot
more to it, but you get the basic idea.
It also includes the whole testing and
monitoring framework.
Again, the idea is to take all the
incredibly boring shit work out of being
a sysadmin. If you have been a sysadmin
for a while and try to make
being maintaining a medium size
provider and actually fun experience.
So some of the new protocols, just
a few of them, the
mainstay of what we do is everything's
built on this thing we call solid, that
which allows us to store all
the data in the cloud, but also
make it searchable locally and
synchronized among devices, presents
a database API to locally
run code.
And then we also have a whole set of
protocols to manage the user
registration and password stuff.
And
the third one of the third major
components is handling
handling keys in a way that are
invisible to the user and that
encode all the possible best practices
of of open PGP,
which is what we're currently using.
But we could swap it out with something
else.
So the third thing, the bitmap client,
this is a screenshot of what it looks
like on Linux currently,
we don't the stable version doesn't
actually have email working, but
will in the coming month.
And you can if you have
a Google listening device in your pocket
right now, you can go to the play store
and install the mask app.
The I just want to say one thing that
our goal is to have very, very minimal
UI in general.
So in this case, if you want to use email
with business, you have to you connect
with a traditional male user agent to
a locally running IMAP or some TV proxy.
And then later we'll look at something,
an alternative to that.
So regarding
the email we set
out actually two years ago, maybe
longer than two years ago, and our goal
was to obtain
all the possible security properties that
we could think of for better next
generation email, but make it super
easy to use. And this is an incredibly
fucking insane goal.
And somebody should have shot us, but.
So we have it we had it
working a year ago, but we still haven't
released it because there's so many
little things to work out.
So we're very close, but
we've actually I think we're pretty close
to attaining all
or most of these.
And I'd like to show you exactly
how. But I cannot in a
lot of time. But
just briefly, we use this
kind of soldat to support
all of our storage synchronized among
devices, but also protect all the
metadata. And while it's stored
on the server and in some
cases while in transit.
And also we've started
with a very simple system of
Federated Khiva, automatic
discovery and key validation of its
forward computer before compatibles, all
the cool new things that people are
working on, maybe
a name or Conex.
And also we've started
to do some
hidden service relay of SMTP.
Obviously, it's it's very limited
between provider provider.
And then the next step is to do from
a pond like from user
to provider relay and
then to to make
the user experience as seamless
and as most most like what people are
used to. We have
we rely heavily on security, a password
so that the the
provider never has that password.
So we can use it for all kinds of other
things, like decrypting local
secrets that are used for solidary.
Oh, I guess since I'm going to go after
us, let me just basically say that
infrastructure approaches.
We're in this category of infrastructure
approaches that are, I think, harder to
implement and offer more security
potential.
Sometimes the client approaches are more
appropriate depending on the context.
So DIAM is similar to what we're working
on. The ticket took a slightly different
strategy and then
there's also a bunch of interesting
client approaches.
OK, so
we thought leapers, a cool project,
but what we wanted to do
is we wanted to increase
the cost of dragnet surveillance and
we can't really do that without
mass adoption.
We really wanted to have as many
people as possible to use to use
GBG and use encryption.
And if you really
want to have everybody encrypting every
time, everything, every time you're
really today, you need a Web interface.
People use Gmail because it has
a Web interface.
Nobody really wants to install any
software on their computer anymore.
So we thought Leape really
does a cool job in encrypting everything,
but it does a poor job in
having a solution
that works for everybody.
So we don't extend it a little bit
and have a Web interface for Leape.
So what we did
is we wanted to have a backup interface
that is encrypting everything
and but also is good
looking and has everything you need for a
weapon to face from email.
And that is mostly search and tagging.
And the problem
is and that is a solution
we really, really did on purpose
is now that you have
everything on the server and there
is no crypto in the browser.
You also have the private key material
on the Web server.
We thought this is a it's OK
in our situation because we really
didn't want to be a solution for the
Noonans of this world, but we wanted to
be something that is as usable
as possible.
And we thought having
a provider, managing
your key material might be
usable, a trade off,
because then the provider can
have backups for your key.
You can't lose them maybe on
crossing the borders.
You don't want to have the keys with you
anyway.
And
that's how the web interface
looks at the moment.
So we are trying this is
as transparent as possible.
So as soon as you start typing in
and sending one, it gets encrypted
and every email
that you receive gets decrypted without
even noticing.
We have these little orange things
that are telling you the status of
the encryption, but that's it.
You don't have to do anything.
You can't forget to click the
icon to encrypt mail when you're sending
them.
Um, yeah,
I think
so.
When Christoph says you can put
when Christophe says you could use the
keys are stored on a server with pixilate
approach, it might be the server, might
be some little embedded device in your
house, it might be your friend server
you. It is designed
to provide maximum flexibility.
So you get to decide who to trust.
You can move that trust around.
Yeah, Leape is a federated, so it's not
Google that knows every key on the
planet. It is.
I don't know your private server at home
or I don't know your company or something
like that. And we thought it was a good
trade off.
Thanks.
Thanks a lot, Elijah and Jean-Christophe.
So how do I escape
the full screen?
OK, there it is.
So the next talk is going to
be Equinox this time.
This time for real.
So, again, Footscray.
And you are ready to go.
Thank you.
Hi.
AM
I'm trying to present to you
about using the krypto
that you already have, so this
talk is not going to be about algorithms,
is not going to be about protocols or
schemes or anything.
This is about making the best use of
the stuff we already have.
And I think that's something that has
been a little bit neglected.
So
there's Dean and DNS in
the title of this talked to us.
And I guess you're wondering why
I'm saying that this is not a group to
talk.
And I'm going to try
and show to you why we should use these
protocols and how we can combine them in
a useful way to
to get to a point where we have a better
Internet.
So let's do the quick in
terms of, you know, what I'm talking
about, this is just your plain
old system.
You have delegations from the various
zones down
just as the data for the Tower Project's
website.
Then we have recently tried
to add security to that by pushing
along the same lines, key material.
This is the DNS part.
And even more recently, we're trying
to push data into DNS that
ties these this key
infrastructure to the Web server cert.
So you can see on the bottom there is the
TOR Project's certificate for the
website.
And this is basically the very, very
abbreviated introduction to
Thayn, which is DNS like authenticated
naming of entities, I think.
But this is not new and this
is not anything special.
And it's not something that has received
a lot of positive feedback because
the protocol is really annoying.
You can do denial of service attacks with
it.
You need to trust.
I can because it's tied to the
domain name infrastructure.
If they are broken, then everything's
broken.
And I guess the
NSA is really in a good place there
because they can just go to dot net and
ask them for the keys and then they
can sign your domain with a different
for the different key and
they can push and that
the certificate that your Web server
uses.
So this doesn't seem to
be useful, but
there's Tor in the name of the talk, so
hopefully your.
Wondering where this is going,
what?
What this is about is that this system
with on the Nasdaq is one
single hierarchy and it's an
online system, so we can use
Tor, we can try
and use the DNS system
not on its own, but actually
by including Tor to get
the common base here.
Um, basically
we have we have this layer here
that allows us to mix and
isolate so
we can we can ask tor what
is what does the current DNS key for
my own domain.
That's the bottom part here.
And as a user I can go ask Tor,
Hey, I got this domain name,
can you can you fetch me the Dynarski for
it. And you can do that more than once.
You can check the reply is consistent
and this is only possible because
there's only one system here.
You can't have Dukas issuing
certificates for the same domain name.
It's it's an online system.
It needs to happen live.
You can't do offline attacks.
And suddenly this this
technology that that is so
far bigger in
and error prone is becoming interesting.
It makes it possible to
to have this discussion layer of trust
that establishes another chain aside
from the root domain infrastructure.
So we can go check.
And that's actually
something that I guess we should do.
We may need to to improve talk to do
this in a more efficient way.
There's the problem that DNS requests are
usually UDP and you don't want to
establish a session for it.
So it's not well suited to the current
infrastructure.
We need to do a lot of pushing if you
want to take advantage of this scheme
here, because most software doesn't
even support yet.
If you look at the major browsers, they
are taking a long time to implement it
with really bad excuses.
And we also need to push down on the NSA,
on our own domains, and we need to make
sure our registrars actually support it,
which is taking longer than it should.
But in the end.
Getting getting to this picture, I think,
would make the Internet more secure for
anyone using it in the
plain old way of going to a
website and establishing a
secure connection.
And, um, well, I
think that's already it.
You may have noticed this talk doesn't
really contain anything new.
It doesn't talk about algorithms.
There's there's no stuff that needs to go
through the ISO for standardization.
Um, and we we have I think
we have been neglecting trying to make
use of the tools we have here.
We need to to watch out for these
combinations and, um,
try try and see if we can make the
existing systems just
more secure by combining them.
And that was actually what I wanted to
leave.
Yeah, and go go through the case.
Thank you.
So last talk to
put it in here.
Mm hmm.
So hopefully it shows
up somewhere here.
Mm hmm.
Q Jeopardy melody.
So, um.
There it is, finally
flesh.
Yeah, it's behind
disk, not ejected properly.
So, um,
Bill Chillum, President Presentencing.
Please welcome Ladar Levison
Leiker Al.
Hi, folks, I'm here to talk about Daine,
it's kind of a big day for me.
I just pushed this massive
document out to the Internet.
It's the architecture specifications
threat model, pretty much about
a year's worth of work.
One hundred and eight pages.
It is guaranteed to put you to sleep.
That's where you can go to find it.
I'm actually putting a call out because
I want feedback.
It's still early enough that
if people make good suggestions
about little things that we can do to
make the system better, more secure,
more reliable, more user friendly,
I certainly want to hear it.
We set up a forum on dark male dot
info so we can engage electronically
and talk about what's in that massive PDF
file and hopefully.
Come up with some good ideas about how to
improve this, and then, of course, we
posted some code to GitHub, all
of the key management stuff is kind of
working most of the time when it feels
like it.
The message passing in Generation
Library is almost done.
We're going to push that out next month.
We've already started the server
integration. And right now your
client is kind of a command line tool.
Lipps.
I broke it.
It overheated.
So that's my basic model,
if you see these little icons on the
outside.
Those are your keys.
We actually call them signets.
We've kind of given up on the five
09 format.
The Cygnet format is just
a very simple binary
format that carries your cryptographic
information along with some signatures.
But I also built it in a very flexible
way because I realized that
I can't solve everyone's problems
right out of the gate.
So I wanted to build a format that would
be a gateway
to even more secure protocols,
a way for you to take your
key, stick it out on the Internet, use
this sort of more traditional service
provider model, but also
advertise that if somebody starts up a
conversation with you, they can click
a button and all of a sudden you guys are
talking peer to peer after a few Helman
handshake through Tor.
Those were our goals, put
simply, we wanted to make
encryption automatic.
For the masses,
we wanted to make it much more difficult.
To sort of track your social graph.
And basically, whenever possible, we
wanted to bring the security of the
system down to two things, the
strength of your password.
And the strength of your endpoints,
defenses to things that
we can control most of the time.
Our goal
was to do that.
I'm an American, I tend
to like the Second Amendment.
I know it has a bad rap over here,
but if you go back 200 years,
what the Second Amendment is really
about, it's about giving people the
ability to defend themselves.
And I just feel like right now
we're all wandering around the Internet.
But you.
And what we need is a new generation
of protocols that allow us to do
everything we do today on the Internet.
But do it without having to trust the
infrastructure to protect us, without
having to trust our service providers.
I want us to go back to a world where the
service is just hauling
a bunch of empty, nameless containers
like we do with ships.
Now, the way I built it, it's relatively
transport agnostic,
I created this bastardized version
of SBP that I called the MVP,
but there isn't anything preventing that
from going over a completely different
transport like TOR.
Or carrier pigeons.
The cornerstone of the entire system, and
I'm not going to be able to go through
everything in 10 minutes, but
I'm going to give it a shot, is
this DNS record that
a service provider posts
with their signing keep?
Everything ties back to that,
and I think I actually posted the wrong
property.
No, no, I posted the right property
with the wrong name.
So this is a slightly more complex
DNS record and
it actually sort of links up with
the previous talk, if you are using
DNS, SEC, you can actually stick.
A signed fingerprint
for your test certificate in the DNS
system, and you don't even need to get
your shirt signed by.
Of course, if you're not using DNS
sick, you still need to go pay for a
cert.
We're not stupid.
I just thought I'd cover briefly some of
the fields that I'm adding to the
organizational level Cygnet.
You know, I'm not just about improving
security, I'm about improving
accessibility and usability,
and part of that is making it easy
for people to configure their clients,
easy for their Web browser
to figure out where to go to let them log
in.
But like I said, the format is flexible.
Which means I put
in fields
from the get go, if you happen
to be running tours and you
would like to let people access your
system over tours
or deliver messages through tours.
All you got to do is populate that field
with the right information.
Now, that's a message.
And what I want you to take away from
this, and I can't go through all the
details right now and you probably can't
see all of the details,
is that each one of those blue boxes is
actually encrypted completely separately.
And if you can see what's after the dash,
you'll be able to see who
can access which particular box.
Now, one of the very sort of new
avant garde things that I did
was I moved the envelope information
out of the protocol
and into the encrypted message object.
And you've actually got two chunks here
that are relevant, the origin and the
destination chunk, which means
the sending service provider can see what
domain the message needs to go to,
but has no idea who on that domain
it's going to.
The destination domain gets the message,
knows where it came from.
But doesn't know who sent it.
They need to know where it came from.
They don't like it and they want to send
it back Christmastime,
right? Nobody returned any
packages.
So when I started with this project,
I wanted to not just
fix the current system, I wanted
to think about email
from the ground up with a focus
on security.
Because one of the big problems we have
with email today is the long
tail, everybody wants to be backwards,
compatible all the way back
to those elevons
from 40 years ago that were running
buggy versions of Sendmail.
So I started from the get go and I said,
we're going to have some certain security
requirements.
I was going to use a CBC
because I wasn't sure I trusted GCM, but
I kind of got talked out of that.
Made it simple, if you're running
a DMG only server,
stick it on point twenty six,
use Cenni.
So if you're hosting a service provider
with multiple domains, you
know, via that which certificate
to return,
don't feel like giving up pork.
Twenty six or don't think you could
convince your sys admin to open
up that port on the firewall.
No problem.
Just running down point twenty five.
And execute the specially crafted
start to this command that says, yes,
I really want to upgrade my connection
to.
And all the same rules apply,
in fact, there's no guarantee that
when you execute that command, you're
even staying on that same server.
Be very simple and very easy
to write a plug in to a current mail
implement mail server implementation
that sees that and just tunnell's it out
to somewhere else, possibly
even to a box in somebody's home.
So just briefly.
What does it look like when you send a
message and if you can see that?
Then you'll see there are no mailbox
names.
I kind of snipped the fingerprints there.
But in that conversation,
I set it up so that the servers know
they have the correct signets before
they transfer the message, and if they
don't, they just give back a temporary
error, go out, grab the cygnet,
because presumably the domain that
sending also supports dark mail.
If they don't, they probably shouldn't be
sending encrypted messages
and grabs the signal so it can verify the
signature on the inbound message.
And then you get a bunch of
gobbledygook.
So that's suspect is one hundred and
eight pages, like I said.
I could use your feedback,
everything from the three hundred and
twenty seven typos I know about.
To the 30
or so sections that just say TBD.
But there's a lot of information in
there.
There are a lot of things that I'm doing
at a very low level
that need to be reviewed by people who
know more than me.
I mean, I know a lot, but I also
know I don't know everything.
For example, I can't figure out how to
keep my servers from running off with my
best friend.
So that's it, folks.
I was going to say it takes about three
days to go through this and I only had 10
minutes, but after closing ceremonies,
if you want to keep talking, you can come
find me at the bar over at the Radisson.
OK, thank you very much.
So
please give a big hand for all of the
speakers of the session.
Again.
And now please enjoy the rest of the
Congress.