 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>> Also, if the investigators fill with true random bits the sections that you
>> have encrypted, before turning it over, can you sue them for lost data?
>
> But then, how do they know that they are overwriting encrypted data?
> They have no way of proving that a certain file is actually encrypted
> rather than containing some data used by some program.
>
> They might as well destroy all your files. Do they perform such a
> vandalism?
I guess he meant writing stuff onto space allocated as free. That will
destroy any hidden partitions.
--
"Auntie Em: Hate Kansas. Hate You. Took Dog. -Dorothy."
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawaz org<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> history -c is your friend....
Doesn't work on zsh.
--
"Auntie Em: Hate Kansas. Hate You. Took Dog. -Dorothy."
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 13 Oct 2008 17:09:29 -0500, Mueen Nawaz wrote:
> Jim Henderson wrote:
>> history -c is your friend....
>
> Doesn't work on zsh.
One good reason not to use zsh, then. I've never used it, I tend towards
tcsh myself.
So you got me curious - so a few seconds in zsh and a look at the man
page and found the following: RCS is set, then the history file isn't
saved.....If it's unset, then the history file is saved.
You also have the option of wiping the .zsh_history file.
So even then there's an out, you just need to know the environment you're
working in well enough to protect yourself.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz <m.n### [at] ieeeorg> wrote:
> Warp wrote:
> >> Also, if the investigators fill with true random bits the sections that you
> >> have encrypted, before turning it over, can you sue them for lost data?
> >
> > But then, how do they know that they are overwriting encrypted data?
> > They have no way of proving that a certain file is actually encrypted
> > rather than containing some data used by some program.
> >
> > They might as well destroy all your files. Do they perform such a
> > vandalism?
> I guess he meant writing stuff onto space allocated as free. That will
> destroy any hidden partitions.
They would have to decrypt the main partition first.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz <m.n### [at] ieeeorg> wrote:
> If he navigated to the directory where it was mounted recently, that'll
> show up in the history, and may give clues to its content. This will
> give them a strong indication that there is a TC volume somewhere, and
> they could ask him about it.
Just because you have navigated to a directory doesn't mean the directory
was a TrueCrypt mount. It could have been anything.
After you unmount from TrueCrypt you could execute a "rm -rf *" inside
that directory (so that that command is stored in your command history)
and simply say that you deleted all the files from there.
> >> Or they could look to see if you have truecrypt installed.
> >
> > Still doesn't prove that you have encrypted files. You could simply say
> > that you installed it a long time ago just to see how it works, or whatever.
> Won't work if you navigated into it recently (command history).
Starting TrueCrypt does not prove you have encrypted files. Besides,
command histories can be easily deleted, if you are so worried about them.
> > Then use FAT? What's the problem?
> Not obvious to folks on Linux that they shouldn't use ext3 on a TC
> volume. Last I checked, the docs didn't imply additional security if you
> use FAT.
Last I checked, the TrueCrypt documentation clearly stated why you should
use FAT as the file system, and why it is the default when nothing else is
specified.
> > AFAIK TrueCrypt puts random garbage at every free block for the precise
> > reason that it's impossible to tell whether it's just that, random garbage,
> > or a hidden partition.
> Yes, but I think you miss my point. Or I don't understand how things
> are stored on the HD.
> The area occupied by the hidden partition will have random stuff in
> it, but will appear to be "free" space by the FS (as in space available
> for writing). A contiguous block of 10 GB, especially with actual data
> around it, will look suspicious. Regardless of whether that space has
> random data.
What do you mean "actual data"? Of course all the sectors will have "data".
The ones which are free will have random garbage (or a hidden volume).
There's no way of telling if that data is just random gargabe or something
else.
> It's as if you just deleted 10 GB worth of contiguous material.
> Possible, but not likely.
How about you simply created the volume and added some files to it?
The rest of the volume will be unused.
> Of course, they can't *prove* anything with what I'm saying. And if you
> think you could get into real trouble, it is of course better to just
> deny. However, there is a risk in lying, and if you really don't have
> much to hide, that risk can be quite high (at least in the US - say when
> you're crossing the border).
Well, good luck for them to prove that you are indeed lying.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz wrote:
>> Actually, the case is new enough that I didn't find any appeals that
>> would make it actual precedent, so I suspect it's still up in the air.
>
> It's happened once or twice in the US.
>
> http://yro.slashdot.org/article.pl?sid=07/12/15/1459243
That's the same US Magistrate Judge. That isn't a precedent.
Case law becomes precedent only *after* you appeal and win.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:48f38e44@news.povray.org...
> somebody <x### [at] ycom> wrote:
> Except that TrueCrypt is open source. That more or less ensures that it
> doesn't do anything behind the scenes.
Fair enough, didn't check that first. Although, OS alone does not of course
ensure anything in principle. There's much OS out there which I doubt more
than one person ever looked at the source. Depends on how many developers
are actually working on it. Also, the backdoor may not be visible in the
code. It's possible to develop a novel encryption scheme for which only you
know the weakness. It may take a while for others to discover the problem.
> > Also, if the investigators fill with true random bits the sections that
you
> > have encrypted, before turning it over, can you sue them for lost data?
> But then, how do they know that they are overwriting encrypted data?
They don't need to know. They can low level fill all unused sectors.
> They have no way of proving that a certain file is actually encrypted
> rather than containing some data used by some program.
Neither can you claim they wiped your data then.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
somebody wrote:
> Fair enough, didn't check that first. Although, OS alone does not of course
> ensure anything in principle. There's much OS out there which I doubt more
> than one person ever looked at the source. Depends on how many developers
It's a well known product. You might as well not trust gpg, pgp, or
anything else you don't code yourself.
> are actually working on it. Also, the backdoor may not be visible in the
> code. It's possible to develop a novel encryption scheme for which only you
> know the weakness. It may take a while for others to discover the problem.
They use, or at least offer, standard well known encryption schemes
(assuming you mean algorithms). Stick to those if you want to be safe.
>>> Also, if the investigators fill with true random bits the sections that
> you
>>> have encrypted, before turning it over, can you sue them for lost data?
>
>> But then, how do they know that they are overwriting encrypted data?
>
> They don't need to know. They can low level fill all unused sectors.
I'm not sure you get it.
I can create a file (call it outer) that is a container for my
encrypted stuff. Within it, I can create another hidden container.
The hidden container appears to be unused space only after you decrypt
the outer container.
If you don't decrypt outer, then the whole space outer appears as a
file - not as an unused sector. The idea is that if someone does not
know that the file outer is actually an encrypted container, then that
someone will not be able to figure it out. It looks just like any other
data file.
So unless they actually decrypt something first, the technique you
describe will only delete stuff that had already been deleted, so to
speak, and of little relevance to anyone.
--
DO NOT REMOVE THIS TAG (UNDER PENALTY OF LAW)
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Just because you have navigated to a directory doesn't mean the directory
> was a TrueCrypt mount. It could have been anything.
You're looking at it from an inverted viewpoint. When they look at the
computer, they're not going to start with "Does he have a truecrypt
container?".
They'll likely browse your command history, and find something of
interest in a given directory. They navigate there to see it is empty.
Fine - let's say the person always did a rm -rf *. But they see you
repeatedly accessing stuff there time after time. It may raise eyebrows.
Not proof of anything, but perhaps enough to warrant a questioning.
> Last I checked, the TrueCrypt documentation clearly stated why you should
> use FAT as the file system, and why it is the default when nothing else is
> specified.
I don't see it in their online docs. They mention you can do NTFS and
FAT, but a quick glance did not show any discussion on what you should
use. And as the docs are quite geared towards Windows, one could get the
impression that it just has NTFS and FAT to target that audience. I
don't think they actually suggest anywhere *not* using any other FS.
(Edit: I just saw in the section about hidden containers that it says
not to use a journaling FS).
>> The area occupied by the hidden partition will have random stuff in
>> it, but will appear to be "free" space by the FS (as in space available
>> for writing). A contiguous block of 10 GB, especially with actual data
>> around it, will look suspicious. Regardless of whether that space has
>> random data.
>
> What do you mean "actual data"? Of course all the sectors will have "data".
> The ones which are free will have random garbage (or a hidden volume).
> There's no way of telling if that data is just random gargabe or something
> else.
See figure at http://www.truecrypt.org/docs/hidden-volume.php
Let the total area be 30 GB, and the hidden container be 10 GB.
You start off with nothing in either. You just created it.
So you slowly add stuff to both, as time goes by.
If anyone were to decrypt the outer container, they'd see at least 10
GB (typically more) of unallocated space. It has random bits in it, but
the FS reports it as available.
The 10 GB used by the hidden container, if contiguous (which I suspect
it is), will always appear as a 10 GB contiguous block of free space
when you decrypt the outer container.
A 10 GB contiguous unallocated block in a 30 GB partition is not
expected to exist over a long period. It's expected that one writes a
lot, and deletes a lot, resulting in fragmentation. The remaining 20 GB
will appear fragmented, but that 10 GB will always appear available,
with the FS reporting no data there.
Sure, it will have random bits, but nevertheless, it will all be one
contiguous, unallocated block.
How much this matters depends on your usage. If you just keep 1 GB of
stuff in the outer container, then this may not look weird.
I may be stretching, but I don't think I'm wrong. You pick your level
of paranoia as a user. When it comes to those who design the software,
though, they have to assume worst case scenarios.
Perhaps I'm totally wrong. I don't see a flaw, though. The following
page gives some precautions:
http://www.truecrypt.org/docs/hidden-volume-precautions.php
Frankly, the trouble I'd have to go through to follow all the advice on
that page is not worth it. I'm quite content at not trying to hide TC
(or any similar system) usage, and I'm more concerned about
non-law-enforcement accessing stuff on my HD (e.g. someone visiting my
house so that he cannot see financial records).
> Well, good luck for them to prove that you are indeed lying.
Interrogations can be surprisingly effective. Even the ones where they
don't do anything illegal.
--
DO NOT REMOVE THIS TAG (UNDER PENALTY OF LAW)
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> You also have the option of wiping the .zsh_history file.
True.
> So even then there's an out, you just need to know the environment you're
> working in well enough to protect yourself.
Yeah. Frankly, I don't yet have anything to warrant the inconvenience
of hiding TC (or any similar system) usage. But good to know the options
are there...
--
DO NOT REMOVE THIS TAG (UNDER PENALTY OF LAW)
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
