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/63 Thanks!
OK, so now I shall
announce the speaker.
Um, that's because, uh, because
John got off his stomach, uh, my turn off
Brunet and she is
assisted by Florian
Dawdled, who was, uh, sitting
there and as a student, uh, to
Munich and as a
student assistant for the same project.
Um, and it's about, uh, what
is the alternative
have to the.
So have fun.
Thank you.
Now, I want to begin by saying this is
not just, you know, the two of us working
on it.
In particular, I have some coauthors,
Smartass and Martin Johnson.
And then there are a bunch of people who
have contributed code ideas.
I'm not going to read the names for it to
you here, but it's a long list, and
I might want to mention that this was
funded by the DFG, as some people really
are afraid of government funding, but
they didn't do any involvement.
We didn't get any calls.
OK, so where
are we? Well, we are in a
world with environmental disasters,
and the resulting unrest
among the civil population is being
countered by authoritarian institutions.
The surveillance to suppress dissent
and, well,
it's a difficult situation.
So in this situation, we want to
protect our privacy, our civil
liberties and so our adversary
model, as we now know,
has to be a rather strong one.
So we have to assume that first, we can
have any role, can have multiple
identities, has lots of computational
power, has legal power
in our national security that are
subpoenas. Give me your private key,
please.
Now we still want to assume that you
can't break or prevent the use of
cryptography because, well, if you can do
that, we're pretty much screwed.
We hope he doesn't compromise every end
user system out there, and
that's a bit of a strong assumption.
But again, if he does that, I can't
help and we assume he doesn't
want to prevent network communication
overall again, that the economic
cost of doing so, the economic costs of
controlling all communication is formed
presumably too high, even for that kind
of adversary.
So if you have the kind of adversary
and we say, OK, we want to secure our
communication by using encryption.
One fundamental thing all of our
systems rely on is a public key
infrastructure, and the public
key infrastructure is broken under this
adversary model that we have.
And so and we look at the
various systems that have been
compromised recently.
You know, Skype bought by Microsoft
and now easily controlled Lavabit.
Give me your keys.
Thank you very much.
PRISM. I have sent stuff to a central
server. Central servers easily
taken over.
Did you know Tor? Well, I've trusted some
authority and 12th the trust was somewhat
misplaced.
It doesn't matter if my encryption is the
best encryption on the planet.
If the PCA is broken, everything is lost,
right?
So we must decentralize really
to look at this centralized
infrastructure, as we have today, is
easily controlled, I.A.
controls no resources.
There's the roots on the DNA school
certificate, ex-boyfriend case,
major browser vendors. All of these live
in one country pretty much, or have a
significant business presence in one
country and are therefore subject to the
laws of that country.
And we know that that country is not
known for respecting users privacy.
So we need to decentralize
now when we try to build a decentralized
Pichai.
One of the fundamental insights into this
domain comes from Zuku.
It's called Zuko's triangle.
Some of you might have heard about it
before. And what he said is, Well, we
want three things to one name system.
We want it to be secure.
We want the names to be global.
We want the names to be memorable.
OK, global names means the meaning for
name is the same for everybody on the
planet. If they ask for it, they get the
same value. Ideally memorable
means I can pick names that are like
Alice Bob, not he has some cryptographic
512 bit identifier.
Remember that and type it incorrectly
every time and secure
it? Well, secure is kind of a bit fuzzy.
You know, what does it all include?
But we have to think secure as
with respect to the adversary model we
have, if we have a trust anchor like the
DNS root zone, like the next five or nine
certificate authority, that's no longer
secure, right?
And if you decide, well, secure is not
that strong, the adversary, then well,
Zuko's triangle doesn't hold.
But if you really look at this adversary
model, you have to say, OK, we can't have
all three.
Let's look at some examples for those
systems that have two of them.
So it's global and memorable names.
We have hierarchical registration in the
classical domain name system.
I assume everybody is somewhat familiar
with that.
With cryptographic identifiers.
We have global names that are perfectly
secure with the public key.
It's in the name, so we can then
sign the records with state publication
of the crypto is fine. It's all good, but
well, they're not memorable.
Not yet seen a crypto system that has a
public key that I can memorize easily
and memorable and secure.
Well, this pet name system.
So the easiest example of this is it's
the host file in there.
You can put a memorable name and a
number, and as long as your computer
isn't compromised, you don't even need
crypto. You will get that name up to a
number, but it's not useful for anybody
else. It's the least global system.
It's only for, you
know, their designs to try to improve
this.
If you look at DNS, sic where we add
certificates to DNS, that's trying to
make DNS a bit more secure
if we don't quite get all the way secure
given our adversary model, there's
a monarchy or else we're serious, OK,
let's make a phrase that makes it easy to
remember this Python 12 bit string.
It's a suggestion by the guys at the sera
suggestion. And the problem is
for me, when I define memorable, I say
low entropy. And of course, I don't get
away with C entropy. I need to keep the
information there.
And yes, maybe this broken English
sentence is a bit easier to remember than
if iPhone 12 bit key.
But again, we don't really get memorable,
right?
And then there is an approach called
sudsy, which effectively says, OK, we
have these pet name systems.
How about I make my pet names available
to you?
So I put them into a public database
and then you can carry my names as long
as you have a name for me.
So we get kind of transitivity.
You can use my name so no longer just for
me, but they're not truly global.
But everybody has its own his own
perspective, and this is kind of the
foundation for the new name system.
Now, some people here might say, OK, what
about name coin?
And was a nice article by Aaron
Schwartz, who said squaring Zuko's
triangle and said Name coin right bitcoin
allows us to fix that.
OK, well, the names and income I give
them, they're memorable.
Check that the global check
that are they secure?
Well, if they have a different adversary
model to start with
availability of names.
So availability is a security goal.
Well, they limit the registration rate.
I can't just register building domains
too, but it's not enough name coin out
there to do that.
And the second problem is that first, we
must not have fifty one percent off the
compute power.
So aside, for inefficient and so on,
the assumption that it's made is adverse.
So it's not very strong computationally.
I'm not sure that that is necessarily
true, given what we
know about the buildings in Utah and the
rest of the world.
Or, you know, maybe the NSA has a nice
botnet to.
They do it.
OK, so let's talk about the new
name system.
So we have a decentralized name system is
secure, memorable names.
So you start by editing your
own zone and you can
make those names available to others by
signing them and publishing them online.
As I said, you get this delegation
property from Sazi that others when they
have learned your zones, can look up
names in your zone.
We also support global unique secure
identifier, so the dot onion
style where you have your publication, if
you can use that to, you know, nobody
said that you cannot have two different
name systems combined, so you can take
this side of the triangle, that side of
the triangle, that side of the triangle
and mix and match.
We just don't get one name that has all
of them at the same time.
We
have additional indigenous query
and response privacy.
So when you do a query in the system in
DNS, everybody OK, everybody
at the NSA can see what name you're
looking up and what the answer was that
you got back.
In our case, we want to make sure that we
make this as private as possible, so it's
not trivial for anybody to figure out
what you did.
And as a result, we get an alternative
public infrastructure.
And I say it this way because we can use
this to replace the web of trust.
We can use this to replace six five four
nine six. We can use this to replace the
NSIC doesn't mean
any of these are the best things to
replace.
We first want to focus on peer-to-peer
network social applications,
identity management in this kind of
scenarios because we don't have to worry
about interoperability so much.
But in principle, for all of these
things, we have a new public
infrastructure and we can
be interoperable with Dennis by making
all record types will
be the same as the network of types.
And then we have some more.
OK, let me first start with what does
this really look like from the user's
perspective?
And this is not the user quite that,
you know, we might want in the end for
usability purpose, but suppose your
current your DNS administrator
administering a zone.
What does it mean for you to switch to
DNS?
Well, we have a zone editor
which is geographically.
All of the screenshots are real.
By the way, if somebody questions that
before finally real,
you have your normal labels, the record
types, the values you want to map to and
some expiration time.
So you pretty much get the same
experience as you would get from DNS in
terms of managing a zone,
but nothing really changes there.
So suppose we have Bob here, he says.
Web server and he puts into his local
zone. WW Do is reachable
at the IP address. Five six seven eight.
Good.
Next thing he's going to do, it's going
to make himself a little business card
like the ones that Holland Foundation is
willing to print for you guys at this
event and on this business card,
he's going to put his public key.
OK.
And was that he can introduce himself to
his friends. So he
goes to Alice.
Alice learns Bob's public key
and puts into her own under
the table Bob Bob's public key, and he
has a new record Typekit we have for the
public key of another entity.
Once he's done that, she can reach Bob's
web server under WW Dot Bob Dot.
Going to notice Dot
stands for me because that's
myself, my zone, the one that I control,
that I have all freedoms over.
All right, the freedom to give it to
others. The freedom to change any name I
want.
Yeah.
Now, how does this work?
No, we have the following set up Bob has
his own database, Alice has hers on the
service was an entry for Bob and we have
from the middle of the peer-to-peer
network with a distributed hash table.
So this is a test table for those who
don't know. Just think hash table.
All right.
OK, so first thing, Bob, what Bob does is
he periodically stores the records from
his database in the DHT.
Just store them periodically
because, well, records in the distributor
hash table tend to sometimes go away.
Now, when Ellis says, OK, who is Bob Dole
going to first thing herself with us?
It's OK, new means it's my own zone.
Who is? Bob asked.
Put it up. Who's Bob?
Davis comes back and says Bob's public
key is whatever some public key.
And she says, OK,
the ADHD, who is
in that zone and ADHD comes back and
says, OK, here's your record.
Now that was easy, right?
And if we have that and we have the
security, we can put creative records
in there, for example here.
I have an actual screenshot of Firefox,
where I put into my own freedom, Daugunu
putting Kanu's IP address.
And can you tell us record and my
browser? And I said, Oh, I validated this
against the new name System Certificate
Authority because, well, that's what
the proxy says the CIA was when
it created the respective validation
certificates on the fly.
Great.
Now where's the security problem here?
Well, we have this little thing in the
middle, right? The Magic Box,
right? So what we have here is what,
but it looks like it's ADHD can see
what's being put in when I get out and
well, they could do whatever they want to
their contents, right?
So here's what we need crypto.
OK, here comes the crypto.
So we use elliptic curves.
That's wonderful curve, because
it's short in terms of public key size.
So in elliptic curve cryptography,
I'm just giving a brief refresher here.
You have a generator.
The point on the curve, the size
of the Elliptic Curve Group, and it's
a prime number.
So these are publicly known values that
everybody knows.
They were set in stone once per curve
forever.
Then I have a private key, which I'm
going to refer to as small x.
So that's the secret for my zone that I
have to protect, obviously, and
I have a public key.
That's the point on the curve, which is
calculated by, well, during
X times.
Remember, X is a number, so x times she
just means adding the pointy x times to
itself. That gives me another point p
if I know what Curve Point Edition is,
and all we need to know is elliptic
curve. Cryptography says given p
i cannot get back to x
height, I can't really prove
that fundamentally, we just don't know
anybody who knows how to do that.
And it's like factoring
large, uh, products.
OK, now well, we also have this.
We have a label for the record, the zone.
So that's the W W, for example, height
or the name Bob.
All right. So that's again, we're going
to map that label to a number more and
then we have a set of records for the
label L end zone P.
So that's the plaintext records like the
IP address for the web server is one two
three four five and
then we have the query hash, which is
what we want to use to store the
information under in the D.
So I didn't quite say how I get this, but
we have to have some hash code for the
hash table and in the hash
table. We're not going to store the
records in plaintext.
We're going to store them in encrypted
forms. I'm going to call that the BPL,
the block for Zone P
and the label L with all of the records
under that label.
OK, let's just basic
terms.
So given this, how do I publish?
First thing I do is I calculate
the hash of the label and the public
key, some hash function
and I get a small h and
then it's just a number again, contagion
hash just a number when I multiply hash
with the second X to get a derived
secrets, d so d is now
another private key in this on
the same curve, but just a number.
That's why it's all so modern.
Now using that d, I can
sign using AC DC.
What I'm going to sign is I'm going to
encrypt. The Reichardt's was a key
derived again from the label and the
public key.
So it's a hash key derivation function
here, and I'm going to add D times
g at the end. That's the public key
corresponding to D
so that people can verify that signature
using that information.
I'm going to store all of this under the
hash of D times G.
That's my query.
What does this mean for an attacker?
Well, given
the information stored on the hash table
D Times G, I can't get back to X, I can't
get back to H.
That's the standard assumption that we
have given
that the records were encrypted with the
label and the public key of the zone.
Unless I know exactly what label and what
public key it was, I can't decrypt
now if I know what the label and the
public key was. Well, then I could ask
the same question. Then I have to be able
to decrypt if it's a public record, so we
can't fix that, right?
But unless I can guess exactly the label
and the public key, I will learn nothing.
I will not be able to decrypt the
records, but I can
still verify that the signature is
correct.
I can say, Oh yeah, that signature is the
same as the private key.
Demetris was this public key.
So intermediaries in the DHT can verify
that the records are correct.
They will not even cash invalid records,
but they cannot decrypt what the contents
were. They cannot tell which don't they
belong to. None of that.
But when I look for a label
for the release, what I do is again, I
can regulate small h of LNP
hashing those.
Now I can calculate
h times
p load, which is the same
as H Times X Times three, which is the
same as H Times D Times G,
which gives me the query.
And then I can use this to obtain the
encrypted block from the DHT and I can
decrypt again because I can do the HKT
myself also.
So here I've got very privacy.
And, of course, integrity checking
authenticity at the same time.
OK. One issue that we
sometimes face is that people lose their
keys.
We might want to revoke them and say, OK,
don't use this anymore.
The basic idea of revocation is, of
course, likely the revocation
certificate, which I'm saying this
private keys is no longer valid, so I'm
using my private keys, sign a message and
say, forget about this private key.
Now, whenever a peer receives
a valid vocations certificates, what we
do is be flooded to all of the neighbors
because a piece of your phone is really
hard to stop.
Right? Even if we got a couple of
compromised guys will, they'll just flood
around them. All right.
Just islands in the ocean.
All of the peers that receive
reparations for to get us going to store
it forever. And whenever they encounter a
certificate or private key, they're going
to check against the list has it's been
revoked.
Now this is, of course, an expensive
operation flooding the network.
We must not be able to do this every five
milliseconds that will take down the
network and storing it forever.
Well, we don't want people to be able to
store stuff even on machines.
So here we're going to use inexpensive
proof of work using the script hash
function, effectively forcing you to do a
calculation on your computer for a couple
of days before you can cause this flood
that will have to be stored forever.
But once you've done that, it's pretty
much impossible to stop the revocation.
And then there's also no latency for
checking, has this private key be
revoked?
That's a bit more revocation magic needed
here.
And specifically, there might be peers
that are offline during the initial
flood. So they might have missed that
this thing was revoked.
Or I might have a network that was
partitioned and might have had, you know,
Egypt being cut off from the internet for
a couple of months and all these guys
come back online. They've missed a lot of
replication that might have been
important to them.
If they really were cut off, I couldn't
have gotten to them during the time.
But now that we're reconnecting, I need
to kind of get the set back together.
So we need to reconcile the revocation
sets whenever peers
connect to each other,
so need to compute the set.
Union also certification set.
And that sounds expensive, right?
Not quite fly.
All right, so let's just make
yes. So let's do efficient set
union. So just from this idea is
not ours, but based on
an idea by Epstein and others.
And this was first prison in 2011.
So this is kind of prison work, and
we were the first one to provide
public and free software implementation.
So the basic setting here is that we
have our two players, Bob and Alice,
and they have two sets and B
and those sets are very
large. They contain all the
revocations of the system,
but they're symmetric.
Difference is really low and
we want to explore exactly of that to
reconcile them efficiently.
So what are you going to do? Ellis wants
to know the a b minus.
That's the stuff she doesn't know, and
Bob wants to know A-minus B.
Those are exactly the only keys missing.
So let's talk about how
we can do this efficiently.
The first approach, which is a really bad
solution, would be just to have
Alice send her set to Bob.
Then Bob can come shoot what
Lawrence Ellis needs and
sends back.
And then you do accept the reverse
thing. But that's really bad to
has a real bad communication course
because it grows with the size of the
whole revocations set.
What we want to do is we want to have an
algorithm that can do the reconciliation
and time proportional to
the symmetric set's difference.
So only the elements
that we missed, for example, because we
had a down time who
are actually counting into the runtime
time for other rhythm.
So one frozen problem
that doesn't really work, we can just
slot some whole elements, but
the hashes of elements that that
doesn't improve the runtime that just
makes each element smaller.
So let's look at some
more fancy protocol.
So a very important basic
building block for that that most of you
probably know from not working,
as are blue filters.
So Bloomfield Terrace is basically
a data structure that has a fixed size
that is some kind of summary
for a set.
So the basic operations for that, you
can create one and then you specify
a size for it.
And the size of the blue filter
and the memory necessary represented
will never change.
You can insert elements into the bloom
filter and then you can
check whether an element
was previously inserted in blue filter.
And this operation is
not this
just probabilistic.
So you get an answer that
either size says the element
is definitely not in the set
or you'll get an answer.
The other one probably is of a set.
So let's look at how this works.
So basically, blue filter is
just an array of buckets
and those binary buckets, so they start
either zero or one and let some sort
of an element element in this.
This element one here gets sent
to a hash function, and this hash
function just gives us a number
of buckets.
So there's indices for this buckets.
So, for example, a one
to three and seven.
So let's insert our element into this.
It's obvious we just started to.
One was insert another
element.
This hashes to different world use
and we just
said those two one.
Now that we have inserted those
two elements, we can
check membership by just also
hashing the element and checking
if all the buckets that this element
hashes into are sets
to one.
So if one
of the buckets is zero,
the elements could not have been inserted
into the set.
But now here's a more problematic case
with an element that's definitely
not in the set as this element for,
but incidentally, it hashes.
Uh, two buckets were previously
some other element hashed into,
and then we'll get a false
positive.
So bloom filters are
not enough to do a set reconciliation.
We need to do some extensions on them.
The first extensions are counting bloom
filters, so it's the same as
another one filter.
But the bucket does not store
binary. Well, yes, but it stores the
count.
And by this, you
can also remove elements
from the set because
if you only have a binary count and
then removing the element, you
don't know if there was a previous
element in exactly that bucket that had
been inserted.
So you need to have a real challenge
as a binary.
The problem with.
But it's really important that you can
have false negatives if you remove an
element from a boom filter that was
not previously insurgents.
But that's also not sufficient for
reconciliation.
For that, we need in virtual bloom
filters.
So here we also allow negative counts,
and we do not only have the current
field, but we also store
an X or some of
element hashes in the buckets.
We'll see an example soon.
And they're called in virtual bloom
filters because for them, you
can often extract operation that
gives you the hash of an element
that you previously inserted, which is
really nice.
And this does not always work because
it's filter.
It's a data structure with a fixed size,
and we can insert as many
elements as we want into it.
So the extractor operation will
return a result code that
says either yes, we
could extract the element and it had
a negative count.
We can extract the element and head out a
positive count.
We're done. So there's no more elements
in the original one filter or it just
failed than we are out of luck.
The next version, you can also do fine on
those filters, so
there's no reason for the symmetric
difference.
So you put two in virtual
one filters into it and you get another
one that represents exactly
bloom filter, where the symmetric
difference of the two sets is
stored in.
But you tag
from which sides the element
comes from with either positive
or a negative count.
So let's look in, except for this one
filters
just this produce from
the usual bloom filter, and here
we have our additional bucket with the
hashes.
So in our hash function does not only
give us the list of buckets, but
also a hash
value that we can insert
to assess the lesson so that this element
just the extra with zero results
in the number itself.
And if we have the count listeners, there
is another element.
So here the
differences are you actually count
to two.
And here you just compute the XOR.
So now that we have inserted all those
elements, we want to extract them.
And for that, we use
so-called pure buckets for pure workers
is a bucket with only one element
inserted.
And there's only one element
in this field here stirs the
hash, which is exactly what we want, so
we can extract the hash and reverse
the operation for all of the other
buckets. So this
bucket here that currently has a kind of
two, we'll get a count of one
and then we can use the extract operation
again to get the next element.
But this, of course, will only work if we
initially have a pure bucket.
So the more elements we have in our
Bloomfield are, the less
the chance that we can actually
extract elements.
So and then really full
IBF, we will not be able to extract
little filters.
So let's define
the symmetric difference operations.
And this is really easy to compute.
We just subtract the counts,
obviously, and then we
extract the hashes.
So let's see how we can use this for
the set reconciliation protocol.
So our two players could all their
elements in an IBF and
then exchange it and compute
the symmetric difference.
And now they can start extracting
elements because there's
only the symmetric difference in
the bloom filter and we set
the symmetric difference is really
small.
It will be very likely that
there are some pure buckets and
the resulting difference IBF and we can
start to extract.
And if that fails, we
have just to repeat
that the larger IBF.
So one thing that's missing
here is that we have no idea
how large the IBF should initially
be. So for that, there
is an additional additional step.
Previous Firstly, where we
do differences to measure.
So we could estimate the size
of the somatic reference for the sets.
It turns out we can
reuse IBF for that.
They're really suitable here
because you can
estimate the difference
actually for especially
when it is very small.
So other approaches to that
work much better when the difference is
really large. But that's not our case.
Here are
the basic ideas for the difference.
Estimation is that you sample
your sets by looking at
the hash.
So, for example, the number of leading
zeros and then.
You put it in this structure here, those
are all in reversible filters.
And here many
elements are sampled and the
more we get to the outside, less elements
are sampled.
So now that we have created
this data structure, of course,
both peers have to
create this data structure and then
subtract the variable
and filters element element
and then we can try to decode
them. So the first one will
probably work. And let's say we have
three elements out of that's three times
the extraction succeeded
and we're done with it.
Next one succeeds two
and we get more elements because we have
sampled more elements into
this structure.
And let's say the next one fails.
So we have no idea how elements, how many
elements are in this
one. But now we can do an estimation
because we have a relation
to how many of
how many items we have sampled into
this bloom filter to this pool filter.
So for example, we can say
in one hour delay of there will
be just half of the elements.
So let's look at this.
Uh, here we
have counted three, four, seven, so
10 elements.
And then there are those blue filters
that did not decode because they
had a large number of elements.
But we can just estimate
that because this one will
contain them twice
as much as those combined.
And this again will contain twice as much
combined. So if you multiply it by
four, we have an estimate for the
set of friends.
And then we can use our IBF.
Thank you.
So as you can see in a tiny problem like
revocation, there's always a bigger
problem. Now the nice thing is if you use
the internet framework providing you own
applications, you have this efficient set
on conservation. That's a nice API and
you don't have to care about the details
in case you want it.
You're welcome.
Now back to the new name system now that
we know how to do is replication.
There's also, as I mentioned, global
cryptographic identifiers.
That's what we call the Zwicky TLT.
So when you have the memorable ones, you
add new at the end, if you have a
public key and you have typed it in
painful, I know, then you put dots
at the end you have a global name.
Now this is your entry point, right?
You entries before that global name, you
can again put arbitrary labels that
follow the normal delegation
and are readable.
So this kind of works a bit like the
onion.
Now then we also have the problem that if
you have these delegation teams, they
might get a bit long at times.
So might be Elliston the bottom, but that
they've taken to it's not well defined,
but not quite usable.
Not to mention, every time you type this
in, we have to kind of trust the zone of
day. If there's one off carol of Bob to
get to Ellis, so well,
we can do better
if I'm on my problem.
Ellis, what we have here would we like to
be called Krista?
I just Bob Colter Ellis, but you know,
that's a slander attack, right?
So what we do is we add a new record
type we call Nick Records.
Let's say Chris specifies that her
preferred nickname is Krista.
We add this to every record said
automatically once it's configured.
And so when Eve first uses that name
for the first time, she notes that
nickname and she puts into her database
and entry, saying crystal shorter can to
the short version of this long thing.
It's not quite so short.
She learned this automatically now, in
the future, she just has this much
shorter name for it that she got
automatically.
Now, Krista has an important incentive
here. She needs to pick a unique
pseudonym for too many crystals
out there. This will not work because
they can only be one crystal or shorter
group.
It doesn't have to be global unique just
within her social context.
It has to be unique.
All right.
So in short, we get a memorable
short trespass for future use
and can consider as a form of tofu trust
on first use.
All right. Once I've looked it up, I know
I have a short handle for it.
OK, one other problem
is we use this to you now in the DRC,
you have latency. I might put a record in
and it takes some time for the record to
be propagated, replicating the be
available, be fetched by users from the
DHT.
And sometimes when I have a
DNS like system, I want to change.
The mapping might be my server.
It's going to be moved from the US to
Europe on the 1st of January,
and I really would not like to have the
old records be valid at that point,
and I need to use this to get to the new
records. But I don't want to be down for
three days while things propagate in the
DHT.
Maybe three days is a bit long for the
team. But ideally we have no downtime.
So how do we do this?
Well, you can put into your normal
record set. Shadow records a shadow
record as effectively saying this record
is not valid as long as any other record
under the same label was the same type is
valid.
So you say they set the expiration date
for the old one to the 31st of
December? All right.
Put in a shadow record that has a
validity of twenty fourteen and
then the shadow records will not be
considered as valid until the time
when the other record expires.
So it's a little trick to make this
caching work nicely without having
this problem that we need to at this
very particular time, get an update
to everybody in the network.
So it's just a flag in the network.
OK, now practical concerns.
Well, I wanted to address a couple of
them. So first name registration support
for browsing new record types,
integration of applications set of the
implementation for five minutes.
OK.
So registering a name in Genesis, OK, we
saw the first version, you know, I give
you my card and you have it.
Second possibility is we can, of course,
still have a register.
We are running the unit, FCF is
registering with it or you can go there
first, come first serve.
If you trust our registrar, it promises
it will never remove your keys and you
can use it and we actually ship.
That was the distribution as a public key
underpin, not canoe.
So if you see somebody food or pinned,
you can do it while you're using our
registrar, but you have very good trust
agility here.
You can choose to put another register
you can on your own.
Either way, it doesn't matter.
And many paths can lead to the same
user of the same zone.
All right. So if one register is bad,
we'll just use another one.
Not quite so easy with dot com these
days.
Yeah. So after this import,
we can resolve. But now from
DNS to DNS, well and DNS
names are not global unique, but we
have these issues. We do web browsing
like virtual hosting and SSL,
where existing protocol.
Let's assume that the HDP host header
contains the hostname,
and the web server really wants it to be
the right one.
And the SSL certificates it says, you
know, got off the mark
and it doesn't say growth of that group,
and hence browsers will hate it.
So one solution for this be deployed is
the client side Sox proxy, effectively
proxy that will fix everything up for the
browser and makes us happy.
Right? So you can put into DNS
a legacy hostname, which effectively
says, Well, yeah, you know this good of
the glue guy and the legacy system.
It's called good off the mark.
So when you go and validate against the
system, if you have to, well,
if the certificate says go of that, OK,
that's OK.
All right. And if you have to talk to a
legacy web server on that machine, just
put in a whole set of says I'm going to
go to talk as opposed to going after
going to ISO,
the web server goes and says, I want a
WWE body talking to the proxy translator
to, Oh yeah, I'm going to go to college
degree, but I'm going to put in Bob's
website dot com, right?
And yeah.
Second possibility again, as this
certificate, the local proxy effectively
is a certificate authority.
We have scripts to automatically import
the certificate of this certificate
authority that runs on your own machine
into your own browser.
So you're trusting just on loop back here
what you're doing yourself a mat in the
middle, right?
That's safe.
If your own machine is safe.
So again, the web request goes to Bob
Duncan, who actually goes up to Bob's
website dot com.
We validate the answer.
Again, we can vote against x 5.9 PCI,
or we could vote against the tell us.
A record depends on whatever is in the
DNS system, and we tell the
browser, Yeah, this is a valid
certificate for Bob. They're going to
tell you will trust us because we are his
trusted CAA.
OK, now proxies
are a mess.
Let me just say this is the proxy does
not work as well as I would like it to.
So in the long term, it would of course,
be nicer to just integrate this
understanding into the browser.
And if
we have virtual hosting, we could, of
course, just put another headline saying,
OK, please don't go for the legacy
hostname. Here's the DNS zone.
I want this public key swept web server
instead of a hostname record.
And again, if we move to Telus Records as
opposed to using X17 existing
picker, we are again better off
there.
OK.
Relative names. So we have this notion
that in some DNS record types, I can
put in names of other,
uh, uh,
other names. For example, in the NSA
record, I can put mail dot
dot org right or in C.
name records. I put whatever the real
canonical name of the machine is
something that's called something else.
Now here, if you put it in an absolute
name, I can delegates to DNS.
I can put into the Zwicky or I can
put it in the relative name. So if you
put Dot Plus at the end, says the name
I'm giving you in this record is relative
to what you've resulted from.
So we just use relative host names with
Dot Plus, which
again would be nice if browsers supported
those kind of links.
New record types we saw already, we
have public records, we've got neck
records and legacy hostname records.
We've added records genes to DNA
so we can say, OK, this sub domain,
I'll go back to DNS and resolve using
DNS.
We have VPN records, but we can say, OK,
this machine is actually hosted within
the peer-to-peer overlay.
Establish a peer-to-peer tunnel to the
target, relay the IP traffic over it.
And when a normal legacy application
comes and says I want an IP address,
we'll give it one of the virtual
interface and synthesize it.
We have phone records for conversation
and yeah,
that was a very short version of that.
But part of it wasn't all about
conversation.
Florian might present some more, and new
crypto at the assembly and
course represent our approach to
unlocking. So please come to our assembly
in the next couple of days and have more
fun with secure networking.
There are also, of course, concerns with
how to integrate. This is my application,
so we haven't set a socks proxy.
You can plug it into NSA Lipsy name
services switch as a plugin.
We can intercept DNS packets using DNS
servers, effectively revise your firewall
rules to give all DNS traffic to us,
and then we can mess with it if needed.
We have a API to access the whole thing
we have in the process. Communication
protocol if you hate, see, and there's a
command line tool, or
of course, you can write your little C
code and call our command module
many ways to integrate it.
Now Julius is part of Knutsen zero point
nine three, but we changed all of the
crypto and 0.10,
which is out like four days ago.
Now,
international domain names are supported.
In case you're wondering, the
installation of I should warn you is
non-trivial.
I wrote instructions for Start with
Debian stable and start with pinning and
mixing. Your system was unstable and
stable and then download a couple of
source codes.
Yeah, for not all of our
record types, we have a nice voice, but
for most of them,
we're trying to have a genius key
exchange party where you print your
QR codes and give them to your buddy that
they have been introduced.
Of course, you can then put into your DNS
owns your, you know, BGP keys if you
want. That's great.
So go ahead and start going today.
Create your private keys.
You can use BCD, the business
card daemon, to launch a web server where
you can type in your details and get the
PDF with your business card.
Need to install it, though, and you can
give the PDFs to Ireland for printing.
Thank you.
We are really quick.
Speak up and speed up
at no problem is the question.
I've seen this.
If you have any questions, you can ask
them now. And no, there's at least one
question on the internet, and I think
we start with this question.
User Pepper, 64, wants
to know about collision detection on
key look up, especially the short keys.
Traditional attacks on key look up,
the collision detection on key look up,
collision detection on key look up.
Yeah, what kind of collision we have for
the public is we don't even use hashes of
public keys here, so I'm not sure what
kind of collisions he's thinking about.
I think in the DHT, you saw
something.
OK, the DHT use five and 12 bit hashes.
We assume that there aren't collisions
there, the likelihood of there being a
512 bit collision that
was a decent hash function.
It's more likely you get hit by
lightning.
Way more likely.
OK, then microphone to
you.
A bit of a technical question, but I
don't quite understand how the how your
set different thing or set resolution
thing is that efficient because you rely
on the set up of all these boom filters.
And the way I understand it, like setting
up a bloom filter is over in.
Yeah, but you do this once you don't have
to do it for every interaction and never
choice, so each time.
With the revocation
comes to.
OK, I was so it's amateurish.
You can do it once ahead of time.
And most importantly, this is really only
local CPU consumption on the network.
You don't have to do this.
So what I'm as a networking person
concerned about is how much network
traffic do I have?
The fact that I might have a database
with a million entries have to do an
iteration of a once a
so circular.
I'm curious to see us having a million
revocation keys first.
Right? So the circular slide that
had like the multiple apps inside
each other. This is something that
continues to exist on your system, and
it's not something you compute when you
meet another peer to peer to peer server.
The strata estimate is
actually totally static.
So for the IWBF,
you may have to re
compute the larger one if some
of the reconciliations fail.
But this
data structures toys are static
for your whole set.
OK, that's another question.
Yeah, I had a question about,
for example, dynamic DNS what
we have today. And if you're
half changing IP addresses,
how fast can you propagate these in the
network if you don't know your
new IP address?
And yeah, yeah, OK.
So the question let me repeat it was
suppose to have didn't DNS and my telecom
changes my IP address every twenty four
hours and I can't predict.
So the shadow records won't help me at
all because I don't know what I'm having
as an IP address tomorrow.
Well, that's again a question of how good
is the DHT?
And yes,
you might have a downtime of a couple of
minutes or an hour, depending on how
aggressive you put stuff into the DHT.
But really, ultimately, I wouldn't even
want to use IP addresses
in. I want to hold stuff in the peer to
peer network. I want to, you know, have
social applications where I address my
friends and I may not have this
problem as IP is changing so much.
But yes, the DHT is then again, the
question of how fast to Google things.
So that's a performance issue, but
it's not a security issue.
OK. Another question that's microphone to
your well, what is
the use case?
I mean, I can see a lot of use case
for geeks and
some, but
in commercial applications
and a large scale.
Um, do you think there is a concept
how one can use that there?
Well, my first use case that I'm trying
to get implemented working nicely is
not conversation with it.
Ideas I want to call you.
I'm going to court, you know, you are
going to as a call, you can do,
and that's your address.
I don't need a, you know, company that I
trust was managing aims.
I don't need to exempt a trust
based federation.
I can just say, OK, I want to call you.
You gave me your business card.
Now you say, Hey, you should call my
buddy and I just his buddy that you took
two and a half your buddy securely.
Right? So for those kind of social
networking applications, these these are
my friends. These are my social
rooms that we meet or we exchange
information bulletin boards where
these kind of identity matching
applications that are fundamentally
decentralized. But right now, we can't
even get people to use DNS because they
don't want to pay the registration fees
and they can't administer DNS
printing out these business cards.
When you are able to install the software
and giving that to your friend and then
the friend saying, Oh, you know, I have
you as friends are going to vote and
now I can call you now I can access your
social profile. Now I can do all of these
things was that I think that is something
that we can get into the mainstream.
OK, thank you.
Yes, another question that's microphone
one, is it?
Yeah. So the way I understand
it, you provide authenticity
and integrity.
And so that means if I get a message, I
know it is from that person and so on.
And but what about robustness?
I mean, what if somebody actually tries
to screw up your system, maybe by
flooding it with wrong messages or
like, you know, like the NSA,
let's say it has a botnet and tries to
flood everything with wrong messages and
maybe tries to corrupt also
hash tables on your side and chooses and
chooses the message as well.
How would you say and basically use
your system?
OK. So the question is what if somebody
attacks the DHT effectively?
Well, firstly off the fence, we obviously
can't give us invalid requests that have
to be signed.
But yes, if you have lots of bandwidth
in, you know, you can just $d us.
And yeah, well, most systems don't
survive Adidas unless they are big
enough, right?
I can't fix that.
Overall, we of course, tried to avoid the
issue itself as efficient.
So you have a hard time making very
expensive operations happen.
We try to route around peers that are
misbehaving in the DHT.
But it's a question of how do we see of
the. I didn't talk about the DHT here
because I didn't have five hours.
So I'm sorry. But you can read
Nathan Evans, Ph.D., thesis or
our paper on our five end, which is to
ADHD, which has some more details
and measurements and experiments on our
current ADHD non-autistic new name
system. Yes, it needs ADHD.
The theory works with any DHT.
So if you have a better one?
Let us know.
OK. OK, we have another question on the
internet.
The question is if revocation
lists grow too big.
Is there a plan for a of
lists?
OK, so the question was the revocation
list go to a big they're plan for
versioning of lists.
There was a plan where I would sort of
in the far future, implementing a slight
exception for who would say if I've
talked to this peer recently and be
reconciled our revocation lists and
we know we had, you know, a thousand
entries in that revocation list.
I can just skip going over those thousand
at that point.
So if if I have interactive with stop
here recently before, I only have to go
over all of the entries that are newer
than that, but I don't quite see that
being necessary for quite some time.
Honestly, I have not
really gotten the data, but I don't think
even for X 5.9 Picard, they are all that
many revocations to worry about this.
Maybe there should be. But
in practice, I personally think
revocation is only going to be done by a
high profile users that really got badly
hit. And most users are probably going
to forget to create their replication
certificate and be not even noticed that
they got compromised or c not care.
So this is not really a feature for if
you, you know Jacob Appelbaum and you
really need to rip off your key,
then you have a mechanism and then you'll
be hard to stop it.
OK, another question over here.
I mean, I don't really understand why you
would need to keep the revocation
certificates forever.
Couldn't you just limit the lifetime of
everything that's put into the DHT?
OK, the question was, can you limit the
lifetime of everything in the in the.
Yes. But whenever I get something from
the DHT, what we didn't talk about here
was we have a local cache and the local
cache just looks at how long was this
record valid?
And I can, of course, say, you know, my
delegation to you is valid forever,
right?
And I can't take that back even right.
So the problem is, and somebody might
have taken that into his cache, which is
great. He doesn't need to go back to the
DHT. He doesn't need to have the
availability. All of that doesn't matter.
He has it all in his local cache, but
now it's in the local cache.
Even if the issue doesn't happen anymore,
it might still be used and we have to
prevent that.
So it's really for the case where
somebody picked an excessively long
expiration time for PKI
delegation.
But couldn't you just require that it
needs to be refreshed
after, say, six months or something
that if I require that something needs to
be refreshed, that again opens a
possibility for censorship?
I could say, OK, you know, I'm going to
force people to delete something.
I just want to remove something.
I want to make sure that, you know, if I
met this guy and nothing compromise
the security, no, it's going to stay
valid forever. But I don't need to have
another look up, don't need to expose to
the rest of the world, even that I'm
doing a lock up, even if they can't tell
what I'm doing.
OK?
OK. And back there another
question.
It seems to me that it's quite
complicated to fit this into
the current stack with the browser and
everything.
My question would be is that how
good?
How much better can you improve the this
technique that you just described?
OK, the question was how can how much
better can I improve the technique I
described?
I don't know. We don't know a better way.
Otherwise, we would have done it.
OK.
Let me rephrase it.
Do you think it would be
possible to get the cooperation
of browser vendors and stuff like that?
I think there is a certain browser vendor
which is called the Tor Browser Bundle,
and we've been talking with these people
a bit that might be rather interested
in adding support for this.
I do not think it's likely that we're
going to make it into IMS Explorer
anytime soon.
Thanks.
OK. I don't see any other questions.
We have five minutes left, but
you can decide if you want to sell
something.
No thank you.
Go spend those five minutes installing.
OK, then thank you.
Good luck.
Very nice to you.