1. Cool project, this space always felt rather empty after the mysterious ending of TrueCrypt.
2. This was made as part of a Swiss Government tech lab’s program and requires you to install kernel drivers that were written in C. So think carefully about what you are actually doing here and if that makes sense for you or not.
3. I’m still much less clear on how it prevents this famous XKCD security problem https://xkcd.com/538/ but it seems that any system that was captured with this would be immediately obvious what was going on right down to the userland CLI tool and isn’t going to save you from getting wrenched if that’s a part of your security model, if anything you’re almost certainly going to get wrenched a LOT more unless you’re able to provide them with 15 different working passwords which is the max limit of how many “layers” this thing provides.
In fact, that’s kind of at the crux of the problem here. While it seems like a great idea initially to have a system where “you can’t prove that there are any hidden files there” is actually a huge liability not the ace up your sleeve you might assume it is at first.
Because let’s say you make a public, secret and top secret layer on a device with this thing. You don’t seem to be able to prove that there was ever not an ultra top secret layer so it’s going to just be you trying to convince someone when that someone might be very violent. So if a physical interrogation is a part of your threat model I’d probably say to avoid this approach entirely as it will possibly do more harm than good.
With this reasoning, whether or not you actually have a hidden FS is not relevant, as it's unprovable. So you will be tortured with no end anyway just to make sure that there is no hidden FS. Because that you have a hidden FS will be the assumption of anyone thinking you are hiding something.
Oh, another thing. Just to be clear, the 15 password maximum is just an implementation choice to make our life easier, but we actually think it is a liability, and we are working to remove this limit completely. We do not think that anyone sane in their mind will ever need 15 levels of secrecy with Shufflecake, but that's not the point. The point is that, with a hardcoded maximum limit (regardless of the limit, even if it's 200 or 2000) there is a workaround that allows the user to do something very dangerous. By removing this limit (up to what is allowed by the disk size), we remove the possibility for the user to shoot in their foot. See the section "Safeword" in our research paper.
Hey, Shufflecake co-author here, thanks for the questions.
1. Indeed!
2. Wow wow wow, hold on there :D there is a misunderstanding, the "Swiss Government" was never involved not even remotely. First of all, this project has roots that go waaay back in time [1]. It was finally realized when I met Elia, who was then a student at a joint ETHZ/EPFL MSc program, and Elia accepted the thesis project that I proposed in the Kudelski Security Research team [2]. Kudelski Security (disclaimer: my current employer) is a traditional cybersecurity company, mainly focused on MDR, CISO-As-A-Service stuff, etc, but it's also one of the few ones which also has a dedicated fundamental research team, which I'm part of as a Principal Cryptographer. The goal of our team is not only to "invent new ways for the company to make money", but also to do "good PR", through e.g. scientific/academic publications, talks at conferences, open source software etc., all things which is what I'm personally focused on. As part of this, we offer the possibility to students to do their thesis in our team on some selected topic, and that's where Shufflecake came from.
That is, originally. As it is now, Kudelski Security is not involved in Shufflecake anymore, it's basically a pet project of Elia and myself, we pay out of our pocket for website hosting, etc, and we work on Shufflecake on our spare time. So, please feel free to contribute, we need help!
3. That is exactly the point! The "killer feature" of Shufflecake is exactly that there is no way to determine when you have finished giving up all your passwords, or there is still something undisclosed. It is true that this also means that the adversary "does not know when they can stop torturing you", but we firmly believe, both as a matter of philosophy but also pragmatically, that "plausible deniability" does not make sense if you're not willing to accept this risk.
Let me explain better, because this is a recurring questions we have.
First of all, you have to keep in mind the security model. We are not necessarily talking about Snowden-level paranoia here, it might be something more mundane, for example an investigation in a civil court because you're suspected of being in possession of illegal material, whatever "illegal" means. At least in democratic countries, you don't risk of being waterboarded for this. We know [3] that even TrueCrypt or similar systems are enough to be acquitted in some cases.
Then there are those cases where the adversary doesn't really care, they just want to find something. We recently had a discussion with a large international humanitarian organization, one of their officers told us "our agents often cross borders with laptops full of sensitive informations, in theory we are protected from searches by the UN treaty XYZ but... go to explain that to the angry Afghan guard at the airport!". Shufflecake allows to bypass this problem efficiently.
And then there are those cases where you are hiding secrets that you care about more than your own life. Let's be clear: if you are an investigative journalist in Guatemala and the Cartel kidnaps you, you're dead, period. If you're a member of a resistance group of a repressed minority in a dictatorial state and the police apprehend you, you're gonna disappear, no matter what. But, with Shufflecake, you at least have the chance maybe to resist and possibly save the life of your informants or comrades. With TrueCrypt, you don't really have this option.
Hope that clarifies, but feel free to ask more. Thanks!
Thanks for the detailed reply, I really appreciate it.
I only ask that you continue to make that 3rd point clear to people who might be considering using it because although yes it is not a scenario most of us will likely ever face, what you have built is absolutely going to attract people who are at risk of torture and I don’t think it’s conscionable to put this in their hands unless they are extremely clear on the fact that with this tool they literally won’t have a way of being able to clear their name in that situation because I think that might not actually be obvious to them until it’s too late and maybe they would make other choices if they knew that ahead of time. I’d personally see it as a huge liability but everybody’s situation is different obviously.
But at a minimum I think just helping them to understand where a tool like this fits into the bigger picture and what other steps they should take because otherwise people will do really dumb shit with this because they put all of their faith in it and skipped a lot of other fundamental things that might have helped them because my experience with this topic is that they are absolutely going to get those passwords from you one way or the other and if your plan is to trick them you’re going to have a really shit time.
It may even be worth getting in touch with some folks who have been on the receiving (or giving) end of the wrench scenario to just chat with them about what you’ve built here and if it is something they think would have helped them or not.
You raise a good point, and we try our best to say that Shufflecake is not a toy, that users must be conscious, etc. I think what is missing is a proper user manual as a central source of documentation, we'll need to work on that.
But we cannot save the users from themselves. We do our best to make things easy and secure, but at the end of the day plausible deniability is one of those things that are kind of "hardcore".
To be more clear, I don't think I can see a reasonable scenario where using Shufflecake would put you in trouble but using VeraCrypt would not. I'd be happy to talk with people at the "receiving end of the wrench" (lol) and this is also part of our ongoing outreach campaign, but so far all of the cases I've seen are either "we cannot prove you're a criminal so we release you" or "even if we're convinced that you gave us all you have, we will still kill/torture you just because". For me, it's either you go plausible deniability "all-in", or you don't bother at all. And of course you're right that one needs to consider many things and adopt all sort of other precautions on top of that, but still a solution like Shufflecake is sorely missing right now.
But, yes, you are absolutely right that we must continue to put a big disclaimer for the users, and help them to understand the risk of using this.
I’m actually with you on all these points for the record and again, this is a very specific scenario that isn’t going to be relevant to most people thankfully but for those people, it’s as you said… not a toy.
It’s also realistically not on you to give them the training required to operate in that environment because a tool like this is going to only be a tiny part of it.
In my mind there is a very specific kind of individual I’m thinking of who has maybe a bit more enthusiasm than brains or experience who will reach for a tool like this if it’s positioned to them a certain way who is going to get themselves into a very preventable world of trouble unless somebody can step in to just remind them that they should be sensible and think very carefully about what exactly they are doing because things can sound great from a technical point of view but really mess you up in the real world and I think this is one of those things in that situation.
1. Cool project, this space always felt rather empty after the mysterious ending of TrueCrypt.
2. This was made as part of a Swiss Government tech lab’s program and requires you to install kernel drivers that were written in C. So think carefully about what you are actually doing here and if that makes sense for you or not.
3. I’m still much less clear on how it prevents this famous XKCD security problem https://xkcd.com/538/ but it seems that any system that was captured with this would be immediately obvious what was going on right down to the userland CLI tool and isn’t going to save you from getting wrenched if that’s a part of your security model, if anything you’re almost certainly going to get wrenched a LOT more unless you’re able to provide them with 15 different working passwords which is the max limit of how many “layers” this thing provides.
In fact, that’s kind of at the crux of the problem here. While it seems like a great idea initially to have a system where “you can’t prove that there are any hidden files there” is actually a huge liability not the ace up your sleeve you might assume it is at first.
Because let’s say you make a public, secret and top secret layer on a device with this thing. You don’t seem to be able to prove that there was ever not an ultra top secret layer so it’s going to just be you trying to convince someone when that someone might be very violent. So if a physical interrogation is a part of your threat model I’d probably say to avoid this approach entirely as it will possibly do more harm than good.