Slashdot Mirror

Exactly. This email is (img src=http://myphishingsite.com/yourbank/verified.gi f)Verified!(/img).

And if you require any sort of verification that's stronger than a .gif, well, it's going to involve the email client executing something with the form of (script language = "exploit.js")

And if you go to two-factor authentication (like Bank of America did with "Sitekey"), you'll just further inconvenience the users on secure systems.

My box: lives behind NAT, and my web browser drops cookies after every session. User experience? Go to bank site, enter ID/pass. Because the cookie no longer exists, it doesn't "recognize" my box. So I have to enter a challenge question (one of 3 variations of "What's your mother's middle name", which means I have to remember three more passwords), and then enter my regular password a second time. I know I'm not being phished, because I see my "SiteKey" challenge image - but if I had been phished, I'd have already given up the keys to the kingdom.

Some Insecure Luser's Box: Is already compromised and is running any one of a zillion keyloggers. Cookie is present, so luser is prompted only for ID, not ID/pass. Luser enters ID, which is picked up by keylogger. Luser is shown their "SiteKey" challenge image - but the author of the keylogger doesn't give a rat's ass if it's correct or not. He logs the password. Luser is pwn3d.

The weakest link in this case isn't the end user, so much as it's the dumbfuck management at BofA who got sold a gallon of snake oil

The only reason most XP malware is so simplistic is because the defenses are so piss poor.

There have been some incredibly sophisticated rootkits out there in the past. One can easily fathom malware that _cannot_ be detected without booting from known good media, and performing a scan without excuting any on-system code.

there really only are a few different ways in which a bug can operate on the system. They all need startup access, (and there are only really two ways that they can get that, one being a standard location in the registry) and they're all going to leave a RAM/CPU footprint.

You're really incredibly wrong here. While this has been the rule so far, there is no reason that this will remain true. Most likely, it won't; the only reason current malware is dumb is because it can remain dumb and _succesful_.

Unix breakins are far, far more difficult to deal with then Windows breakins

This is not because Unix sucks. This is because Unix doesn't have a vast number of crappy script kiddies out there; the Unix black-hats are the real deal. And it happens in the Windows world, too; remember when Valve's source repository was stolen? (Valve produced Half-Life 2. There was a custom crack job into their systems.)

Its a fuzzy memory, but I remember reading one story where a rootkit was introduced into a compiler at an early stage in some system design. The rootkit'd compiler was used to compile the base system's binaries, and then was used to build future revisions (and a more complete version) of the compiler. I can't find the exact story, but here's a link to an attack experiment that does just that. Click
Basically, an attacker changes a compiler binary to produce malicious versions of some programs, INCLUDING ITSELF. Once this is done, the attack perpetuates, essentially undetectably. Thompson demonstrated the attack in a devastating way: he subverted a compiler of an experimental victim, allowing Thompson to log in as root without using a password. The victim never noticed the attack, even when they disassembled the binaries -- the compiler rigged the disassembler, too.

Of course, the nightmare scenario hasn't happened, and most likely won't. Imagine if someone seriously infiltrated the Windows development process; including Visual Studio. Don't snicker; GNU's development systems have been compromised, as has Valve's source repository. Both of these organizations have admin-level software running on many, many machines worldwide. Sure, someone would eventually find out if MS was rooted that badly, but imagine if there was a patch release, or an service pack, or something.

A vast number of systems worldwide would need to be manually booted from clean media in order to be restored. Scary.

Now, given that:

• Private businesses have a huge motive to avoid losing data -- when they do, customers are free to go elsewhere (and we do!)
• You're not free to "go elsewhere" when your Government loses your data
• Governments are likely to have way more sensitive and intrusive data than private businesses
• You typically know exactly what info, say, the credit card company has about you. You typically have no idea what info the government has about you.
• No database is 100% secure, no data is 100% safe -- especially not from humans with administrative access and plenty of reasons to leak the data
• Which do you trust to get IT right: a make-or-break project for a company, or Yet Another Government Project?

With all the above in mind, surely it makes sense to limit what data the Government collects, and to keep that data compartmentalized in local databases, rather than a nice, juicy, massive, single federal instance? Right!?!?!

Yet, that's exactly what is happening right now, with the "Real-ID" bill. (Here's what Bruce Schneier has to say on that).

Every single U.S. State except one has lined up like crack addicts to accept the federal money to implement Real-ID. That one State is New Hampshire, aka the Free State.

Here's a link to some pretty cool info about how and why the NH House rejected Real-ID:
http://freestateblogs.net/node/306

They do afer all specialize in some pretty high end hardware such as tamperproof encryption modules. If it were any other manufacturer I'm not sure I'd "buy it".

Heh. I know the guys who do the IBM 4758 and PCIXCC cards and they aren't involved with the fingerprint scanner on the notebooks.
IBM is a big company.

Although not IBM specific, here's a few links about the falibility of fingerprint scanners, the last one is tragically funny.

http://www.schneier.com/crypto-gram-0205.html#5
http://catless.ncl.ac.uk/Risks/22.37.html#subj4.1
http://www.schneier.com/crypto-gram-0205.html#5
http://news.bbc.co.uk/2/hi/asia-pacific/4396831.st m

They do afer all specialize in some pretty high end hardware such as tamperproof encryption modules. If it were any other manufacturer I'm not sure I'd "buy it".

Heh. I know the guys who do the IBM 4758 and PCIXCC cards and they aren't involved with the fingerprint scanner on the notebooks.
IBM is a big company.

Although not IBM specific, here's a few links about the falibility of fingerprint scanners, the last one is tragically funny.

http://www.schneier.com/crypto-gram-0205.html#5
http://catless.ncl.ac.uk/Risks/22.37.html#subj4.1
http://www.schneier.com/crypto-gram-0205.html#5
http://news.bbc.co.uk/2/hi/asia-pacific/4396831.st m

"it doesn't solve the security problem. One way to look at encryption is that it takes very long secrets--the message--and turns them into very short secrets: the key. With a one-time pad, you haven't shrunk the secret any. It's just as hard to courier the pad to the recipient as it is to courier the message itself...Any product that claims to use a one-time pad is almost certainly lying. And if they're not, the product is almost certainly unusable and/or insecure." --Secrets and Lies

... on the list of snake-oil warning signs.

From: http://www.schneier.com/blog/archives/2006/03/cred it_card_com.html

To understand why it's happening, you need to understand the trade-offs and the agenda. From the point of view of the credit card company, the benefits of giving someone a credit card is that he'll use it and generate revenue. The risk is that it's a fraudster who will cost the company revenue. The credit card industry has dealt with the risk in two ways: they've pushed a lot of the risk onto the merchants, and they've implemented fraud detection systems to limit the damage.

All other costs and problems of identity theft are borne by the consumer; they're an externality to the credit card company. They don't enter into the trade-off decision at all.

We can laugh at this kind of thing all day, but it's actually in the best interests of the credit card industry to mail cards in response to torn-up and taped-together applications without doing much checking of the address or phone number. If we want that to change, we need to fix the externality.

This was also covered in Bruce Schneier's Blog: Credit Card Companies and Agenda a few days back.

But we can file an objection... Here's mine. I'm open to suggested improvements:

Name
Address
Telephone Number

In re SONY BMG CD Technologies Litigation:

I am objecting to the settlement process on the grounds that,

A) The settlement excludes people who may not have purchased one of the listed compact disks from Sony/BMG, but have otherwise been affected by the software contained on it. It is conceivable that someone may have legally borrowed a compact disk, been affected by the rootkit, and have no receipt to file a claim in the settlement.

B) The settlement excludes people who may not have used any compact disk from Sony/BMG but may have otherwise been affected by the nature of the software. There has been no investigation into what, if any, personal information protected by law was surreptitiously obtained by Sony/BMG's use of the rootkit or by others who may have taken advantage of security holes left open by the rootkit itself.[1]

C) The settlement does not address the criminal actions of individuals at Sony/BMG. If this were the case of a "computer hacker" distributing a rootkit, that person would have been jailed on charges of computer trespass. Sony/BMG shipped an estimated 20,000,000 affected compact disks, some of which installed software REGARDLESS of whether or not the end user accepted the terms of their license agreement.[2] All members of the settlement class are potentially victims of Sony/BMG's criminal actions. Yet there have been, to my knowledge, no charges regarding criminal actions brought against Sony/BMG or any individual of that company.

[1] http://www.schneier.com/blog/archives/2005/11/sony s_drm_rootk.html
[2] http://www.freedom-to-tinker.com/?p=936

Hmmm, after that last bit, I wonder if I should instead file for exclusion. One or the other must be done before May 1, 2006. You can't do both... and I'll probably just get lip service from the courts with my objection...

RSA asymmetric key cryptography and Diffie-Hellman Key exchange are two fundamentally different procedures, although at the end of the day they allow two parties to come to the agreement of a shared secret.

One reason why no-one hears much about Diffie-Hellman is that Diffie-Hellman keys/parameters are usually generated per secure comms session and not persistently stored. Although the computational hit to do this is nothing like generating RSA pub/priv keys it is still a major bottleneck ( generating a big num in a required range ). With RSA you can generate your keys once, with DH you generate them per-session.

So in the context of a secure comms session. I could use RSA to wrap some AES ( for example ) keys and have my protocol up and running in a metter of seconds or I could use DH and take a 15-30 second hit ( 2048 bit keys ) to generate my DH paramaters, from which I can then generate a shared secret to act as a seed for my AES session keys.

If anyone is more interested in the area, I'd recomment Practical Cryptography and Applied Cryptography, both by Bruce Schneier. Both are excellent works for getting to know the algorithms inside-out and understanding how to implment communications security in the real world.

I think someone is confused here. RSA asymmetric key cryptography and Diffie-Hellman Key exchange are two fundamentally different procedures. Although at the end of the day allow two parts to come to the agreement of a shared secret, both also however suffer from the pain in the arse that is PKI. One reason why no-one hears much about DiffieHellman is that Diffie-Hellman keys/parameters are usually generated per secure comms session and not persistently stores. ALthough the computational hit to do this is nothing like generating RSA pub/priv keys it is still a major bottleneck. With RSA you can generate your keys once, with DH you generate them per-session. So in the context of a secure comms session. I could use RSA to wrap some AES keys and have my protocol up and running in a metter of seconds or I could use DH and take a 15-30 second hit to generate my DH paramaters, from which I can generate a shared secret to act as my a gen. for my AES key. If anyone is more interested in the area, I'd recomment Practical Cryptography and Applied Cryptography, both by Bruce Schneier. http://www.schneier.com/books.html Both are excellent works for getting to know the algorithms inside-out and understanding how to implment communications security in the real world.

Tempting as it may sound (having a whitehat virus/worm), I agree with Bruce Schneier: it's not a good idea..
http://www.schneier.com/blog/archives/2005/12/bene volent_worm.html

I find it frightening enough to install Microsoft's patches.

The real problem is that tests like this are garbage in the first place.

In fact, Bruce Schneier (a respected cryptographer, responsible for Blowfish) addressed the topic thoroughly almost 8 years ago in his column Crypto-Gram. Here's a relevant snippet:

You see them all the time: "Company X offers $1,000,000 to anyone who can break through their firewall/crack their algorithm/make a fraudulent transaction using their protocol/do whatever." These are cracking contests, and they're supposed to show how strong and secure the target of the contests are. The logic goes something like this: We offered a prize to break the target, and no one did. This means that the target is secure.

It doesn't.

Contests are a terrible way to demonstrate security. A product/system/protocol/algorithm that has survived a contest unbroken is not obviously more trustworthy than one that has not been the subject of a contest. The best products/systems/protocols/algorithms available today have not been the subjects of any contests, and probably never will be. Contests generally don't produce useful data. There are three basic reasons why this is so.

You can read the original here.

The real problem is that tests like this are garbage in the first place.

In fact, Bruce Schneier (a respected cryptographer, responsible for Blowfish) addressed the topic thoroughly almost 8 years ago in his column Crypto-Gram. Here's a relevant snippet:

You see them all the time: "Company X offers $1,000,000 to anyone who can break through their firewall/crack their algorithm/make a fraudulent transaction using their protocol/do whatever." These are cracking contests, and they're supposed to show how strong and secure the target of the contests are. The logic goes something like this: We offered a prize to break the target, and no one did. This means that the target is secure.

It doesn't.

Contests are a terrible way to demonstrate security. A product/system/protocol/algorithm that has survived a contest unbroken is not obviously more trustworthy than one that has not been the subject of a contest. The best products/systems/protocols/algorithms available today have not been the subjects of any contests, and probably never will be. Contests generally don't produce useful data. There are three basic reasons why this is so.

You can read the original here.

Any reason why The Fallacy of Cracking Contests doesn't apply to this one?

While the original sources of this story aren't the most reliable in the world, it's likely that there's some truth to it. There's a reasonable discussion at http://www.schneier.com/blog/archives/2006/03/the_ terrorist_t.html . Essentially, cash transactions over $10K have always been monitored, but now financial institutions other than banks have to do analogous reporting. And DHS has nothing to do with it; it's FinCEN, which is part of the Treasury Department. The fact that the person in question triggered such an inquiry at $6500 is probably due to the wide latitude that the regulations give to financial institutions to implement the reporting requirements.

I suspect the NSA, (who I seem to recall left a few stray tags lying around in a previous version of Windows' code)

Yes and no.

True, there was a tag in one version of Windows NT 4 that had the name "_NSAKEY". However, it has never been linked to the NSA in any way whatsoever, except by conspiracy theorists.

You might as well claim that USER32.DLL is proof of a conspiracy to turn American back into a British colony (U.S. obviously stands for United States, and E.R. = Elizabeth Regina = the queen of England! OMG BILL GATES HATES AMERICA!)

Here is Bruce Schneier's take on the matter.

I'm just a dilettante when it comes to encryption; but I can tell you that's not a good tactic. Lots of people think they have a great encryption idea and rush off to implement it. Most of the time they have a fatal flaw. The established ones have withstood attack and you can be sure no one can crack them if you RTFM. And actually all codebreakers have to start by working out what kind of code is being used. Few bother to try to conceal the kind of encryption because of the above though; unless you get into steganography, the rather over-hyped methods of hiding code in things like image or sound files, etc. Check out Bruce Schneier's site, and especially his monthly newsletter for a professional approach to cryptography.

Basically, they put too much faith in the encryption technology, and didn't put enough effort into securing the rest of the process. It's not unusual, many of today's systems have similar issues.

The comments in Bruce Schneier's blog list some more things that went wrong in the Enigma process.

The problem with fingerprints is that it's inherently a very insecure way of authentication for two reasons:

Firstly, you can't change it if it leaks out. A password or a credit card number can be easily changed and the damage minimised in case of an information leak. Doing this with a fingerprint is much harder.

Secondly, the fingerprint is very hard to keep secret. Your body has this annoying ability to leave copies of your identification token all over the place, very easy for anyone to pick up. If you were worried about the ability to scan proximity tags (RFID), then you should be really scared about the use of fingerprints as authentication tokens.

If you don't believe me how easy it is to pick up, read this about how to make a copy of ones fingerprint using common household items.

What you seem to be talking about is a Man-in-the Middle attack. However the symetrical session key wouldn't be used for anything sensitive until both sided have authenticated. There are already a wealth of techniques for protecting against MITM attacks; if there weren't then ssl and tls would be just as broken.
For this application you can use mutual authentication to be even more resistant to MITM attacks. Both sides should have certs. The website has a cert to prove who it is, and the client(cpu-only, not generaly accessible) has a cert to prove what it is running.
So fast forwarding to the part after the client has gotten the AIK and more fleshed out this time:
Client establishes ssl/tls connection and sends request. At this point an Mallory might have a hard time even knowing what exactly a valid request might look like.
Server send back a random number cookie. At this point Mallory shouldn't even know what that cookie is.
Client send back an AIK and that random key properly signed. Properly signed includes timestamp and yet more random numbers thrown in the mix to help fix against replay attacks. Server verifies the signature is correctAt this time the client and server have an authenticated connection both ways. However Mallory is still left out in the cold.
It is only after both sides have sufficiently authenticated to each other that the session key is used for anything sensitive. You could be even more secure and wait to send the exact request until after both sides have danced the full protocol.
There are some devils in the details.. like it is posible to misuse rsa in certain ways. When used in practice, RSA must be combined with some form of padding scheme, so that no values of M result in insecure ciphertexts. . Also the protocol that I gave is a real rough draft, for real one you'd would want to study the cryptographic protocols literature for a good list of known issues that people have run into in the past. However this is a well worn part of the crypto-protocols area. It's not like digicash, blind signatures, bit commitement, time-stamps, zero-proofs, mental poker, or some of the other things you can learn about in books like Applied Cryptography by Bruce Schneier that however don't see quite as much use; secure key exchange and authentication is the bread and butter stuff. So it a little more tried and true; you can see where people in the past failed in some parts of a subtle nature and thus avoid them yourself.
PS not that sll/tls doesn't have problems see Ten Risks of PKI: What You're not Being Told about Public Key Infrastructure By Carl Ellison and Bruce Schneier.

What you seem to be talking about is a Man-in-the Middle attack. However the symetrical session key wouldn't be used for anything sensitive until both sided have authenticated. There are already a wealth of techniques for protecting against MITM attacks; if there weren't then ssl and tls would be just as broken.
For this application you can use mutual authentication to be even more resistant to MITM attacks. Both sides should have certs. The website has a cert to prove who it is, and the client(cpu-only, not generaly accessible) has a cert to prove what it is running.
So fast forwarding to the part after the client has gotten the AIK and more fleshed out this time:
Client establishes ssl/tls connection and sends request. At this point an Mallory might have a hard time even knowing what exactly a valid request might look like.
Server send back a random number cookie. At this point Mallory shouldn't even know what that cookie is.
Client send back an AIK and that random key properly signed. Properly signed includes timestamp and yet more random numbers thrown in the mix to help fix against replay attacks. Server verifies the signature is correctAt this time the client and server have an authenticated connection both ways. However Mallory is still left out in the cold.
It is only after both sides have sufficiently authenticated to each other that the session key is used for anything sensitive. You could be even more secure and wait to send the exact request until after both sides have danced the full protocol.
There are some devils in the details.. like it is posible to misuse rsa in certain ways. When used in practice, RSA must be combined with some form of padding scheme, so that no values of M result in insecure ciphertexts. . Also the protocol that I gave is a real rough draft, for real one you'd would want to study the cryptographic protocols literature for a good list of known issues that people have run into in the past. However this is a well worn part of the crypto-protocols area. It's not like digicash, blind signatures, bit commitement, time-stamps, zero-proofs, mental poker, or some of the other things you can learn about in books like Applied Cryptography by Bruce Schneier that however don't see quite as much use; secure key exchange and authentication is the bread and butter stuff. So it a little more tried and true; you can see where people in the past failed in some parts of a subtle nature and thus avoid them yourself.
PS not that sll/tls doesn't have problems see Ten Risks of PKI: What You're not Being Told about Public Key Infrastructure By Carl Ellison and Bruce Schneier.

From what I understand, the RSA patent has expired now.

I well remember the party I attended to celebrate the patent expiry, in September 2000

So, why havent we seen people working on a simple to use way to do encrypted email now that they dont have to pay RSA for the patent?

Ever used Outlook? Or Thunderbird? Those email clients (and many others) do have a simple way to encrypt (and sign) email using S/MIME. The problem never was patent restrictions, rather the difficulties associated with key management (certificate management and PKI never took off the way it was originally hoped, for a number of reasons).

Here's a way to verify that your compiler can be trusted: http://www.schneier.com/blog/archives/2006/01/coun tering_trus.html. It's not 100% safe but it's better than blind trust.

> Biometric passports and most other applications that need secure tokens utilize smart cards.

Except for the ones which really are planed to use RFIDs.

Here's some homework for you:
http://www.schneier.com/blog/archives/2005/08/rfid _passport_s_1.html
http://www.theregister.co.uk/2006/01/30/burnham_rf id_evasions/
http://catless.ncl.ac.uk/Risks/22.98.html#subj7.1
http://catless.ncl.ac.uk/Risks/23.87.html#subj5.1

The trusted computing group is a group of the big and heavy hitters in the industry, they have collaborated on this technology, and have made it quite robust in functionality.

A primary function of the tpm is the setup of a transitive trust mechanism, whereby in an enterprise a central policy mechanism can be setup and enforced, signing all computer operations and file system objects. This functionality also provides for remote auditing and administration.

Please see my unaccepted post

It's true that the era of trusted platforms is quickly coming upon us. After much controversy the Trusted Computing Group has posted its specifications for the whole world to review. Many of our industry's analysts, artists, and commentators have both supported and denounced the technology in equal measure.

After a complete review of the literature, it is my understanding that many excellent uses are proposed for the technology. As a network integrator and consulting system administrator I'm particularly excited about the remote management capabilities that the specification calls for, and the ability to lock the hardware, software and ensure that documents created in a business stay in the business without the appropriate trust level. The transitive trust nature of the TPM will allow me to set up group policies and enforce them in ways I've never experienced. Truly industrial grade tech.

As a slashdot reader, concerned with my privacy, I was pleased to note that the specification repeatedly called for privacy protection settings, including allowing the owner full control of the module. This is particularly good for home users who may not need these features enabled, particularly the remote auditing and administration functionality. In truth, the specification is quite balanced.

My question to slashdot readers is in light of this very balanced specification, which protects all stakeholders. Is it okay that Apple is currently implementing TPM in their new iMacs and Macbooks, and not documenting it in their system specifications ? Furthermore, is it also okay that they've failed to provide home users with the appropriate tools to monitor the trust mechanism and disable the module if it's not necessary?

Okay, that's two questions, but 'the third time's the charm' Is it okay that the specification describes remote auditing and administration capabilities, and I can't even see if that's enabled?

If you had typed in www.bankofamerica.com, this would not happen. That's why clicking an URL on an e-mail from an unknown sender is a bad idea.

In a more sophisticated version of this attack, phisher can create a UNICODE string that looks exactly like www.bankofamerica.com. See http://www.schneier.com/blog/archives/2005/02/unic ode_url_hac_1.html

2. It can be revoked. However, unless you download a CRL from GeoTrust (and all other trusted CAs) frequently, or use OCSP every time you do SSL, it does not solve the problem.

It is always interesting to read how the Government wants to invade our lives, listen to you talking to your girlfriend about how your day went... Do you people honestly think that this is the goal?

Of course it's not the goal, now... Problem is it sets a precedent and leads us down a path to an Orwellian existence. Don't think this is true? Look at the western world's reaction to the cartoon issue. People are fired, governments are condemning the printing of the cartoons. How long before someone is incarcerated for publishing something of that nature on their blog. Fortunately we are still protected against that in the US, but as our rights continue to degrade we get closer and closer to that situation.

Seriously. If you are talking to someone in Iran about blowing up a site in the US, I want the Government listening to that call.

That's the issue exactly. I don't care what you want. The Bill of Rights were designed to protect us from each other. Maybe I don't want you watching that gay pron or listening to that rock and roll music. Where does it stop? If 90% of us are all for this, get them together and repeal the 1st Amendment. Then everything will be nice and legal.

That aside, what are the odds of the US Government, even with all the money they are throwing at this issue, to listen to my call. If I'm stupid enough to make a phone call from a phone registered in my name to plan a terrorist attack I'm likely too stupid to carry the attack out successfully. There are trivial ways to get around phone taps, email evesdropping and Internet spiders looking for chatroom activity. Listening to everything and everyone just isn't an efficient way of ensuring security.

We are the greatest country in the world, and I don't care if anyone thinks differently. We are, and I would fight and die for the US and my way of life if I had to.

Absolutely, but I would fight for the freedoms our country enjoys and represents. If we end up living in a totalitarian society we will no longer be the greatest country in the world.

Just because JFK, Carter, Lincoln, FDR, Carter, Nixon and how many others did things that compromised our freedoms and society does NOT make them right. I'm not anti-Bush. I disagree with some of his policies, but overall I like the guy. I AM against the foolishness and wastefulness that has saturated our government. If you want ideas about effective security measures I suggest you read Bruce Schneier's writing on the subject. He has excellent, well thought out reasons why things will and won't work. Most of the actions since 9/11 taken by our government have been politically motivated, not security motivated. Until the political agendas are removed I will continue to be extremely critical of the government's security activites.

Either the bullet is actually the RFID tag, in which case I'm not sure of the aero dynamic properties of hte RFID tag, but something that small wouldn't really travel well in straight lines, and would be too light to maintain the necessary speed. If it was larger, and could carry the necessary momentum necessary to get to you from a distance, then i would surely feel a lot more painful than a mosquito bite, or you'd notice the dart sticking out of your neck.

Bruce S. covered the conceept of RFID Injection from a Distance. It may still be science fiction...

Bruce Schneier has some excellent things to say about "security" measures that defend against movie-plot threats. If you don't read Crypto-Gram yet, go sign yourself up, and learn how counter-intuitive reality can be.

Here's a link.

Another point, where are the "innocent Americans" that are being spied on? Can you name one? Has anyone been prosecuted based on such spying? Do you think an "innocent American" who had no involvement in terrorism would have any trouble at all getting such evidence thrown out?

Well, there were cases of people getting put on the no-fly list, causing innocent Americans to miss their flights. Per CBS News, "[Senator Ted] Kennedy says he had to enlist the help of Homeland Security Secretary Tom Ridge to get his name stricken from the list. The process took several weeks, in all." Imagine how long it would take for an "ordinary" citizen without any political clout to get this resolved.

So, yes, there's precedence for concern over things like this.

Speaking for myself, I'm not opposed to the surveillance, but I want some due process to ensure that the government is not abusing this power. My concern is that the Bush administration may be ignoring that due process.

mathematically proven to be impossible to reverse-engineer

    I imagine they are using something like Bruce Schneir's Clueless Agents:
http://www.schneier.com/paper-clueless-agents.html

    I've read the paper a few years ago, but the gist of how it might work in this case is that instead of the agent comparing the actual keywords to a database, they parse the document and try decrypting some of its code against hashes of the keywords (or, say, sorted sub-sets of keywords).

    That way, even the response behaviour would be "mathematically proven to be impossible to reverse-engineer" until it reacts. The only way to know what it's looking for is discovering each input it reacts for - it could be a huge search space.

    The concept is quite interesting for use in mobile agents. It'd be even more interesting if they were as popular now as people predicted they'd be, though .

I'd like to see the demonstration. Until such time, I call bollocks and I refuse to believe an "impossible to reverse-engineer" piece of code ever exists.

I second your bullshit and raise! The problem with proofs such as this is that they assume broad axioms that in reality might not be true in the hardware. For example, they may well have proved the theorem if they assume all operations of a certain set take the same length but in reality they might not. The processor might take a ten billionth of a second longer to do one operation than it does another, or it might release more heat when it does one operation than it does when it performs another, or it might release a certain magnetic field when it does one operation and not another.

Side-channel attacks, as these are called, are often totally devastating. There was one attack where simply heating the computer up can cause a system to get owned. If the proof is correct, it's certainly interesting but practically we're a long way from getting to this gold standard.

Simon

Bruce Schneier has a good article explaining why you shouldn't be "bored"

http://www.schneier.com/essay-102.html

Al Gore does a good job covering the same ground (albeit a bit more verbosely) in his Martin Luther King day speech:

http://www.washingtonpost.com/wp-dyn/content/artic le/2006/01/16/AR2006011600779.html

That said, here's some documentation for that claim, some of which include suggestions for how to easily bypass such systems, perhaps one of them will work for you, although I don't recommend the first one:

Malaysia car thieves steal finger

DHS and UK ID card biometric vendor in false ID lawsuit

Unsupervised biometric scanners more toys than serious security

Impact of Artificial Gummy Fingers on Fingerprint Systems

Replying to self.. sorry...

Admittedly google watch comes across a bit tinfoil hat, but what I outlined above has all been verified by Google.

Bruce Shneier is probably a more reliable resource.

I find it intensely interesting that people will [...] villify the recording of phone conversations of people who have known links to terrorist organizations.

You misspelt "ignoring congressional refusal of presidential powers" and accidentally substituted the word "known" for the word "suspected". HTH.

"Bush's eavesdropping program was explicitly anticipated in 1978, and made illegal by FISA. There might not have been fax machines, or e-mail, or the Internet, but the NSA did the exact same thing with telegrams" -- Project Shamrock

Trey Anastasio, Shine (Columbia)
Celine Dion, On ne Change Pas (Epic)
Neil Diamond, 12 Songs (Columbia)
Our Lady Peace, Healthy in Paranoid Times (Columbia)
Chris Botti, To Love Again (Columbia)
Van Zant, Get Right with the Man (Columbia)
Switchfoot, Nothing is Sound (Columbia)
The Coral, The Invisible Invasion (Columbia)
Acceptance, Phantoms (Columbia)
Susie Suh, Susie Suh (Epic)
Amerie, Touch (Columbia)
Life of Agony, Broken Valley (Epic)
Horace Silver Quintet, Silver's Blue (Epic Legacy)
Gerry Mulligan, Jeru (Columbia Legacy)
Dexter Gordon, Manhattan Symphonie (Columbia Legacy)
The Bad Plus, Suspicious Activity (Columbia)
The Dead 60s, The Dead 60s (Epic)
Dion, The Essential Dion (Columbia Legacy)
Natasha Bedingfield, Unwritten (Epic)
Ricky Martin, Life (Columbia) (labeled as XCP, but, oddly, our disc had no protection)

Perhaps I'm a coward, but that should tell you something of what this country is slowly turning into...

A Dictatorship. Well, according to recent actions it already is. Per Definition, "dictator refers to an absolutist or autocratic ruler who governs outside the normal constitutional rule of law.". http://en.wikipedia.org/wiki/Dictator

The fact that president Bush was able to order a huge illegal eavesdropping-action, and was not impeached and imprisoned for high treason immediately makes him per definition a dictator.

See also: http://schneier.com/crypto-gram-0601.html#12

Actually the changes suggested by the NSA increased the strength of DES rather than decreasing it.

http://www.schneier.com/blog/archives/2004/10/the_ legacy_of_d.html

Actually, Bruce Schneier's analysis is somewhat different.

http://www.schneier.com/crypto-gram-9909.html#NSAK eyinMicrosoftCryptoAPI

The fact is, the majority of the people making claims about this don't even understand what it does. The majority of the speculation isn't possible. It doesn't give anyone (Not even Microsoft, much less the NSA) a backdoor into your computer.

Actually, it's pretty well known that that isn't what happened at all.

"It's good to see that this vulnerability is getting some exposure, but this article's synopsis is misleading. It is well known that the WMF vulnerability stems from an intentional feature in the design of WMF that allows code to be embedded into WMF images; this code is executed when the image is viewed. The original purpose of this was mainly to handle the cancellation of print jobs during spooling. This is a feature that has extreme security implications in the context of the Internet, but is from another time (Windows 95), when MS had very little interest in networking beyond trusted internal corporate environments. Over the years this code has lived on in Windows without being reviewed in the current context of Internet connectivity. Never ascribe to malice that which can be explained by incompetence. See http://en.wikipedia.org/wiki/2005_WMF_vulnerabilit y for a lot more detail.

I don't mean to make an ad hominem attack (this podcast is actually fairly accurate), but Steve isn't exactly known for being a respected researcher in the security industry - he's a bit of a poser. He frequently hypes issues to crazy levels and tries to make himself look like a hero/expert. In fact, he usually offers little insight and often tries to pass off regurgitation (often inaccurate) as original research. Just listen to him in this recording talking about "rolling up his sleeves" and "wrote all my own code", etc - trying to sound like he substantially contributed to the security industry. Look up his stuff on nano-probes (http://grc.com/np/np.htm) for some really ridiculous stuff. I am a security professional and can tell you that it's mostly BS and/or hyped/obfuscated wording for technologies and techniques that have been in common usage for years and years before he wrote this crap.

Much better resources and much more insightful experts are accessible. Try http://www.schneier.com/blog/ and http://isc.sans.org/diary.php for FAR more interesting information. No one I know or work with pays any attention to Steve Gibson, except as a source of humor. :)"

They won't be able to do it because perfectly uncrackable DRM on a general-purpose computer is an impossible task. The only way to make uncrackable DRM is to remove the general-purpose ability from computers such as what is intended for Palladium/NGSCB, and I find it difficult to believe that Google is planning to get into the market of "trusted computing".

If you, the user, have an ultimate say on what software can and cannot be run on your own computer, then any uncrackable DRM is impossible.

Yeah, I'd say a week is a good estimate, if there are motivated people, and it looks like there's no shortage of those.

Just thought I'd toss in my few cents.

Bruce Schneier has a couple of essays that you might want to have your daughter check out. (Hopefully she already knows the info in the first, but....)

Here is his imput on how to get into the crypto field.

Why is crypto so hard .

If you or she aren't so keen on working with a local college/university math/CS department, I second the advice to hit up Phil Zimmermann. His site lists a number of ways to contact him. It also talks about his current project. (I found Mr. Zimmermann to be very gracious. I think the worst he would do is say no. More likely he would either agree or suggest someone as a alternative.)

Just thought I'd toss in my few cents.

Bruce Schneier has a couple of essays that you might want to have your daughter check out. (Hopefully she already knows the info in the first, but....)

Here is his imput on how to get into the crypto field.

Why is crypto so hard .

If you or she aren't so keen on working with a local college/university math/CS department, I second the advice to hit up Phil Zimmermann. His site lists a number of ways to contact him. It also talks about his current project. (I found Mr. Zimmermann to be very gracious. I think the worst he would do is say no. More likely he would either agree or suggest someone as a alternative.)

Of course, there are arguments that this does not constitute security. I think the concept of free fixes for bugs found by customers works a little better - it keeps all the stakeholders in the loop.

Yes, it should be possible, and no, anti-worm worms are still not a good idea. Bruce Schneier wrote about it just last month.