Slashdot Mirror

It's unfortunate that obscuring code has taken on the negative connotation of "hiding bugs." That's not always the case.

True, but the more power/money involved, the greater the temptation to cheat (from simply cutting corners to intentionally compromising the system). That's why the connotation is there - because history shows that's the way to bet. Thus the need, as you point out, for independent code review. (Of course one of the best ways to insure independence is to allow anyone access, which brings us back to opening up the source.) However, we need to take it a step further; what we need is a system (i.e. the whole thing, including hardware/software/procedures/etc.) that is verifiable. Not an easy task, of course.

Bruce Schneier wrote a good article on the pros and cons of this last year; see Secrecy, Security, and Obscurity in the May 2002 Crypto-Gram.

If Win2k gets a higher rating than Linux, then why do we have stuff like this happening?

Isn't it odd that a "comprehensive security rating" can overlook something as serious as a complete remote compromise?

EAL4 - methodically designed, tested and reviewed

EAL4 permits a developer to maximize assurance gained from positive security engineering based on good commercial development practices. Although rigorous, these practices do not require substantial specialist knowledge, skills, and other resources. EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line. It is applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOEs, and are prepared to incur additional security-specific engineering costs.

An EAL4 evaluation provides an analysis supported by the low-level design of the modules of the TOE, and a subset of the implementation. Testing is supported by an independent search for vulnerabilities. Development controls are supported by a life-cycle model, identification of tools, and automated configuration management.

Same thing happened as NT evolved for workstations and servers, or when the Windows codebase was ported to handhelds in Windows CE.

Yes, Linux, *BSD, and any other open source operating system can have that modification done by the users, rather than the owners, but the OS's don't just wake up and say "HEY! we're gonna run on a Toaster today!"

Again I say - all modern operating systems evolve quickly to fill demands. And if you're including GNU or GPL'd software in the "evolving/mutating/process" of Linux, take a look on SourceForge and search for win32 or windows - a lot of Windows programmers are doing open source too it seems.

And I think Ian should have at least tipped his hat to Bruce for abusing an expression that was already popularized by someone else - except in Bruce's case it was correct. Security is in fact, a process.

has been described as "a process, not a product". One of the more common quotes in this area is available here . (Be sure to read down a page or so.)

Uh-oh, now he's gonna get sued by Bruce Schneier!

Yes, but a lot of people put way to much stock into biometric identification. I'm reminded of this story where a Japanese cryptographer used $10 of household chemicals to bypass the majority of fingerprint readers. Keep in mind, this guy was not a professional finger print cracker.

I think Schneier hits pretty close to home when he points out that security is based on three things: something you are (fingerprints), something you have (an ATM card), and something you know (a pin number). A good security system will use at least two of these (think about your ATM card).

What about the Street Performer Protocol, or variations such as the Rational Street Performer Protocol? Are there any actual companies implementing it?

public beta of steam? oh, it's a game! When I first read the title I thought they were using a euphemism for "vaporware"...

That is a great pun indeed. However I would like to point out that anyone who is thinking about unbreakable copy protection, digital content delivery system sending binary digits (bits) which are impossible to copy,* or other perpetum mobile for that matter, might consider getting a clue and educating oneself. Crypto-Gram and some books could be a good start.

Of course I am not talking to anyone from the Slashdot community, as I am sure everyone of us is perfectly aware of everything I am talking about. I am saying it in case someone from this steampowered dotcom is listening.

__________
*) also acceptable would be: a lossless compression of random data, a one-time-pad cryptography without key distribution problem or with reused keys or keys shorter than cleartext, immortality drug, perpetual motion machine, prove of the existence of omnipotent superbeing, strong artificial intelligence on Turing machine, homeopathy, magic, multilevel marketing that works, et cetera ad infinitum, ad nonsensum... I think you get the point already.

uses a proprietary encryption scheme

translated:

Some crappy, broken scheme baked up by programmers not professional cryptographers.

I'm glad it is not my venture captial money backing this broken puppy.

Sigh. Snake Oil FAQ or the Crypto mini FAQ and various Cryptogram will remind you, proprietary encryption is very bad.

The FBI procedure might be to use equipment that can crack worthless cellular encryption in real time.

There is at least one secretive, DoD centric, left-nameless US government agency that strongly dislikes open source because they don't trust it. Then, if it was developed by someone in a foreign country, that's even worse. Getting the package accredited could take months. (Sorry Guido)

And this organization knows who they are. Just say the words "Please approve Samba" and they all clam up and start fighting amongst themselves. Forget getting that package approved.

Say the words "Please approve Windows Office [current year]" the same week it comes out and you'll get an answer back the same day saying approved. Say "Please approve [name of US vendor] [name of commercial product]" and you'll probably get an approval the same week.

Never mind the gaping holes every one knows exist in Internet Exploder and Outlook. They are approved without concern. Ask for anything OSS and it will take some video footage of you jumping on your grandmother's grave to convice them you'll lock it down because it's your production system.

They obviously don't read anything Bruce Schneier has to say in his Cryptograms. Lots of companies sell snake oil or never put a patch out when the exploits are alive in the field. It's just that the OSS one's are a little more visible.

Long live paperwork!

There is at least one secretive, DoD centric, left-nameless US government agency that strongly dislikes open source because they don't trust it. Then, if it was developed by someone in a foreign country, that's even worse. Getting the package accredited could take months. (Sorry Guido)

And this organization knows who they are. Just say the words "Please approve Samba" and they all clam up and start fighting amongst themselves. Forget getting that package approved.

Say the words "Please approve Windows Office [current year]" the same week it comes out and you'll get an answer back the same day saying approved. Say "Please approve [name of US vendor] [name of commercial product]" and you'll probably get an approval the same week.

Never mind the gaping holes every one knows exist in Internet Exploder and Outlook. They are approved without concern. Ask for anything OSS and it will take some video footage of you jumping on your grandmother's grave to convice them you'll lock it down because it's your production system.

They obviously don't read anything Bruce Schneier has to say in his Cryptograms. Lots of companies sell snake oil or never put a patch out when the exploits are alive in the field. It's just that the OSS one's are a little more visible.

Long live paperwork!

Disney is launching a pilot DVD-rental program that uses self-destructing DVDs. The idea is that the DVD has a coating that oxidizes after a few days, rendering the DVD unreadable.

I think this is a very clever security countermeasure. The threat is regular consumers. Disney wants to be able to rent DVDs to them at a price-point lower than their sale price. By making a DVD that only lasts a few days after being taken out of the package, Disney has solved the problem of needing an infrastructure to process DVD returns.

Of course this doesn't solve the problem of making illegal copies of the DVD, but that's not the problem that Disney is trying to solve. Self-destructing DVDs are a clever solution for a specific security problem, and if it works well it's likely to be a cheap and effective one. (Compare this to Circuit City's superficially similar DIVX format, which also had expiring DVDs, but required a phone line and special player.)

In January 2003, the SQL Slammer worm disrupted 13,000 ATMs on the Bank of America's network. But before it happened, you couldn't have found a security expert who understood that those systems were dependent on that vulnerability. We simply don't understand the interactions well enough to predict which kinds of attacks could cause catastrophic results, and terrorist organizations don't have that sort of knowledge either -- even if they tried to hire experts. ...

Despite our predilection for calling anything "terrorism," these attacks are not. We know what terrorism is. It's someone blowing himself up in a crowded restaurant, or flying an airplane into a skyscraper. It's not infecting computers with viruses, forcing air traffic controllers to route planes manually, or shutting down a pager network for a day. That causes annoyance and irritation, not terror.

This is a difficult message for some, because these days anyone who causes widespread damage is being given the label "terrorist." But imagine for a minute the leadership of al Qaeda sitting in a cave somewhere, plotting the next move in their jihad against the United States. One of the leaders jumps up and exclaims: "I have an idea! We'll disable their e-mail...." Conventional terrorism -- driving a truckful of explosives into a nuclear power plant, for example -- is still easier and much more effective.

The bug finding, reporting, fixing, and patching process should minimize the potential damage. If your goal is to minimize damage then neither full immediate discloser or no disclosure is a good answer. Bruce Schneier has written a good article about full disclosure in his Crypto-Gram newsletter.

Unless bugtraq is falling down on the job, why do we need another one?

How's AES for serious encryption format? That's what the new WinZip 9 beta boasts.

AES what (how many bits)? And how do they collect entropy? How do they generate the IV? Are there password complexity rules, or at least warnings on insecure passwords?

The actual encryption algorithm is but one small factor in determining the security of a system. People who say thinngs like, "It uses AES, so its secure," are the ones that the NSA, CIA, and FBI encourage, because they're the ones that can be easily fooled.

If WinZip9 uses AES with 56 bits, no thanks. That's not secure. If they use 128 bits, kudos.. its adequate for most uses. If its configurable up to 256, even better. However, using a published and reviewed encryption product like PGP or GPG would still be my method of choice.

I'd like to suggest Bruce Schneier's Cryptogram as a good source of applied crypto knowledge. My favorite section of his newsletter is The Doghouse, where he debunks dubious claims and "cryptographic snake oil".

Anything labeled as "proprietary" is generally bad when it comes to cryptography. Peer review is the best way to verify a system can be trusted. And that's difficult to do on closed-source products.

How's AES for serious encryption format? That's what the new WinZip 9 beta boasts.

AES what (how many bits)? And how do they collect entropy? How do they generate the IV? Are there password complexity rules, or at least warnings on insecure passwords?

The actual encryption algorithm is but one small factor in determining the security of a system. People who say thinngs like, "It uses AES, so its secure," are the ones that the NSA, CIA, and FBI encourage, because they're the ones that can be easily fooled.

If WinZip9 uses AES with 56 bits, no thanks. That's not secure. If they use 128 bits, kudos.. its adequate for most uses. If its configurable up to 256, even better. However, using a published and reviewed encryption product like PGP or GPG would still be my method of choice.

I'd like to suggest Bruce Schneier's Cryptogram as a good source of applied crypto knowledge. My favorite section of his newsletter is The Doghouse, where he debunks dubious claims and "cryptographic snake oil".

Anything labeled as "proprietary" is generally bad when it comes to cryptography. Peer review is the best way to verify a system can be trusted. And that's difficult to do on closed-source products.

How's AES for serious encryption format? That's what the new WinZip 9 beta boasts.

AES what (how many bits)? And how do they collect entropy? How do they generate the IV? Are there password complexity rules, or at least warnings on insecure passwords?

The actual encryption algorithm is but one small factor in determining the security of a system. People who say thinngs like, "It uses AES, so its secure," are the ones that the NSA, CIA, and FBI encourage, because they're the ones that can be easily fooled.

If WinZip9 uses AES with 56 bits, no thanks. That's not secure. If they use 128 bits, kudos.. its adequate for most uses. If its configurable up to 256, even better. However, using a published and reviewed encryption product like PGP or GPG would still be my method of choice.

I'd like to suggest Bruce Schneier's Cryptogram as a good source of applied crypto knowledge. My favorite section of his newsletter is The Doghouse, where he debunks dubious claims and "cryptographic snake oil".

Anything labeled as "proprietary" is generally bad when it comes to cryptography. Peer review is the best way to verify a system can be trusted. And that's difficult to do on closed-source products.

It seems there is a real need both for strong, open-source cryptographic solutions for VoIp applications and some kind of open-source hardware for telephone communications. Open source because presumably the problem with current telephony encryption is that its closed source implementation has made it easy for the government to crack, as Schneier points out.

Since PZ once wrote an PGPfone for encrypted VoIP communications I'd really like to hear his opinion on this topic.

I'm just waiting for Bruce Schneier (author of Applied Cryptography and founder of Counterpane Internet Security. Oh yeah, and author of the Twofish and Blowfish algorithms to boot.) to comment on this in the next Cryptogram...

I'm sure he'll have some interesting things to say. ;)

I'm just waiting for Bruce Schneier (author of Applied Cryptography and founder of Counterpane Internet Security. Oh yeah, and author of the Twofish and Blowfish algorithms to boot.) to comment on this in the next Cryptogram...

I'm sure he'll have some interesting things to say. ;)

I'm just waiting for Bruce Schneier (author of Applied Cryptography and founder of Counterpane Internet Security. Oh yeah, and author of the Twofish and Blowfish algorithms to boot.) to comment on this in the next Cryptogram...

I'm sure he'll have some interesting things to say. ;)

I'm just waiting for Bruce Schneier (author of Applied Cryptography and founder of Counterpane Internet Security. Oh yeah, and author of the Twofish and Blowfish algorithms to boot.) to comment on this in the next Cryptogram...

I'm sure he'll have some interesting things to say. ;)

I'm just waiting for Bruce Schneier (author of Applied Cryptography and founder of Counterpane Internet Security. Oh yeah, and author of the Twofish and Blowfish algorithms to boot.) to comment on this in the next Cryptogram...

I'm sure he'll have some interesting things to say. ;)

I'm just waiting for Bruce Schneier (author of Applied Cryptography and founder of Counterpane Internet Security. Oh yeah, and author of the Twofish and Blowfish algorithms to boot.) to comment on this in the next Cryptogram...

I'm sure he'll have some interesting things to say. ;)

There is actually a 3-part Cryptography course (the 1st part of which is merely entitled, "Network Security") that I intend to take the 2nd two parts of pretty soon here.

Since timing will not allow me to take the entire sequence, I'm covering the material of the first course on my own.

To that end, a few resources:

[the following presumes a background in network engineering, the protocols, etc.; it also presumes some number theory but most of that is covered as needed]

1. For starters: Charles & Shari Pfleeger's Security in Computing, 2nd Edition -- this is a nice, intro text for high level (a) security, (b) encryption, (c) OS security, (d) DB security

2. Then move onto more specific texts, i.e. Silberschatz's Operating Systems Concepts, 6th Edition -- this provides a much more detailed look into OS security -- mechanisms/policies/implementations etc.

3. Then there are a couple wortwhile Cryptography only texts: (a) Schneier's Applied Cryptography, (b) Menezes' Handbook of Applied Cryptography

4. Then there is a good course website for the course I referred to, the 1st in the series of three that also has downloadable handouts as well as some coding projects that you could do independently, providing an enviro

5. Finally, I'd suggest a subscription to the Counterpane Crytpogram newsletter -- found at this link. Also, checking out this site periodically or perusing it somewhat in-depth will give you far more visibility into day-to-day threats.

IMHO any information security professional needs to develop a professional paranoia, being thoughtful of potential risks and failures, and understand what might go wrong.

Reading Bruce Schneier's Secrets and Lies is a really good start in this area. It is a not very technical book, written at the level suitable for an IT manager. This is also useful to help explains risks, vulnerabilities, and failures to IT Management.

The ever so ugly covered Hacking Exposed, which explains the basics of what criminals (or attackers) do commonly to gain unauthorized access to (networked) computer systems. This is so you a) know how easy it is, and b) are familiar with an overview of the basic steps and techniques to gain illicit access.

For online resources, RISKS digest (not focused on malicious activities, but how systems fail - very insightful and low volume), and Bugtraq a full disclosure mailing list will show you recent exploits, and vuln notices, but it is fairly lacking in actual educational content, and there are several other mailing lists at SecurityFocus that could also be useful to developing professional paranoia.

Next you need the language and basics of information/computer security. For this textbooks like Computer Security by Dieter Gollmann, Information Security Management Handbook by Tipton and Krause, Practical Unix & Internet Security by Simson Garfinkel, Gene Spafford, Alan Schwartz, and Security in Computing by Pfleeger and Pfleeger.

For procedures look at CISSP study material, BS 7799 / ISO 17799, and security auditing and incident handling materials. Some knowledge of risk management can also be useful.

From these basics, of the right mindset, the common language of infosec, and procedures and policy you can get into the low-level details of firewalls, VPNs, IDS, and network design. For this you should have a good network/internetworking basics, a very detailed understanding of TCP/IP, and understand firewalls, VPNs, and IPsec.

Firewalls and Internet Security: Repelling the Wily Hacker, 2nd ed. by William R. Cheswick, Steven M. Bellovin, and Aviel D. Rubin is a great place to start, and Building Internet Firewalls by Elizabeth D. Zwicky, Simon Cooper, D. Brent Chapman is a great follow-up. An alternative book on firewalls and VPNs is Inside Network Perimeter Security: The Definitive Guide to Firewalls, VPNs, Routers, and Intrusion Detection Systems by Stephen Northcutt, Karen Frederick, Scott Winters, Lenny Zeltser, Ronald W. Ritchey (crowd from SANS).

For networking basics, a Cisco certification like CCNA could useful in providing knowledge about internetworking and Cisco router's IOS. For the gory details of TCP/IP either TCP/IP Illustrated: Volume 1: The Protocols by Richard Stevens or Internetworking With TCP/IP Volume 1: Principles Protocols, and Architecture, 4th edition by Douglas Comer.

For IDS - Network Intrusion Detection: An Analyst's Handbook by Stephen Northcutt and Intrusion Signatures and Analysis by Matt Fearnow, Stephen Northcutt, Karen Frederick, Mark Cooper are the best IMHO.

I am not sure what to recommend for VPNs, other than you need to know about IPsec.

Security is not an Engineering discipline. Knowing one security tool, or even many tools does little or nothing towards cultivating the approach, process, culture and awareness-in-context that are basic to a professional in the Information Security field.

One could do worse than browse the documents collection in the Reading Room at SANS.org,and the archive of Bruce Schneier's Crypto-gram newsletter.

If Information Security still appeals to you, and you can specialize in an area suited to your temperment -go ahead.

Personally however I'd recommend Password Safe for storing things like credit card numbers, bank details etc. It's not that I don't trust Mozilla to do the job, but I just prefer a standalone and simple program for that kind of thing. It also lets you add comments and notes and it's easy to copy it onto a keyring USB device and carry it around with the database.

This attack was used to inundate the "Spam King" Alan Ralsky when he made the mistake of leaking his address, which was then posted to Slashdot. I can't imagine the slashdot effect he had on his front door everyday.

The parent post is gratuitous plagiarism. See for yourself.

From Bruce Schneier's February 15 Crypto-Gram:

"But there's an interesting Microsoft twist. During the days of the attack, Microsoft tried to deflect any blame by claiming that they issued a patch for the vulnerability six months previously, and that the only affected companies were the ones who didn't keep their patches up to date. A couple of days later, news leaked that Microsoft's own network was hit pretty badly by the worm because they didn't patch their own network."

From the parent:

"There's an interesting Microsoft twist to the recent Sapphire Worm, aka SQL Slammer. During the days of the attack, Microsoft tried to deflect any blame by claiming that they issued a patch for the vulnerability six months previously, and that the only affected companies were the ones who didn't keep their patches up to date. A couple of days later, news leaked that Microsoft's own network was hit pretty badly by the worm because they didn't patch their own network."

From Crypto-Gram:

"For a couple of years now I've been saying that the idea that we can achieve network security by finding and patching vulnerabilities in the field is fatally flawed. I don't blame Microsoft sysadmins for not having their patches up to date -- no one does -- but I don't like the hypocrisy out of the company.

The SQL Slammer worm also reopened the full disclosure debate. Microsoft announced the vulnerability in July 2002, at the same time they released the patch. A few days later, David Litchfield published exploit code that demonstrated how the vulnerability could be used to break into systems. January's SQL Slammer worm used that exact code. Some point to that and say that Litchfield should not have released the code, while others correctly say that the code wasn't hard to write, and that the worm author could have easily written it himself.

An amusing, but irrelevent, incident: A week after the worm, I was invited to speak about it live on CNN. The program was eventually preempted by the Columbia tragedy, but not before the CNN producers invited Microsoft to appear on the segment with me. Microsoft's spokesman -- I don't know who -- said that the company was unwilling to appear on CNN with me. They were willing to appear before me, they were willing to appear after me, but they were not willing to appear with me. Seems that it is official Microsoft corporate policy not to be seen in public with Bruce Schneier."

From the parent:

"The idea that we can achieve network security by finding and patching vulnerabilities in the field is fatally flawed. I've been saying this for a couple of years now. I don't blame Microsoft sysadmins for not having their patches up to date -- no one does -- but I don't like the hypocrisy out of the company. The answer lies in software programmers creating secure code.

The SQL Slammer worm also reopened the full disclosure debate. Microsoft announced the vulnerability in July 2002, at the same time they released the patch. A few days later, David Litchfield published exploit code that demonstrated how the vulnerability could be used to break into systems. January's SQL Slammer worm used that exact code. Some point to that and say that Litchfield should not have released the code, while others correctly say that the code wasn't hard to write, and that the worm author could have easily written it himself.

An amusing, but irrelevent, incident: A week after the worm, I was invited to speak about it live on CNN. The program was eventually preempted by the Columbia tragedy, but not before the CNN producers invited Microsoft to appear on the segment with me. Microsoft's spokesman -- I don't know who -- said that the company was unwilling to appear on CNN with me. They were willing to appear before me, they were willing to appear after me, but they were not willing to appear with me."

1. Education - Get educated about what information security is all about, you should know what C.I.A. stands for (in infosec, not the US federal agency), you should know what a security policy is, understand risk management and mitigation, and known what criminals/attackers can do in your organization.

You can get a lot of this from several books and websites, such as Secrets and Lies by Bruce Schneier, the SANS Reading Room, if you can afford it SANS/GIAC training and/or certification may be of benefit to you and your org, the CISSP and SSCP Open Study Guides even if you don't go for CISSP or SSCP (I don't recommend paying any money to ISC^2), and Security Focus.

2. Audit - This step is critical and too many places forget to do it. You need to know what you are trying to secure, yet most organizations do not have a complete picture of their network and all the systems on it. This includes security and non-security issues (e.g. software licenses, maintenance patches, standardization)

Tools like those from IBM Tivoli or HP Openview can help here. For security specific vulnerability analyzer, open-source Nessus and eEye's Retina, ISS's Internet Scanner

3. Policy - You need a plan and a document to give you and others guidenance, and this if your infosec policy.

Large orgs should consider BS 7799 or ISO 17799 whereas smaller groups can look at Center for Internet Security for benchmarks, and SANS Reading Room - Auditing and Assessment, and Site Security Handbook - RFC 2196.

4. Implement -- Using your education, audits and policies you can now implement decent security.

Basic principles of defence in depth, fail-safe, separation of privilege, and complexity is the enemy of security can guide you to build a practical network of secured systems that limits exposure to criminal activities, and minimizes damage from attacks.

5. Be vigilant - "Security is a process, not a product" - Bruce Schneier

Now the work begins, up to now it was the fun stuff, now you get to dig in with boring but important tasks such as analyzing log files, maintaining a accurate asset database, applying patches, maintaining user accounts, periodic audits (internal and if you can afford it and it is warranted, external), educating users, and maintaining your security posture.

Firewalls are really not unlike locks on a door... with time someone'll get through. Intrusion Detection Systems don't do much good unless someone responds when an Intrusion is Detected. -- not unlike a building alarm without an alarm company responding! I think this company counterpane has an interesting approach. They have their own data centers doing 24x7 monitoring of their customers networks so if any IDS has any suspicious activity, someone can respond immediatelly.

Microsoft Baseline Security Analyzer (MBSA) and Microsoft's version of HFNetChk both failed to detect the presence of the well-known vulnerability in SQL Server exploited by Sapphire, which is one of the reasons so many admins (both inside and outside MS) had failed to install the necessary hotfix. MBSA and HFNetChk are Microsoft's official patch status verification tools meant to be used by all owners of Windows server boxes ...

...In addition to designing MBSA to avoid scanning for SQL Server vulnerabilities, failing to update mssecure.xml reliably and in a timely manner, deprecating HFNetChk by pushing the MBSA GUI as its preferred replacement, and hiding the details of the technical limitation

These books are like popular science books such as A Brief History of Time, or Cosmos. They're not about making people an expert in a field, they're about helping the layman learn a little bit about a field.

Microsoft Baseline Security Analyzer (MBSA) and Microsoft's version of HFNetChk both failed to detect the presence of the well-known vulnerability in SQL Server exploited by Sapphire, which is one of the reasons so many admins (both inside and outside MS) had failed to install the necessary hotfix. MBSA and HFNetChk are Microsoft's official patch status verification tools meant to be used by all owners of Windows server boxes ...

......In addition to designing MBSA to avoid scanning for SQL Server vulnerabilities, failing to update mssecure.xml reliably and in a timely manner, deprecating HFNetChk by pushing the MBSA GUI as its preferred replacement, and hiding the details of the technical limitations

Right -- and guess who's going to make money off of charging 'email taxes' for everybody who wants to send a message? This is like the big kerflufle over the (false) claims that Canada was going to charge a $.05/email tax to help cover the losses to Canada Post.
So now we're going to pay more money to NSI/Verisign for an email cert when they're refusing to deny DNS to prolific spammers? We'd still need a grey-market method of keeping track of which of those certs were sold to spammers.

Before we get too deep into the idea of using PKI to 'secure' email, I'd suggest that people look at the rather interesting article pointed to by the GnuPrivacyGuard site about The Ten Risks of PKI.

A more interesting question is whether this could be done in an open-source manner, with peer-to-peer authentication servers, webs of trust etc.

The protocol wouldn't be so much a drop-in replacement for sendmail as it would be a parallel delivery mechanism. As (and if) it became proven and trusted, I expect that such a system would slowly overtake SMTP as the preferred method of accepting email (with the 'old' method being less and less trusted). Once 'enough' people started using such a system, the critical mass would result in a flip-over in emphasis by the bigger players.

RSA doesn't need to be cracked for most applicatios, since the real-world deployments be cracked instead. From the inside out, here's a few: timing attacks, bad PRNGs, a bad timestamper that lets people submit arbitraty messages be signed, people talking on an STU-III before going secure, any number of Outlook or IE bugs that let arbitrary code be run, a user who got tricked into running BO, bad physical security, espionage, or just plain bribery.

Similarly, maybe Intel's device gets its reference timeclock from the chipset, or a crystal external to the chip. So what if that lead is cut? What if it's replaced with a slower crystal? There's bound to be implementation issues (if this is ever implemented).

The core technology may be secure, but that doesn't mean the system is secure. Read Crypto-Gram; Bruce talks about attacks against systems all the time, rarely discussing attacks against the ciphers.

Fortunately, it's open source. We can learn from it and take the lessons with us to other code. While there are a lot of people getting mileage out of the amount of malware out there that attacks Windows, one of the reasons there is so much of it is that it is absolutely no challenge to find Windows machines on the net because of their sheer number. And many of them are poorly secured because Windows is the OS that is shipped on machines that are sold to people who have neither the knowledge to secure a computer nor the time to learn how.

There are several efforts to improve the security of Linux and *BSD. In the end, I think they'll benefit us all. Bruce Schneier talks about the window of exposure in his book Secrets and Lies. Efforts to improve the security of open source OSs have several benefits in reducing that window.

Some bugs will be fixed before they are ever exploited. A security vulnerability is still a vulnerability. But the damage is much less in this case.

Some bugs will be fixed faster after they are first exploited. Again, this reduces the damage that is done.

But in the long run, a greater benefit is the number of people who acquire some knowledge of how to analyze and test for security vulnerabilities and how to fix them. That is going to be greatest in open source. It provides the opportunity for competent programmers to wear the white hats.

Fortunately, it's open source. We can learn from it and take the lessons with us to other code. While there are a lot of people getting mileage out of the amount of malware out there that attacks Windows, one of the reasons there is so much of it is that it is absolutely no challenge to find Windows machines on the net because of their sheer number. And many of them are poorly secured because Windows is the OS that is shipped on machines that are sold to people who have neither the knowledge to secure a computer nor the time to learn how.

There are several efforts to improve the security of Linux and *BSD. In the end, I think they'll benefit us all. Bruce Schneier talks about the window of exposure in his book Secrets and Lies. Efforts to improve the security of open source OSs have several benefits in reducing that window.

Some bugs will be fixed before they are ever exploited. A security vulnerability is still a vulnerability. But the damage is much less in this case.

Some bugs will be fixed faster after they are first exploited. Again, this reduces the damage that is done.

But in the long run, a greater benefit is the number of people who acquire some knowledge of how to analyze and test for security vulnerabilities and how to fix them. That is going to be greatest in open source. It provides the opportunity for competent programmers to wear the white hats.

Fortunately, it's open source. We can learn from it and take the lessons with us to other code. While there are a lot of people getting mileage out of the amount of malware out there that attacks Windows, one of the reasons there is so much of it is that it is absolutely no challenge to find Windows machines on the net because of their sheer number. And many of them are poorly secured because Windows is the OS that is shipped on machines that are sold to people who have neither the knowledge to secure a computer nor the time to learn how.

There are several efforts to improve the security of Linux and *BSD. In the end, I think they'll benefit us all. Bruce Schneier talks about the window of exposure in his book Secrets and Lies. Efforts to improve the security of open source OSs have several benefits in reducing that window.

Some bugs will be fixed before they are ever exploited. A security vulnerability is still a vulnerability. But the damage is much less in this case.

Some bugs will be fixed faster after they are first exploited. Again, this reduces the damage that is done.

But in the long run, a greater benefit is the number of people who acquire some knowledge of how to analyze and test for security vulnerabilities and how to fix them. That is going to be greatest in open source. It provides the opportunity for competent programmers to wear the white hats.

It's also worth mentioning that "It's a high-risk algorithm, meaning that there was a high risk of compromise. Hence, the NSA is unlikely to put its most secret (or clever) design elements in the algorithm." (from July 15, 1998 Cryptogram)

So, yeah, I agree completely with all of the conclussions in this thread, but I also think it's very unlikely that the NSA has equal or fewer crypto techniques than the public.

You or Bruce Schneier?

I'm of the opinion that it is almost criminal these days for a system to not run a quick test against passwords as the user chooses it. This is the case on most, if not all linux systems I use, and many others as well.

The problem is, that many users have a large number of systems they must access, and can't be bothered to choose decent ones for each systems, and can't be bothered to change them at any regular interval once they've been set. Password aging is a pretty basic security concept that is rarely implemented.

I always reccommend the use of passwords that are not words, but are pronouncable by the user. Many years ago, when I went to work for MCI, we were assigned MCIMail accounts. When you would initially log in, it would prompt you to change your password. Rather than just let you type in any old thing, it would give you 3 choices like this.

puwacane
solahota
yamatotu

You had the option of choosing one of the three listed, or could roll the dice for another three more to your liking. I kinda liked it.

These days, there are a number of programs that will do this for you quick and easily. I'm sure most of you are aware of 'gpw', which will generate passwords similar to those listed above. I've seen many variations of the program, and in fact currently use a perl-based one on my Solaris boxes when it's time to change passwords.

I mentioned earlier that people have many different passwords to remember. This, as well as the problem of multiple usernames are a major problem for many users. Fortunately, there are software solutions for this as well. For Linux users, I like 'gpasman', which is a small program that will keep track of usernames/passwords for you that is itself protected with a password/passphrase (use a darn good one!). Windows users may find ' password safe' to be a good choice.

Both of the above programs have enabeled me to have excellent passwords everywhere. Password Safe will even generate extremely strong passwords for you.

I guess my point, if there really is one, is that some of the pain of passwords can be alleviated to some degree by good technology. I wish more people took more care in their choice of passwords. Given the results reported elsewhere on this page, they don't seem to.

Perhaps the best solution would be biometrics?

Bruce Schneier warns that biometrics cannot be revoked. If somebody pirates your thumbprint, you can't be issued a new one ;-)

Then there was the amusing experiment where a bunch of Germans managed to fool retina scanners using printed images of eyes that could be taken at a reasonable distance with a camera.

Xix.

Clearly, you have not heard about the gummy fingers.

Yeah. The funny bit is that WoS appear (from the correspondence log on their site) to have replied to the munged .no.junk.mail address. Who knows whether IDSA received anything? :-)

This case really reminds me of the Harrison trawl, where RIAA lawyers asserted that George Harrison owned copyright to images named "Portrait of Mrs. Harrison Williams 1943" and (perhaps more seriously) "Nude Preteens and Young Teens Naked ... Brian is 14 and Harrison is 8".

Maybe he does. In the latter case, shouldn't somebody tell the police? We could do with another paedophile frenzy here in the UK... :-)

It's quite safe - robably more so than having WiFi connections.

"I said something like: 'I can hardly wait for Bluetooth to become universal, because I really want a wireless keyboard and mouse with the "base station" built into my computer.' He said: 'Yes, but you really probably don't want to use Bluetooth for that, because then somebody could stuff keystrokes or mouse clicks into your system.' I didn't know whether to laugh or cry. Talk about not getting it."

What the AC was probably trying to say (but in a, shall we say, crude way) is that there is no key to extract.

Any encryption protocol worth it's salt (ie generally not those propriatary/secret protocols) is protected against this. Eg SSL or SSH which you can snoop all you want, but there's never a key sent in clear text across the channel. Neither is there any key to find in the source. Instead a key is agreed upon by the clients as they connect, but using "one way functions" which are hard and/or practically impossible to crack. You can also use public key encryption with it to add even more security and authentication to the system.

That's why he suggested that you should read about SSL. A cheap way is to just look at the relevant RFC, although it may be a bit complex if you don't have any experience in number theory. Another hint could be look at crypto sites such as Bruce Schneier's crypto-gram (counterpane.com).

In any case, if you use a well tested protocol and implement it correctly (not always trivial) then the system will be secure.