Not only should the article written by the firm specializing in password security be taken with some salt, but it is also a good idea to add salt to passwords.
The public key support for eCryptfs can handle more than just public keys. It includes a communication mechanism with a user daemon that can be queried from the kernel on file open events. There is a pluggable key module interface accessible through that daemon. OpenSSL is currently implemented, but there is nothing stopping anyone from writing a module to use GnuPG or any other key management/encryption backend, all in userspace. The module just needs to accept a key signature, and it can perform encryption and decryption based on whatever that signature refers to.
In other news, eCryptfs has recently been given the go-ahead for inclusion into Fedora:
My uncle just retired as a commercial pilot. I asked him about the bending wings once, and he told me that one of the standard certification tests done by the FAA on new aircraft is to basically twist the wings until they break. He told me that sometimes the wings bend to a full 90 degrees before that happens.
For those who have not caught wind of this yet, transactional memory is currently the most promising solution to this problem and perhaps the most-covered subject in research conferences on parallel computing today. There have been several proposals for both hardware-based (at the cache level) and software-based architectures. Transactional memory greatly simplifies concurrent programming. When using transactions instead of locks, deadlocks go away completely and there is increased concurrency.
If you don't necessarily need plausible deniability, and if you're looking for per-file encryption with just as much transparency and a lot more flexibility, check out eCryptfs. It can be used directly on top of your existing mounted filesystem in Linux. eCryptfs has been in the mainline Linux kernel since 2.6.19. Here is a section in the eCryptfs FAQ that compares and contrasts block device encryption with stacked filesystem encryption:
Contains the phrase (in Italian), ``Il fumo uccide.'' Translated into English, that reads, ``Smoking kills.'' Can you imagine something that bold and straightforward being printed on a carton sold in the U.S.? I think this illustrates the level of influence that the tabacco industry has in American politics, in comparison to other countries.
One of the many work items on the queue is to allow the metadata to be stored in the file header or in the extended attributes at the user's request; for now, the metadata resides only in the file header for maximum compatibility. Furthermore, extended attribute storage space is very limited in most filesystems (e.g., 512 bytes). In most cases, this is not a problem, but then number of keys that can be associated with any given file is arbitrarily limited. Also, extended attributes are somewhat of an afterthought for filesystems like ext2/3; the performance is abysmal. Lastly, common userspace tools like tar are not extended attribute-aware; users have to know to use star, for instance. eCryptfs will probably support EA's eventually, but due to the many problems with EA's, there are many higher-priority work items ahead of that at the moment.
What eCryptfs does not solve is the issue of system integrity, and secure temporary storage.
Right. eCryptfs currently only provides data confidentiality for persistent storage in the event of compromise of your physical media. There is other software available to provide integrity (SLIM) and secure swap space (dm-crypt with a random key on boot).
How does it differ from encfs (http://encfs.sourceforge.net/)?
eCryptfs is kernel-native; EncFS is userspace. Since EncFS is userspace and depends on FUSE, shared memory mappings are not possible. Furthermore, FUSE incurs tremendous overhead with context switching between kernel and userspace; keeping everything native in the kernel during the page reads and writes is a big performance boost.
eCryptfs has an entire infrastructure that is geared toward complex cryptographic policies. This work has yet to be done, but for now, eCryptfs is at least as functional as EncFS when it comes to providing data confidentiality, but eCryptfs can provide full POSIX compliance and it does not incur the overhead of continually bouncing between kernel and userspace.
Ideally, we'd have FDE in hardware (using a TPM chip, perhaps) to prevent tampering of your libraries should you be out of control of the machine for some period of time. Even better is encrypting/signing the bootloader and every file along the way to the applications and data.
Integrity enforcement is an entirely different problem. If someone had access to your hardware at any time, all bets are off. Never mind replacing your system libraries; just install a physical key logger.
If you care about integrity enforcement on your machine, you can use a solution like SLIM in conjunction with eCryptfs on your laptop (to provide confidentiality), and you still do not need to encrypt every one of your system libraries.
dm-crypt is a block device encryption tool. eCryptfs is an actual cryptographic filesystem. Files can sit side-by-side in the same directory and be encrypted with entirely independent sets of keys. Incremental backup utilities can access the encrypted versions of the files. eCryptfs is an order of magnitude more complex and flexible than block device encryption tools.
eCryptfs is an actual filesystem operating at the VFS layer of the Linux kernel. It stacks on top of other filesystems like ext3 and encrypts files one at a time, with each file getting its own key.
Who cares about encrypting libc or the x.org libraries? People want to encrypt their financial, medical, and other such data. eCryptfs makes it easy to encrypt only what users want to encrypt.
Some ways that eCryptfs deals with the issues raised:
What happens when the user forgets his/her new FDE password?
The best answer is, ``You're screwed.'' That is the way it should be; without the secret, nobody -- not even you -- can get to the data.
Now, out here in reality, things can't be quite that convenient. Try telling the CEO that his third-quarter reports are lost forever. The next-best thing is intelligent key escrow. I tend to recommend (m,n)-threshold sharing, wherein a certain number of people in a group need to collude (say, 3 out of 5 people in the company) in order to reconstruct the secret value.
eCryptfs userspace tools have a pluggable key management infrastructure, and thus it can keep the secret value in any token device for which a module exists. These hardware devices do not need to be expensive. In fact, Thinkpads come with TPM chips built-in, and a TPM key module already exists for eCryptfs:
How to manage the encryption key backup files?> Who has possession of the backups of the encryption keys? What about when the users quits and does not hand over the password / encryption keys?
All of these are addressed with something like (m,n)-threshold sharing:
Also, because eCryptfs encrypts on a per-file basis, an incremental backup utility can just access the encrypted files on the lower filesystem. All of the information needed to decrypt the files is right in the header of each file; all you need is the key.
Who can access the system and its encrypted files?
This is a semantic security problem that the tools should definitely address. eCryptfs, in its current form, provides fairly flexible key management options, but the design goals of eCryptfs are much more ambitious, and they seek to address these sorts of issues:
How frequently does the password need to be changed?
Ideally, one would use eCryptfs in public key mode, so that is largely a non-issue. The secret can remain locked in a TPM chip, and the key can be escrowed.
How to prevent the user from writing the passwords down?
There is nothing wrong with writing passwords down, as long as the paper on which the passwords are written is stored in a location that can be made at least as secure as is necessary to protect the data that the passwords are protecting. In any event, the secret value can depend on a password *and* something else, like a file. The OpenSSL key module can be used in that way.
Using hardware token (RSA Token, smartcard etc) can alleviate many of the password management issues. But these hardware tokens are costly!
Not really; many laptops shipped today have TPM chips built-in.
Oh, yeah, and all of eCryptfs -- both the kernel and userspace components -- are GPL. Give it a try.
I just spent the last couple of days re-building my MythTV box after a drive failure (why, oh, why did I build my entire RAID out of Maxtor drives?). My RAID-5 corrupted the XFS filesystem (software bug). My last system was Debian/x86-based, and it ran pretty well for about 9 months. There were a few annoyances, mainly having to do with stability and a few hacked-together packages not quite working together (e.g., transcode). This time around, I went with Gentoo/x86_64, mainly so that video transcoding codecs will run faster. I have ivtv (PVR-250) and cx88 (HD3000) both working in a fully 64-bit environment. The system, so far, has been stable, and all of the parts are well-integrated and functional.
There is just one issue I need to work out at the moment; HDTV is consuming 100% CPU and skipping a lot on playback under MythTV. This was not happening under Debian/x86. I know I have XvMC working on the box; if I dump the mpeg video straight to disk from the capture card and then play back to XvMC under MPlayer, I get 20% CPU utilization, and the video plays back smoothly, so I'm going to have to do some investigation in to how to coax MythTV to use XvMC right.
Based on personal experience, I have a few bits of advice:
- Don't rely on RAID-5 (software or hardware) to save your butt when a hard drive fails; keep regular backups if your media -- including a dump of your mythconverg database -- on external media (e.g., a 750GB USB disk).
- Keep detailed notes about anything special you had to do to get your machine to work right. Print them out and tape them to the inside cover of your box. Keep copies of your configuration files (lirc, etc.) somewhere off the box.
- Once you have everything in your root partition the way you want it, tarball the whole thing up and burn it a couple of times out to DVD-R's. My complete installation, with original package files and all, weighs in at under 4 gigs when gzipped. Should I need to restore the system back to a functional state, I can go through the first few steps of a Gentoo minimum install and then simply untar the root partition image.
shemnon wrote: > one time pads can be broken, but the problem is you aren't sure you have broken it.
Any ``break'' that equates to generating random numbers and claiming that the result may be the original plaintext is not a ``break'' by any rational interpretation of the word. OTP ciphertext generated with cryptographically strong random pads cannot be cryptanalyzed or ``broken''; you must be able to at least partially reconstruct the pad to mount an attack.
*Everyone* knows by now that every time they find another fossil, was also have another gap in the fossil record. As time goes on, the number of gaps just keeps increasing!
It's all in the kernel, which means that shares memory mapping work (unlike userspace filesystems), and it keeps metadata on a per-file basis, which is *really* nice for things like incremental backup utilities.
Admins in the IT department can deploy an eCryptfs policy on employee workstations that indicates, for instance, that any data written to external storage devices is automatically and transparently encrypted according to a certain cryptographic context. We are working on implementing full policy support by the end of the summer, but in the meantime, eCryptfs will at least provide mount-wide passphrase protection today. For instance, eCryptfs will be able to be told, via IT policy, that ``any data written to/mnt/usbdrive must be encrypted with a public key with a certain ID, which is dynamically retrieved from the corporate PKI at the time that the file is created.'' For a preview of how we will go about doing this, check out the ``experimental'' branch from the CVS repository. In the meantime, if you want something functional today with only mount-wide passphrase support, get the ``testing'' branch. The tarball and the main branch will work too, but the ``testing'' is where I keep what I consider to be the most interesting version (it usually takes a week or so for changes in ``testing'' to migrate to the main branch).
Maybe human death rituals (e.g. burial, burning, leaving to vultures) got started because they ensured predators didn't profit from the death of the victim.
In Pascal Boyer's book, Religion Explained, he suggests that burial rituals may have formed for a variety of reasons. One idea is that burial rituals mark a transition between two states of being, since our human free agent inference system in our brains still think of the corpse as somehow still possessing an attribute of human-ness. In that way, burials can be viewed in the same light as other rite-of-passage rituals like baptism or marriage.
Another theory is that mentioned by the parent poster, in that dangerous scavangers are less likely to come near the clan looking for dead bodies to eat. The problem with that idea is that early humans were nomadic foragers, which would make it easy for them to avoid such an invasion. And then why do these early burials involve such unnecessary components as flowers, aligned horns, or tools? Furthermore, it would seem that risks of infection from a decaying body would present a more compelling reason to dispose of the body (burial, burning, ingesting by a spiritual specialist, etc.).
Death rituals are likely to stem from the natural human disposition that something must be done. I could go on for several more paragraphs, but this diversion has gone on far enough; those who would like to more fully investigate the phenomenon of burial should read chapter 6 of Boyer's book.
Onto the subject of being preyed upon by birds -- Joseph Campbell talks about experiments wherein scientists draw a wood cutout of a hawk on a string across a chicken pen. The chicks will scurry for cover when that happens. When the scientists drew the hawk across the pen backwards, the chicks did not react. Campbell identified this behavior as an innate releasing mechanism (IRM). It is somewhat like a hard-wired circuit in the brains of these animals that evolved through the selection pressure of millions of years of being hunted by hawks. Other posters have mentioned that perhaps that is why we are so fascinated by dragons and what not in our mythological tales. We have an inference system in our brains that is wired to evoke a stronger emotive response to the image of a big bird-like creature, and hence that leads to the adoption of the bird meme in the images of our culture.
At the end of the day, the bank is entrusted with managing my funds. If my bank transfers my funds to someone else without my express approval, then the bank is at fault, no questions asked. The bank should have properly verified that I indeed wanted my funds to be released to the other party. If someone claims to be me, then the bank better make damn sure to authenticate that it really is me before taking my money out of my account.
Slashdot Mirror
Looks like someone needs to drop the FCC a note to inform them that an Open Source operating system has somehow managed to achieve LSPP/EAL4+ Common Criteria security certification.
Not only should the article written by the firm specializing in password security be taken with some salt, but it is also a good idea to add salt to passwords.
Okay, that was a stretch.
The public key support for eCryptfs can handle more than just public keys. It includes a communication mechanism with a user daemon that can be queried from the kernel on file open events. There is a pluggable key module interface accessible through that daemon. OpenSSL is currently implemented, but there is nothing stopping anyone from writing a module to use GnuPG or any other key management/encryption backend, all in userspace. The module just needs to accept a key signature, and it can perform encryption and decryption based on whatever that signature refers to.
? id=218556
In other news, eCryptfs has recently been given the go-ahead for inclusion into Fedora:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi
In the meantime, you can grab all the userspace stuff from the eCryptfs SourceForge site:
http://ecryptfs.sourceforge.net/
Now is the time to buy a DX9 card. When DX11 comes out, then buy a DX10 card.
You might have more luck with MPlayer than you are currently having with the proprietary player.
http://www.mplayerhq.hu/design7/dload.html
My uncle just retired as a commercial pilot. I asked him about the bending wings once, and he told me that one of the standard certification tests done by the FAA on new aircraft is to basically twist the wings until they break. He told me that sometimes the wings bend to a full 90 degrees before that happens.
For those who have not caught wind of this yet, transactional memory is currently the most promising solution to this problem and perhaps the most-covered subject in research conferences on parallel computing today. There have been several proposals for both hardware-based (at the cache level) and software-based architectures. Transactional memory greatly simplifies concurrent programming. When using transactions instead of locks, deadlocks go away completely and there is increased concurrency.
If you don't necessarily need plausible deniability, and if you're looking for per-file encryption with just as much transparency and a lot more flexibility, check out eCryptfs. It can be used directly on top of your existing mounted filesystem in Linux. eCryptfs has been in the mainline Linux kernel since 2.6.19. Here is a section in the eCryptfs FAQ that compares and contrasts block device encryption with stacked filesystem encryption:
# compare
http://ecryptfs.sourceforge.net/ecryptfs-faq.html
Current versions of the Linux kernel have a key retention feature. For PKCS#11, there is openCryptoki.
The packet of cigarettes in this image:
4 4_setup.jpg
http://www.pctuner.info/test/results/200701221901
Contains the phrase (in Italian), ``Il fumo uccide.'' Translated into English, that reads, ``Smoking kills.'' Can you imagine something that bold and straightforward being printed on a carton sold in the U.S.? I think this illustrates the level of influence that the tabacco industry has in American politics, in comparison to other countries.
Encryption serves a whole lot of purposes other than keeping your data unreadable, such as guaranteeing integrety
Encryption does not provide integrity; it provides confidentiality.
One of the many work items on the queue is to allow the metadata to be stored in the file header or in the extended attributes at the user's request; for now, the metadata resides only in the file header for maximum compatibility. Furthermore, extended attribute storage space is very limited in most filesystems (e.g., 512 bytes). In most cases, this is not a problem, but then number of keys that can be associated with any given file is arbitrarily limited. Also, extended attributes are somewhat of an afterthought for filesystems like ext2/3; the performance is abysmal. Lastly, common userspace tools like tar are not extended attribute-aware; users have to know to use star, for instance. eCryptfs will probably support EA's eventually, but due to the many problems with EA's, there are many higher-priority work items ahead of that at the moment.
What eCryptfs does not solve is the issue of system integrity, and secure temporary storage.
Right. eCryptfs currently only provides data confidentiality for persistent storage in the event of compromise of your physical media. There is other software available to provide integrity (SLIM) and secure swap space (dm-crypt with a random key on boot).
How does it differ from encfs (http://encfs.sourceforge.net/)?
eCryptfs is kernel-native; EncFS is userspace. Since EncFS is userspace and depends on FUSE, shared memory mappings are not possible. Furthermore, FUSE incurs tremendous overhead with context switching between kernel and userspace; keeping everything native in the kernel during the page reads and writes is a big performance boost.
eCryptfs has an entire infrastructure that is geared toward complex cryptographic policies. This work has yet to be done, but for now, eCryptfs is at least as functional as EncFS when it comes to providing data confidentiality, but eCryptfs can provide full POSIX compliance and it does not incur the overhead of continually bouncing between kernel and userspace.
Ideally, we'd have FDE in hardware (using a TPM chip, perhaps) to prevent tampering of your libraries should you be out of control of the machine for some period of time. Even better is encrypting/signing the bootloader and every file along the way to the applications and data.
Integrity enforcement is an entirely different problem. If someone had access to your hardware at any time, all bets are off. Never mind replacing your system libraries; just install a physical key logger.
If you care about integrity enforcement on your machine, you can use a solution like SLIM in conjunction with eCryptfs on your laptop (to provide confidentiality), and you still do not need to encrypt every one of your system libraries.
How does this compare to dm-crypt and LUKS?
dm-crypt is a block device encryption tool. eCryptfs is an actual cryptographic filesystem. Files can sit side-by-side in the same directory and be encrypted with entirely independent sets of keys. Incremental backup utilities can access the encrypted versions of the files. eCryptfs is an order of magnitude more complex and flexible than block device encryption tools.
it seems like reinventing the wheel.
Read the paper:
http://ecryptfs.sourceforge.net/ecryptfs.pdf
A new addition to the 2.6.19 Linux kernel, eCryptfs, addresses many of these problems:
k start.html
http://ecryptfs.sf.net/
eCryptfs is an actual filesystem operating at the VFS layer of the Linux kernel. It stacks on top of other filesystems like ext3 and encrypts files one at a time, with each file getting its own key.
Who cares about encrypting libc or the x.org libraries? People want to encrypt their financial, medical, and other such data. eCryptfs makes it easy to encrypt only what users want to encrypt.
Some ways that eCryptfs deals with the issues raised:
What happens when the user forgets his/her new FDE password?
The best answer is, ``You're screwed.'' That is the way it should be; without the secret, nobody -- not even you -- can get to the data.
Now, out here in reality, things can't be quite that convenient. Try telling the CEO that his third-quarter reports are lost forever. The next-best thing is intelligent key escrow. I tend to recommend (m,n)-threshold sharing, wherein a certain number of people in a group need to collude (say, 3 out of 5 people in the company) in order to reconstruct the secret value.
eCryptfs userspace tools have a pluggable key management infrastructure, and thus it can keep the secret value in any token device for which a module exists. These hardware devices do not need to be expensive. In fact, Thinkpads come with TPM chips built-in, and a TPM key module already exists for eCryptfs:
http://trousers.sourceforge.net/tpm_keyring2/quic
How to manage the encryption key backup files?> Who has possession of the backups of the encryption keys? What about when the users quits and does not hand over the password / encryption keys?
All of these are addressed with something like (m,n)-threshold sharing:
http://en.wikipedia.org/wiki/Secret_sharing
Also, because eCryptfs encrypts on a per-file basis, an incremental backup utility can just access the encrypted files on the lower filesystem. All of the information needed to decrypt the files is right in the header of each file; all you need is the key.
Who can access the system and its encrypted files?
This is a semantic security problem that the tools should definitely address. eCryptfs, in its current form, provides fairly flexible key management options, but the design goals of eCryptfs are much more ambitious, and they seek to address these sorts of issues:
http://ecryptfs.sourceforge.net/ecryptfs.pdf
How frequently does the password need to be changed?
Ideally, one would use eCryptfs in public key mode, so that is largely a non-issue. The secret can remain locked in a TPM chip, and the key can be escrowed.
How to prevent the user from writing the passwords down?
There is nothing wrong with writing passwords down, as long as the paper on which the passwords are written is stored in a location that can be made at least as secure as is necessary to protect the data that the passwords are protecting. In any event, the secret value can depend on a password *and* something else, like a file. The OpenSSL key module can be used in that way.
Using hardware token (RSA Token, smartcard etc) can alleviate many of the password management issues. But these hardware tokens are costly!
Not really; many laptops shipped today have TPM chips built-in.
Oh, yeah, and all of eCryptfs -- both the kernel and userspace components -- are GPL. Give it a try.
I just spent the last couple of days re-building my MythTV box after a drive failure (why, oh, why did I build my entire RAID out of Maxtor drives?). My RAID-5 corrupted the XFS filesystem (software bug). My last system was Debian/x86-based, and it ran pretty well for about 9 months. There were a few annoyances, mainly having to do with stability and a few hacked-together packages not quite working together (e.g., transcode). This time around, I went with Gentoo/x86_64, mainly so that video transcoding codecs will run faster. I have ivtv (PVR-250) and cx88 (HD3000) both working in a fully 64-bit environment. The system, so far, has been stable, and all of the parts are well-integrated and functional.
There is just one issue I need to work out at the moment; HDTV is consuming 100% CPU and skipping a lot on playback under MythTV. This was not happening under Debian/x86. I know I have XvMC working on the box; if I dump the mpeg video straight to disk from the capture card and then play back to XvMC under MPlayer, I get 20% CPU utilization, and the video plays back smoothly, so I'm going to have to do some investigation in to how to coax MythTV to use XvMC right.
Based on personal experience, I have a few bits of advice:
- Don't rely on RAID-5 (software or hardware) to save your butt when a hard drive fails; keep regular backups if your media -- including a dump of your mythconverg database -- on external media (e.g., a 750GB USB disk).
- Keep detailed notes about anything special you had to do to get your machine to work right. Print them out and tape them to the inside cover of your box. Keep copies of your configuration files (lirc, etc.) somewhere off the box.
- Once you have everything in your root partition the way you want it, tarball the whole thing up and burn it a couple of times out to DVD-R's. My complete installation, with original package files and all, weighs in at under 4 gigs when gzipped. Should I need to restore the system back to a functional state, I can go through the first few steps of a Gentoo minimum install and then simply untar the root partition image.
I am disappointed to see that Justin Korelc and Ed Tittel entirely missed eCryptfs, which is already in the -mm tree of the Linux kernel.
shemnon wrote:
> one time pads can be broken, but the problem is you aren't sure you have broken it.
Any ``break'' that equates to generating random numbers and claiming that the result may be the original plaintext is not a ``break'' by any rational interpretation of the word. OTP ciphertext generated with cryptographically strong random pads cannot be cryptanalyzed or ``broken''; you must be able to at least partially reconstruct the pad to mount an attack.
*Everyone* knows by now that every time they find another fossil, was also have another gap in the fossil record. As time goes on, the number of gaps just keeps increasing!
Don't forget this new competitor: eCryptfs, mostly written and supported by IBM, and fully GPL:
http://ecryptfs.sf.net/
It's all in the kernel, which means that shares memory mapping work (unlike userspace filesystems), and it keeps metadata on a per-file basis, which is *really* nice for things like incremental backup utilities.
-----BEGIN PGP SIGNED MESSAGE-----
/mnt/usbdrive must be encrypted
;-)
9 uvLMmCyjRJNmzPW BjkMIfoUxoXWXU4 tcuDaquRL8KYRhB 8fDscdCJeLMw9ge IhOXmQqUGDbKNyP K7aw==
Hash: RIPEMD160
Lam1969 wrote:
> the possibility of companies breaking laws, whether for data-loss
> disclosure or regulatory compliance, is growing dramatically.
This is exactly the sort of scenario I had in mind when I designed
eCryptfs:
http://ecryptfs.sf.net/
Admins in the IT department can deploy an eCryptfs policy on employee
workstations that indicates, for instance, that any data written to
external storage devices is automatically and transparently encrypted
according to a certain cryptographic context. We are working on
implementing full policy support by the end of the summer, but in the
meantime, eCryptfs will at least provide mount-wide passphrase
protection today. For instance, eCryptfs will be able to be told, via
IT policy, that ``any data written to
with a public key with a certain ID, which is dynamically retrieved
from the corporate PKI at the time that the file is created.'' For a
preview of how we will go about doing this, check out the
``experimental'' branch from the CVS repository. In the meantime, if
you want something functional today with only mount-wide passphrase
support, get the ``testing'' branch. The tarball and the main branch
will work too, but the ``testing'' is where I keep what I consider to
be the most interesting version (it usually takes a week or so for
changes in ``testing'' to migrate to the main branch).
Oh, and it's Linux only. Of course.
Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iQEVAwUBQ9YyvdtAhTFtyodpAQN44QgAlr2+8KF5kIu5b4b+E
NTZ3Mz/Sq06gCzC7KddWWO6J5ivlW59EOV0qxPaNEFGnAgatF
N7b5Un/g/Ag5Et2kLKze8X+b1eAJlbtcl6kJXkc5SF/GDxsU7
K4Nx7+3CelIUVJ9c2/QPbooxb0yOfQnvncfA75RqLG8GwemSG
K/Y3l1U6FANWrxeH/PCwgZ+4AoLjRBWQBPD3TefhIV05m4kiy
qqWEcD8T+M0bOOdkEB2ZiwgRPI1sqwR1wh0RxOTbWnDGuJMUE
=gtQd
-----END PGP SIGNATURE-----
Maybe human death rituals (e.g. burial, burning, leaving to vultures) got started because they ensured predators didn't profit from the death of the victim.
In Pascal Boyer's book, Religion Explained, he suggests that burial rituals may have formed for a variety of reasons. One idea is that burial rituals mark a transition between two states of being, since our human free agent inference system in our brains still think of the corpse as somehow still possessing an attribute of human-ness. In that way, burials can be viewed in the same light as other rite-of-passage rituals like baptism or marriage.
Another theory is that mentioned by the parent poster, in that dangerous scavangers are less likely to come near the clan looking for dead bodies to eat. The problem with that idea is that early humans were nomadic foragers, which would make it easy for them to avoid such an invasion. And then why do these early burials involve such unnecessary components as flowers, aligned horns, or tools? Furthermore, it would seem that risks of infection from a decaying body would present a more compelling reason to dispose of the body (burial, burning, ingesting by a spiritual specialist, etc.).
Death rituals are likely to stem from the natural human disposition that something must be done. I could go on for several more paragraphs, but this diversion has gone on far enough; those who would like to more fully investigate the phenomenon of burial should read chapter 6 of Boyer's book.
Onto the subject of being preyed upon by birds -- Joseph Campbell talks about experiments wherein scientists draw a wood cutout of a hawk on a string across a chicken pen. The chicks will scurry for cover when that happens. When the scientists drew the hawk across the pen backwards, the chicks did not react. Campbell identified this behavior as an innate releasing mechanism (IRM). It is somewhat like a hard-wired circuit in the brains of these animals that evolved through the selection pressure of millions of years of being hunted by hawks. Other posters have mentioned that perhaps that is why we are so fascinated by dragons and what not in our mythological tales. We have an inference system in our brains that is wired to evoke a stronger emotive response to the image of a big bird-like creature, and hence that leads to the adoption of the bird meme in the images of our culture.
Bruce Schneier has long held the position that the banks need to be held fully responsible for this sort of fraudulant activity:
e a_solves_th.html
http://www.schneier.com/blog/archives/2005/12/kor
At the end of the day, the bank is entrusted with managing my funds. If my bank transfers my funds to someone else without my express approval, then the bank is at fault, no questions asked. The bank should have properly verified that I indeed wanted my funds to be released to the other party. If someone claims to be me, then the bank better make damn sure to authenticate that it really is me before taking my money out of my account.