Re: root fs/crypted
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]