Hey!
Instead of using an hidden volume for plausible deniability of the existence of an encrypted volume, wouldn't it be also possible to use a file container and and hide the file as something unremarkable?
The encrypted container can't distinguished from random. You could name it "004.dump" or "mem.log" to make it seem like it's just a blob of uninterpretable binary.
Are there any programs which generate big files of data which can't be distinguished from random afterwards?
Veracrypt file plausible deniability / cuckoo's egg
Other urls found in this thread:
forensicswiki.org
dyne.org
steghide.sourceforge.net
spin.atomicobject.com
golem.de
veracrypt.codeplex.com
ghacks.net
semanticscholar.org
security.stackexchange.com
xkcd.com
twitter.com
That usually means that it's an encrypted file.
>forensicswiki.org
I just tried that. You can use a hex-editor and add a few bytes to the end of the container. Both outer and hidden volume mount fine.
As already said, highly random data is suspicious. There are a handful of steganographic methods to hide a file in another file (simple example: in the low order bits of an image), but I have no idea how reliable these actually are.
The image steganography method doesn't work for larger files. Other methods might work but I don't know any.
I'm not denying that it looks weird. It's about deniability. I could for example claim that I did a programming project and (for some reason) dumped 10GiB of /dev/urandom into a file.
Also, after creating the container, you can override the not yet used part of the container with whatever not random data you want. Only the onset is going to look random.
The "only" way to have plausible denyability is to have a hidden volume unknown to the operating system and only recoverable and decrypted with various recovery tools. This inexplicably means the OS will write over your precious data without a second thought ( Which proves and guarantees the denyability of 'random data') Though no such system is usefull or achievable because said OS will instantly corrupt the data, on ssd's at least. HDD might work a bit longer.
The other, not completely denyable, way is to reflash SSD firmware to not register all blocks. Though I've never even tried something like that. Again. You can phisically see and guess the size of an ssd because part numbers and other markers. This is pretty much rp'ing as most authorities are inept at technology. even feds use relatively simple copy procedures for phones. They aren't trained in autismo linux masterminds and if they encounter one they'd just lock you up and toss the key once you start sperging out.
Best way is to use "cloud" storage and other storage servers because they can't plausibly prove you have given up all remotely owned data or not.
That's an important point, especially if you are in the US.
Pretty much. maybe if you have good defence lawyer then you'll be able to convince the judge/jury. Otherwise you'll convicted like that one "bitemark" expert who convicted hundreds on silly things like a bite out of a ham sandwich. and that exerp is almost literally the defence TPB gave upon the police seizing their servers.
OS will not accidentally destroy this, seems fairly deniable to me.
that doesn't look suspicious at all
Deliberately putting files into a unused paration is deniable? Are you brain dead?
Why do you think it would look suspicious? Just arrange things so it seems like they have some logic behind it, e.g. 256G drive. Partion 1: 0-20G, Partition 1: 32G to 256G. If anyone asks, say that you wanted to start the second partition at a power of 2.
You obviously have no idea how filesystems / storage works at a low level. What exactly do you think is wrong with my idea?
Forensics will image the whole entire disk, not just valid partitions.
This would be a great solution. You could just have a command to turn off and on the hidden data. When it's off it always just returns zeros or maybe an occasional one to make it look less suspicious. I doubt anyone would figure this out.
Why didn't the defense lawyer just make like ten people bite a sandwich, and see if the expert could identify them correctly?
It's not really suspicious to have random free space. Sometimes people delete a partition because they don't want it anymore, but don't have time to make a new one (with a new OS?). If they checked the secure erase box it will even be filled with random data. Viruses can do funky shit too.
I mean will the prosecution suspect it? They'll probably suspect everything you can think of and then some. But the standard in court is not what the prosecution suspects, but what is proven beyond reasonable doubt.
Because good legal counceling is expensive. And if im not mistaken, this "expert" wasn't an independent expert witness. Therefore he wasn't required to take the stand.
One way to do this with a degree of plausibility is to buy a drive bigger than 2TB and partition it with MBR, which is limited to 2TB. I've seen genuine cases of people who did this by mistake asking how they can use the missing space.
Just split the vc file into multiple rar files you dumb faggot. Then burn every separate rar file on a cd-rom and bury the cd-roms across the country.
Encase 8 is a popular forensic tool, when processing evidence unpartation space is one of the first things checked. Files don't just apear in the unpartation part of the hard drive, they can only get placed. It would stick out so much.
You're really retarded. You don't understand how retarded juries or judges are when it comes to tech. They can't understand technical matters so they can reach a verdict of guilty even you think you have plausible deniability.
How many times you explain it, they can't understand!
Whether or not how many times you explain it, they can't understand!
Just encrypt a couple of hundred files of various sizes on an ssd and when they ask about them just say some f&%^# virus you installed encrypted all my files and now I can't access them. ¯\_(ツ)_/¯
...
So it helps you be less degenerate too, great.
I'm going to let you try that again
That's just shooting yourself in your foot. Cops and media will be all over the "hundreds of encrypted files that he claims he lost the password to" You're basacally tying the rope around your neck yourself. Not that you larpers give a shit. everything for a (you)
When "they" ask questions, you don't answer. In the U.S., you have the right to remain silent, and it's really stupid to do otherwise unless a lawyer you trust says it's to your advantage to do so. Cops aren't on some kind of dispassionate search for the truth. If they've obtained a warrant to confiscate your electronics, they're there to fuck YOU in the ass by any means necessary. Don't acknowledge that the computer is yours (they'll successfully make that assertion anyway, if it's in your home/room), don't acknowledge that any of the files are yours, and don't say anything that indicates that you have any knowledge of anything that's on the hard drive. Don't say "Neener neener, I'm not going to give you my password!" Don't play coy and say, "Password? Why, what password, detective?"
DON'T
SAY
ANYTHING
Fucking zip it. Then it's their job to make their case, and if your lawyer knows what he's doing, he's going to make them look like fucking fools on the stand claiming that a bunch of garbage data that they don't have ANY information about (even the certainty that it's actually encrypted and not just random shit) is really leaded trade secrets/revenge porn/CP/whatever they're claiming it is.
This.
It has been the single most important piece of advice for years. Yet people are stupid and talk to cops. The cliche is actually true. No one is smart enough to talk to cops. Even fucking lawyers can screw this up.
Sure, don't talk to the cops. Your lawyer is the only one who talks to the law enforcement. Having a good alibi is better than not having one, tho.
That's why vc has hidden volumes. You can hand over the outer volume passphrase, but they can't prove the hidden volume even exists. Plausible deniability.
Yep, giving no information is better than anything else. You are not a trained interrogator. You may have seen some interrogation techniques but you are likely not familiar with them at all. Have on standard line "I plead the fifth" or "No comment" or whatever and answer EVERY question with it. From whats your mothers name to do you want coffee? It will be much, much easier for you to stick with almost automatically saying a single line over and over again in a very stressful interrogation than for you to keep a lie going. Even if you manage to keep the lie going, you really didn't gain much over simply giving them no information.
Remember its not the police that decide your case, its the court. There is nothing you will ever say to the police that will help your case when you get to court. A exception might be cases like a very clear alibi, which would stop them from pursuing the case against you in the first place. But even then, you should not bring it up in an interrogation. Know the exact time/date/place you have an alibi against, get your evidence and provide it to them afterwards. Say nothing in interrogation.
It is also a good idea to, if your lawyer isn't actually preset yet (for example a first, short interrogation, you likely do not have the funds to keep lawyers present at all time), record the complete interrogation. Especially if they do not know you did. This can be done for example with a smart watch or whatever that isn't too visible. This can help yourself afterwards to spot moments they are lying to you. Because they will likely try to make you break bonds with people you trust. Because you being angry at them means you are likely going to start saying stuff. They can and will lie if they think it will help. Never say anything.
It only provides plausible denyability for key storage. Not datastorage. see
storing keys in images is also the worst option. Many FDE software reserve multiple spaces for encryption keys even if you just use one. With keys being so small that has never been a problem.
No. Tomb is a key and a file based encryption system. You create a tomb of a particular size, you "tomb dig" the file, create it, create a compatible key for the file, and only that hidden key can open the hidden volume. You can also hide volumes and keys in different ways. Watch the video on the Tomb page.
also, it works with steghide, and steghide supports JPEG, BMP, WAV and AU files. So you can, theoretically, hide keys and "data" in songs too. Haven't tried that yet but that's what it claims on their page.
ive tired it and it still works for me
terminal command?
steghide embed -cf blah.jpg -ef sometextfile.txt -p password
your cover file has to be bigger then the file your going to put into it
thanks, I'll give it a try.
All kinds of errors, absolutely no results with steghide. Tomb works though, just no bury function.
never mind, found a way
I also found out, you can rename the tomb key file and the tomb files themselves, they become a text file, you can then rename them again and they will become their regular binary and apple keystone files respectively. Effectively disguising their own filenames and function in the terminal.
the best defense is not to have any data that matters in the first place.
use a vm configured to never write to disk, with the backing mounted read only, only writeable when you need to run upgrades or change configuration. many tor distro's have a live mode, whonix, tails, etc, or roll your own with an overlayfs or some other custom solution to create a live usb (which you can run in a VM), with no persistence.
if you have some cianigger shit you want to store don't do it on any electronics you have any physical contact with. mine bitcoin, with the miner's never touching a network that isn't tor, into a wallet that never see's anything outside of tor, (just change wallets everytime you make a purchase, mine only enough for the purchase before switching wallets). purchase a vps with bitcoin completely over tor and never connect to it outside of tor and store your files there. assuming you have reliable power this can be accomplished in live mode, with the wallet never leaving ram, never being written to disk.
worst case it can be proven only that your a tor user and you operate live VMs.
you should symlink as much as possible to /dev/null, including .bash_history. You won't loose it completely every terminal I've tried stores it in ram and only occasionally pushes to disk.
If you try to symlink all of /var/log to /dev/null you'll run into a bunch of problems, half of the software on the system depends on the directory structure there created during installation. Instead you can cp /dev/null to every file in /var/log with a simple script. cp will not change file ownership or permissions of the file exists already, so nothing will get messed up, or just cat > , does the same thing. In live mode it doesn't matter anyway but when you disable live to run configuration changes or upgrades logs will be created which should be deleted on shutdown before going into live mode again.
Wait a second, are you talking about USB's here?or Terminal commands to erase processed activity? (not a total noob, but still a braintlet at this).
I'm talking about both.
normally all your bash commands are saved in ~/.bash_history
this should be deleted and a symlink created in it's place to /dev/null
this way when terminal tries to save your command history it goes to nothing.
on a live cd/usb, or a VM configured in a "live" mode, it wouldn't matter anyway, because there's already something setup where all writes to root go somewhere else, a tmpfs or something, which doesn't persist anyway.
If your running a "live" mode VM, where you have to disable this live mode and actually have writes go to the disk for an upgrade, or you want to change your configuration occasionally , then having this symlinked is still a good idea, because it would be written to disk at that point otherwise. If it wasn't symlinked then when you turn live mode back on, the shit is still on the disk, it just won't get updated; ie the last command you ran in non-live write mode will be in .bash_history. nothing you do in live mode will be written to disk, but everytime you reboot your still going to have the last shit that happened the last time you turned live mode off, bash_history, anything in /var/log, etc. This is why it's a good idea to symlink as much of this shit as possible with /dev/null, and overwrite everything else you can't on shutdown.
news to me...
got a terminal command for it in ubuntu?
this type of setup probably isn't practical for everyday use, but if you restrict all your network activity that you would want to be private, which should be everything possible short of your bank account and other official things where your name is attached already, it would be a good idea.
think of it like torbrowser+
instead of just using tor browser, you run tor browser in a VM that is configured to write nothing to disk, it operates completely in read only mode on the backing drive. The operating system couldn't write anything to disk even if it wanted too, because the hypervisor has the disk set to read only. If there's some kind of fuckup or exploit in tor browser, then it's irrelevant unless it can escape the VM. It can't write to disk, it can't read anything outside of the VM, and nothing inside of the VM is relevant anyway, because it's nothing but non-persistent data, practically no different than the day you created/installed it and turned live mode on.
ideally you would have two VMs, one for the workstation, which runs tor browser, and another for a gateway, which runs tor; ie a Whonix style setup. The workstation should never see a network that isn't tor, it should be configured to only be able to communicate via an internal network with the gateway VM. All connections will fail otherwise, even without a firewall, because there is no NAT on the gateway, and that's all it sees. (you should have firewalls on in addition anyway, why not). Anything that wants to make a connection on the workstation VM would have to have a tor socks port specified on the gateway VM as a proxy (including tor browser). This has the effect of actually run tor over tor with tor browser, but it doesn't make much of a difference speed wise. To run tor browser in the workstation VM, you must tell tor browser to use a socksport as a proxy (which is a tor socks port running on the gateway VM), or it won't be able to make any connections.
ubuntu actually makes it super easy to roll your own live-VM.
look into overlayroot
there's a decent guide on it here
spin.atomicobject.com
there isn't a lot of documentation on how to use overlayroot to cover the whole system root directory, with with gentoo/arch wiki's. overlayroot just does it, but it's only for ubuntu. on gentoo/arch based systems you would have to modify the init or initramfs yourself to play a bunch of games at boot time to make this happen.
overlayroot works great even with lvm and encryption going on.
Once it's setup and you follow that guide, you'll get two boot options, one you can write too, and one where you can't, it's live mode (the default option will be live mode you have to add the write-mode yourself). Add whatever shit you want, configure it how you want in write mode, then clear all the logs you can and go back into live mode for actual work. In live mode with this overlayfs you can lock the drive in the hypervisor (virtualbox, virt-manager/qemu etc) into readonly mode and everything will still work fine. If you try to do this in write mode half of the system will fail.
Simply mounting / as read only with fstab is not going to work out well, nothing on the system was designed to operate that way, which is why even livecd's or liveusb's for distro's are using overlayfs, (or aufs, another overlayfs type filesystem that linus rejected in favor of overlayfs).
I appreciate the details. I don't use Tor anymore, just turn it on occasionally to see what people are talking about. I have it on Icecat and don't really use Icecat much either. But yeh I see what you're saying about VM use. Only time I use proxy is i2p and that thing is slow for a while, real slow, hardly anything to do there anyway. What I'm really interested in now is the comeback of p2p like the old days of WinMX, Kazaa, and Limewire. With programs like Tixati and Fopnu, but hardly anyone is really using them, I guess most people prefer IRC or sumn.
You know anything about serpent cipher? Or how to use it in some amateur way? Just to see what it can do I guess.
Thanks again.
I meant to say there isn't a lot of documentation about how to use "overlayfs" to cover the whole system root directory.
There aren't any neat wiki articles on it anyway. Everything I've read says this must happen at boot time, either in the init, or inside of the initramfs, early boot. You can't remount root after the system has already booted, it has to be done early in the boot cycle. This means on anything but ubuntu, on arch/gentoo, you have to fuck with the init scripts directly and it's more than I've had time to mess with.
overlayroot on ubuntu just does it. it can be used for more than just making a non-persistent mode by sending all changes to the filesystem to a tmpfs. You can use it to instead save the persistence somewhere else, some encrypted disk if you want to deal with that. You could have a base install and then a considerably smaller "persistence" file stored somewhere else, a usb drive, etc; which is how some distro's do persistent livedvd's. You boot with the livedvd and then any deviation you made from the livedvd (new packages, configuration files etc) are saved on a usb drive.
i2p is dead. you should use tor for all internet traffic that doesn't have your name attached to it.
jews are selling your internet history for profit
cryptsetup will do it but it depends on the kernel for the crypto, the kernel must be compiled with serpent enabled, it's an option but if you didn't compile the kernel yourself it might not be enabled.
cat /proc/crypto | grep serpent
if it doesn't spit anything out then recompile the kernel with serpent enabled.
I don't know how great it is or isn't. I use AES as the first level for anything, because it's free; all processors that aren't ancient support hardware accelerated AES. It might be backdoored but who cares, you can always stack more crypto on top of it, treat the first level of crypto as anti-nigger crypto not anti-cianigger crypto.
Tor is literally run by jews, if they're not looking though clearnet activity, they're over on Tor. Definitely got their noses in the bitcoin market.
And yeah, serpent cipher is real difficult to crack.
wiki: All publicly known attacks are computationally infeasible, and none of them affect the full 32-round Serpent. A 2011 attack breaks 11 round Serpent (all key sizes) with 2116 known plaintexts, 2107.5 time and 2104 memory (as described in [1]). The same paper also describes two attacks which break 12 rounds of Serpent-256. The first requires 2118 known plaintexts, 2228.8 time and 2228 memory. The other attack requires 2116 known plaintexts and 2121 memory but also requires 2237.5 time.
This, is interesting to me.
corrections here
ln -s /dev/null logfile
gave me this
ln: failed to create symbolic link 'logfile': File exists
overlayroot didn't work for me either. perhaps there's something I gotta remove or fine tune.
that's because it already exists, logfile is just for demonstration purposes
here is a better demonstration of how symbolic link works
#create a test file with some textecho "i'm a nigger" > testfile#create a new symbolic link of the testfileln -s testfile symfile#read the symfilecat symfile#it should read "i'm a nigger"#write to symfile and then read the testfileecho "i'm really a nigger" >> symfilecat testfile#notice writing to symfile actually wrote to testfile#write to test file and read symfileecho "i'm really really a nigger" >> testfilecat symfile#notice what you wrote to testfile shows in symfile
a symlink is like a windows shortcut, only you can read and write to it.
it's
ln -s target_file symlink_to_file
if logfile already exists it's because you created it, delete it and try again.
if your trying to do bash history it's not logfile, it's ~/.bash_history, or /home/your_user_name/.bash_history
read the article, overlay root takes some configuration, just installing it doesn't do anything out of the box, which is a good thing because if it did and you haven't modified your grub to allow you to boot into a writeable mode, you would be fucked and have to boot with a live usb and mount the hard drive to unfuck it.
Surely the FBI has software that searches all your files or possibly the entire partition for Veracrypt headers so hiding the file is no good.
Talking about headers - a little reported upon vulnerability was found in Veracrypt and Truecrypt a few years back during some big audit.
It turned out that hidden volumes were not hidden at all, one simply had to check if there were two headers at the beginning of the file instead of just one m(
lol, do you have a source on this?
This is where I got it from. Usually they just post sponsored content but they were the only ones who mentioned this:
golem.de
There is a link to a relevant discussion in the article:
veracrypt.codeplex.com
Also random search result:
ghacks.net
those commands worked, the bash log deletion thing, not so much. I'll keep trying to see if I manage to do it without totally bricking my stuff.
I actually began browsing around and found this_
sudo gedit .bash_history
(then your password)
You can manually remove it from the bash file this way.
A hidden vloume is the best way to get plausible deniability. Do you wanna go to jail?
HAPAS ARE SUPERIOR TO WHITES
Later I discovered that bleachbit performs this task and even destroys ram data so, heh.
HAPAS ARE SUPERIOR TO WHITES
HAPAS ARE SUPERIOR TO WHITES
HAPAS ARE SUPERIOR TO WHITES
Masons, Masons everywhere...
This is a slide thread. SAGE AND REPORT
I love Black women. They are so dominant and masculine!
LOL, I wish I thought of doing that!
bruce schneier described serpents as a tank, in comparison to other encryption algorithms
makes you thin why rinjdael won the contest, when security wise serpents is superior
some are cute too
The AES competition was pretty transparent. Rijndael won out for performance reasons and was widely considered pretty good all around. Schneier certainly doesn't have a problem with AES. Do any professional cryptographers?
This might be interesting to you.
He said no such thing, he never had it to begin with. And the primary reason noone will bother is that it's just a collection of appropriately named public domain :') old films that got encrypted. or something in that order.
security.stackexchange.com
on the subject of cipher and hash
so in a theoretical situation where you are a judge and you're trying to understand all this what do you do?
There's a good reason too: /dev/urandom is slow-ish and sometimes you need fast even if non-new randomness.
On the other hand, this whole thread is xkcd.com
I'd like to use hidden volumes when it comes to CP.