Hello, everyone. We would like to start our talk on cloud storage encryption with Cryptomator now. I'm here with Sebastian Stenzer. And my name is Tuvia Sargemann.

We are both currently studying master of computer science at this university. So we are very pleased to talk about our project at this year's FROSCON. So before we get started, I would like to ask you a couple of questions before we talk about the details of Cryptomator. So you know why cloud storage encryption

is so important for you. So the first one is easy. Do you use any cloud storage service? Just to name a few, Dropbox, Google Drive, OneDrive, or maybe your own cloud. So most of you are using cloud storage services.

And it's great. So I personally use Dropbox and Google Drive. Speaking of Dropbox, it has been around for seven years now. So we are all familiar with cloud storage. So I don't have to explain that anymore. So we use it either personally or even business-wise

because it's very convenient. We have more and more devices. We have a smartphone, a laptop. Or at home, we have a desktop computer or a tablet. So we would like to access all our files without synchronizing them manually between all those devices because it would be totally annoying. So we use cloud storage service in our everyday life.

But now here's another question. Do you trust this cloud storage service you're using right now regarding security and privacy? Maybe you already have a strong opinion on this one. Maybe you trust them. Maybe you don't. Or maybe you're indecisive because you say it depends on the files I would like to upload.

So let me ask you some other questions or simpler ones. Would you upload naked pictures of yourself to the cloud? I'm shaking my head. No, probably not the best idea. And would you upload maybe personal and documents with personal and sensitive information

of yourself to the cloud? Maybe a scan of your identity card? Maybe, maybe not. So where do we even draw the line here? What to upload to the cloud and whatnot? So wouldn't it be great if you wouldn't even have to ask ourselves, what files should we upload there? So the key thing is here that we

aren't in control of our data if we upload our data to a cloud storage. Before that, everything was fine on our local hard drive. But now we put the files in the cloud in some server farm. We just don't have control anymore. We pretend to be in control because we are logging into a password-protected account.

But in reality, we aren't. So for example, Dropbox is even obligated by law that they give out your data if law enforcement requests it. So what just happened here? We used cloud storage service. It's very convenient. But now I've got all these troubles

that we don't know what to upload and whatnot. And it suddenly became inconvenient. So yeah, wouldn't it be great if we just get control of our data? So another title of our talk could have easily been, how do I gain control of my privacy in any cloud storage

service? So that we still can use Dropbox, but that we can trust our data to be secure. So maybe you can also say, OK, we just talked about trust and control. And if we aren't in, so maybe some of you

may say, I can trust them and not be in control. So for example, yeah, I mean, I'm a good citizen. I have nothing to hide. So what's even the deal? So I would like to quote Edward Snowden for this one. And he said, arguing that you don't

care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say. So I think this is a powerful quote. Because with free speech, we can all relate. And it's a beautiful comparison. But I'll stop here. I don't want to get too political here.

And so let's look at a scenario. OK. Say hello to Alice. She wants to store some files in the cloud. So she has heard that the cloud could be potentially dangerous. Maybe she read some worrisome news, articles about celebrity photos getting hacked.

Or maybe she just watched a Hollywood movie where they tend to put a bad light on the cloud. So she also read that encryption might solve the problem. So Alice is looking for a tool which uses encryption to protect her privacy so that she gains control

of her privacy again. And she needs a tool that is trustworthy. It should obviously work well with cloud synchronization. And it should be easy to use. So the last point is very important for us because if it's not easy to use, Alice wouldn't even bother trying it out.

So you have to always look for the typical user and not maybe just as geeks and here in the room. So it should be easy to use. So she found Cryptomator. And this is what Cryptomator does. It's optimized for cloud synchronization, obviously.

And it's doing that by encrypting each document for itself. So individually. And the thing is, Cryptomator does only the encryption part. And so it is provider independent. So we can use any cloud storage service we want. And we leave the cloud synchronization untouched.

Cryptomator is obviously open source. Otherwise, I wouldn't talk here at the FrostCon. And Sebastian will talk about it later why open source is so important. And we always had in mind to keep it simple. So it should be easy to use. So Cryptomator does what it does best and nothing else.

Okay, so Alice wants to store two files in the cloud. And she uses Cryptomator like a middle man in between. And those files that are stored, oh, the colors are great. The files that are stored through Cryptomator land in a password-protected vault.

So what happens in the vault? The files get encrypted. Not only the file contents are encrypted, also the file names are encrypted. And they land in a folder D, which stands for data. There are also other types of files, for example, a directory. And we also have some metadata files,

a prefix with M. Because sometimes they are just long file names and to be compatible with the file system, we have to map it to an ID. But this is something that a user doesn't even have to worry about. It all happens automatically. So what does Cryptomator obfuscate? So obviously file contents, which is the most important one.

Also file names. File size to some extent, because we don't want to fill up your cloud storage space with garbage data, but to some extent file size. And directory hierarchy. So to put this in perspective, most of encryption tools we've seen

only do obfuscate file contents. And it's not even that common to obfuscate file names, which we find very surprising. And these other tools, just the icing on the cake. So this is how Cryptomator works. And just to remind you,

it's not a big container, it's not a vault that has to be synchronized as a whole to the cloud. It's these individual files inside that are synchronized. So if you edit just one file inside or add a new file, it's only this that has to be synchronized with the cloud. Okay, so now the Bastian will talk about more,

well here, why open source is important and tell you some more insight about security. Oops. Oh, the mic just exploded.

Take this side.

So, okay, why open source? And I do realize this is kind of a dumb question to ask in an open source conference. But there are some pretty important reasons why we chose Cryptomator to be an open source project, especially when, well, it's on security projects, so there are some advantages.

First, let's talk about the obvious advantages. So anybody on the world can go ahead and if he finds a bug, he can report it on our GitHub repository, especially when there are security weaknesses. Those kinds of bugs are very important to us. And if someone wants to add features to the project,

just can fork it and add something. So those are the obvious advantages we know from kind of every open source project around. But there's more. So especially when we are talking about trust. So I think many of you heard about the relations about AT&T and the NSA lately.

And what I want you to ask yourself is what happens if only a single person in a huge company is corrupt? So the employees in these companies, they don't even know what the colleagues are working currently on. So only a single person might be enough

to implement a backdoor in some project. And while talking about AT&T, those backdoors, they don't get discovered for years. And this is something that cannot happen in an open source community project because we have the very opposite case here.

If only one single person is not corrupt and all the others are, he might blow the whistle on the whole project and well, the NSA wouldn't even have a chance of implementing or forcing somebody to add backdoors to some project. So this concept of shared code ownership,

this is very important when we are talking about security projects here. So this is about trust, but there's even more. But first, there's another question. Many people ask us, isn't an open source project less secure than a closed source one? And before I answer this, let's look at some typical marketing web pages

of different security products. So here's the first one. We see a lot of buy buttons. Obviously they want to make money with it. And they are talking about military strength encryption algorithms. Okay, pretty cool, right?

We don't really know what this means, but sounds convincing. So let's take a different page. Oh again, military-grade security seems to be some kind of industry standard, right? And what's on the side are something about 256-bit AES. Whatever this is. And SSL, yeah, I kind of heard this is important.

And oh, this is trusted by the military and the government. This needs to be quality, right? Well, our German government, they are still using Windows XP, so I don't really know. Sorry. Let's take a third example. This one is designed for reliable security.

And again, they have military strength data encryption. So, well, pretty cool. So I'm here today to tell you a secret. There is no such thing as military-grade security. It's just a made-up marketing term. And if you Google for it, you won't even be able to find a definition for it.

So what did we learn so far? They are all military-grade secure, but they didn't really say anything about how the encryption really works. And does this make the software more secure? One might think so, but there is, sadly, this principle called Cocos Principle,

which basically says that the security of a system must not rely on the implementation of the algorithm being kept secure or kept private, but only on the key. And so this means that there is no gain in security by not publishing the encryption algorithms.

So there must be some different reasons why the marketing web pages don't tell us anything about the encryption. And maybe it's just because of their commercial interests. Of course, they want to sell their product, so they keep it private. And, well, no, this isn't really the reason.

Because the encryption is only a small part of the project. There's a lot more effort that went into the user experience and the workflow logic, et cetera. So maybe that's a different reason. Maybe those products have just bad quality. Maybe they don't want people to find vulnerabilities. And this is something where we ask ourselves,

is this the way we want to go? And we said no. We do want people to find vulnerabilities, at least while we're still in beta, of course. So that's why we went ahead and, well, we published our encryption scheme on our website. We have, obviously, our source code on GitHub.

People started cloning it, those are the clones in the last 14 days. And we went to crypto communities and asked for help, and we got tons of feedback. So on this Reddit page and by email, from different persons who, they found vulnerabilities and they reported them.

Here's another one. And, well, we fixed them, and today, here we are. So, how does Cryptomator work? If we look at it from a high perspective, there are four components, five if you count the user interface, but let's concentrate on the core.

So there's some webduff interface, which is the front end, the user has to interact with, which provides the virtual hard drive. One can drag and drop files onto. And, of course, there's something cryptographic in the middle, and a storage device, where all the encrypted files are written to, and something called key derivation.

More on this in a second. So let's look at webduff first. Webduff is a protocol based on HTTP. It's very mature, it's used by all major operating systems, supported natively, and it allows us, as I said, to mount this virtual hard drive.

And, as it's supported by all these major operating systems, we're able to write just one application, which runs on all those systems, and, well, this is, as I said, very mature, well tested, and has some other advantages. One of them is that, as HTTP has this

request response model, and all the encryption thus happens on the fly, there are no leftovers on your computer, even if you're on some internet cafe, for example, if the application crashed. Because this virtual hard drive is just, not more than just a virtual hard drive. All those files are encrypted and decrypted on the fly.

And, well, now about our crypto scheme. We have a patented military-grade secure algorithm. Just kidding. Well, we have, as Tobias said before, we have file name encryption, for that we use something called synthetic initialization vector mode

of operation for AES, which is a deterministic mode. So, even if you open a file multiple times, and encrypt it a lot of times, the file name will always be the same, so there won't be 20 different copies in your Dropbox folder. And the file content, well, before we encrypt them,

we slice your file in chunks. Each chunk is up to 32 kilobytes in size, and gets encrypted using counter mode, which is not, well, it's a cool mode, but it needs, additionally, something called HMAC to provide some integrity protection. So, we calculate, additionally to the encryption,

and, well, this HMAC, yeah. And so, we prevent things like shows and ciphertext attacks and chunks cannot be reordered in some different position, et cetera. So, those chunks are then merged together, and there we have your encrypted file, which is then written to the storage device, obviously,

and, yeah, as I said, or as Toby said before, synchronization is not our business, so once we have written the file on your hard disk, your native synchronization client of Dropbox, to Google Drive, whatever, will see this change and start synchronizing. So, let's talk about key derivation.

We have something, we have encryption in our system, so we need keys. Where do we get these keys from? Well, when you use a user, you type in your password, which is like a 10 character password, for example, but what we need is 256-bit keys, and this process of deriving this long key

from a quite short password, this is called key derivation, and there are different functions for this. So, in formal versions of Cryptomator, we use PBKDF2, which is pretty good, but one of the community contributions was that we are now using script, which is even better,

regarding the brute force protection. So, what does this mean? If we derive these keys, this function we use for this is very hard to calculate, and this is meant to be hard to calculate.

So, it takes a lot of time. We're talking about milliseconds here, and this is pretty okay when you enter in your correct password. You can wait a millisecond, I think, but when we try to brute force all the different combinations of passwords we have, this will take a while, and we're talking about a few thousand years here,

so nobody can wait this long when he tries to brute force with this. So, what can the NSA do about it? They can, of course, buy a lot of hardware, and run this brute forcing process in parallel. And these are numbers from Colin Percival, he published in his paper about script, of how much this hardware would be worth

if one would try to crack the passwords in one year. And, as you can see, script is a little bit better than PBKDF2, PBKDF2 is still okay, as I said. And, yeah, so we need a lot of hardware, and I'm not talking about PCs.

I'm not even talking about some high-performance clusters here. I'm talking about specialized hardware which can only do calculations used for these key derivations, like, for example, PBKDF2, we use a secure hash algorithm, too. And the fastest device available today

calculates about 5.5 trillion hashes per second, which is a lot, but it also burns a lot of energy. So, this device uses more than three kilowatt. And, now, if you do the calculation, if you buy a lot of these machines, they cost about $2,000,

and if you buy a lot of them, you also need a lot of energy. So, I've made the calculation somewhere here. Yeah, so to run all these machines, you need 80 terawatt, just to give you a comparison. The largest power station on earth produces 22 gigawatt.

So, okay, this might be a problem to crack. So, what if we bypass the key derivation and directly guess the 256-bit key? Well, not the best idea. This is a huge number, and no, this is not the number of possible 256-bit keys. This is about one six trillion,

which is the approximate amount of sand grains on earth. So, let's zoom out a bit, and this is the number of possible 256-bit keys. Just to give you a better understanding, if we add three more digits to the end, this is 10 to the power of 80. We have the approximate amount of atoms in our universe.

So, okay, we are talking about a system which is practically not really crackable, but maybe there are different approaches, and sadly, yes, there are. So, let's talk about the biggest weakness, which is the human factor on our system. There's this neat webcomic from Miska Thede.

He pretty much put it in a nutshell what social engineering means. So, we can either, on the left-hand side, we can either build this multimillion dollar machine and a few thousand power stations and all this stuff, but it will cost us a lot of money and there's a cheaper way. We can also buy a baseball bat, for example,

and try to beat the password out of the person knowing it. Way cheaper. But even without violence, there are still ways to perform this social engineering attack. So, take phishing, for example. You all know phishing. You all, I think, have gotten emails from some fake customer service tricking you to click on a link

where you have to provide a password or your account credentials. And while yesterday, this may have worked, but today, really, who would fall for this? But luckily, luckily for the hackers, all the accounts and security systems got more complex,

and today, your account not only consists of your username and your password, but also we have a ton of password recovery settings. And Fisher can maybe aim for this, right? So today, phishing mail might look like this. Dear customer, please remember, do not ever enter your password anywhere,

but you have to reconfirm your password recovery settings, so please go on here. Pretty convincing, right? He even warns us about not entering your password everywhere, so this is trustworthy. And yeah, sadly, there are people still falling for this trick. So, what do we learn from this? Well, complexity adds further attack points

for social engineering, so we want to avoid complexity. And what does it mean for Cryptomator? We talked about void sharing a lot. In some former versions, we had multi-user support, but this added complexity and people didn't understand it and, well, a huge mess.

So, how can we share a secret with somebody? We can either use public keys, which is a pretty well-known and good thing, and technically perfectly secure, but users tend to not really understand how to deal with this.

And, well, take this example. If there's a phishing mail and somebody wants Alice to upload her key on some website and this website promises to strengthen the key or something like this, and Alice isn't really aware that her private key is something which should be kept private, then this might work.

Or take this example. When Alice wants to share something with Bob, she needs Bob's public keys, so she goes ahead and asks Bob, hey, give me your public key, and Bob responds, yeah, here you have my public key. But what Bob didn't say, Alice, is that Bob isn't really Bob. So, as I said, this public key cryptography

is a good thing, but it needs the user to understand what is happening. So, while in communication we do support this, this isn't the best choice for us in Cryptomator where we want some per user privacy,

and we want to eliminate the human factor from this system. So, we are just using pre-shared SQL, which is technically not that secure, but if you add the user to the system, I think we are going with the best choice here.

So, I will say, when you share a password with somebody, you are aware that you share a password. Even my grandma understands this. My grandma wouldn't tell somebody on the phone her banking PIN just because he says, well, she won a lottery or something, or he's a kind of prince from, I don't know.

So, if I want to share something with my grandma, we both just agree on a common password we both know about, and there are no additional complex means that, well, at attack points.

So, yeah, talking about my grandma. My grandma really likes her iPhone.

The part again. Maybe I'll hold it right now, it's easier. Okay, so, we have been working on a desktop application

and we started last year, but Sebastian is a main contributor of the desktop application, and I joined earlier this year to work on the mobile application, because, as I said, cloud storage is very important for all our devices, so we also have to have a mobile application.

So, wouldn't it be just maybe easy to take the desktop application, port it to mobile, and that's it? Sadly, it's not that easy. So, what's so different about a desktop computer and a mobile device? So, maybe it's size. Well, no, it's the resources are fundamentally different.

So, take, for example, the internet connection. So, on a desktop computer, we usually have a dedicated line, we have unlimited traffic through a flat rate, and on the other hand, on a mobile device, if we are not in a Wi-Fi, then we have the cellular network,

and it's slow, probably here in this building, I don't even have a signal, and we have limited traffic, just a couple of hundred megabytes per month, or maybe a couple of gigabytes per month, if you have a good plan. So, yeah, internet connection is a problem

for cloud storage, and another one is, of course, storage space. So, we don't have these hundreds and thousands of gigabytes hard drives on our mobile phone. At least, yeah, it's slowly catching up, but still, we can't just synchronize our cloud with 50 gigabytes of data to our smartphone.

Another thing that's different is the operating system. So, let's take the desktop computer, for example. We are working with files and folders, we drag and drop them, we manage them, and we are working on something called the file system.

Hence the name, that's our computer, we are working with our virtual desktop. So, on our mobile device, we don't really have a file system, so it's a high level of abstraction, we have apps on our home screen. Well, technically speaking, of course, there is a file system, but it's not comparable to the desktop ones,

we just don't have a central file system. So, let's take, for example, the Dropbox app on a mobile device. Isn't that a file system? Not really. So, the Dropbox app is imitating a file system, so you can move your files around and create new folders

and upload something and download something, but it's everything happening in the cloud, so remotely. It's not happening on a device, it's not getting all the complete data. So, what has to be done here with Cryptomator, because Cryptomator works on the file system.

So, we basically have to do the same as the Dropbox app. We have to implement our own basic file system functionality, and we have to build the user interface and design a workflow completely from scratch, because there's no standardized way to do that.

And keep in mind, we have this everything on a desktop computer for free by the operating system. So, we have to implement that. And another thing is, we are dependent on the provider, so we have to know which cloud storage service we are working with, because we have to call their APIs.

So, we have to integrate each cloud storage service one by one, and yeah, this is one of the benefits that's lost, but it can be done with the major ones. So, where are we now today with Cryptomator? Currently, it's in beta.

So, we would like to talk now about what's next on our list, so maybe you can help us out in some of the points. So, let's look at the desktop application first. The crypto code is mostly done. So, we just released a final release candidate of our crypto component, so the core is done,

but we have to improve the integration with each OS, so with Mac, Windows, Linux. And talking about Windows, well, we sure had a lot of problems with it in the past, so we need still more improvement on that. But we would also like to improve Cryptomator on Linux. For example, we would like to have more native builds

for various Linux distributions. We just have a Debian build online right now, so it would be great if you would contribute to that. And of course, on GitHub, you can post an issue. It might be a bug, a feature request, or even a vulnerability.

And also, pull requests are very welcome. On the mobile application, so we are currently working on an iOS app right now. So, also there, we would like to improve the integration with the operating system, in this case, with something called App Extensions that has been introduced last year,

and just to make Cryptomator for us more seamless with the system and more integrated, so it doesn't have to switch back and forth between the apps. And of course, we would like to support more cloud storage services. Currently, we are supporting Dropbox, Google Drive, OneDrive, and iCloud Drive. And we would also like to, for example,

include WebDev, for example, for old cloud. But this is just something we are working on currently. And of course, it has to be easy to use, so also first-time users instantly know how to use Cryptomator, so we are refining the user interface and the user experience. But there's probably now an elephant in the room.

How about Android? So, we just don't have the manpower yet. But if you are an Android developer and Cryptomator sparked your interest, it would be great to have an Android app, because the crypto code is already written in Java, so you don't even have to start at square one.

So, now it's time for a little demonstration of Cryptomator first in the desktop application. Okay, where should I start? So, yeah, I just recently got these cool new songs

by Paul and the Atlas, really great band, you know them? Yeah, great, yeah, I know Paul, it's great. So, if you're interested, I could just open our shared vault and add those files to it. Okay, great. So, as you can see here, this is our Cryptomator desktop application,

and here's the list of our vaults. So, let's take this one, which is the shared one of us both. So, I like frogs. Pro tip, by the way, do not ever enter your password this way when you're in public, but okay. So, if I unlock the vault, I can now close the window,

and yeah, here's, oh, what the fuck? Don't look inside. No, no, no, the public knows it, deserves to know what's in there. Oh, yeah, Toby, Toby, Toby. Okay, let's better get on with our presentation. So, as I said, here I have some unpublished songs, and they must better not leak yet.

So, I put them into this virtual hard drive, and as you can see, that's all. Now they are encrypted. So, yeah, anything you want to see? Okay, so maybe I'm not that convinced yet, so let's look in Dropbox how it looks like. Okay, so I open my Dropbox folder.

Here it is. You can already see there are a lot of kind of, well, funny file names in here. So, where do we have this? Ah, yeah, here. No, Top Sequel, this is our vault. So, I look inside it, and as you can see, there are a lot of different files.

Yeah, and if I open these, they would just contain some gibberish. So, well, yeah, these are our encrypted files. So, anyway, what about mobile? Okay, so let's look at the mobile application in its current state.

So, we will use QuickTime just to have you, have my phone on the screen. Okay, great. So, as you can see, we have all the vaults we just had,

and Top Secret is the one we just used together, and another thing that we can now do is instead of writing the password in, we can use Touch ID to log into our vault, and now it's using the Dropbox SDK to load the data.

So, of course, I can browse here through it. Everything looks normal. I can download a file and look at them and operate on them. So, all the basic file system functionality, yeah, had to be written. So, for example, if I would like to create a folder, I can do that or upload a file, and basic file operations on each file,

it can do by swiping, for example, rename it, move it to another folder, and also delete it. You just talked about third-party app integrations, what about this? Okay, so, for example, let's go to the camera app. Oh, yeah, let's take a selfie.

Okay. So, we just took a photo, and we don't want to, oh, sorry, we don't want to leave the app. We want to stay inside. So, on the bottom left, there's a share button, and on the bottom, there are all app extensions.

So, I can use Cryptomator, and this opens a new Cryptomator window without switching to the app itself. So, we are still in the camera app. The default settings are fine. I just press save. I still have to unlock my vault. It gets encrypted, uploaded. I'm so happy that the Wi-Fi connection is working.

And now, it's in our shared vault. So, we can now switch to the desktop application, and see if it really landed there. Okay, great. So, that seems to work. Pretty easy. Okay, then, so, you can get Cryptomator now for free

on Cryptomator.org. It's currently in beta, but we would like to have more testers. Also, via iOS beta, you can sign up for, which is distributed through TestFlight, and Cryptomator is hosted on GitHub.

You can get it there. And we would like to see any kind of contribution that would be great. So, thank you for attending, and happy crypting. Okay, I guess we have still time for questions.

Okay, so, the question was about the crypto component,

how many people have looked over them, and how about auditing? So, yeah, as you said, the biggest mistake would be to just assume that our code works, so we really rely on other, on different people

to review our code. And I really can't tell you a number right now, but it has been around 30, 40 different people. And, well, it's not only anonymous community people from I don't know where, but also the whole concept

has been reviewed by some professor from this very university. I don't know if you know Professor Lemke-Roost. In the very beginning of this project, I went to, and then later on, one of the emails you saw there was by, what's his name?

I don't know, I just know him by Christoph, who is from, who is from the, and he really helped us a lot with it. And yeah, as you have seen, there have been tons of comments on the crypto subreddit. But as I said, I don't really know

the exact number of people. Yes, please. No, you cannot share, also, I want to repeat the question, what about sharing files from within a vault with other people? So, you cannot share a single file which is inside a vault,

but obviously you can create as many vaults as you want, and create a shared vault where the password is known to all people who work with it.

Okay, the question was, can it be used as an encrypted backup tool? This was the motivation, why I started the project. Well, back in, I think, almost two years ago, there was, all the cloud providers, they had more and more gigabytes of free quota,

and this was when I myself said, well, okay, I have my backup drive at home, but if my home burns down, this won't help me anymore. So, the cloud is pretty good when we're talking about availability of data,

but not good when it comes to privacy. This is the motivation why I started this, and I wanted to back up my important documents that need the cloud availability, but my home disk privacy, so, yeah.

The question was,

if the master key only depends on the password, and one would change the password, thus the master key would have been changed. So, everything needs to be re-encrypted. No, this is not the case. What you have seen there was just a key encrypting key,

and this is used for further keys, especially each file has its very own key, so this is especially important as we are using counter mode, where the combination of key and initialization vector needs to be unique. So, yeah, we have a lot of different keys, but there is this key encrypting key,

which is derived from the passwords, and if you change this, only your master key file, which is a JSON file inside of the vault, will need to be re-uploaded.

The question was, is there a command line application? No, there isn't, and you're not the first one asking this. There's already a GitHub issue of some people who want exactly this, and currently we just have this user interface thing, but it's kind of modular,

and I think it wouldn't be too much of a problem to create one.

So the question was, if we're encrypting the file names, we will only see encrypted file names, and the Dropbox pop up,

which notifies us about changes, and so we cannot really, we as users cannot really say what really changed if somebody uploaded or edited a file. And yeah, this is obviously something we have to live with, and it might be an option in further releases

to make it a user choice if file names should be encrypted or not, but currently, yeah, this is the situation, just as you describe it.

So the question or more as the suggestion was, on the mobile application, so we are all using APIs for Dropbox and so on,

so everything is stored remotely, and it was asked if we could access our files sometimes offline, because maybe sometimes we don't have an internet connection, and we would like to access them either less. So this is a feature that's currently missing, that's true.

I guess this is now a feature request, so it's a great suggestion, maybe something like a favorites bar, I've seen it in Dropbox apps, so you can have them offline accessible, but it's just not in the beta right now, so thanks for the suggestion.

The question was, if there's a search capability inside the encrypted files,

or the plain text view of the encrypted files, and now we don't create some kind of index or something. I don't know to what extent what operating systems are able to search on a web drive. If they are, there will be native search capabilities

by the operating system, but as we just concentrate on the cryptographic part, we don't interfere with either the side left from the web drive interface, and right from the synchronization. So maybe if there is a problem searching encrypted files,

there might be some tweaks we can do to make the operating system support the native search capabilities, but we have to investigate operating system for its own, so I hope you understand this is kind of difficult,

but definitely also a good point for a feature request.

The question was, to what extent we can share just,

create sub-vaults inside a vault, where we just give access to some certain folders to a different user group, and no, we do not support this. This is a decision made because reducing the complexity, so we think if we want to address

the whole majority of users, so including my grandma, the best approach is to have one vault with one password, which is shared with one group of users, and so if you want to have different groups, you have to create new vaults,

and of course, yes, this does have the disadvantage that you may have to copy files in different vaults.

OpenStack. So I think the question was, correct me if I'm wrong, if this can be integrated with OpenStack, and well, to be honest, I'm not an OpenStack expert, but if there's some storage synchronization mechanism

in OpenStack, then this shouldn't be a problem here.

The question was about file system kind of limitations like length of file names, depth of the directory path, or char sets, et cetera. So we have something where we reduce file names

if the path is longer than 255 characters to support Windows, which is kind of a sad story because due to encryption, the file name gets blown, and also we have the space 32 encoding which blows file names additionally,

and Windows pretty much sucks on long file paths, so yeah, anyway, we are currently reducing file name length and also the directory structure is, well, it's restructured to a kind of flat directory structure, and so all the folders,

no matter how they are nested in the decrypted hierarchy, they all are sibling folders, but those sibling folders are then created inside well, of up to 1024 subfolders that are created on the root level

of our encrypted data directory. So we are aware that there are a lot of problems with especially one operating system, and we have done a lot of tweaks to get around this, and as you have seen in our demo vault here, we have even this emoji character inside the file name,

so yeah, case sensitive and insensitive file systems will be supported both, that's why we are using base 32 encoding and not base 64 would be more efficient, and yeah, if there are any further restrictions, oh, you asked about file size, I think.

Not anymore, not really. There is some natural restriction due to the counter mode we are using, where we have an initialization vector used together with the AES, which consists of a non-center counter part, and the counter is up to 64-bit,

and it must not repeat, and so any number, any 64-bit number would be the maximum number of bytes we support per file, but this is kind of, well, you will never reach it.

At least not today. One more? Yes, it's, okay, the question was about huge files.

If we have, for example, one gigabyte file inside our vault, and we change just two bytes of it, then yes, we have to re-upload the whole one gigabyte. This is also done because we generate a new random profile key, so the whole file needs to be re-encrypted,

and we decided, well, to go for security instead of convenience here, and yeah, I know this is a problem. It wastes your bandwidth and is, yeah, not ideal, but if we are talking about the cloud, this might not be an everyday use scenario,

because who stores his movie collection in the cloud? I don't know if this is the best use case. Yes, please.

Can you speak a bit up, please? It's about file size obfuscation. So the question is how do we obfuscate file size as each file gets encrypted for its own? One would assume that the encrypted file

is always as big as the plain text file, and while we add some random length padding to the end, which is up to, we want to add up to 10% of the original file size, but we have lower and upper bound,

so there will be enough randomness, so it isn't a 100% obfuscation, but it helps, for example, if Hollywood knows that your leaked movie is exactly two gigabytes, 300 megabytes, 250, I don't know, some certain size,

this will be obfuscated so it cannot be identified just by the number of bytes. So yeah, it's at least four kilobyte overhead and a maximum of, I think 16 megabytes overhead somewhere between this range, but as I said, small files will not have

that much of an overhead because we try to keep it up to 10%. So cryptographically, not ideal, so this is kind of a compromise between perfect random numbers and deterministic approach to keep it to some good extent

the amount of additional bytes. Are there more questions? Okay, I think this was about that. Thank you. Thank you.