Silk Road forums
Discussion => Security => Topic started by: truVeel on November 13, 2012, 07:05 pm
-
Hey hey.
I'm new here, obviously. I have been lurking, learning and thinking.
TrueCrypt is great. It works. people use it. Hidden volume is cool, too. I understand how it works from a higher level, but I may very well have many things wrong. Fair warning.
The encryption algorithms that TC uses have not yet been broken. A brute-force attack on the encrypted data is not feasible and I believe most would find it to be a worthless endeavor and give up even before beginning. Right?
So the usual method of cracking an encrypted file is to crack the password. TC uses a salt and user-entered password to generate the key and decrypt the container, right?
By using a salt, an attacker cannot use a pre-generated hash table. The attacker has to generate the table by using the specific salt of the encrypted container that the attacker wishes to crack, right?
The first 64bytes of the TC container contains the salt. So an attacker can use that salt to generate the hash table when brute-force attacking. This seems like no big deal, since the time it takes to run through every iteration of a strong password is too long for a feasible attack. However, it is possible for the attacker to get lucky and get the right password within a short time.
That scenario is what worries me a little bit.
I was a-thinking and then I thunk, "Hey. Why not cut the salt from the TC header and store it in another encrypted contatiner on a separate drive?" That way, an attacker would have to break the password of the container containing the salt and then use the salt to break the password of the container to which the salt belongs. An attacker would unlikely be so lucky as to break both strong passwords within a short time.
A script could be written to add the salt back on to the container's header file, reducing the amount of work needed to access the container.
Does this make sense? Is it flawed in some way that I have overlooked?
Could the container be cracked even without knowing the salt? I assume the answer is 'yes' , but I do not know if this causes any more work for an attacker. My guess is that it does.
What are your thoughts?
EDIT:
I did some more thinking and if I'm going to go through all of the trouble of modifying the header, I should really just go for the master key. If I copy the master key data, store it somewhere else and then overwrite the data on the TC container with random data, the TC container wil be unopenable. Only a full crack of the encryption scheme would do the trick.
I was also thinking, why not just nest TC containers. Create an outer container with a unique password and then, within the outer container, create another TC container with a unique password. This would mitigate the likelyhood of an attacker cracking both strong passwords within a short time.
I have seen a bit of discussion around the clearnets about these methods, but most of the time the ideas are dismissed as pointless and the converstaion is steered in a direction dictated by those calling the idea pointless. It usually ends up being about how you shouldn't worry about this attack vector because you should be more worried about having a truly random password of sufficient length and how passphrases are so much better (but they just said random was the best) and how keyloggers are the monster under your bed and that's what you should be afraid of and your're dumb for thinking otherwise. Also, the resources it would take to break AES are so tremendous that it's totally, absolutely impossible to break and so long as your random passphrase has the same bit-strength as your encryption algorythm, an attacker will always be foiled.
There are many points to be considered and a lot of good advice in those responses but the question never gets answered.
What I want to know is whether there is any weakness introduced that would not otherwise exist by nesting TC containers.
I would also like affirmation of my hypothesis that removing the TC master key from the TC container's header would remove any attack vector other than directly cracking the encryption scheme.
Also remember that I am most worried about the statistical anomaly that would cause a strong password to be cracked within a short time. That is what is driving the ideas presented.
I will surrely continue my own search, but if anyone has any info, it would be greatly appreciated.
-
i need to keep a eye on this as its a good question
-
Ask bruce schneier ? very interesting question..
-
I decided to go for the first 131072bytes of the TrueCrypt container (the whole header). I have successfully cut the header off and pasted it back on. There was no loss of data.
When the header was cut off, TC could not decrypt the container.
Additionally, I tried creating two containers with different passwords and put container1's header on to container2 and vice versa. Container1's password then was accepted by container2. However, since the data in container2 was encrypted with a different key than that which was included in container1's header, the data was not decrypted and TC returned an error stating that a filesystem had to be specified.
This brought up some interesting ideas.
If no filesystem is specified during the creation of a TC container, the empty space will be filled with random data. To a third party, this random data is indistinguishable from encrypted data.
Let's say we have two TC containers, tcc1 and tcc2.
The passwords and master keys are wholly different from each other.
tcc1 contains encrypted data. It's pw is: USEFUL
tcc2 contains only useless, random data. it's pw is: CRAP
When the pw USEFUL is used on tcc1, the data is decrypted, the filesystem is mounted and the data contained can be used as needed.
When the pw CRAP is used on tcc2, TC tries to decrypt the data, but since there is no filesystem or any usable data, an error returns stating that a filesystem must be specified.
Now if we replace tcc1's header with tcc2's header, tcc1 will now be decrypted with the pw CRAP. TrueCrypt will accept this pw and believe that it is correct, however when the data is decrypted, the master key will be incorrect and so the data will appear to be useless, random data. TC will return an error stating that a filesystem must be specified. We know that there actually is good data stored there, but TC doesn't. It bcomes hidden by attaching the wrong header.
If we do the same thing for tcc2, it will be decrypted using the pw USEFUL. Again, TC will accept the pw and believe it to be correct. Since the data appears to be random (and actually is this time) the same error will return stating that a filesytem must be scpecified.
I see this method as another layer of deniability and/or secrecy.
Say I have some old hdd's laying around. I want to overwrite the old data on them. The data is mainly some freaky porn that I used to be in to but now I'm not and I don't want my wife to see it one day and think that I'm still in to that stuff. So I use TrueCrypt to make the whole drive into a TC volume. When it asks for a password to use, I just mash the keyboard a few times because I don't need to rememebr what I enter. I'm just trying to overwrite old data. So I continue with the wizard and when it asks what filesystem I want, I specify 'None'. Again, I do this because I am just using TC to overwrite old data. At the end of the process I have a hdd filled with random data and a TC header on the front. If the correct pw was ever somehow enetered, TC would return an error stating that a filesystem must be specified.
Now let's say I take a hdd and use TC to turn the whole thing into an encrypted volume but this time I actually want to store my SR and BTC info on it. I go through the volume creation process, remember the pw I enter and specify a filesystem. Now I have a useable TC volume where I keep my secret data. If I put a different header on there, then it would be impossible to tell whether this drive has real data or if it's just another old hdd that I have laying around.
There are a few other variations on this, but you get the idea.
-
EDIT:
I did some more thinking and if I'm going to go through all of the trouble of modifying the header, I should really just go for the master key. If I copy the master key data, store it somewhere else and then overwrite the data on the TC container with random data, the TC container wil be unopenable. Only a full crack of the encryption scheme would do the trick.
That's what I was going to suggest as I was reading the first part of your post. Why not store the encryption key on a USB thumb drive? I believe TC already has a tutorial for that, or you can find them on the internet.
I decided to go for the first 131072bytes of the TrueCrypt container (the whole header). I have successfully cut the header off and pasted it back on. There was no loss of data. When the header was cut off, TC could not decrypt the container.
Are you using dd to make a bit for bit copy? And how are you "removing" it, just zeroing it out?
Additionally, I tried creating two containers with different passwords and put container1's header on to container2 and vice versa. Container1's password then was accepted by container2. However, since the data in container2 was encrypted with a different key than that which was included in container1's header, the data was not decrypted and TC returned an error stating that a filesystem had to be specified.
This brought up some interesting ideas.
If no filesystem is specified during the creation of a TC container, the empty space will be filled with random data. To a third party, this random data is indistinguishable from encrypted data.
Let's say we have two TC containers, tcc1 and tcc2.
The passwords and master keys are wholly different from each other.
tcc1 contains encrypted data. It's pw is: USEFUL
tcc2 contains only useless, random data. it's pw is: CRAP
When the pw USEFUL is used on tcc1, the data is decrypted, the filesystem is mounted and the data contained can be used as needed.
When the pw CRAP is used on tcc2, TC tries to decrypt the data, but since there is no filesystem or any usable data, an error returns stating that a filesystem must be specified.
Now if we replace tcc1's header with tcc2's header, tcc1 will now be decrypted with the pw CRAP. TrueCrypt will accept this pw and believe that it is correct, however when the data is decrypted, the master key will be incorrect and so the data will appear to be useless, random data. TC will return an error stating that a filesystem must be specified. We know that there actually is good data stored there, but TC doesn't. It bcomes hidden by attaching the wrong header.
If we do the same thing for tcc2, it will be decrypted using the pw USEFUL. Again, TC will accept the pw and believe it to be correct. Since the data appears to be random (and actually is this time) the same error will return stating that a filesytem must be scpecified.
I see this method as another layer of deniability and/or secrecy.
Say I have some old hdd's laying around. I want to overwrite the old data on them. The data is mainly some freaky porn that I used to be in to but now I'm not and I don't want my wife to see it one day and think that I'm still in to that stuff. So I use TrueCrypt to make the whole drive into a TC volume. When it asks for a password to use, I just mash the keyboard a few times because I don't need to rememebr what I enter. I'm just trying to overwrite old data. So I continue with the wizard and when it asks what filesystem I want, I specify 'None'. Again, I do this because I am just using TC to overwrite old data. At the end of the process I have a hdd filled with random data and a TC header on the front. If the correct pw was ever somehow enetered, TC would return an error stating that a filesystem must be specified.
Now let's say I take a hdd and use TC to turn the whole thing into an encrypted volume but this time I actually want to store my SR and BTC info on it. I go through the volume creation process, remember the pw I enter and specify a filesystem. Now I have a useable TC volume where I keep my secret data. If I put a different header on there, then it would be impossible to tell whether this drive has real data or if it's just another old hdd that I have laying around.
There are a few other variations on this, but you get the idea.
That's pretty advanced. :) I assume you'd write a script to automate switching the headers before and after use.
-
EDIT:
I did some more thinking and if I'm going to go through all of the trouble of modifying the header, I should really just go for the master key. If I copy the master key data, store it somewhere else and then overwrite the data on the TC container with random data, the TC container wil be unopenable. Only a full crack of the encryption scheme would do the trick.
That's what I was going to suggest as I was reading the first part of your post. Why not store the encryption key on a USB thumb drive? I believe TC already has a tutorial for that, or you can find them on the internet.
Yea, I was thinking to store the header on a mobile or even disposable/easily-destroyable medium.
I decided to go for the first 131072bytes of the TrueCrypt container (the whole header). I have successfully cut the header off and pasted it back on. There was no loss of data. When the header was cut off, TC could not decrypt the container.
Are you using dd to make a bit for bit copy? And how are you "removing" it, just zeroing it out?
Yep. This is how it goes:
dd if=/dev/sdb of=tc_hdr1 bs=131072 count=1
Then to remove the header:
dd if=/dev/zero of=/dev/sdb bs=131072 count=1
You could also specify the header of another TC container for the input instead of zeros.
This also works with head, tail and cat, btw.
dd is much easier, though.
That's pretty advanced. :) I assume you'd write a script to automate switching the headers before and after use.
Yea I probably would, but the dd commands are quick and easy enough. I could just alias them, too.
-
You seem to know what you're doing, so let me ask your opinion.
I believe that encrypted volumes (files, partitions, external media) are not as safe as full disk encryption. Information about the contents of those volumes can leak onto the unencrypted drive. In your example, playing FreakyPorn.avi with VLC would put the path of that file in the Recent Media list. At least with VLC you can disable it, but with a lot of programs you can't. So if you open WhistleBlowerEvidence.doc, the path to that will be in Recent Documents in Word. That's just one way data can leak. Browsing the FreakyPornPics folder with a file manager can put thumbnails on the unencrypted drive. That is why I don't believe encrypted volumes are safe, and I prefer FDE.
-
Very true. All of those examples are paths to revealing one's secrets.
Full Disk Encryption takes care of that problem, but only so long as the computer isn't booted up. I'm sure you are aware of that, however.
My approach is to do the activities I want kept secret ONLY on a live cd. No unencrypted hdd's or other media are connected to the computer while doing those activities. The only time that a trace is left is when I want it to be left on the encrypted hdd or media.
I advocate separating all secret activities and information from any public activity and information. So FDE is fine, but it's a good idea to use that system either for secret activities or public activities; not both.
Also, by straying from the quick-and-easy route, I find it's easier to ensure I take the proper precautions with my anonymity and don't get lazy.
-
Yeah, admittedly I just find it inconvenient to reboot all the time, but it would be safer to use a bootable distro on a CD or a VM with FDE and to not have it running when you're not using it. At least I turn it off when I leave the house. But encrypted volumes are the least safe.
-
But encrypted volumes are the least safe.
Agreed.
Thanks for the +1, btw. I assume that was you.
-
It was me, your posts are hard to follow but very interesting. Keep 'em coming. :)