Next presenter. Who is Theo? Yes. So, talking about cryptpads. Yes, the floor is yours.
Thank you. Yeah, whom do you trust? I think this question is really a serious question,
especially for privacy and collaboration in today's Internet. Well, yeah, let's directly start
with this question or with what collaboration is. Collaborative editing is that multiple people
work on the same document at the same time and they want that their changes are transmitted
in near real time. So here in this example you see that one person writes there, the update is
propagated to the server and the server further forwards the message to all other users. Here
you see that in this generic example that the server can see all messages. The server has a local
copy of the document and updates as soon as it gets a message from a user. And already here we
should say we're like, hmm, okay, so whom do we need to trust? We obviously need to trust the
server in this example because the server can see the documents. So this leads me to the second
part, to the privacy that we want. And here I give you some informal definition and we say that no
untrusted entity can infer personal information, document content, or who the collaborators are.
So for an untrusted party, the document should look like this, just like snippets. And this
untrusted party should not infer any information. Here the key point is that it's an untrusted entity.
Because this does not hold for everyone. For example, the collaborators, they should be able to read the
document. So the question is whom we trust? And I'll start with the solution that's probably the most
used today. And yeah, why not trust Google and Co. And there may be many reasons. I just want to give
you one example. And it's the case of Desha Rawi. Here, Naomi Klein, a famous environmental
activist writes that India targets climate activists with the help of Big Tech. Tech shines like
Google and Facebook appear to be abating and abetting a vicious government campaign against
Indian climate activists. So what happened here, there was, cannot go too far to the side, was
climate activist Desha Rawi who founded the Indian, was co-founder of the Indian chapter of
Fridays for Future. And they worked on my Google Docs where they discussed how to help Indian
farmer protests. And there was stuff like use this tweet or you can write a letter to your
government. This document was leaked publicly on Twitter, I think. And then the Indian government
thought of this is a conspiracy theory and wanted to track down who actually wrote this document.
So they asked Google and Google helped them and said it's this and this and this person. And then
Desha Rawi was arrested for a few days. She was later on, she was against freedom and there was
no sentence against her in the end. But nevertheless this shows that we cannot really trust
Google to host sensitive documents. So what can we do against? Or what is an alternative
solution? And I think one of the most obvious answers, especially at a conference like here, is to
say that we need to control the software. We need to have the server and the client's open source.
Because if this is the case, then we can host the software on our own instance, on our own server. And
we can decide whom we want to give the data. And yeah. So this would be a first approach. So we
could say, yeah, it's freedom of software, we are safe. And this is exactly a quotation here from
Jitsi Mead. And they say that the possibility to run your own instance completely removes the need to
trust a third party provider and therefore eliminates the need for end-to-end encryption. So they say
exactly this, you can run it your own. You don't need any other pre-consciousness. No, this is fine
because it's open source. Jitsi Mead is a video conferencing platform you may be familiar with. So this
is a bit different. I will come to it later. And also interestingly, also interesting is that they
remove the statement from their website only a bit after I started to prepare my talk. So this is
from December 2022. But are we really safe? And to answer these questions or some more questions, can
really everybody run their own instance? I mean, yes, probably most of you have the technical
capabilities. But do other people have this capability? Do they have the infrastructure? Do they
have the money to run this? No, probably not. And the second question is, do you really want to
trust a system administrator to see all your documents? So imagine you're in a company and you
are working in a collaborative system and you have the salary sheets online. Do you want the system
administrator to read that? No, probably not. Even if you trust it in the first place.
And then, and this is where the difference is to video conferencing, is that documents are not
ephemeral. So a video stream you can safely delete after the conference has ended. But a document
must be stored in the server because you want to access it later. And this means you do not only
need to protect your documents currently, but also in the long term. So that if the server is
under attack or an attacker gets access to it, they should not have access to the documents.
Okay, so if you see this, then you probably think we need end-to-end encryption. And end-to-end
encryption is in principle that you have one party, let's say Alice, and Alice encrypts a
document, they send it to Bob and Bob decrypts it. And in the middle, the data is not readable.
So this is the encrypted ciphertext. And you see here, it's exactly the snippets we want. So this
technically looks good, and we could say, okay, we apply this, and we can say it's end-to-end encrypted,
we are safe. And here's a statement of Google, and they say that with Google Workspace, client-side
encryption, content encryption is handled in the client's browser before any data is transmitted.
So here first note that client-side encryption is not the same as end-to-end encryption. It's
different, especially in the question who holds the key. And client-side encryption, it's not you
as a user who holds the key, but the keys are stored on a third-party server. So there comes
again this question of trust, if you trust this third-party server. Okay, so we could say it's
end-to-end encrypted, we are safe. Well, really. First, there are the metadata. And metadata is
all about who connects to the server, at which time, from which IP address, who collaborates, which
people are accessing the document at the same time. And all these metadata, they are still there,
even if the content is encrypted. So, yeah, still a problem. And second, we have Kirchhoff's
principle from cryptography, which says that a cryptosystem should be secure, even if everything
about the system accepts the key is public knowledge. So you should be able to release all the
code, and all information accepts the key, and it should still be secure. And for me, it's really
urgent for open source. And, yeah, that's why I think it's urgent for open source. So we see that
we need both of them. And here, I want to present you CripPad. CripPad is an online collaborative
editing tool. There are multiple parts of it. There is a whiteboard. There is code marked
on. There are slides, like these ones, and documents. It's open source software from the
client code is open source, as well as the server code. So you can host your own instance.
And there are about 200 maintained instances. We at the CripPad team, we host a flagship
instance, which has about 200,000 registered users. And how does CripPad encrypt? So in
CripPad, we have this end-to-end encryption. We have that an update is propagated in encryption
form, encrypted form, and the server only has an encrypted state of the document. So the
server cannot infer the actual content of the document. And how do we share the keys? In the
most basic way, we share the keys over the fragment identifier of the URLs. That means we put the
keys after the hashtag of the URL. Like this, you can easily share a document. What do we
trust? As I saw, as I said, you still have the metadata. So you still need some trust. In
CripPad, you have to trust that the server is not an active attacker. That means that you
expect that you trust that the server acts according to the protocol. It runs the correct
code, and it does not deliver any malicious things. Or it does not repeat stuff, and so
on. It does not reorder stuff like this. And why do we have this trust requirement? There are
two reasons. The first one is a practical. We have a web application where you get the
client source code from the server. So if the server would deliver bogus client code,
well, then every security guarantee is lost. And then there is the second one, which is
more theoretical. Namely that the server can always delete files. Even if they are encrypted,
the server can delete them without problem. Okay. So you see that you need some trust. But
the cool thing about CripPad is that there are other stuff which you don't have to trust.
Namely, the server could be an honest but curious attacker. That means that even if the
server watches you, you're still safe. You don't have to trust the server that it does
not watch you. No, it's explicitly allowed. And why do we have that? Well, the server
may become corrupt. Even if you trust it to be not actively malicious, it's still
maybe at some point in time, it may be corrupt. And this was especially the case here in
last summer where there was the CripPad instance hosted by Germany's private party. And on
this instance, some sensitive documents about the G7 summit were leaked. And then the police
asked the pirate party to hand out their data. Otherwise, they would seize the server. So
the police got access to this data. And now the police could not read anything. They
could not read the documents. Namely, because everything was entered into encryption. So
this shows that even if you trust it in the first place, we still cannot be sure that
it's trustworthy forever. And this setting, yeah, and as I said, this setting is exactly
covered in this honest but curious attacker, which we allow. There's also another point
of view to look at this. We could all say that we protect the server from its users. So
for example, the server administrator of the CripPad of Germany's pirate party was not
consulting. How could they know what documents were published on their server because it's
encrypted? So this shows that such encryption is also nice for you in terms of system
administrator because it allows you to offer the service without taking too much risk to
you. So, yeah, as a take home message, I really want to say that we need both. We need
open source and end-to-end encryption for good trust assumption. And with this, I'm at
the end of my presentation. Shout out to my team. It's David is there somewhere. Wolfgang
is here. And Ludo is also there. I am Theo. And CripPad is developed at Xwiki in France
by this small team. We have a stand here in the K building. Yeah, come by. Drop by. We
have stickers. Thank you.
So are there any questions?
Would a peer-to-peer version be possible to reduce risks with the server and would it
help? Yeah, it would be possible, theoretically. The main point why we have a server is that
we want that the documents are accessible all the time. So in a peer-to-peer setting,
you will firstly have the requirement that always one party must be online. And we don't
want that. Yeah.
So another question.
Thank you very much. You say we need open source and E2E for good trust assumptions. I would
suggest you might need a slightly stronger statement. The code on the server has to be
open source as well. So potentially you need something like the Afaro GPL. And in terms
of the E2E, you need post-quantum resistance. Yeah.
If you have those two things, then maybe you have good trust assumptions. Yeah, good point.
TripPad is licensed under the ATPL. So this point is easily answerable. And on the second
point we are working on, we are looking on how to make TripPad secure in a post-quantum
resistance. Thank you very much. You mentioned that it's problematic to have the metadata
still. So what is TripPad doing against that or how can we make sure that the server is
not collecting metadata? Yeah, two answers to this. One is that there's always some
metadata which will be there. For example, the IP address or the browser agent. This one
we have to live with. And this is also the case why it's important that you can host it
on your own instance. And then the second part is that TripPad collects as few information
about you as possible. So for example, we don't have a list of users, of user names.
There's even no list of hashed user names. So we just hash the user. The user name and
the password locally on the client side and generate from this all the keys. So this
is just as an illustration how we try to ensure to have as few metadata as possible.
Good afternoon. And that's the first question you answered that you don't use peer-to-peer
because you want the server to be online all the time. Does the server have to be unique
or can you have multiple servers just in case one gets in the hands of the police or gets
out for some reason? Are you speaking of federation? Yes. Okay. Possibly there, currently there
is no possibility for federation. No, sadly not. Yeah, you mentioned the case where a
server was raided by police. So they have the server. Is it not enough then to have that
server and also have somebody's browser history with the key in the URL and then that conversation
is open? So if I got your answer, if you got your question correctly, it was if an attacker
has access to the server and to the URL, then they have full knowledge. Yeah, that's the
case because the URL leaks the full URL including the part after the hash, which is not sent
to the server. If the attacker has this, yeah, then they have the key to the server and add
the key to the document and can decrypt it. Yeah, connected it. So yes. How does editing
collaborators adding removing work do like re-encrypt the file of different keys every
time or how do you handle that? So we have, we only send updates. So it's not the entire
file every time and it's symmetrically encrypted. And in order, there are two ways you can
access a document in a read-only mode. There you have the keys for decryption and to prove
that you're able to update the document, you need to sign it with a sign-in key. But the
keys are static for a document. But if a user gets removed from read access, they would
still be able to read the file after it's being modified, wouldn't they?
Yes, exactly. Yeah. Yeah, they'll still be able to read it. There is, there are access lists
which we have which can defend against this scenario. But yeah, there's also something
we're working on. And maybe if I can just mention something which with more goes into
these detailed questions. We just published a white paper. You can go to our website on
kruppad.org and check it out. So if there are no other questions.