Re: root fs/crypted

2001-05-30 Thread Hubert Chan
On Wed, 30 May 2001, Aaron Dewell wrote:

> 
> Having a crypto install option (even if it's a little more complex to
> get) is still better than not having one.

I agree.  I just wanted to remind people that we would need two sets of
install disks if we were to bundle crypto into the installation procedure.

Hubert



Re: root fs/crypted

2001-05-30 Thread Aaron Dewell

Having a crypto install option (even if it's a little more complex to
get) is still better than not having one.

At this point, all one can do is encrypt a filesystem off of a non-
encrypted root partition.  Like removable media or something else that
is mounted by hand.  There are some logistical problems with doing
that for a root filesystem, but those can probably be worked out.

Does anyone know of a good cypherpunks list/site?

Aaron

On Wed, 30 May 2001, Hubert Chan wrote:
> Don't forget those countries where the use of cryptography at all is
> illegal.
>
> If Debian were to implement a cryptography-by-default install, it would
> also need a non-cryptographic install.  The cryptographic install would
> also only be avaiable via non-US and its mirrors due to export
> restrictions in certain countries.
>
> Hubert.



Re: root fs/crypted

2001-05-30 Thread Hubert Chan
On Wed, 30 May 2001, Zak Kipling wrote:

> Although in some countries (eg Britain) you can be required by law to
> disclose the decryption keys, and imprisoned if you fail to do so. The
> only way around this is to use a steganographic approach where, in the
> absence of the passphrase for a given set of data, it is impossible even
> to prove its existence.

Don't forget those countries where the use of cryptography at all is
illegal.

If Debian were to implement a cryptography-by-default install, it would
also need a non-cryptographic install.  The cryptographic install would
also only be avaiable via non-US and its mirrors due to export
restrictions in certain countries.

Hubert.



Re: root fs/crypted

2001-05-30 Thread Hubert Chan

On Wed, 30 May 2001, Aaron Dewell wrote:

> 
> Having a crypto install option (even if it's a little more complex to
> get) is still better than not having one.

I agree.  I just wanted to remind people that we would need two sets of
install disks if we were to bundle crypto into the installation procedure.

Hubert


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-30 Thread Aaron Dewell


Having a crypto install option (even if it's a little more complex to
get) is still better than not having one.

At this point, all one can do is encrypt a filesystem off of a non-
encrypted root partition.  Like removable media or something else that
is mounted by hand.  There are some logistical problems with doing
that for a root filesystem, but those can probably be worked out.

Does anyone know of a good cypherpunks list/site?

Aaron

On Wed, 30 May 2001, Hubert Chan wrote:
> Don't forget those countries where the use of cryptography at all is
> illegal.
>
> If Debian were to implement a cryptography-by-default install, it would
> also need a non-cryptographic install.  The cryptographic install would
> also only be avaiable via non-US and its mirrors due to export
> restrictions in certain countries.
>
> Hubert.


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-30 Thread Jim Breton
On Tue, May 29, 2001 at 11:54:29PM -0800, Ethan Benson wrote:
> trouble is when your dealing with corrupt/fascist/evil
> government/regimes encryption isn't going to do you much good, either
> they will throw you in prison for refusing to disclose the decryption
> key or worse they will use methods that make you very very eager to
> reveal it

Bearing in mind that the alternative is a non-encrypted FS, which leaves
you no choice in the matter whatsoever.

At least with an encrypted FS you are "secure by default" and can then
judge what to do later based on the threat.



Re: root fs/crypted

2001-05-30 Thread Hubert Chan

On Wed, 30 May 2001, Zak Kipling wrote:

> Although in some countries (eg Britain) you can be required by law to
> disclose the decryption keys, and imprisoned if you fail to do so. The
> only way around this is to use a steganographic approach where, in the
> absence of the passphrase for a given set of data, it is impossible even
> to prove its existence.

Don't forget those countries where the use of cryptography at all is
illegal.

If Debian were to implement a cryptography-by-default install, it would
also need a non-cryptographic install.  The cryptographic install would
also only be avaiable via non-US and its mirrors due to export
restrictions in certain countries.

Hubert.


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-30 Thread Jim Zajkowski
On Wed, May 30, 2001 at 02:30:48AM -0700, Jon Leonard wrote:

> I'm not aware of any actual implementations, unfortunately.

Rubberhose, www.rubberhose.org, implements deniable crypto,
exactly as you described.

--Jim

-- 
Jim Zajkowski
System Administrator
ITCS Contract Services



Re: root fs/crypted

2001-05-30 Thread Jim Breton

On Tue, May 29, 2001 at 11:54:29PM -0800, Ethan Benson wrote:
> trouble is when your dealing with corrupt/fascist/evil
> government/regimes encryption isn't going to do you much good, either
> they will throw you in prison for refusing to disclose the decryption
> key or worse they will use methods that make you very very eager to
> reveal it

Bearing in mind that the alternative is a non-encrypted FS, which leaves
you no choice in the matter whatsoever.

At least with an encrypted FS you are "secure by default" and can then
judge what to do later based on the threat.


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-30 Thread clemens

it should also be possible to include basic network support
into the initrd to enable 'entering' a password remote.
we can't support all methods allowed by /etc/network/interfaces
(ppp/wvdial should be omitted..) but static/dhcp/bootp are 
possible.
there authorization process could beneath reading /dev/console
also listen on an udp port.
local and remote station must share a secret(key) to allow secure 
communication. a couple of one time pads for maximum security
would be the best.

i don't want to drive through the whole city because someone
accidentally unplugged my box :)

On Wed, May 30, 2001 at 03:01:17AM +0200, clemens wrote:
> 
> SAWFASP^*
> 
> as laws around the globe are forged to weak personal privacy, 
> police knocking on one's door, because of portscanning a
> previously hacked website, and - i don't have to tell those
> of you, which are reading slashdot - as pretty strange things start
> to happend worldwide, i'm getting somewhat nervous about
> my data safety.
> 
> what i'm aiming at, you might ask? 
> debian should support a crypted rootfs right out
> of the box.
> 
> i'll try to grasp within a few words, what's necessary to realize this:
> 
> - the international kernel must be introduced as regular 
>   debian packages. 
> - the boot disks needs to be modified (just do a losetup
>   on some loopdev, and mount that one instead of the realrootdev)
> - of course, there must be an initrd to boot from, 
>   which accepts authentication information.
>   (this ramdisk has to be placed unencrypted on 
>the rootfs, so the kernel code has to be circumwented or
>the plain data has to be manually decrypted in usermode
>to be re-encrypted to the original plain data when flushed 
>to disk.. easy for EBC mode crypto but harder to
>achieve for CBC mode - creative suggestions welcome)
> - there must be an alternative passphrase, since i nor
>   any user will be willing to trust one forgetable phrase.
>   (how many times have you forgotten your mobil phone pin?)
>   suggestion: the actual key will be random generated, and 
>   encrypted twice by two different passphrases/keys - one 
>   choosen by the user, one random generated - useful to write on 
>   a piece of paper and hide behind the bookshelf.
> 
> (probably i should crosspost to debian-legal. the 
> whole non-US issue has been left untouched)
> 
> what do YOU think?
> shell debian be the first(?) privacy enhanced distro?
> 
> clemens
> 
> ^* SAWFASP = searched archives without finding a similiar 
> posting



Re: root fs/crypted

2001-05-30 Thread clemens
On Wed, May 30, 2001 at 12:17:35PM +0900, Curt Howland wrote:

> [cut]
> but that only works at startup. if the system is running,
> having the entire disk encrypted is no different than the
> fact it's all in hex already. an individual user based
> encryption means all you have to do is logout, not power
> down, to kill the "decryption" process and thwart snooping.
> 
> so how about a start-up passphrase protecting everything
> owned by root, then another for each individual user? but
> that would cancel root's ability to read everything

we should not aim to protect root from accessing userdata.
user must trust root. root could replace losetup by a 
malicious logging one.

this double keying makes sence, in the usual raided-case.
(the rootfs could reside on an encrypting loop device,
the user homedirs could reside as image files on an
unencrypted secondary partition, although we lose
the feature of dynamic space allocation, since these
user files are images with static file sizes.
cfs is much more usefull for user encryption, but
much slower).

cle



Re: root fs/crypted

2001-05-30 Thread clemens
On Tue, May 29, 2001 at 08:02:50PM -0700, Paul Lowe wrote:
> I like this. Would it be difficult to modify Debian, so that
> upon install, it creates an encrypted root volume and starts
> things off the right way?

3 things are needed to that upon installation:

- losetup -e  /dev/loop0 /dev/
  (for further actions set rootdev to /dev/loop0)

- kerneli (see http://kerneli.org)

- copy a standard initrd to the root disk, and add it 
  to the lilo parameters.

looks promising, doesn't it?

cle



Re: root fs/crypted

2001-05-30 Thread clemens
On Wed, May 30, 2001 at 10:46:19AM +0200, Jan Niehusmann wrote:
> On Wed, May 30, 2001 at 01:08:21AM -0700, [EMAIL PROTECTED] wrote:
> > Couldn't you say something like "I'm so sorry, I can't remember the pass
> > phrase, my mind has failed me...etc?"
> What about a more provable approach: 
> 
> The passphrase could be changed automatically on every system
> boot, and the new passphrase could be written to a floppy disk
> on a clean shutdown (which, of course, is only possible with
> the root password).
> 
> So if the police takes the computer and doesn't do the clean
> shutdown (how could they?), you can tell them: Sorry folks,
> you just destroyed the possibility to get any data from that computer...
> 
> This, of course, means that you lose your data if the computer 
> crashes. 

if there would be two keys to the system (the way i described in
my original posting) the user key could be written to disc
only on clean shutdown. so if the system is unplugged by law
enforcement, the key you know is unusable. under truth serums
are whatever you can rightfully assert you don't know the key.
(you don't know the alternative random generated key either,
but you know it's behind the bookshelf written on a piece 
of paper). 

but that belongs to debian-legal.

cle



Re: root fs/crypted

2001-05-30 Thread Jim Zajkowski

On Wed, May 30, 2001 at 02:30:48AM -0700, Jon Leonard wrote:

> I'm not aware of any actual implementations, unfortunately.

Rubberhose, www.rubberhose.org, implements deniable crypto,
exactly as you described.

--Jim

-- 
Jim Zajkowski
System Administrator
ITCS Contract Services


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-30 Thread clemens


it should also be possible to include basic network support
into the initrd to enable 'entering' a password remote.
we can't support all methods allowed by /etc/network/interfaces
(ppp/wvdial should be omitted..) but static/dhcp/bootp are 
possible.
there authorization process could beneath reading /dev/console
also listen on an udp port.
local and remote station must share a secret(key) to allow secure 
communication. a couple of one time pads for maximum security
would be the best.

i don't want to drive through the whole city because someone
accidentally unplugged my box :)

On Wed, May 30, 2001 at 03:01:17AM +0200, clemens wrote:
> 
> SAWFASP^*
> 
> as laws around the globe are forged to weak personal privacy, 
> police knocking on one's door, because of portscanning a
> previously hacked website, and - i don't have to tell those
> of you, which are reading slashdot - as pretty strange things start
> to happend worldwide, i'm getting somewhat nervous about
> my data safety.
> 
> what i'm aiming at, you might ask? 
> debian should support a crypted rootfs right out
> of the box.
> 
> i'll try to grasp within a few words, what's necessary to realize this:
> 
> - the international kernel must be introduced as regular 
>   debian packages. 
> - the boot disks needs to be modified (just do a losetup
>   on some loopdev, and mount that one instead of the realrootdev)
> - of course, there must be an initrd to boot from, 
>   which accepts authentication information.
>   (this ramdisk has to be placed unencrypted on 
>the rootfs, so the kernel code has to be circumwented or
>the plain data has to be manually decrypted in usermode
>to be re-encrypted to the original plain data when flushed 
>to disk.. easy for EBC mode crypto but harder to
>achieve for CBC mode - creative suggestions welcome)
> - there must be an alternative passphrase, since i nor
>   any user will be willing to trust one forgetable phrase.
>   (how many times have you forgotten your mobil phone pin?)
>   suggestion: the actual key will be random generated, and 
>   encrypted twice by two different passphrases/keys - one 
>   choosen by the user, one random generated - useful to write on 
>   a piece of paper and hide behind the bookshelf.
> 
> (probably i should crosspost to debian-legal. the 
> whole non-US issue has been left untouched)
> 
> what do YOU think?
> shell debian be the first(?) privacy enhanced distro?
> 
> clemens
> 
> ^* SAWFASP = searched archives without finding a similiar 
> posting


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-30 Thread clemens

On Wed, May 30, 2001 at 12:17:35PM +0900, Curt Howland wrote:

> [cut]
> but that only works at startup. if the system is running,
> having the entire disk encrypted is no different than the
> fact it's all in hex already. an individual user based
> encryption means all you have to do is logout, not power
> down, to kill the "decryption" process and thwart snooping.
> 
> so how about a start-up passphrase protecting everything
> owned by root, then another for each individual user? but
> that would cancel root's ability to read everything

we should not aim to protect root from accessing userdata.
user must trust root. root could replace losetup by a 
malicious logging one.

this double keying makes sence, in the usual raided-case.
(the rootfs could reside on an encrypting loop device,
the user homedirs could reside as image files on an
unencrypted secondary partition, although we lose
the feature of dynamic space allocation, since these
user files are images with static file sizes.
cfs is much more usefull for user encryption, but
much slower).

cle


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-30 Thread clemens

On Tue, May 29, 2001 at 08:02:50PM -0700, Paul Lowe wrote:
> I like this. Would it be difficult to modify Debian, so that
> upon install, it creates an encrypted root volume and starts
> things off the right way?

3 things are needed to that upon installation:

- losetup -e  /dev/loop0 /dev/
  (for further actions set rootdev to /dev/loop0)

- kerneli (see http://kerneli.org)

- copy a standard initrd to the root disk, and add it 
  to the lilo parameters.

looks promising, doesn't it?

cle


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-30 Thread clemens

On Wed, May 30, 2001 at 10:46:19AM +0200, Jan Niehusmann wrote:
> On Wed, May 30, 2001 at 01:08:21AM -0700, [EMAIL PROTECTED] wrote:
> > Couldn't you say something like "I'm so sorry, I can't remember the pass
> > phrase, my mind has failed me...etc?"
> What about a more provable approach: 
> 
> The passphrase could be changed automatically on every system
> boot, and the new passphrase could be written to a floppy disk
> on a clean shutdown (which, of course, is only possible with
> the root password).
> 
> So if the police takes the computer and doesn't do the clean
> shutdown (how could they?), you can tell them: Sorry folks,
> you just destroyed the possibility to get any data from that computer...
> 
> This, of course, means that you lose your data if the computer 
> crashes. 

if there would be two keys to the system (the way i described in
my original posting) the user key could be written to disc
only on clean shutdown. so if the system is unplugged by law
enforcement, the key you know is unusable. under truth serums
are whatever you can rightfully assert you don't know the key.
(you don't know the alternative random generated key either,
but you know it's behind the bookshelf written on a piece 
of paper). 

but that belongs to debian-legal.

cle


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-30 Thread Zak Kipling
On Wed, 30 May 2001, Jon Leonard wrote:

> I'm not aware of any actual implementations, unfortunately.

http://www.mcdonald.org.uk/StegFS/



Re: root fs/crypted

2001-05-30 Thread Jon Leonard
On Wed, May 30, 2001 at 10:46:19AM +0200, Jan Niehusmann wrote:
> On Wed, May 30, 2001 at 01:08:21AM -0700, [EMAIL PROTECTED] wrote:
> > Couldn't you say something like "I'm so sorry, I can't remember the pass
> > phrase, my mind has failed me...etc?"
> 
> What about a more provable approach: 
> 
> The passphrase could be changed automatically on every system
> boot, and the new passphrase could be written to a floppy disk
> on a clean shutdown (which, of course, is only possible with
> the root password).
> 
> So if the police takes the computer and doesn't do the clean
> shutdown (how could they?), you can tell them: Sorry folks,
> you just destroyed the possibility to get any data from that computer...
> 
> This, of course, means that you lose your data if the computer 
> crashes. 

This is likely solving the wrong problem, your security is almost never
limited by cryptographic strength, but rather by human factors or other
non-cryptographic weaknesses.

However, there is a known answer to this particular threat model.
You want UNprovable security, with a duress filesystem.

Set up a cryptographic filesystem where some blocks are filled with encrypted
data, and some are filled with garbage.  There are various keys that identify
which parts of the filesystem that are in which filesystem and how to read
them.  To use some of the files, you supply just the keys you need, and leave
most of the disk as untouched garbage.

If someone demands that you decrypt your disk, all you can do is provide them
some of the keys, which reveals some of the disk contents, but leaves a lot
of suspiscious garbage left.  But since you always have some real garbage
left on the disk, you can't prove that you've told them everything, even
if you wanted to.  (This lets you conceal a key or two, since it would
look like you had anyway.)

Don't do this unless your data is quite valuable:  The rational police
response is to apply as much pressure as would coerce the most stubborn
suspect, so expect to spend several years in jail for contempt of court
(or your local equivalent) should you get raided with such a thing.

I'm not aware of any actual implementations, unfortunately.

The usual reference for this sort of thing is the cypherpunks list.

Jon Leonard



Re: root fs/crypted

2001-05-30 Thread Jan Niehusmann
On Wed, May 30, 2001 at 01:08:21AM -0700, [EMAIL PROTECTED] wrote:
> Couldn't you say something like "I'm so sorry, I can't remember the pass
> phrase, my mind has failed me...etc?"

What about a more provable approach: 

The passphrase could be changed automatically on every system
boot, and the new passphrase could be written to a floppy disk
on a clean shutdown (which, of course, is only possible with
the root password).

So if the police takes the computer and doesn't do the clean
shutdown (how could they?), you can tell them: Sorry folks,
you just destroyed the possibility to get any data from that computer...

This, of course, means that you lose your data if the computer 
crashes. 

Jan



Re: root fs/crypted

2001-05-30 Thread paul
Couldn't you say something like "I'm so sorry, I can't remember the pass
phrase, my mind has failed me...etc?"

Are there real truth serums?

hehe,

Paul

Ethan Benson wrote:

> On Wed, May 30, 2001 at 03:01:17AM +0200, clemens wrote:
> >
> > SAWFASP^*
> >
> > as laws around the globe are forged to weak personal privacy,
> > police knocking on one's door, because of portscanning a
> > previously hacked website, and - i don't have to tell those
> > of you, which are reading slashdot - as pretty strange things start
> > to happend worldwide, i'm getting somewhat nervous about
> > my data safety.
>
> trouble is when your dealing with corrupt/fascist/evil
> government/regimes encryption isn't going to do you much good, either
> they will throw you in prison for refusing to disclose the decryption
> key or worse they will use methods that make you very very eager to
> reveal it
>
> stegfs *might* but then again if the entity your dealing with is
> horrible enough it won't matter whether or not the alleged data really
> exists or not, if they think it does then...
>
> --
> Ethan Benson
> http://www.alaska.net/~erbenson/
>
>   
>Part 1.2Type: application/pgp-signature



Re: root fs/crypted

2001-05-30 Thread Ethan Benson
On Wed, May 30, 2001 at 03:01:17AM +0200, clemens wrote:
> 
> SAWFASP^*
> 
> as laws around the globe are forged to weak personal privacy, 
> police knocking on one's door, because of portscanning a
> previously hacked website, and - i don't have to tell those
> of you, which are reading slashdot - as pretty strange things start
> to happend worldwide, i'm getting somewhat nervous about
> my data safety.

trouble is when your dealing with corrupt/fascist/evil
government/regimes encryption isn't going to do you much good, either
they will throw you in prison for refusing to disclose the decryption
key or worse they will use methods that make you very very eager to
reveal it

stegfs *might* but then again if the entity your dealing with is
horrible enough it won't matter whether or not the alleged data really
exists or not, if they think it does then...

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpmD1sUWbJ5N.pgp
Description: PGP signature


Re: root fs/crypted

2001-05-30 Thread Zak Kipling
On Tue, 29 May 2001 [EMAIL PROTECTED] wrote:

> I see it as more than this. I see it as ensuring that the data on the disk 
> does
> not get accessed by anyone never intended to see it. (physically, of course).
> I guess this would mostly be cool for thwarting things like police raids,

Although in some countries (eg Britain) you can be required by law to
disclose the decryption keys, and imprisoned if you fail to do so. The
only way around this is to use a steganographic approach where, in the
absence of the passphrase for a given set of data, it is impossible even
to prove its existence.

(I have in the past used StegFS, although it didn't seem stable enough for
critical use, and it doesn't work on 2.4 kernels yet. However, it seemed a
very promising concept.)

> servers vulnerable in remote locations (e.g. colocation, etc). My opinion is,
> with privacy, you can never have too much.

Very true, although a *false* sense of privacy can of course be worse than
none at all -- so it is important that any such system is implemented with
a lot of forethought.

Just my 2p worth...

Zak.




Re: root fs/crypted

2001-05-30 Thread Zak Kipling

On Wed, 30 May 2001, Jon Leonard wrote:

> I'm not aware of any actual implementations, unfortunately.

http://www.mcdonald.org.uk/StegFS/


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-30 Thread Jon Leonard

On Wed, May 30, 2001 at 10:46:19AM +0200, Jan Niehusmann wrote:
> On Wed, May 30, 2001 at 01:08:21AM -0700, [EMAIL PROTECTED] wrote:
> > Couldn't you say something like "I'm so sorry, I can't remember the pass
> > phrase, my mind has failed me...etc?"
> 
> What about a more provable approach: 
> 
> The passphrase could be changed automatically on every system
> boot, and the new passphrase could be written to a floppy disk
> on a clean shutdown (which, of course, is only possible with
> the root password).
> 
> So if the police takes the computer and doesn't do the clean
> shutdown (how could they?), you can tell them: Sorry folks,
> you just destroyed the possibility to get any data from that computer...
> 
> This, of course, means that you lose your data if the computer 
> crashes. 

This is likely solving the wrong problem, your security is almost never
limited by cryptographic strength, but rather by human factors or other
non-cryptographic weaknesses.

However, there is a known answer to this particular threat model.
You want UNprovable security, with a duress filesystem.

Set up a cryptographic filesystem where some blocks are filled with encrypted
data, and some are filled with garbage.  There are various keys that identify
which parts of the filesystem that are in which filesystem and how to read
them.  To use some of the files, you supply just the keys you need, and leave
most of the disk as untouched garbage.

If someone demands that you decrypt your disk, all you can do is provide them
some of the keys, which reveals some of the disk contents, but leaves a lot
of suspiscious garbage left.  But since you always have some real garbage
left on the disk, you can't prove that you've told them everything, even
if you wanted to.  (This lets you conceal a key or two, since it would
look like you had anyway.)

Don't do this unless your data is quite valuable:  The rational police
response is to apply as much pressure as would coerce the most stubborn
suspect, so expect to spend several years in jail for contempt of court
(or your local equivalent) should you get raided with such a thing.

I'm not aware of any actual implementations, unfortunately.

The usual reference for this sort of thing is the cypherpunks list.

Jon Leonard


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-30 Thread Jan Niehusmann

On Wed, May 30, 2001 at 01:08:21AM -0700, [EMAIL PROTECTED] wrote:
> Couldn't you say something like "I'm so sorry, I can't remember the pass
> phrase, my mind has failed me...etc?"

What about a more provable approach: 

The passphrase could be changed automatically on every system
boot, and the new passphrase could be written to a floppy disk
on a clean shutdown (which, of course, is only possible with
the root password).

So if the police takes the computer and doesn't do the clean
shutdown (how could they?), you can tell them: Sorry folks,
you just destroyed the possibility to get any data from that computer...

This, of course, means that you lose your data if the computer 
crashes. 

Jan


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-30 Thread paul
I see it as more than this. I see it as ensuring that the data on the disk does
not get accessed by anyone never intended to see it. (physically, of course).
I guess this would mostly be cool for thwarting things like police raids,
servers vulnerable in remote locations (e.g. colocation, etc). My opinion is,
with privacy, you can never have too much.


Thanks,

Paul
[EMAIL PROTECTED]
The price of freedom is eternal vigilence.


Curt Howland wrote:

> there is already a HowTo on how to create an encrypted
> loop-back "file system". it doesn't encrypt the whole
> disk, but it could certainly hold anything worth having
> encrypted.
>
> don't get me wrong, i fully understand the reasons behind
> putting the entire system behind a good pass-phrase. with
> the way *nix's put configuration files, data files, manuals,
> binaries, etc in so many different places, the only way to
> be absolutely sure would be to encrypt everything.
>
> but that only works at startup. if the system is running,
> having the entire disk encrypted is no different than the
> fact it's all in hex already. an individual user based
> encryption means all you have to do is logout, not power
> down, to kill the "decryption" process and thwart snooping.
>
> so how about a start-up passphrase protecting everything
> owned by root, then another for each individual user? but
> that would cancel root's ability to read everything
>
> hmmm.
>
> Curt-
>
> -Original Message-
> From: Paul Lowe [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 30, 2001 12:03
> To: clemens; debian-security@lists.debian.org
> Subject: Re: root fs/crypted
>
> I like this. Would it be difficult to modify Debian, so that
> upon install, it creates an encrypted root volume and starts
> things off the right way?
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: root fs/crypted

2001-05-30 Thread paul

Couldn't you say something like "I'm so sorry, I can't remember the pass
phrase, my mind has failed me...etc?"

Are there real truth serums?

hehe,

Paul

Ethan Benson wrote:

> On Wed, May 30, 2001 at 03:01:17AM +0200, clemens wrote:
> >
> > SAWFASP^*
> >
> > as laws around the globe are forged to weak personal privacy,
> > police knocking on one's door, because of portscanning a
> > previously hacked website, and - i don't have to tell those
> > of you, which are reading slashdot - as pretty strange things start
> > to happend worldwide, i'm getting somewhat nervous about
> > my data safety.
>
> trouble is when your dealing with corrupt/fascist/evil
> government/regimes encryption isn't going to do you much good, either
> they will throw you in prison for refusing to disclose the decryption
> key or worse they will use methods that make you very very eager to
> reveal it
>
> stegfs *might* but then again if the entity your dealing with is
> horrible enough it won't matter whether or not the alleged data really
> exists or not, if they think it does then...
>
> --
> Ethan Benson
> http://www.alaska.net/~erbenson/
>
>   
>Part 1.2Type: application/pgp-signature


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-30 Thread Ethan Benson

On Wed, May 30, 2001 at 03:01:17AM +0200, clemens wrote:
> 
> SAWFASP^*
> 
> as laws around the globe are forged to weak personal privacy, 
> police knocking on one's door, because of portscanning a
> previously hacked website, and - i don't have to tell those
> of you, which are reading slashdot - as pretty strange things start
> to happend worldwide, i'm getting somewhat nervous about
> my data safety.

trouble is when your dealing with corrupt/fascist/evil
government/regimes encryption isn't going to do you much good, either
they will throw you in prison for refusing to disclose the decryption
key or worse they will use methods that make you very very eager to
reveal it

stegfs *might* but then again if the entity your dealing with is
horrible enough it won't matter whether or not the alleged data really
exists or not, if they think it does then...

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

 PGP signature


Re: root fs/crypted

2001-05-30 Thread Zak Kipling

On Tue, 29 May 2001 [EMAIL PROTECTED] wrote:

> I see it as more than this. I see it as ensuring that the data on the disk does
> not get accessed by anyone never intended to see it. (physically, of course).
> I guess this would mostly be cool for thwarting things like police raids,

Although in some countries (eg Britain) you can be required by law to
disclose the decryption keys, and imprisoned if you fail to do so. The
only way around this is to use a steganographic approach where, in the
absence of the passphrase for a given set of data, it is impossible even
to prove its existence.

(I have in the past used StegFS, although it didn't seem stable enough for
critical use, and it doesn't work on 2.4 kernels yet. However, it seemed a
very promising concept.)

> servers vulnerable in remote locations (e.g. colocation, etc). My opinion is,
> with privacy, you can never have too much.

Very true, although a *false* sense of privacy can of course be worse than
none at all -- so it is important that any such system is implemented with
a lot of forethought.

Just my 2p worth...

Zak.



--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-29 Thread paul

I see it as more than this. I see it as ensuring that the data on the disk does
not get accessed by anyone never intended to see it. (physically, of course).
I guess this would mostly be cool for thwarting things like police raids,
servers vulnerable in remote locations (e.g. colocation, etc). My opinion is,
with privacy, you can never have too much.


Thanks,

Paul
[EMAIL PROTECTED]
The price of freedom is eternal vigilence.


Curt Howland wrote:

> there is already a HowTo on how to create an encrypted
> loop-back "file system". it doesn't encrypt the whole
> disk, but it could certainly hold anything worth having
> encrypted.
>
> don't get me wrong, i fully understand the reasons behind
> putting the entire system behind a good pass-phrase. with
> the way *nix's put configuration files, data files, manuals,
> binaries, etc in so many different places, the only way to
> be absolutely sure would be to encrypt everything.
>
> but that only works at startup. if the system is running,
> having the entire disk encrypted is no different than the
> fact it's all in hex already. an individual user based
> encryption means all you have to do is logout, not power
> down, to kill the "decryption" process and thwart snooping.
>
> so how about a start-up passphrase protecting everything
> owned by root, then another for each individual user? but
> that would cancel root's ability to read everything
>
> hmmm.
>
> Curt-
>
> -Original Message-
> From: Paul Lowe [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 30, 2001 12:03
> To: clemens; [EMAIL PROTECTED]
> Subject: Re: root fs/crypted
>
> I like this. Would it be difficult to modify Debian, so that
> upon install, it creates an encrypted root volume and starts
> things off the right way?
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




RE: root fs/crypted

2001-05-29 Thread Curt Howland

there is already a HowTo on how to create an encrypted
loop-back "file system". it doesn't encrypt the whole
disk, but it could certainly hold anything worth having
encrypted.

don't get me wrong, i fully understand the reasons behind
putting the entire system behind a good pass-phrase. with
the way *nix's put configuration files, data files, manuals,
binaries, etc in so many different places, the only way to
be absolutely sure would be to encrypt everything.

but that only works at startup. if the system is running,
having the entire disk encrypted is no different than the
fact it's all in hex already. an individual user based
encryption means all you have to do is logout, not power
down, to kill the "decryption" process and thwart snooping.

so how about a start-up passphrase protecting everything
owned by root, then another for each individual user? but
that would cancel root's ability to read everything

hmmm.

Curt-

-Original Message-
From: Paul Lowe [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 30, 2001 12:03
To: clemens; debian-security@lists.debian.org
Subject: Re: root fs/crypted


I like this. Would it be difficult to modify Debian, so that
upon install, it creates an encrypted root volume and starts
things off the right way?



Re: root fs/crypted

2001-05-29 Thread Paul Lowe
I like this. Would it be difficult to modify Debian, so that
upon install, it creates an encrypted root volume and starts
things off the right way?

-Original Message-
From: clemens <[EMAIL PROTECTED]>
To: debian-security@lists.debian.org 
Date: Tuesday, May 29, 2001 6:04 PM
Subject: root fs/crypted


>
>SAWFASP^*
>
>as laws around the globe are forged to weak personal privacy,
>police knocking on one's door, because of portscanning a
>previously hacked website, and - i don't have to tell those
>of you, which are reading slashdot - as pretty strange things start
>to happend worldwide, i'm getting somewhat nervous about
>my data safety.
>
>what i'm aiming at, you might ask?
>debian should support a crypted rootfs right out
>of the box.
>
>i'll try to grasp within a few words, what's necessary to realize this:
>
>- the international kernel must be introduced as regular
>  debian packages.
>- the boot disks needs to be modified (just do a losetup
>  on some loopdev, and mount that one instead of the realrootdev)
>- of course, there must be an initrd to boot from,
>  which accepts authentication information.
>  (this ramdisk has to be placed unencrypted on
>   the rootfs, so the kernel code has to be circumwented or
>   the plain data has to be manually decrypted in usermode
>   to be re-encrypted to the original plain data when flushed
>   to disk.. easy for EBC mode crypto but harder to
>   achieve for CBC mode - creative suggestions welcome)
>- there must be an alternative passphrase, since i nor
>  any user will be willing to trust one forgetable phrase.
>  (how many times have you forgotten your mobil phone pin?)
>  suggestion: the actual key will be random generated, and
>  encrypted twice by two different passphrases/keys - one
>  choosen by the user, one random generated - useful to write on
>  a piece of paper and hide behind the bookshelf.
>
>(probably i should crosspost to debian-legal. the
>whole non-US issue has been left untouched)
>
>what do YOU think?
>shell debian be the first(?) privacy enhanced distro?
>
>clemens
>
>^* SAWFASP = searched archives without finding a similiar
>posting
>
>
>--
>To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
>



root fs/crypted

2001-05-29 Thread clemens

SAWFASP^*

as laws around the globe are forged to weak personal privacy, 
police knocking on one's door, because of portscanning a
previously hacked website, and - i don't have to tell those
of you, which are reading slashdot - as pretty strange things start
to happend worldwide, i'm getting somewhat nervous about
my data safety.

what i'm aiming at, you might ask? 
debian should support a crypted rootfs right out
of the box.

i'll try to grasp within a few words, what's necessary to realize this:

- the international kernel must be introduced as regular 
  debian packages. 
- the boot disks needs to be modified (just do a losetup
  on some loopdev, and mount that one instead of the realrootdev)
- of course, there must be an initrd to boot from, 
  which accepts authentication information.
  (this ramdisk has to be placed unencrypted on 
   the rootfs, so the kernel code has to be circumwented or
   the plain data has to be manually decrypted in usermode
   to be re-encrypted to the original plain data when flushed 
   to disk.. easy for EBC mode crypto but harder to
   achieve for CBC mode - creative suggestions welcome)
- there must be an alternative passphrase, since i nor
  any user will be willing to trust one forgetable phrase.
  (how many times have you forgotten your mobil phone pin?)
  suggestion: the actual key will be random generated, and 
  encrypted twice by two different passphrases/keys - one 
  choosen by the user, one random generated - useful to write on 
  a piece of paper and hide behind the bookshelf.

(probably i should crosspost to debian-legal. the 
whole non-US issue has been left untouched)

what do YOU think?
shell debian be the first(?) privacy enhanced distro?

clemens

^* SAWFASP = searched archives without finding a similiar 
posting



RE: root fs/crypted

2001-05-29 Thread Curt Howland


there is already a HowTo on how to create an encrypted
loop-back "file system". it doesn't encrypt the whole
disk, but it could certainly hold anything worth having
encrypted.

don't get me wrong, i fully understand the reasons behind
putting the entire system behind a good pass-phrase. with
the way *nix's put configuration files, data files, manuals,
binaries, etc in so many different places, the only way to
be absolutely sure would be to encrypt everything.

but that only works at startup. if the system is running,
having the entire disk encrypted is no different than the
fact it's all in hex already. an individual user based
encryption means all you have to do is logout, not power
down, to kill the "decryption" process and thwart snooping.

so how about a start-up passphrase protecting everything
owned by root, then another for each individual user? but
that would cancel root's ability to read everything

hmmm.

Curt-

-Original Message-
From: Paul Lowe [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 30, 2001 12:03
To: clemens; [EMAIL PROTECTED]
Subject: Re: root fs/crypted


I like this. Would it be difficult to modify Debian, so that
upon install, it creates an encrypted root volume and starts
things off the right way?


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: root fs/crypted

2001-05-29 Thread Paul Lowe

I like this. Would it be difficult to modify Debian, so that
upon install, it creates an encrypted root volume and starts
things off the right way?

-Original Message-
From: clemens <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, May 29, 2001 6:04 PM
Subject: root fs/crypted


>
>SAWFASP^*
>
>as laws around the globe are forged to weak personal privacy,
>police knocking on one's door, because of portscanning a
>previously hacked website, and - i don't have to tell those
>of you, which are reading slashdot - as pretty strange things start
>to happend worldwide, i'm getting somewhat nervous about
>my data safety.
>
>what i'm aiming at, you might ask?
>debian should support a crypted rootfs right out
>of the box.
>
>i'll try to grasp within a few words, what's necessary to realize this:
>
>- the international kernel must be introduced as regular
>  debian packages.
>- the boot disks needs to be modified (just do a losetup
>  on some loopdev, and mount that one instead of the realrootdev)
>- of course, there must be an initrd to boot from,
>  which accepts authentication information.
>  (this ramdisk has to be placed unencrypted on
>   the rootfs, so the kernel code has to be circumwented or
>   the plain data has to be manually decrypted in usermode
>   to be re-encrypted to the original plain data when flushed
>   to disk.. easy for EBC mode crypto but harder to
>   achieve for CBC mode - creative suggestions welcome)
>- there must be an alternative passphrase, since i nor
>  any user will be willing to trust one forgetable phrase.
>  (how many times have you forgotten your mobil phone pin?)
>  suggestion: the actual key will be random generated, and
>  encrypted twice by two different passphrases/keys - one
>  choosen by the user, one random generated - useful to write on
>  a piece of paper and hide behind the bookshelf.
>
>(probably i should crosspost to debian-legal. the
>whole non-US issue has been left untouched)
>
>what do YOU think?
>shell debian be the first(?) privacy enhanced distro?
>
>clemens
>
>^* SAWFASP = searched archives without finding a similiar
>posting
>
>
>--
>To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
>


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




root fs/crypted

2001-05-29 Thread clemens


SAWFASP^*

as laws around the globe are forged to weak personal privacy, 
police knocking on one's door, because of portscanning a
previously hacked website, and - i don't have to tell those
of you, which are reading slashdot - as pretty strange things start
to happend worldwide, i'm getting somewhat nervous about
my data safety.

what i'm aiming at, you might ask? 
debian should support a crypted rootfs right out
of the box.

i'll try to grasp within a few words, what's necessary to realize this:

- the international kernel must be introduced as regular 
  debian packages. 
- the boot disks needs to be modified (just do a losetup
  on some loopdev, and mount that one instead of the realrootdev)
- of course, there must be an initrd to boot from, 
  which accepts authentication information.
  (this ramdisk has to be placed unencrypted on 
   the rootfs, so the kernel code has to be circumwented or
   the plain data has to be manually decrypted in usermode
   to be re-encrypted to the original plain data when flushed 
   to disk.. easy for EBC mode crypto but harder to
   achieve for CBC mode - creative suggestions welcome)
- there must be an alternative passphrase, since i nor
  any user will be willing to trust one forgetable phrase.
  (how many times have you forgotten your mobil phone pin?)
  suggestion: the actual key will be random generated, and 
  encrypted twice by two different passphrases/keys - one 
  choosen by the user, one random generated - useful to write on 
  a piece of paper and hide behind the bookshelf.

(probably i should crosspost to debian-legal. the 
whole non-US issue has been left untouched)

what do YOU think?
shell debian be the first(?) privacy enhanced distro?

clemens

^* SAWFASP = searched archives without finding a similiar 
posting


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]