I, for one, would buy one.
Make it small and I would buy 3.
85 karma · joined November 9, 2022
Make it small and I would buy 3.
Question: does either of the model have NFC capabilities, or is there any plans to add this feature in the future? I am looking specifically for a way to pay contactless with Graphene OS (which does not support NFC payments because Google does not want to).
EDIT: yes, it looks like it is not possible to disable "transfer lock". Shame on you Gandi, but you know no shame.
There is the possibility of reducing a bit this chance at the cost of wasting more space by using error-correction, e.g. with RAID, if so desired. This is explained in the paper and in the FAQ and the README.
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.
And wait when we'll release a Shufflecake-powered, fully hidden multi-OS distro ;)
Oh, I see what you mean. In your scenario, you can still write data, because creation and deletion of files is managed by the filesystem on the volume, not by Shufflecake. So, those slices (disk space) that you have previously allocated for the volumes will now still be there, but contain empty space that is recognized as such by the filesystem and can then be overwritten.
What might be improved, instead, is the fact that once a slice is empty because you have deleted all files, that slice still exists and is still assigned to the volumes which first allocated that. It might be good to have a system that reassigns that slice to the list of "unallocated" slices and that hence be claimed in future by other volumes. We have some ideas (using TRIM, see Section 6.6 of research paper) on how to implement that but, frankly, I personally think this is not extremely crucial, because it only matters if you exploit heavily the overcommitment feature (which we'd rather limit through the use of virtual quotas, as explained).
Currently, we achieve this with overcommitting the volume size: if you have, say, 1 GB device, and you format it with a 3-volume Shufflecake setup, each of these 3 volumes will appear as 1 GB in size. Then the question is, what happens if you write more than 1 GB in total? Well, you will start receiving I/O errors. Volumes themselves will not get corrupted, because they will not clobber each other, but the kernel module will basically tell you "sorry, I ran out of space earlier than I expected".
A planned feature in the future, to manage this more elegantly, is to use "virtual quotas". With this system, low-secrecy volumes will have a limited size (chosen by the user), but the "topmost" unlocked volume (the "most secret one" that you have unlocked with a given password) will not have this limit: it will always appear as taking all the leftover space. See the section 6.5 "Use of Disk Metadata" in the research paper.
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!
[1] (in Italian) https://e-privacy.winstonsmith.org/e-privacy-X.html#i13
[2] https://research.kudelskisecurity.com/
[3] https://www.theregister.com/2010/06/28/brazil_banker_crypto_...
I will also reply to comments below.
Shufflecake is a tool for Linux that allows to create multiple hidden volumes on a storage device in such a way that it is very difficult, even under forensic inspection, to prove the existence of such volumes. You can consider Shufflecake a "spiritual successor" of tools such as TrueCrypt and VeraCrypt, but vastly improved.
You can consider Shufflecake a "spiritual successor" of tools such as Truecrypt and Veracrypt, but vastly improved. First of all, it works natively on Linux, it supports any filesystem of choice, and can manage up to 15 nested volumes per device, so to make deniability of the existence of these partitions really plausible. The reason why this is important versus "simple" disc encryption is best illustrated in the famous XKCD comic #538. You can read more about Shufflecake in this blog post [https://research.kudelskisecurity.com/2022/11/10/introducing...].
More in detail: Shufflecake allows creation of multiple hidden volumes on a storage device in such a way that it is very difficult, even under forensic inspection, to prove the existence of such volumes. Each volume is encrypted with a different secret key, scrambled across the empty space of an underlying existing storage medium, and indistinguishable from random noise when not decrypted. Even if the presence of the Shufflecake software itself cannot be hidden - and hence the presence of secret volumes is suspected - the number of volumes is also hidden. This allows a user to create a hierarchy of plausible deniability, where "most hidden" secret volumes are buried under "less hidden" decoy volumes, whose passwords can be surrendered under pressure. In other words, a user can plausibly "lie" to a coercive adversary about the existence of hidden data, by providing a password that unlocks "decoy" data. Every volume can be managed independently as a virtual block device, i.e. partitioned, formatted with any filesystem of choice, and mounted and dismounted like a normal disc. The whole system is very fast, with only a minor slowdown in I/O throughput compared to a bare LUKS-encrypted disk, and with negligible waste of memory and disc space.