People will keep writing bad code, this is unavoidable, but what automated tests could be run to make sure to avoid the worst of it?
Automated testing for security problems doesn't really work. Oh, you can do fuzzing, but that's hit and miss, and general unit testing can catch a few things, but not much. Mostly, security code just requires very careful implementation and code review. Eyeballs -- smart, experienced eyeballs.
OpenSSL has terrified me for years. The code is very hard to read and understand, which is exactly the opposite of what's desired for easy review and validation of its security properties. It needs to be cleaned up and made as simple, straightforward and accessible as possible, or replaced with something else that is simple, straightforward and accessible. My theory on why it is the way it is -- and it's far from unusual in the crypto library world -- is that cryptographers tend not to be good software engineers, and software engineers tend not to have the cryptography skills needed.
I spend some (not very much, lately) of my time working on an open source crypto library called Keyczar that tries to address one part of this problem, by providing well-engineered crypto APIs that are easy to use and hard to misuse. That effort focuses on applying good engineering to the boundary between library and application code, which is another source of rampant problems, but Keyczar uses existing crypto libs to provide the actual implementations of the primitives (the C++ implementation uses openssl, actually). I've long wished we could find crypto libs that were well-engineered, both internally and in their APIs.
Then you are not going to be very productive anyway.
If you have to bribe people to code, they clearly do not enjoy coding.
They're not bribing girls to code. The gift certificates go to the teachers. And, actually, the certificates just give the teachers money they can donate to charities, not cash in their own pockets. So it's just a small incentive to motivate teachers to give girls a little more opportunity to find out whether they like coding.
On a serious note, Google actually takes gender discrimination in the workplace very seriously, and monitors gender-based statistics on hiring, pay scales, promotions, etc. and looks into any inequalities. Pay inequalities between genders at the same level in the hierarchy are very easy to fix, of course -- you just give raises to the people who are being paid less than their peers -- so they just fix those.
More subtle problems, such as women not getting promoted, are harder. In fact Google HR noticed a couple of years ago that there was no gender difference in promotions for those who applied (you have to nominate yourself for promotion in Google, and put together a packet demonstrating your track record of performing at the higher level), but that women nominated themselves at a lower rate than men, resulting in a net lower promotion rate for females. So, Google instituted some programs in which senior women reach out to and run workshops for junior women, encouraging them to nominate themselves for promotion, and also directed managers to be more aggressive about convincing their female subordinates to self-nominate.
So, no, Google doesn't want women because it can pay them less. What the company does want is greater diversity, because the data (everything is data-based at Google) shows that diverse teams are more productive and more creative. The company also wants to increase the size of the pool it can hire from because the limit to Google's ability to hire isn't finding qualified candidates who accept Google's offers, it's finding qualified candidates.
(Disclaimer: I work for Google but do not speak for Google. The above is only my opinions, based on my observations.)
I thought about this last night, as I was working on my taxes. A lot of my tax information has moved on-line and so to complete my return I needed to log into bank, brokerage, mortgage lender and other web sites... sites I'd really prefer to avoid logging into right now until I'm sure they've been made safe. I did test each of them with a Heartbleed testing tool before logging in, but most people won't know to do that. I really wish the US had opted to move the filing date back a week or two.
Many people seem to enjoy strict segregation of work and personal life. I don't. I like flexibility; I like being able to leave work for a few hours in the middle of the day to go to a kids' school play, or go for a bike ride, or go skiing (next winter I'll be working from home full-time, 20 minutes from a ski resort; I'm seriously planning to be skiing from 9-11 AM almost daily) or whatever. I like being able to, with a totally clear conscience, spend an hour reading and posting on slashdot or G+ or whatever. I also like being able to work in the evening when inspiration strikes, or to make up for time spent away from work during the day, or for whatever reason. Heck, maybe I just want to and for whatever reason don't have anything better to do just then.
I don't live to work, but I like my work, and I don't like drawing a sharp line separating work and non-work. I think that sort of separation is a recent invention anyway; historically work has been a part of life rather than walled off into a particular portion of each day. Of course, I have no objection to people who prefer to manage their work/life balance by sharply separating them. If that what works for them, more power to them. It's not my preference, though, and it's not the only way to balance the two. It's not something that should be legislated.
No, you're right and I was wrong. It's the memcpy call that causes the problem. For that matter, I have to concede the GPs point, at least partially. It's allowing memcpy to run off the end of rec_p that is the problem. I was thinking the garbage was left over in the allocation of buf, but that isn't the issue. I should have more than glanced at the code; I kind of fixated on the first dumb problem I saw.
This is not a memory management issue per se, and has nothing to do with mmap or malloc.
But what the grandparent post said still applies. It's how C treats memory via pointers. The issue, from looking at the code you posted, is that memcpy() copies from beyond the length of rec_p. In a sane language that doesn't treat memory as free-for-all, this isn't possible.
No, that's not the issue, in fact there really isn't any significant pointer arithmetic used here. Yeah, it does use a bit to pull the size field out of the incoming request, but there's nothing wrong with that part of the code.
The issue is that the code allocates a buffer of a size specified by the user, without validating it, and doesn't zero the allocated memory. Yes, many languages automatically zero heap-allocated arrays, which is good, but it's also a performance cost which is often unnecessary and there's nothing wrong (IMO) with not doing it by default. There is, however, plenty wrong with just accepting a user-provided value without validation, and with not completely overwriting heap-allocated memory before sending it.
It's worth pointing out that you can also shard SQL databases. Sharded MySQL is used pretty widely at Google, for example, especially for data that needs transactional consistency guarantees, not just eventual consistency, and/or lower long-tail latency. I've seen sharded MySQL scale to petabytes just fine.
The downsides, of course, are that you have to pick a value to shard on, you have to implement the sharding, and if you need to do a lot of cross-shard joins in interactive time frames, you're sunk. For batch processes, there's mapreduce, or for interactive queries that can stand update latency you can pump the data into a different database structured for that purpose.
In the short term, though, just use a regular, unsharded, SQL database. By the time you grow enough to need to shard it, or to move to a NoSQL solution, you'll be able to afford a team of engineers to build and migrate to the new solution.
I've been ADHD since the 8th grade in the 80's. I simply can't read a book without skimming and turning pages when I come upon a section that seems boring. Since moving to unabridged audiobooks I'm actually hearing the whole novel.
I notice the same thing. However, I think that switching to audio books (primarily for the convenience of being able to do other things while "reading") has also further decreased my ability to read without skimming. This sometimes gets to be a problem when I need to read technical documentation. I've begun to think I really need to make sure that I spend at least 15-30 minutes per day reading text which I don't want to skim.
(Note that building biometric security systems for general populations -- including the elderly -- was my day job for years. There are big problems with damage, illness and even day-to-day changes in hydration and other physical characteristics, but I never found age to be an issue, nor have I seen any research indicating it.)
It is. There are many tools out there that implement it. It's the whole reason that we use CAs -- not that they're an ideal solution to the problem, but without some way to verify the authenticity of the public key you're using to bootstrap the key exchange, any PK-based key agreement protocol is subject to MITM attacks.
Now that one person is doing it, everyone is going to have to do it. It's going to be difficult selling a 32-bit processor when the guy across the street is selling a 64-bit one.
There's a lot more reason to go 64 bit than that. The biggest is that it's not going to be long before smartphones and tablets have > 3 GiB RAM. Yeah, there are all sorts of workarounds you can use to access larger amounts of RAM with 32-bit pointers, but it's much nicer to have a flat address space, including plenty of address space for memory-mapped devices. Granted that we're probably a couple of years away from needing 64 bits, but it's coming, fast.
I feel like I'm spelling out the obvious, but: mail server A opens a TLS connection to mail server B to transfer mail, which starts with a TLS handshake, requiring B to send its public key A. The attacker intercepts the message and sends his public key to A, and completes the handshake with both sides, then proceeds to happily pass the data through reading all of it, since he has the session keys on both sides.
No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.
they needed to introduce a delay of 350ms as a way to make things fair for everyone.
Slight (well, three orders of magnitude:)) correction: That's 350 us, not 350 ms (microseconds, not milliseconds). So the proposed delay here is 1429X what the IEX guys found they needed to add.
I know 20+ people who have installed solar on lease options like this, and all of them report paying significantly less, net, for their electricity -- even though the lower cost per kWh has resulted in increased consumption. And this in an area where the power company pays basically nothing for power generated in excess of power consumed (unlike other areas where peak-time generation can be very lucrative).
MITM requires active interception to eavsdrop, wheras an unencrypted connection is vulnerable to passive eavesdropping.
Yes, of course. However, in practice the set of real-world circumstances in which an attacker manages to get sufficient physical access to eavesdrop without also getting sufficient physical access to perform active attacks are vanishingly small, at least in the wired networking space. For wireless it's different, of course (assuming there's no link-layer encryption applied), but inter-MTA transfers are almost never wireless.
And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.
I think you're arguing that would be a bad thing, but in reality it'd be a nearly-irrelevant thing. Without authentication, encryption protects only against the most casual of snoopers, most of whom wouldn't be able to sniff the packets anyway.
Which is not going to happen because the authors haven't given any reason why anyone should care. We have lots of widely-deployed ciphers which are fast and secure. No one attacks modern cryptographic security systems by breaking the ciphers, they do it by exploiting peripheral flaws in implementation, key management, etc.
A potential patent to deal with just to use it is one more nail in the coffin of this.
You are forgetting that once the existing cryptographic schemes are broken, we would probably need a replacement pretty fast. That's when this work could come in handy.
Assuming a method (or series of methods) sufficiently powerful to break all the existing cryptographic ciphers -- which use a variety of approaches -- wouldn't break this one as well. And assuming that this one actually is secure.
It's not. This has nothing to do with biology, other than being vaguely inspired by it. RTFA.
If so, it's just as stupid as biometrics.
After that information is stolen, you can't easily change it anymore.
Biometrics aren't stupid. They're all wrong for most of the common situations where we see them applied, but they're not inherently a bad idea. And the common/. meme about them being useless because they can't be changed is ridiculous, and arises from the -- badly broken -- analogy between biometric identification and password authentication.
Biometrics are useful as identifiers, and to the degree that the biometric scan and matching process can be trusted, you can bootstrap an identification to an authentication. The kicker is that level of trust. If the biometric scanner is deployed in a secure area, to ensure it's not tampered, and the scanning process is monitored to ensure that the object being scanned actually is the person to be identified, and the template storage and matching process are also adequately secured, then biometric authentication is awesome.
Alternatively, if the scanner isn't secured or monitored and the if security of the template store and matcher are also questionable, biometrics still aren't completely useless -- they just don't provide a significant level of assurance. If what you need is an extremely convenient way to unlock access with such low security needs that your other realistic alternative is to leave it unsecured, then biometrics are also fine. For example, if in the absence of a fingerprint reader you would leave your phone entirely unlocked, then unlocking it with a fingerprint is an improvement.
In between, in contexts where security requirements aren't high enough to justify all of the effort and expense needed to make biometrics really strong, but where some security is actually needed, then biometrics are useless. That doesn't make them stupid, it just makes them the wrong tool for the job.
To use a car analogy, it's like trying to haul a 53-foot semi trailer with a Honda Civic. Or maybe with a Bugatti Veyron, which if you can get it attached somehow might actually have the power to move the trailer, but you can't call the result a functional freight transporter.
Everyone knows the current encryption schemes can be broken if you can (even theoretically) throw enough resources at it.
Everyone who "knows" this is dead wrong. Resource-based, brute-force attacks on, say, AES-256, are completely pointless.
According to Landauer's Principle the lowest possible amount of energy required to perform a single elementary computation is 2.85*10^-21 J. This means that even with a perfectly-efficient computer, to perform 2^256 elementary computations (assuming that an AES-256 trial decryption is a single elementary operation, which it isn't, but I'll ignore that) you would need 3.3*10^56 J. That's a lot.
How much? Well, suppose we built a Dyson sphere and captured the entire energy output of the sun to power our perfectly-efficient computer. The annual output of the sun is 1.2*10^34 J, which means we'd need 2.75*10^22 years of solar energy to complete the search for one key. One problem with that: The sun won't last that long.
Okay, so instead of just using a Dyson sphere to capture naturally-produced solar energy, suppose we found a way to convert the entire mass of the sun to energy. The theoretical mass energy of the sun is 1.8*10^47 J. That means you'd actually need the mass of just under two billion suns -- as well as an ideal computer and the ability to gather and convert all of those suns to energy in order to perform 2^256 operations.
As Bruce Schneier put it in the intro to Applied Cryptography, brute force of a 256-bit keyspace is impossible until computers are made of something other than matter and and occupy something other than space.
Of course, the 128-bit keyspace is miniscule compared to the 256-bit key space... but it's still unimaginably huge. Well beyond anyone's capabilities for at least several decades, perhaps longer. Suppose you had a trillion computers, each of which could test a trillion keys per second, allowing you to test 10^24 keys per second. It would still take you 10 million years to search a 128-bit key space.
No, if "everyone knows" current encryption schemes can be broken by application of enough resources, then everyone is wrong. At least, if the "resources" you're applying are computational brute force. "Rubber hose" cryptanalysis, on the other hand, is much cheaper and more effective. But this scheme, whatever other strengths or weaknesses it may have, is no more resistant to rubber hose cryptanalysis than any other.
It's better to at least have encrypted email transfers than to only allow encrypted transfers from authenticated senders.
Better in what sense? Without authentication MITM attacks are trivial, making the encryption irrelevant.
If what you say is true (and it probably is) then the state of e-mail security is even worse than I thought it was. Most mail providers don't support TLS anyway, but without authentication it doesn't really matter if they do.
Slashdot Mirror
People will keep writing bad code, this is unavoidable, but what automated tests could be run to make sure to avoid the worst of it?
Automated testing for security problems doesn't really work. Oh, you can do fuzzing, but that's hit and miss, and general unit testing can catch a few things, but not much. Mostly, security code just requires very careful implementation and code review. Eyeballs -- smart, experienced eyeballs.
OpenSSL has terrified me for years. The code is very hard to read and understand, which is exactly the opposite of what's desired for easy review and validation of its security properties. It needs to be cleaned up and made as simple, straightforward and accessible as possible, or replaced with something else that is simple, straightforward and accessible. My theory on why it is the way it is -- and it's far from unusual in the crypto library world -- is that cryptographers tend not to be good software engineers, and software engineers tend not to have the cryptography skills needed.
I spend some (not very much, lately) of my time working on an open source crypto library called Keyczar that tries to address one part of this problem, by providing well-engineered crypto APIs that are easy to use and hard to misuse. That effort focuses on applying good engineering to the boundary between library and application code, which is another source of rampant problems, but Keyczar uses existing crypto libs to provide the actual implementations of the primitives (the C++ implementation uses openssl, actually). I've long wished we could find crypto libs that were well-engineered, both internally and in their APIs.
Then you are not going to be very productive anyway.
If you have to bribe people to code, they clearly do not enjoy coding.
They're not bribing girls to code. The gift certificates go to the teachers. And, actually, the certificates just give the teachers money they can donate to charities, not cash in their own pockets. So it's just a small incentive to motivate teachers to give girls a little more opportunity to find out whether they like coding.
...so they can pay them less. amirite?
:-)
On a serious note, Google actually takes gender discrimination in the workplace very seriously, and monitors gender-based statistics on hiring, pay scales, promotions, etc. and looks into any inequalities. Pay inequalities between genders at the same level in the hierarchy are very easy to fix, of course -- you just give raises to the people who are being paid less than their peers -- so they just fix those.
More subtle problems, such as women not getting promoted, are harder. In fact Google HR noticed a couple of years ago that there was no gender difference in promotions for those who applied (you have to nominate yourself for promotion in Google, and put together a packet demonstrating your track record of performing at the higher level), but that women nominated themselves at a lower rate than men, resulting in a net lower promotion rate for females. So, Google instituted some programs in which senior women reach out to and run workshops for junior women, encouraging them to nominate themselves for promotion, and also directed managers to be more aggressive about convincing their female subordinates to self-nominate.
http://www.businessinsider.com/google-hiring-data-reveals-two-things-women-can-do-to-get-hired-and-promoted-more-2012-8
So, no, Google doesn't want women because it can pay them less. What the company does want is greater diversity, because the data (everything is data-based at Google) shows that diverse teams are more productive and more creative. The company also wants to increase the size of the pool it can hire from because the limit to Google's ability to hire isn't finding qualified candidates who accept Google's offers, it's finding qualified candidates.
(Disclaimer: I work for Google but do not speak for Google. The above is only my opinions, based on my observations.)
I thought about this last night, as I was working on my taxes. A lot of my tax information has moved on-line and so to complete my return I needed to log into bank, brokerage, mortgage lender and other web sites... sites I'd really prefer to avoid logging into right now until I'm sure they've been made safe. I did test each of them with a Heartbleed testing tool before logging in, but most people won't know to do that. I really wish the US had opted to move the filing date back a week or two.
Many people seem to enjoy strict segregation of work and personal life. I don't. I like flexibility; I like being able to leave work for a few hours in the middle of the day to go to a kids' school play, or go for a bike ride, or go skiing (next winter I'll be working from home full-time, 20 minutes from a ski resort; I'm seriously planning to be skiing from 9-11 AM almost daily) or whatever. I like being able to, with a totally clear conscience, spend an hour reading and posting on slashdot or G+ or whatever. I also like being able to work in the evening when inspiration strikes, or to make up for time spent away from work during the day, or for whatever reason. Heck, maybe I just want to and for whatever reason don't have anything better to do just then.
I don't live to work, but I like my work, and I don't like drawing a sharp line separating work and non-work. I think that sort of separation is a recent invention anyway; historically work has been a part of life rather than walled off into a particular portion of each day. Of course, I have no objection to people who prefer to manage their work/life balance by sharply separating them. If that what works for them, more power to them. It's not my preference, though, and it's not the only way to balance the two. It's not something that should be legislated.
No, you're right and I was wrong. It's the memcpy call that causes the problem. For that matter, I have to concede the GPs point, at least partially. It's allowing memcpy to run off the end of rec_p that is the problem. I was thinking the garbage was left over in the allocation of buf, but that isn't the issue. I should have more than glanced at the code; I kind of fixated on the first dumb problem I saw.
This is not a memory management issue per se, and has nothing to do with mmap or malloc.
But what the grandparent post said still applies. It's how C treats memory via pointers. The issue, from looking at the code you posted, is that memcpy() copies from beyond the length of rec_p. In a sane language that doesn't treat memory as free-for-all, this isn't possible.
No, that's not the issue, in fact there really isn't any significant pointer arithmetic used here. Yeah, it does use a bit to pull the size field out of the incoming request, but there's nothing wrong with that part of the code.
The issue is that the code allocates a buffer of a size specified by the user, without validating it, and doesn't zero the allocated memory. Yes, many languages automatically zero heap-allocated arrays, which is good, but it's also a performance cost which is often unnecessary and there's nothing wrong (IMO) with not doing it by default. There is, however, plenty wrong with just accepting a user-provided value without validation, and with not completely overwriting heap-allocated memory before sending it.
Shards! It has shards!
:-)
It's worth pointing out that you can also shard SQL databases. Sharded MySQL is used pretty widely at Google, for example, especially for data that needs transactional consistency guarantees, not just eventual consistency, and/or lower long-tail latency. I've seen sharded MySQL scale to petabytes just fine.
The downsides, of course, are that you have to pick a value to shard on, you have to implement the sharding, and if you need to do a lot of cross-shard joins in interactive time frames, you're sunk. For batch processes, there's mapreduce, or for interactive queries that can stand update latency you can pump the data into a different database structured for that purpose.
In the short term, though, just use a regular, unsharded, SQL database. By the time you grow enough to need to shard it, or to move to a NoSQL solution, you'll be able to afford a team of engineers to build and migrate to the new solution.
I've been ADHD since the 8th grade in the 80's. I simply can't read a book without skimming and turning pages when I come upon a section that seems boring. Since moving to unabridged audiobooks I'm actually hearing the whole novel.
I notice the same thing. However, I think that switching to audio books (primarily for the convenience of being able to do other things while "reading") has also further decreased my ability to read without skimming. This sometimes gets to be a problem when I need to read technical documentation. I've begun to think I really need to make sure that I spend at least 15-30 minutes per day reading text which I don't want to skim.
Cite?
(Note that building biometric security systems for general populations -- including the elderly -- was my day job for years. There are big problems with damage, illness and even day-to-day changes in hydration and other physical characteristics, but I never found age to be an issue, nor have I seen any research indicating it.)
It is. There are many tools out there that implement it. It's the whole reason that we use CAs -- not that they're an ideal solution to the problem, but without some way to verify the authenticity of the public key you're using to bootstrap the key exchange, any PK-based key agreement protocol is subject to MITM attacks.
Why are you designing your drone for x86? Are you writing it in assembly code?
He's running Windows on it, duh.
Now that one person is doing it, everyone is going to have to do it. It's going to be difficult selling a 32-bit processor when the guy across the street is selling a 64-bit one.
There's a lot more reason to go 64 bit than that. The biggest is that it's not going to be long before smartphones and tablets have > 3 GiB RAM. Yeah, there are all sorts of workarounds you can use to access larger amounts of RAM with 32-bit pointers, but it's much nicer to have a flat address space, including plenty of address space for memory-mapped devices. Granted that we're probably a couple of years away from needing 64 bits, but it's coming, fast.
I feel like I'm spelling out the obvious, but: mail server A opens a TLS connection to mail server B to transfer mail, which starts with a TLS handshake, requiring B to send its public key A. The attacker intercepts the message and sends his public key to A, and completes the handshake with both sides, then proceeds to happily pass the data through reading all of it, since he has the session keys on both sides.
No, but I understand why you'd think this, as it seems to be a common misconception. If you have a specific example to illustrate this case, that would help.
MITM attack.
they needed to introduce a delay of 350ms as a way to make things fair for everyone.
Slight (well, three orders of magnitude :)) correction: That's 350 us, not 350 ms (microseconds, not milliseconds). So the proposed delay here is 1429X what the IEX guys found they needed to add.
I know 20+ people who have installed solar on lease options like this, and all of them report paying significantly less, net, for their electricity -- even though the lower cost per kWh has resulted in increased consumption. And this in an area where the power company pays basically nothing for power generated in excess of power consumed (unlike other areas where peak-time generation can be very lucrative).
MITM requires active interception to eavsdrop, wheras an unencrypted connection is vulnerable to passive eavesdropping.
Yes, of course. However, in practice the set of real-world circumstances in which an attacker manages to get sufficient physical access to eavesdrop without also getting sufficient physical access to perform active attacks are vanishingly small, at least in the wired networking space. For wireless it's different, of course (assuming there's no link-layer encryption applied), but inter-MTA transfers are almost never wireless.
And the reason I think that's true is that one isn't required to purchase a CA-signed certificate to get that working. If we all had to purchase a CA-signed certificate, I think it would become more rare to see TLS transfers to/from privately-held servers.
I think you're arguing that would be a bad thing, but in reality it'd be a nearly-irrelevant thing. Without authentication, encryption protects only against the most casual of snoopers, most of whom wouldn't be able to sniff the packets anyway.
Which is not going to happen because the authors haven't given any reason why anyone should care. We have lots of widely-deployed ciphers which are fast and secure. No one attacks modern cryptographic security systems by breaking the ciphers, they do it by exploiting peripheral flaws in implementation, key management, etc.
A potential patent to deal with just to use it is one more nail in the coffin of this.
An excellent point.
You are forgetting that once the existing cryptographic schemes are broken, we would probably need a replacement pretty fast. That's when this work could come in handy.
Assuming a method (or series of methods) sufficiently powerful to break all the existing cryptographic ciphers -- which use a variety of approaches -- wouldn't break this one as well. And assuming that this one actually is secure.
What they haven''t shown is a lower bound for brute for attack complexity, or why it is resistant to any of the normal attack methods.
Or why anyone would care. Supposing it is secure, what features does it have that make it better than, say, AES?
I wonder if the crypto key is tied to your body.
It's not. This has nothing to do with biology, other than being vaguely inspired by it. RTFA.
If so, it's just as stupid as biometrics.
After that information is stolen, you can't easily change it anymore.
Biometrics aren't stupid. They're all wrong for most of the common situations where we see them applied, but they're not inherently a bad idea. And the common /. meme about them being useless because they can't be changed is ridiculous, and arises from the -- badly broken -- analogy between biometric identification and password authentication.
Biometrics are useful as identifiers, and to the degree that the biometric scan and matching process can be trusted, you can bootstrap an identification to an authentication. The kicker is that level of trust. If the biometric scanner is deployed in a secure area, to ensure it's not tampered, and the scanning process is monitored to ensure that the object being scanned actually is the person to be identified, and the template storage and matching process are also adequately secured, then biometric authentication is awesome.
Alternatively, if the scanner isn't secured or monitored and the if security of the template store and matcher are also questionable, biometrics still aren't completely useless -- they just don't provide a significant level of assurance. If what you need is an extremely convenient way to unlock access with such low security needs that your other realistic alternative is to leave it unsecured, then biometrics are also fine. For example, if in the absence of a fingerprint reader you would leave your phone entirely unlocked, then unlocking it with a fingerprint is an improvement.
In between, in contexts where security requirements aren't high enough to justify all of the effort and expense needed to make biometrics really strong, but where some security is actually needed, then biometrics are useless. That doesn't make them stupid, it just makes them the wrong tool for the job.
To use a car analogy, it's like trying to haul a 53-foot semi trailer with a Honda Civic. Or maybe with a Bugatti Veyron, which if you can get it attached somehow might actually have the power to move the trailer, but you can't call the result a functional freight transporter.
Everyone knows the current encryption schemes can be broken if you can (even theoretically) throw enough resources at it.
Everyone who "knows" this is dead wrong. Resource-based, brute-force attacks on, say, AES-256, are completely pointless.
According to Landauer's Principle the lowest possible amount of energy required to perform a single elementary computation is 2.85*10^-21 J. This means that even with a perfectly-efficient computer, to perform 2^256 elementary computations (assuming that an AES-256 trial decryption is a single elementary operation, which it isn't, but I'll ignore that) you would need 3.3*10^56 J. That's a lot.
How much? Well, suppose we built a Dyson sphere and captured the entire energy output of the sun to power our perfectly-efficient computer. The annual output of the sun is 1.2*10^34 J, which means we'd need 2.75*10^22 years of solar energy to complete the search for one key. One problem with that: The sun won't last that long.
Okay, so instead of just using a Dyson sphere to capture naturally-produced solar energy, suppose we found a way to convert the entire mass of the sun to energy. The theoretical mass energy of the sun is 1.8*10^47 J. That means you'd actually need the mass of just under two billion suns -- as well as an ideal computer and the ability to gather and convert all of those suns to energy in order to perform 2^256 operations.
As Bruce Schneier put it in the intro to Applied Cryptography, brute force of a 256-bit keyspace is impossible until computers are made of something other than matter and and occupy something other than space.
Of course, the 128-bit keyspace is miniscule compared to the 256-bit key space... but it's still unimaginably huge. Well beyond anyone's capabilities for at least several decades, perhaps longer. Suppose you had a trillion computers, each of which could test a trillion keys per second, allowing you to test 10^24 keys per second. It would still take you 10 million years to search a 128-bit key space.
No, if "everyone knows" current encryption schemes can be broken by application of enough resources, then everyone is wrong. At least, if the "resources" you're applying are computational brute force. "Rubber hose" cryptanalysis, on the other hand, is much cheaper and more effective. But this scheme, whatever other strengths or weaknesses it may have, is no more resistant to rubber hose cryptanalysis than any other.
It's better to at least have encrypted email transfers than to only allow encrypted transfers from authenticated senders.
Better in what sense? Without authentication MITM attacks are trivial, making the encryption irrelevant.
If what you say is true (and it probably is) then the state of e-mail security is even worse than I thought it was. Most mail providers don't support TLS anyway, but without authentication it doesn't really matter if they do.