Okay, so hello everyone.
So I'm, I joined CripLad last year and I'm here to present you
like the product and the future directions.
Yeah, so yeah, so it's called
Securely Collaborate with CripLad and so,
CripLad has already been presented last year,
but I will start again like showing you what it's all
about.
Yes, no?
No?
Okay, thank you.
Okay, so CripLad what it is, it's end to end encrypted like
a collaborative, collaborative office suite.
So you have a lot of different applications inside CripLad.
So it all started as a project, I mean, as a name.
The name is a bit confusing because you may think it's only for pads.
And actually it started like this, so we're only pads.
But then if you think about it, like all files are just like text files.
And that's how we managed to be able to produce a lot of different
applications from that.
So some of them are like homemade, like the Kanban one and
the Form one are really, have been made with our own little hands.
While some other like which text, Whiteboard is for instance raw.io.
Like those three presentations, spreadsheet and document are on the office.
So we either like build a full application or
just try to use other applications and plug it onto the CripLad layer,
which is basically the encrypted encryption part.
And the goal of all of this is to have both collaboration and privacy.
Because when you think about it, when you are collaborating,
you want to share some data.
But then you don't want to share it with everyone.
You want to share it with your collaborators first.
And then maybe once you have a full document, you want to share it to others.
And moreover, you may not want to have like the service provider.
So in our case, it will be CripLad.
But if you are using like some proprietary stuff,
you don't want it to know what you are working on sometimes.
Even if sometimes when you are a company,
you are working with Google for business and then you just give them all your data.
But anyway, here what we are advocating is that, yeah,
we can have both collaboration and also privacy for our end users, which may be you.
Anyway, I should have closed the fender bird.
Take, take, take, take, take, good.
And so one example of that is Disha Ravi,
who is an Indian activist for climate,
which has, I mean, which has been arrested in India near Bangalore
because she was working on the farmer tool kit.
So as you may know, like for instance right now in France, there is like some farmer protests.
But in India, it was more, I mean, there was one as well in 2020, 2021.
And actually, the thing on which Disha Ravi was arrested on
was for helping rating the farmer tool kit,
which is a document helping the farmers to cooperate and get together.
Because India is a very multicultural subcontinent, so it was a big help for them.
And actually, the document was published on Crip Pad in the end.
And, but yeah, but at first it was made on Google Docs and Google helped India police.
I mean, it can be understandable in some sense because it is a big market to become.
But yeah, I'm not sure to judge, but at least we cannot sell your data to anyone.
And how does it work?
So now let's get into it.
So basically, we have a model where we have a central server,
which will deliver the files, but the files are all stored.
So this picture is actually not really accurate because here what you see
is that you have the first Pingu, which is writing hello,
sending it to the server in an encrypted form, which is then broadcasted as well
in this encrypted form.
And then as it's a symmetric encryption and everyone has the key, they can all decrypt.
Actually, it's not exactly like this that it works.
It will be like saying, oh, I wrote an H and then it will send, I wrote an H.
Then you said I had an E and so on.
But it will just be like difference between, it will be decent patches.
But here we just simplify things.
And so we decided to keep this centralized part because in the end,
we could have imagined something like peer to peer, but then it will be hard
to synchronize, we'll have issues like if a message arrives before another.
We'll have another issues, but as we already have a server that delivers the file,
we can also use it to coordinate communications.
And that's how we managed to achieve our goal of having end-to-end encrypted
collaborative edition.
Sorry.
And right now, so that was presentation about CripPad.
And about this, we recently, we are mostly done on it,
but we had an NLNet project, which is called GroupRinse,
where the goal was to analyze the security of CripPad and try to find
new directions prepared for the future here.
I wrote it here.
And so we had many different improvements that have been shown by this analysis.
So there are many things actually in CripPad because it's basically something
that may be called cryptography driven, where basically,
our design really relies on cryptography.
For instance, when you log in, it is used,
I mean your password plus login is used to derive your different keys,
like signing keys, asymmetric encryption and everything.
And so everything is based around this.
And for instance, we don't store, for instance,
a hash of your password and then try to match it.
So for instance, it makes password recovery like a big hassle.
We cannot do it, we just can do it.
When you subscribe on CripPad, there is a big warning saying,
don't forget your password, but of course people forget it.
As well, as we are also mostly working with the document keys
that we are sharing with people, we don't have any ratcheting or any key rotation.
And then for instance, revocation, also no foreign secrecy, but I won't talk about it.
So for revocation, it's also hard to get.
And also another hot topic, like right now in the cryptographic community,
it's post quantum crypto.
So there have been like the NISDs and NIST, which started post quantum
candidates evaluation like in 2015 and last 2022,
almost last year because we are sort of a new year.
Like in 2022, there have been the first selected new standards.
So it was Falcon, Deletion, Kiber and another one.
Anyway, so the thing that right now as well, like as I said earlier,
CripPad started just as a small project in the company and then it's expanded.
But the core is still there and the core is not really easy to work around.
But there are also a lot of like refactor to do about the cryptographic layer
in order to move toward the cryptographic agility.
And actually, I mean, between all these different improvements,
I will talk about the password recovery, recovery,
because it's something that users may want.
And so let's talk about it.
So I said it's like something cryptographic driven.
And I said that user are identified with their signature public key.
And the thing that this relation is only one way.
If you know your password and login, then you can get this public key.
But I mean, maybe you cannot like relate it any other way around.
And the thing that we have something which have become like a hassle to solve
because of cryptography, so one solution is just like, hey,
let's add more cryptography.
So we'll add something which is called linear secret sharing or
sometimes Shamir's linear secret sharing, which is the idea that you want to be
able to share a secret between multiple parties.
And then if a subset of them like above a certain threshold,
but it can be more complex data structure.
But anyway, let's keep it simple.
So if you have more than a certain threshold, like if you have like, for
instance, you split your key into five and you want at least three people to
collaborate, like for instance, the majority to be able to reconstruct it.
Then you can get the key back at the end.
So what we'll use is like social linear secret sharing,
something akin to the ring of trust where you will share your keys between
different participants.
And then you have to trust them, of course, because if two of them colludes,
then they know your password.
And here we can see a weird reference, which is Reed Solomon's code,
because it's basically the same ideas of splitting things.
So yeah, for instance, for me, I came from the cryptographic community.
And we like code people because they are always telling us,
all that code people invented everything before you.
And I mean, at least this time it was true, not always, but sometimes.
And what is social secret sharing?
So as I said, you have a secret, like for instance,
here it will be your password.
And your password, even like directly like some keys to a file which contains
part of the thing in order to be able to have some kind of revocation.
So you have your secret and you share it between your friends.
And then they all keep a shard, a part of it.
Individually they cannot do anything with it.
But then if you ask like for instance here, I will take the majority vote.
So if you ask two of them, then you can get your secret back.
I mean, hopefully they won't keep it to them.
And then once you have your secret back, then maybe you can change your password
with other convoluted way, but ideally.
So then in some sense, you cannot lose your password because it's always
somewhere there.
Obviously it's not very sound because if for instance,
some people are not connected because the thing that you also have to think about
UI and UX, so how will it work?
So if they have to click on a button, they have to be connected for that.
You have to contact them, but I mean, it's still way better than losing your password
in the end.
And this raises like a lot of different questions.
Like for instance, I mean, as I said, how will we make it understandable for
the user because we don't want them to have like really just like a jizz and
take that they have to send you back.
You want it to be stored properly, so maybe directly on crit pad.
But then there is a risk explanation because you have to tell them like what is
sensitive, what is not, what you can do, what you can't.
It's an unusual system for users.
I mean, maybe for good reason.
But anyway, I don't know a lot of systems where you have these kind of things
implemented.
And I think it's something like, okay, so something I didn't say about
crit pad, that one of the aim is also like user friendliness.
We don't want for instance something like PGP, which PGP is a very nice tool, but
it's hard to get around it when you are starting and you just want to do something
simple.
You have to read the documentation, see exactly what you want to do.
Even the OpenSSH client is like really powerful tool, but not very user friendly.
But for us, we want something that, well, a lot of our users just want to use
crit pad because it's open source and it's an office shoot, not because it's end
to end encrypted.
So we also want to keep this user base and we think it's important to make
cryptography available for everyone.
And then also like it just, in the end, just some displacement of the issue because
like before, we were like, oh, but we can just lose everything.
So now we may not lose everything, but then some other people, like if the trust is,
if your friends are not very trustworthy, then they can call you and
compute back your secret.
I said, if they are not available, then you can do much and that.
No?
So to conclude, so I'll come back on everything I said beforehand.
So crit pad is an end to end encrypted collaborative office shoot.
And everything in this sentence is important.
It's collaborative.
You have all the, most of the tools you want.
And it's also secure as in it's end to end encrypted.
As I said in the previous talk, we also have like other issues like we cannot,
I mean, as of now, we don't guarantee that the code you are executing,
the JavaScript running on your browser, that it's indeed the real one.
So there are also some other parts where we still can do better.
We still can improve.
But this is also one very sensitive thing.
It's end to end encrypted, but I mean, there are also like some cryptographic
solution for that.
But yeah, it can be quite expensive.
But we are also thinking about how to go toward this direction.
I forgot to tell you about this, but I mean, as a full office shoot,
you also have other collaborative office shoot,
you have other collaboration tools that are available like calendars.
Unfortunately, we can't synchronize them directly using CalDAV because it's
encrypted on the server side, so it cannot serve it directly.
And we don't want to send the servers the key.
We also have like some teams, I mean, a way to share your document and
calendars in between a team.
Like for instance, right now in CripPad, we are working,
like in XWiki in general, we are working using CripPad.
And we have different teams like one for the support teams,
one for the CripPad teams, like to organize things and stuff where we can
find every document that we need, like the other size for instance.
And also one of the very important points that it aims at being user friendly.
And so for the future, we want to go toward quantum,
crypto agility, like making the code more modular and
that we can switch algorithms more easily to move toward
post-quantum secure collaboration, which will be a way stronger security
guarantee than what we have nowadays.
Even if like right now if you, I mean, basically like as all the symmetric
part is still like more sturdy than the asymmetric part, what is stored in the
server, I mean the data are kind of okay even if, let us imagine that there is
like quantum adversary right now.
It will be more like someone can impersonate you,
which is still a big issue, but it's, I mean, if you just get the data on the
server, you cannot do much more from that.
You need extra information, even if you have a quantum computer.
There is also this revocation which I didn't talk about at all, but
it's also an interesting issue to handle because it will,
may help us to move toward forward secrecy, which is nice to get because it will
mean that if you get a document at some point of time,
you don't know what happened before and you can be revoked and then you won't
know what will happen in the future on this document.
We also can imagine other ways to resolve, I mean, so right now I was mostly
talking about like we have a central server and stuff, but we can also use
conflict-free applicative data type, like CRDTs, to like try to solve conflicts
and stuff because right now it's really something very, very naive, which works
in the end because in text, you don't have that many weird conflicts that
happens and yeah, as I said, perfect execution.
So now, as a last word, I will just present that, I mean, it's just the
Crippett team and so thank you for your attention and if you have any questions,
I'll be glad to answer.
I have two questions. The first one, I visit Crippett only for document writing,
something like Google Docs that have only a little problem for me. It's not
have a full screen document, it was information about Crippett, where
there's information about Crippett around the document, not like Google Docs,
by instance. So I was at the beginning of this kind of thing, but maybe it can
be resolved with a full screen text, something like that. So when I go to
Crippett, the first, the first time. So the second one is interfacing with
different type of document, worksheets, database, also text with table and so on
because Google Docs and Google Sheets, there's not good, a good interfacing
between both and I will be happy if it's good in Crippett.
So let me be referred to be sure. So you said that the interfacing between
spreadsheet and documents are not that good, right?
Yes.
Yeah, I mean like so far with both, I mean we are right now depending on
the office, which we are also like, which we interfaced with the Crippett
service, but it will be kind of hard to get, we can try to, I mean we are always
trying to improve things, but I mean I know that we have work done here which is
working mostly on this part, but yeah, I don't, yeah, maybe it will improve, but
I mean we'll keep it in mind and...
It's a good use of the tool to use, the interface.
Yeah, I mean we are working a lot with user interface. Actually the project lead is a designer,
so it's really giving us feedbacks about how to make things fitting nice.
And yeah, any other questions?
Hi, we'll discuss about it.
Thank you for your talk. I've been helping package Crippett for NixOS, Nix packages,
and one thing that came to my attention was that the whole thing is like 800 megabytes,
and I was like, whoa, what's going on? And then I noticed that it's the integration
with only office, that it's a lot of space. I just wanted to know if, I mean are you keeping
that in mind in the future? Will you keep it? Because it's quite big for, like if you
compare it to a WordPress release for example, the size is huge.
The thing that we have, I mean we don't have the original version of only office because
the thing that we only keep is the only office client and the server part, we are emulating
it with Crippett basically. So we need to have this hacked only office in our repositories,
and every time we have, we need to make an update, it's a mess.
We are aware of this issue, we are trying to find a solution, but we are also other issues too.
And then, that's it. Thanks for your feedback.
Hi, a question. So what are exactly the technical limitations at this point? Because you showed
the secret sharing. I imagine I'm not a cryptographer, so based on the theory, the more people who are
collaborating at that point, the more harder it would be to manage. So what are the other technical
limitations perhaps that you see at this point from that?
So technical limitations for what?
You showed the example of the secret sharing, where you have a secret shared between different users.
The more you scale with the users for any document, the more it might be complicated.
Actually, here's the main...
So basically the question was that what are the technical limitations of Crippett, like in this
context about secret sharing, for instance, they may be scalability issues.
And actually the thing is that for that it will only be small islands where you will share...
I mean, you will only have small sharing islands. For instance, for scalability issues, we don't have any
issues with the number of users growing in terms of collaboration, because in the end, on a single document,
at a single point of time, that many people will be working on it, and the server is only acting,
is only there for communication, because it doesn't... I mean, there is really not much processing
in the server, because it cannot do anything. It cannot be done.
So it's all spread within the clients, within their browsers, which makes it a bit of an issue
on mobile devices, for instance. But for secret sharing, this won't be a technical limitation.
As I said, the main bottleneck with the use of cryptography is the fact that it will block us for...
I mean, it will make some functionalities harder to implement, because everything is hidden, and you
don't have access to it. But at least, as far as I understand, for secret sharing, it may not be an issue.
The main issue will be that you have to coordinate with the other parties, but that's all.
Yes.
Sorry, Ludovic, also from the team, to answer to the next person. One of the big reasons there is a lot of space
is that we have multiple versions of OnlyOffice, and the reason is because we store in the native format
of OnlyOffice because of real-time, we're not storing the Excel version, so for compatibility reason,
when we upgrade CripPad, we need to be able to upgrade the pad, so we need the older version
so that we can upgrade the pad to the newer version of OnlyOffice, and there is a plan to make the installation
of the OnlyOffice modules optional, and basically say, which ones do you want in your CripPad so that you're
not carrying very old versions of OnlyOffice code in CripPad, and this is why it's so big.
We're sorry about that, but there is a technical reason.
Yeah, unfortunately.
Thank you.
So, yeah, I think we are done with this talk. Thank you Fabrice.
Thank you, everyone.