Then you could count the number of blocks currently assigned to visible files and if that differed greatly from what you came up with, you could infer that there are lots of blocks assigned to hidden files. For example, in the presented form, this doesn't work so good because you can immediately see how many blocks were allocated. The idea comes with a number of problems. So you don't need to worry about overwriting hidden files as long as there is still free space on the disk. This means that you won't ever allocate a block that's already used as long as there still are free blocks on the disk. This is impossible to avoid.īut there may be methods to make sure that the files only start to get overwritten after you copied the first 999 GB to the disk.Ĭonsider the following block allocation scheme:Whenever your file system requests a free storage block, a counter gets incremented and the counter determines which block to allocate. If you have, say, 1 TB of space, and you have 1 GB of hidden files stored in it, then no matter how good the system is, if you write 1 TB of files to the disk, your hidden files will get overwritten. If you DON'T want to provide all the relevant passwords, then it becomes much, much harder, and file system efficiency will suffer greatly.įirst, you'll have to agree on an important point: The file system storage space is limited. A very simple way to come up with stable disk storage locations based on passwords is by using hash functions - hash a password, or any other combination of identifiers, and get a stable number, which you can use as a pointer to a disk storage block. This is from your question in the comments:īasically my biggest question was whether you can derive the place to store the file given the password, and somehow there would be a function that would allow you to find a free spot, yet would not reveal used spotsĪgain, if you provide the system with all the relevant passwords, this is easy. So you can easily construct a steganographic filesystem which doesn't lose your files - but in order for the filesystem to not overwrite them, it needs to know where they are, and this can only be achieved if you tell it the necessary passwords/passphrases before starting to work on the file system. StegFS is only lossy if you don't provide it with the passwords to all the security levels you're using. There are more the TrueCrypt manual explains some of them. You can protect the "inner" or "hidden" volume from being partly overwritten if you have access to it. They work by embedding a hidden encrypted container inside an encrypted container. TrueCrypt and it's successor VeraCrypt support hidden volumes. Is it possible to implement a system with plausible denyability that is at least as strong as accepted cryptographic primitives (AES-CBC, SHA1-HMAC, e.t.c.) yet is not a lossy filesystem? One can just 'decrypt' any file name (existent or non-existent) with any random key and you will end up with something. *) I'm not saying exist here, because technically they do exist. So the main question is - is it possible to implement a system with plausible denyability that is at least as strong as accepted cryptographic primitives (AES-CBC, SHA1-HMAC, e.t.c.) yet is not a lossy filesystem? However, there is one disadvantage - these systems (at least StegFS) tend to achieve this by become lossy filesystems. In other words one can plausibly deny that any other keys save the ones he/she provided were used*. As far as I can see (at least in the case of StegFS) infeasibility of determining how many keys are used and how much content is encrypted with different keys is achieved to the extent that it is as strong as the cryptographic primitives involved - it really is infeasible to determine the number of different files encrypted with different keys and how many keys even exist in the system. Recently I've been having a look at some interesting stenographic filesystems such as RubberhoseFS and StegFS.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |