|
List Info
Thread: Encrypted livecd's - need testers
|
|
| Encrypted livecd's - need testers |
|
2007-06-28 06:48:48 |
Hi,
I think I just finished including encryption in Catalyst
(for livecd's).
However this is only my second patch ever, I screwed up my
first one
with bugs, and even though I tested this a lot this time, it
wouldn't
hurt some more feedback.
Patch the svn with
http://mega.ist.utl.pt/~nhqb/gentoo/catalyst/
catalyst_luks_02.patch
Documentation is in the livecd-stage2 example.
Use the linuxrc below and choose 'manual' mode ('keyfile'
mode requires
http://
bugs.gentoo.org/show_bug.cgi?id=162962). Hopefully this
will be
the default genkernel linuxrc.
http://mega.ist.utl.pt/~nhqb/gentoo/catalyst/linuxrc
Cheers,
Nelson
--
gentoo-catalyst gentoo.org mailing list
|
|
| Re: Encrypted livecd's - need testers |
|
2007-07-01 04:13:26 |
|
Hi,
I'm confused about why an encrypted livecd would be an interesting feature.
Indeed if encryption is about protection, then I just see 2 ways the livecd cd user can be attacked.
- while using the OS (real time personal information handling, like login to
gmail.com)
- after using the OS (like leaving some kind of history somewhere)
if you consider this, what is the benefit of having the OS encrypted in memory? What kind of attack can be stopped by having encryption rather than a clean OS?
From the network point of view, nothing changes, I do not see any advantages nor differences.
From the system point of view, as a livecd needs no HD, where would a clear OS leave some trails or history? Can we reverse magnetic fields of RAM devices?
I'm really interested in such topic, please could you explain some scenarios of use/setup in which an encrypted livecd would have advantages over a regular clear livecd?
Thanks in advance
erick
|
| Re: Encrypted livecd's - need testers |
 
Portugal |
2007-07-01 05:44:33 |
|
Hi Erick,
There are many uses for this!
They mainly come
from the fact that now you can have sensitive information everywhere on your cd
root, and not be afraid of losing your cd, either physically (happens to me all
the time), or in the net if you don't want an open distribution.
-Read on for examples:
1) If you're in a country like China and
you can't have applications like Tor on your desktop (suspicious), you can just
make a livecd and try to disguise it as something else by filling the
filesystem. Also it's portable and replicable. You could also encrypt your hard
drive, but this way you don't have to worry if they take it for testing.
Specially if using luks on the desktop (no plausible deniability). It's also
much easier to hide a mini-cd/dvd physically.
2) Also for instance,
I'm going away next semester and I won't be taking a laptop. However I would
like to use gentoo, my favourite programs and have my passwords stored in them
(like Firefox), and transport some personal and/or sensitive files. (only
option is put those files in an encrypted container and extract them on *every*
boot).
3) If you're creating some official livecd and would like to
test it with some group, but for security reasons you prefered if nobody else
tested it.
4) In general companies/organizations can create a easily
updatable portable working environment and mail it or publish it online.
Etc.
Take care,
Nelson
|
| Re: Encrypted livecd's - need testers |
Portugal |
2007-07-01 06:29:50 |
Oh, there's something I forgot to mention that makes the
first example stupid:
if someone *does* find your livecd, if you set
crypt_silent=1 (from
bug 174294), all you have to do is boot the cd without the
keyfile.
It'll enter a shell quietly with no bad files on sight, and
you can
therefore justify to not so tech savy opressed policeman why
some
files on your cd look weird.
--
gentoo-catalystgentoo.org mailing list
|
|
| Re: Encrypted livecd's - need testers |
|
2007-07-01 07:08:08 |
|
Nelson,
Ok, I understand, thanks for clarifying.
So we can narrow down all those scenarios to one type of attack: theft by third part (or yourself).
It does not protect more the user while he uses it nor from potential "after-use" trails. Either you lose the livecd along with your identity (or data that leads to your identity) and you get caught or while using the software you get caught (like your TOR connections have been detected).
The only purpose and advantage encryption would have is to obfuscate some passwords like in the firefox example you gave.
Now, from a legal point of view, being caught with an encrypted material whether livecd or not in major countries (UK,GER,FR,US,china) requires from you the decryption key (us patriot act, uk RIP act, etc) or else you can straight take up to few years in some cases without much chance of having of good defense (china=torture?). So in 95% of cases you end up giving away your key to prove that you are not a spy from whatever organisation and that at least you hadn't that bad intention with your encrypted software. And you do handle the key in the objective of lowering the sentence you get for being caught in the first place.
I think that encryption has nothing to do with hiding. In the contrary, it is like a big flag standing saying "hey look at me I got something to hide, come and get me!". It is just obfuscating technology.
The real solution to your problem would be to use a steganographic layer ( http://en.wikipedia.org/wiki/Steganography ) . Not for the whole squashfs but only for a single file (whatever the size) inside a clear livecd. Note that 20% of the size of that file is really containing data, you do not want to push too much (50%) or we get data loss (blocks from different containers overwriting them) in an exponentially manner.
You want to be able to *deny* that you are in possession of such material. Go from the basis that if you get caught you will *have to* handle your key away. That is real practice because you can get 5 times more being secretive than actual real sentence against the data you want to hide.
A steganographic FS will allow you when being caught with your livecd of saying first: "it is a clear livecd!" Sounds idiotic but believe me, it is the best start for the official police questioning. Then in the worst case scenario, they find your single encrypted file and ask you for the key which you will provide one of the many different you have set up (properties of a steganographic FS), which will decrypt a part of that encrypted file, discovering data that will not incriminate you so far for just having a picture of your dog.
Charges are dropped, you justify your secretive attitude as being respectful of your privacy rights and next morning you wake up in your bed!
Because I want to be fair, I think having an encryption layer is great for catalyst, but when related to the specific purpose you described you would better at least give a try to a steganographic FS if you really fear the sentence you can get for the data you are hiding.
You will not find much (I mean actual real software) besides some linux-2.2 tweak over ext2 "proof-of-concept" (10years old not stable unreliable) and an update by some chinese with 2.4 but the whole is mainly broken and I guess somehow a little taboo, the projects seems dead, no main other projects have been replaced.
You can try an implementation I have worked on few years ago. It does everything that I have described (in a non friendly C hardcore way) so far and is called denyfs.
It is not a driver, and can be started in userland if the correct losetup and cryptsetup have been done.
http://www.openchill.org/2005/06/denyfs_a_steganographic_file_s.php#more
have a look there, it is not fully stable, requires manual compilation and configuration though it does the job (I made a quick GUI in gtk if you provide the gtk USE flag). Follow the howto to get a grip on it. And remember if you want to retrieve with a 90% probability your data as you have put them in the box, do not exceed 15-20% of the total size of the file! And even do not be surprised when it happens.
Steganography is a concept that aims at small and *static* file system. Do not even think about putting an OS(where files are dynamically arranged again and again) inside a steganographic FS, it is as of the concepts and mathematics we have simply impossible.
I didn't realized I wrote so much, I'm just passioned by this topic because of past experiences moving from one country to another. I am currently developing a Portage based GNU/Linux natively encrypted OS and I'm about to re open DenyFS inside that distribution by stabilizing it, hence my reason for being so communicative.
Thanks for reading
erick
On 7/1/07, Nelson Batalha < nelson_batalhasapo.pt">nelson_batalhasapo.pt> wrote:
Hi Erick,
There are many uses for this!
They mainly come
from the fact that now you can have sensitive information everywhere on your cd
root, and not be afraid of losing your cd, either physically (happens to me all
the time), or in the net if you don't want an open distribution.
-Read on for examples:
1) If you're in a country like China and
you can't have applications like Tor on your desktop (suspicious), you can just
make a livecd and try to disguise it as something else by filling the
filesystem. Also it's portable and replicable. You could also encrypt your hard
drive, but this way you don't have to worry if they take it for testing.
Specially if using luks on the desktop (no plausible deniability). It's also
much easier to hide a mini-cd/dvd physically.
2) Also for instance,
I'm going away next semester and I won't be taking a laptop. However I would
like to use gentoo, my favourite programs and have my passwords stored in them
(like Firefox), and transport some personal and/or sensitive files. (only
option is put those files in an encrypted container and extract them on *every*
boot).
3) If you're creating some official livecd and would like to
test it with some group, but for security reasons you prefered if nobody else
tested it.
4) In general companies/organizations can create a easily
updatable portable working environment and mail it or publish it online.
Etc.
Take care,
Nelson
|
| Re: Encrypted livecd's - need testers |
|
2007-07-01 07:32:07 |
|
I forgot a valuable argument!
Because you mainly intend to read from the hidden container (you want your TOR demon binary and libraries to be readable and not writable after you mounted your container) the steganographic technology provided is very suitable for your purpose achieving in a more efficient way the "hiding" property of the task.
Just so that you know there other different ways to achieve your goal.
Thanks for reading
On 7/1/07, Erick M < balkiragmail.com">
balkiragmail.com> wrote:Nelson,
Ok, I understand, thanks for clarifying.
So we can narrow down all those scenarios to one type of attack: theft by third part (or yourself).
It does not protect more the user while he uses it nor from potential "after-use" trails. Either you lose the livecd along with your identity (or data that leads to your identity) and you get caught or while using the software you get caught (like your TOR connections have been detected).
The only purpose and advantage encryption would have is to obfuscate some passwords like in the firefox example you gave.
Now, from a legal point of view, being caught with an encrypted material whether livecd or not in major countries (UK,GER,FR,US,china) requires from you the decryption key (us patriot act, uk RIP act, etc) or else you can straight take up to few years in some cases without much chance of having of good defense (china=torture?). So in 95% of cases you end up giving away your key to prove that you are not a spy from whatever organisation and that at least you hadn't that bad intention with your encrypted software. And you do handle the key in the objective of lowering the sentence you get for being caught in the first place.
I think that encryption has nothing to do with hiding. In the contrary, it is like a big flag standing saying "hey look at me I got something to hide, come and get me!". It is just obfuscating technology.
The real solution to your problem would be to use a steganographic layer ( http://en.wikipedia.org/wiki/Steganography
) . Not for the whole squashfs but only for a single file (whatever the size) inside a clear livecd. Note that 20% of the size of that file is really containing data, you do not want to push too much (50%) or we get data loss (blocks from different containers overwriting them) in an exponentially manner.
You want to be able to *deny* that you are in possession of such material. Go from the basis that if you get caught you will *have to* handle your key away. That is real practice because you can get 5 times more being secretive than actual real sentence against the data you want to hide.
A steganographic FS will allow you when being caught with your livecd of saying first: "it is a clear livecd!" Sounds idiotic but believe me, it is the best start for the official police questioning. Then in the worst case scenario, they find your single encrypted file and ask you for the key which you will provide one of the many different you have set up (properties of a steganographic FS), which will decrypt a part of that encrypted file, discovering data that will not incriminate you so far for just having a picture of your dog.
Charges are dropped, you justify your secretive attitude as being respectful of your privacy rights and next morning you wake up in your bed!
Because I want to be fair, I think having an encryption layer is great for catalyst, but when related to the specific purpose you described you would better at least give a try to a steganographic FS if you really fear the sentence you can get for the data you are hiding.
You will not find much (I mean actual real software) besides some linux-2.2 tweak over ext2 "proof-of-concept" (10years old not stable unreliable) and an update by some chinese with 2.4 but the whole is mainly broken and I guess somehow a little taboo, the projects seems dead, no main other projects have been replaced.
You can try an implementation I have worked on few years ago. It does everything that I have described (in a non friendly C hardcore way) so far and is called denyfs.
It is not a driver, and can be started in userland if the correct losetup and cryptsetup have been done.
http://www.openchill.org/2005/06/denyfs_a_steganographic_file_s.php#more
have a look there, it is not fully stable, requires manual compilation and configuration though it does the job (I made a quick GUI in gtk if you provide the gtk USE flag). Follow the howto to get a grip on it. And remember if you want to retrieve with a 90% probability your data as you have put them in the box, do not exceed 15-20% of the total size of the file! And even do not be surprised when it happens.
Steganography is a concept that aims at small and *static* file system. Do not even think about putting an OS(where files are dynamically arranged again and again) inside a steganographic FS, it is as of the concepts and mathematics we have simply impossible.
I didn't realized I wrote so much, I'm just passioned by this topic because of past experiences moving from one country to another. I am currently developing a Portage based GNU/Linux natively encrypted OS and I'm about to re open DenyFS inside that distribution by stabilizing it, hence my reason for being so communicative.
Thanks for reading
erick
On 7/1/07, Nelson Batalha < nelson_batalhasapo.pt" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
nelson_batalhasapo.pt> wrote:
Hi Erick,
There are many uses for this!
They mainly come
from the fact that now you can have sensitive information everywhere on your cd
root, and not be afraid of losing your cd, either physically (happens to me all
the time), or in the net if you don't want an open distribution.
-Read on for examples:
1) If you're in a country like China and
you can't have applications like Tor on your desktop (suspicious), you can just
make a livecd and try to disguise it as something else by filling the
filesystem. Also it's portable and replicable. You could also encrypt your hard
drive, but this way you don't have to worry if they take it for testing.
Specially if using luks on the desktop (no plausible deniability). It's also
much easier to hide a mini-cd/dvd physically.
2) Also for instance,
I'm going away next semester and I won't be taking a laptop. However I would
like to use gentoo, my favourite programs and have my passwords stored in them
(like Firefox), and transport some personal and/or sensitive files. (only
option is put those files in an encrypted container and extract them on *every*
boot).
3) If you're creating some official livecd and would like to
test it with some group, but for security reasons you prefered if nobody else
tested it.
4) In general companies/organizations can create a easily
updatable portable working environment and mail it or publish it online.
Etc.
Take care,
Nelson
|
| Re: Encrypted livecd's - need testers |
Portugal |
2007-07-01 08:44:03 |
I would like to quote these two statements:
http://gentoo-wiki.co
m/SECURITY_System_Encryption_DM-Crypt_with_LUKS#Two_things_t
o_remember
Thanks for your help, but:
> It does not protect more the user while he uses it nor
from
> potential "after-use" trails.
So? Was I supposed to release a complete secure solution
right now? :P
> Either you lose the livecd
> along with your identity (or data that leads to your
identity) and
> you get caught or while using the software you get
caught (like
> your TOR connections have been detected). The only
purpose and
> advantage encryption would have is to
> obfuscate some passwords like in the firefox example
you gave.
The idea is that with this livecd you're on the move, boot
the cd, use
tor and go away asap once finished. Make sure all your
sensible data
is sent in a package just before leaving. If you lose it or
someone
looks at it, it won't suspect much.
> The real solution to your problem would be to use a
steganographic
> layer ( http://en.
wikipedia.org/wiki/Steganography[1] ) .
It's not like I didn't remembered steganography, read
below.
> You will not find much (I mean actual real software)
besides some
> linux-2.2 tweak over ext2 "proof-of-concept"
(10years old
> not stable unreliable)
False? Look for TrueCrypt.
> I think that encryption has nothing to do with hiding.
In the
> contrary, it is like a big flag standing saying
"hey look at
> me I got something to hide, come and get me!". It
is just
> obfuscating technology.
Using the crypt_silent option how likely are you of being
catched?
Just put some binaries of emacs and so on on the root, and
demonstrate
in the fake root that's what is for. It is a good hiding
technique I
think, but not perfect.
The thing is, given the low probability of being catched,
either by
having the squashfs with Steganography or not, some large
file would
be there, and if they're good enough to realize it is a
bootable
livecd and it is forcing a fake boot, then they're good
enough to see
a big closed file is there.
Unless one did multiple hidden volumes inside this one, or
just hide
some files inside the root. But we're back to less usability
and we're
being forced to use truecrypt (I don't see a currently free
maintained
option).
If we accept the Truecrypt restrictions (haven't read
everything, but
it's not gpl so I assume they're more restrictive :P), we
could
implement these several layers of encryption and increase
functionality with some scripts hidden in a pen for example.
But to
put any programs like firefox+torplugin+tor+privoxy in them,
and
separate in small files, that's a lot of work. This
implementation is
good enough for most cases. Also Luks is well maintained and
GPL.
> Now, from a legal point of view, being caught with an
encrypted
> material whether livecd or not in major countries
> (UK,GER,FR,US,china) requires from you the decryption
key
Fine for me, don't do anything illegal in free countries. As
for the
China example, just do as on my second point and use the
following
idea: encrypt with luks as it is, and for the more sensitive
files you
can use stenography using stenography software in a separate
volume
(like a usb pen). If they ask you for the key, give it to
them and
show just some more innocent files you were hiding.
It's better then have the cd almost all open, again, because
you may lose it.
Let me know if I'm wrong or if you have more ideas ;)
Cheers,
Nelson
--
gentoo-catalystgentoo.org mailing list
|
|
| Re: Encrypted livecd's - need testers |
|
2007-07-01 10:14:53 |
|
I do not mean to undertake your idea, but I got this simple question that your design does not solve:
What's next when you get caught?
The whole point of your system is protection of data for the user if the CD falls into other hands. But the legal context nowadays requires you to give the key.
- With your system on my livecd, legally I can get in Europe 2 years and a huge fine if I keep my password secret, hence I will handle the key to get something under those 2 years, and every one would do so even you, I guess. Your design is like writing on that CD that it is encrypted: the first guy who boots it finds out that you have something to hide!
So at the end, the whole design of such system falls into pieces. I mean, it's alright for the university, your friends but it is simply not enough against legal constraints which is my main concern, let's face the worst enemy, cryptography simply fails to protect valuable information because of yourself: be realistic, will you just keep your mouth shut when that legal voice will trade:"give us the password or it's 2 years!"?
- With my system on my livecd, the overall clear side is part of the stealth concept, keep it as usual as you can from the outside, the less change the better. Then I just copy my binary to something irrelevant into /usr/bin and my container file somewhere in /usr/lib and here we go. From a forensic perspective analysis it is much more difficult to reveal the encrypted material. You got in the first place to actually find the encrypted material(few bytes over a Gigabytes). How can charges be pressed without evidence? Then when evidence is found as a file, you have several containers to fall back to. You give a first and single password away that will decrypt a different part than the one you are protecting.
Finally, the comparison with true-crypt is unfair (for true-crypt) because it can handle up to 2 containers inside of each other, as denyfs goes up to 16 containers, along with 16 != passwords . It's programmed so, but again the setup has to take that 15% data ratio in account or you will start messing with statistic which is your worst enemy. Truecrypt does not deal with this issue and will never, because math cannot solve this problem. The probability of collision increase exponentially with the number of containers along with the size of the main container.
And yes denyfs one so often breaks, by overwriting some bits here or there, let's say 1/10 but this is the reason why it makes it so powerful and no reversible. At the end it is a human choice, the user defines a trade between the size of his main container and the number of sub containers he will create to fit the specific amount of data that needs hiding. And this is the missing parameter in the problem, hence the reason no such perfect system will ever be implemented.
If you have containers A and B that do not know their respective existences, how can you ensure they won't overwrite bit of one another? You simply can't! You fall into statistics and the only choice to optimize integrity is to up size a huge main container and work on say 5% max of the whole size. Add to that, that 5% rate needs to be lower each time as you create sub containers.
Cryptography is an open door to investigation, the first question is:"wtf does he want to hide?";
If you can evade this reflexion in your "opponent" mind then it is then very highly probable that the material that needs to be hidden will stay hidden!
That's the key concept of military data flow over enemy lines (sounds heavy but true) nowadays in military IT mainly inspired by an Oxford professor (the one who wrote the first public implementation forked on ext2 called StegFS, he's easy to find). The point is to evade torture (physical and psychological) of messengers when they get caught with encrypted data.
anyway I made my point that the "best" technology for such job exists and is available and it does *not* apply your design but something much more subtle.
Good work for your stuff, it's good for countries which do not have yet IT laws like the one mentioned, Africa, South America (except Brazil) and I'm sure a couple of penguins in the North pole but for European and US citizens, this kind of protection has no legal dimension, and will fall into piece in a real governmental situation.
I'm looking forward to a merge into the official catalyst project.
Thanks for reading.
On 7/1/07, Nelson Batalha <
nelson_batalhasapo.pt">nelson_batalhasapo.pt> wrote:I would like to quote these two statements:
http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS#Two_things_to_remember
Thanks for your help, but:
> It does not protect more the user while he uses it nor from
> potential "after-use" trails.
So? Was I supposed to release a complete secure solution right now? :P
> Either you lose the livecd
> along with your identity (or data that leads to your identity) and
> you get caught or while using the software you get caught (like
> your TOR connections have been detected). The only purpose and
> advantage encryption would have is to
> obfuscate some passwords like in the firefox example you gave.
The idea is that with this livecd you're on the move, boot the cd, use
tor and go away asap once finished. Make sure all your sensible data
is sent in a package just before leaving. If you lose it or someone
looks at it, it won't suspect much.
>; The real solution to your problem would be to use a steganographic
> layer (
http://en.wikipedia.org/wiki/Steganography[1] ) .
It';s not like I didn't remembered steganography, read below.
> You will not find much (I mean actual real software) besides some
> linux-2.2
tweak over ext2 "proof-of-concept" (10years old
> not stable unreliable)
False? Look for TrueCrypt.
> I think that encryption has nothing to do with hiding. In the
> contrary, it is like a big flag standing saying "hey look at
> me I got something to hide, come and get me!". It is just
> obfuscating technology.
Using the crypt_silent option how likely are you of being catched?
Just put some binaries of emacs and so on on the root, and demonstrate
in the fake root that's what is for. It is a good hiding technique I
think, but not perfect.
The thing is, given the low probability of being catched, either by
having the squashfs with Steganography or not, some large file would
be there, and if they're good enough to realize it is a bootable
livecd and it is forcing a fake boot, then they're good enough to see
a big closed file is there.
Unless one did multiple hidden volumes inside this one, or just hide
some files inside the root. But we're back to less usability and we're
being forced to use truecrypt (I don't see a currently free maintained
option).
If we accept the Truecrypt restrictions (haven';t read everything, but
it's not gpl so I assume they're more restrictive :P), we could
implement these several layers of encryption and increase
functionality with some scripts hidden in a pen for example. But to
put any programs like firefox+torplugin+tor+privoxy in them, and
separate in small files, that's a lot of work. This implementation is
good enough for most cases. Also Luks is well maintained and GPL.
> Now, from a legal point of view, being caught with an encrypted
> material whether livecd or not in major countries
> (UK,GER,FR,US,china) requires from you the decryption key
Fine for me, don't do anything illegal in free countries. As for the
China example, just do as on my second point and use the following
idea: encrypt with luks as it is, and for the more sensitive files you
can use stenography using stenography software in a separate volume
(like a usb pen). If they ask you for the key, give it to them and
show just some more innocent files you were hiding.
It's better then have the cd almost all open, again, because you may lose it.
Let me know if I'm wrong or if you have more ideas ;)
Cheers,
Nelson
--
gentoo-catalystgentoo.org">
gentoo-catalystgentoo.org mailing list
|
| Re: Encrypted livecd's - need testers |
|
2007-07-01 15:44:06 |
All of your points were already addressed.
Besides, if you're afraid to go to jail in the EU/US, then
that's your
problem, I'm looking to help people from theft (or hacking
for the
livecd testing), and maybe some rare opressed citizens
looking for an
extra layer of security. He can still use steganography in
files inside,
provide the key of the system to the goverment and keep his
identity
safe on the root.
All the other cases only need to enjoy the easiness of
having all the
system encrypted, which no steganography implementation can
provide.
--
gentoo-catalystgentoo.org mailing list
|
|
| Re: Encrypted livecd's - need testers |
|
2007-07-01 23:50:43 |
|
That's my whole point, you do not help people, you just give the illusion of security, as of when you get caught the system does not protect anymore, then the very purpose of your supposed protection falls apart.
Most people will think they are safe with encryption as in the contrary, it is just asking for investigation and visibility!
You expose the user rather than protecting him.
so what's the point doing an encryption layer? to hide ~/.firefox or /etc/init.d/tor ? Do you think you actually help the lil' chinese that looks for using TOR? I do not think so at all! Using your software he *will* get tortured if he stays silent. Hence he won't use it!
It's nice to implement features and I show much respect for that, but you need a design in the back, a purpose, something strong and stable that is lacking here. Is it worth? How can I break my system? all those questions you don't seem to have an answer..as there is.
Add a legal dimension to your design and you're screwed man!
Or maybe is it the computer hype, anywhere we put some encryption sounds sooooo l3333t?
I do not know but this does *not* make any sense at all!
but hey that's my 2 cent HO
<troll>
ok I'm off, dui!
</troll>
ps: and ohh yeah you do not seem afraid of going to jail, you look like a tough man, lucky you!
Thanks for reading
On 7/1/07, Nelson Batalha < nelson_batalhasapo.pt">nelson_batalhasapo.pt> wrote:
All of your points were already addressed.
Besides, if you're afraid to go to jail in the EU/US, then that's your
problem, I'm looking to help people from theft (or hacking for the
livecd testing), and maybe some rare opressed citizens looking for an
extra layer of security. He can still use steganography in files inside,
provide the key of the system to the goverment and keep his identity
safe on the root.
All the other cases only need to enjoy the easiness of having all the
system encrypted, which no steganography implementation can provide.
--
gentoo-catalystgentoo.org">gentoo-catalystgentoo.org mailing list
|
[1-10]
|
|