Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Security Expert Paul Kocher Answers, In Detail

Roblimo posted more than 11 years ago | from the your-lock-your-key dept.

Security 227

Paul Kocher, president of Cryptography Research, Inc. and one of the architects of SSL 3.0, said, "The questions were great -- definitely one of the most fun interviews I've ever done." His answers score high on the 'informative' scale, too. Thanks to everyone who submitted such fine questions, and thanks to Paul for putting some real time and effort into his answers.

1) Serious Threats?
by Prizm

While studying cryptanalysis, I've been learning about a number of interesting attacks such as timing attacks and differential power attacks (your specialty, if I recall). While these attacks certainly seem to help cryptanalysis of various ciphers, how practical are they in terms of real security? That is to say, what are the chances that these methods are actively being used by attackers?

Paul:

It depends on the target. If the system you are trying to protect isn't worth an attacker's effort, or if there are easier ways to break in, the chances are small. On the other hand, if you are protecting extremely desirable data (money, data that will affect stock prices, Star Trek episodes, government secrets, etc.) you have to assume that smart people are going to attack your security. We spend a lot of time helping credit card companies and other smart card users build testing programs -- their products need to operate in high-risk environments where DPA, timing analysis, and other sophisticated attacks are a real problem.

2) Worst implementation?
by burgburgburg

In your consulting capacity (and without naming names), have you ever run across a companies security implementation that was so bad, so insecure, so open to exploitation that you felt an overwhelming compulsion to shut down the servers, lock the doors and call in a security SWAT team? That you actually felt like going out and shorting the companies stock? That you had to hold back from whomping someone upside the head? That you inquired about having the head of security investigated to make sure he wasn't a black hat hacker/competitor's security spy/foreign agent? How bad was the worst implementation you've ever seen?

Paul:

To save typing, can I make a list of the systems that don't make me uncomfortable?

A smart, creative, experienced, determined attacker can find flaws in just about any standard commercial product. Our security evaluations find catastrophic problems more than half the time, even though evaluation projects generally have very limited budgets.

The most common situation is where the systems' security objectives could theoretically be met if the designers, implementers, and testers never made any errors. For example, in a quest for slightly better performance, operating systems put lots of complexity into the kernel and give device drivers free reign over the system. This approach would be great if engineers were infallible, but it's a recipe for trouble if all you have are human beings.

What I find most frustrating isn't bad software -- it's situations where we tell a company about a serious problem, but they decide to ignore it because we're under an NDA and therefore the problem won't hurt sales. If your company is knowingly advertising an insecure or untrustworthy product as secure, try to do something about it. Intentionally misleading customers is illegal, immoral, and a gigantic liability risk. (Keywords: Enron, asbestos, cigarettes.)

It's also frustrating that users keep buying products from companies that make misleading or unsupported claims about their security. If users won't pay extra for security, companies are going to keep selling insecure products (and our market will remain relatively small :-).

As for the worst security, I nominate the following password checking code:

  gets(userEntry);
     if (memcmp(userEntry, correctPassword, strlen(userEntry)) != 0)
         return (BAD_PASSWORD);

ROT13 SPOILER: Na rzcgl cnffjbeq jvyy cnff guvf purpx orpnhfr gur pbqr hfrf gur yratgu bs gur hfre ragel, abg gur yratgu bs gur pbeerpg cnffjbeq. Bgure cbgragvny ceboyrzf (ohssre biresybjf, rgp.) ner yrsg nf na rkrepvfr sbe gur ernqre. [Funzryrff cyht: Vs lbh rawbl ceboyrzf yvxr guvf, unir fgebat frphevgl rkcrevrapr, pbzzhavpngr jryy, naq jnag n wbo ng n sha (naq cebsvgnoyr) pbzcnal, ivfvg uggc://jjj.pelcgbtencul.pbz/pbzcnal/pnerref.ugzy.]

3) Internet broken?
by bpfinn

The Internet was primarily designed for use by researchers who were collaborating on similar projects, and so security was not part of the design. Would you advocate designing and building another Internet where security was a major design goal? Or can we tweak the current Internet to reduce that amount of maliciousness that goes on now?

Paul:

I don't think the core Internet is the problem. While some protocols need upgrading, the Internet does a great job of providing untrusted, unreliable communications. Trying to impose security policies in the network layer would destroy the spontaneity and openness that make the Internet great. In other words, we need to find ways to cope with the fact that the Internet is always going to be dangerous.

The place where I see the real need for improved security is in the protocols, applications, and devices that use the Internet. For example, Moore's Law has made processing power so cheap that there is no reason why web pages aren't all encrypted. Similarly, IPSEC, VPN tunnels, and e-mail encryption should be used much more widely.

Of course, large networks are always going to have unpredictable complex security risks. As a result, if you are dealing with critical systems, they should be as disconnected as possible.

4) Dive Right In
by Accidental Hack

What does a newbie do? Having been put in a position where I'm partly responsible for server security, and having been put in that position without the proper background (and the responsibility is here to stay), how do I get my head straight on the core issues and make sure I'm not leaving the doors open for anyone to do whatever they want? Reading books/articles doesn't seem to be enough, but if that's the best place to begin, any recommendations?

Paul:

You are really asking two questions: how to learn about security, and what to do if you are put in situations where you don't know what to do.

For people wanting to learn about security or cryptography, I'm a big supporter of hands-on experience. When you hear about a security bug, go see what actually went wrong. Implement DES, AES, RSA, and your own big-number library. Set up a couple of poorly-configured Linux boxes and break into them. Install a sniffer and sniff your own network traffic. Observe and modify software programs. Learn C/C++. Study known bugs in open-source crypto code and hunt for new ones. If you have the budget at work, hire a security expert and ask lots of questions. Whatever you do, be careful to follow the laws (even if you disagree with them) and act ethically.

The question of what to do if you are put in a situation beyond your skill level ultimately depends on the risks involved. With ordinary servers (corporate e-mail and the like), occasional problems may not be that catastrophic if you have good backups.

On the other hand, if the chances or consequences of failure are severe, you can't just "give it a try" any more than I should try open heart surgery or piloting a 747. For example, if you are dealing with critical infrastructure, likely fraud targets, pay TV networks (or anything involving piracy), or large customer databases, get help. Even if you are experienced, you need to have someone check your work. When you do hire someone, make sure they will answer questions, educate you, and provide good documentation. Avoid mad scientists, people who have never done serious engineering, and anyone who views security audits as threatening or insulting.

5) Quantum Computing and Cryptography
by Nova Express

Will the advent of quantum computing render even current, state-of-the-art cryptography obsolete? Is there any way that cryptography can overcome the challenge presented by quantum computing? And how long will it be, if ever, until quantum computer's can break current, state-of-the-art cryptography?

Paul:

Quantum computing is possibly the coolest discovery in theoretical computer science in the last few decades because it completely changes the rules of computation.

As a practical matter, however, it's not a significant security risk compared to the other things we have to worry about. I think it's highly unlikely that quantum computers will overtake regular computers in the next 50 years at (for example) breaking RSA. The reason for my skepticism is that the challenges involved in building a useful quantum computer are staggering. For example, decoherence becomes a much greater problem as the computer gets larger, yet quantum computers have to be huge because they don't operate sequentially. (Imagine hardware design with no flip flops -- just combinatorial logic.) While error-correction techniques have been proposed, these further increase the complexity of the circuit.

If someone did find a way to build arbitrarily large quantum computers, it would be the end of most existing public key cryptographic schemes. Symmetric cryptography, however, would still work, though key lengths would need to be doubled to get the same level of security.

Note: Quantum computing is different from quantum cryptography. The latter is a method for preventing eavesdropping, typically using polarized photons and entanglement. While quantum cryptography is feasible to implement and is also neat research, I don't see any practical use for it because it requires that parties exchange photons directly. As a result, it won't work over packet switched networks. Furthermore, existing algorithms like AES can do all the same things, and much more. As a result, the only scenario I can see where quantum cryptography would be relevant would be unbelievably weird discovery that completely demolished cryptography, such as someone showing that P=NP.

6) SSL and Forward Security
by Effugas

Paul,

First of all, thank you for agreeing to be interviewed here. It's greatly appreciated.

I'm curious if you wouldn't mind elaborating a bit on the catastrophic failure of the SSL security architecture given the compromise of an RSA private key. An attacker can literally sniff all traffic for a year, break in once to steal the key, then continue to passively decrypt not only all of last year's traffic but all of next year's too. And if he'd like to partake in more active attacks -- session hijacking, malicious data insertion, etc. -- that's fine too.

In short, why? After so much work was done to come up with a secure per-session master secret, what caused the asymmetric component to be left so vulnerable? Yes, PGP's just as vulnerable to this failure mode, but PGP doesn't have the advantage of a live socket to the other host.

More importantly, what can be done for those nervous about this shortcoming in an otherwise laudable architecture? I looked at the DSA modes, but nothing seems to accelerate them (which kills its viability for the sites who would need it most). Ephemeral RSA seemed interesting, but according to Rescola's documentation it only supports a maximum of 512 bits for the per-session asymmetric key -- insufficient. If Verisign would sign a newly generated key each day, that'd work -- but then, you'd probably need to sign over part of your company to afford the service. Would it even be possible for them to sign one long term key, tied to a single fully qualified domain name, that could then sign any number of ephemeral or near-ephemeral short term keys within the timeframe allotted in the long term cert?

Thanks again for any insight on the matter you may be able to provide!

Yours Truly,

Dan Kaminsky
DoxPara Research
Paul:

I specifically designed the ephemeral Diffie-Hellman with DSA option in SSL 3.0 to provide perfect forward secrecy (PFS). While it used to be true that DSA's performance was a concern, it shouldn't be a problem anymore.

[*] If you want to avoid DSA, you can also do a normal RSA handshake then immediately renegotiate with an uncertified ephemeral Diffie-Hellman handshake. (SSL 3.0 and TLS 1.0 allow either party to request a renegotiation at any time, with the renegotiation process protected underneath the first handshake.) As your question mentions, short-lived certificates would work if a suitable CA provided them.

Making PFS mandatory wasn't feasible in SSL 3.0 because of performance requirements, the need to maintain compatibility with legacy RSA certificates, and licensing issues. (Back in 1996, RSA was patented and most companies only had limited RSA toolkit licenses, not patent licenses.)

Overall, I'm delighted so see how many ways SSL 3.0 is being used and that it's become the most widely deployed cryptographic protocol in the world. While there are reasons to debate design choices I made, I don't know that the protocol's handling of PFS is one of them. Although some implementations have had bugs and guidelines had to be added to address error-analysis attacks, the overall protocol has held up well.

[*] In 1996 (when the SSL 3.0 spec came out), computers were only 4% of their current speed. (Moore's Law predicts 4.67 speed doublings in 7 years.) Today, any modern CPU should give well beyond 200 2048-bit DSA verifies/second. Averaging 10 handshakes/second (5% load) = 864K connections daily per CPU. Unless you are running one of the largest web sites (or have your server misconfigured to disable session resumption), this isn't likely to be a problem. For really high-volume servers, SSL accelerators are affordable and very fast. In general, it's rare these days to find a situation where the speed of standard cryptographic operations is actually a problem.

7) trust in open p2p communities
by smd4985

as a software engineer building open source p2p applications (gnutella), we are faced with a huge problem: how do we establish trust in a open environment where any application that speaks the protocol can participate? we've thought of various cryptographic systems to establish trust, but they have several fatal flaws - they require some sort of centralization (a no-no in a p2p environment), they lock out 'untrusted' vendors, etc.

what can we do to maintain an open environment and establish trust between peers?

Paul:

There certainly are decentralized ways to establish trust (PGP's web of trust comes to mind), but you can't have trust and complete anonymity. The closest you'll be able to do is to evaluate participants based on their past actions and assertions. Before you can begin a design, you'll need to clearly define what you are trying to enable, what you are trying to prevent, and what automated rules can distinguish between legitimate and illegitimate actions.

(Note: While I presume that the question relates to legitimate P2P applications, piracy over P2P systems is driving copyright owners to seek legislative and legal relief. The fact that the Internet can be used to massively violate intellectual property rights doesn't make it moral to do so.)

8) How do you think?
by Charles Dodgeson

When I first read about some discovery of a weakness (for example, I know your name from your work on MD5), I am always struck by the thinking beyond the framework of the designer of the system and of the community to date. The same things strikes me about timing attacks and similar sorts of things. These are things that I wouldn't have thought of in a million years. Can you give any insight into how minds like yours work. And to what extent you think that this might be a trainable skill.

I normally hate the cliche of "thinking outside of the box", but here it is fully appropriate.

Paul:

Security work requires understanding systems at multiple levels. For example, differential power analysis involves transistor-level properties affecting logic units affecting microcode affecting CPUs affecting crypto algorithms affecting protocols affecting business requirements. For engineers who are used to working at only a single layer, security results often seem surprising. Broad experience is also important because the vast majority of security problems involve unintended interactions between areas designed by different people.

Two specific subjects that I think are often neglected are low-level programming and statistics. These are essential to understand how things actually work and to assess the likelihood that systems will fail. A skeptical mindset is also important. Try to assume things are bad until you are convinced otherwise.

Some specific questions that are helpful to ask include:

  • What information and capabilities are available to attackers?
  • What information and capabilities are available to attackers?
  • What esoteric corner cases has nobody studied carefully?
  • How would a lazy or inexperienced designer have designed the system?
  • What states can each participant be in?
  • Where is the most complexity in the security perimeter? (Complex parts are the most likely to fail.)
  • What unwritten assumptions are being made, and are they correct?
If you aren't sure how to begin an evaluation, consider sketching out how you would have done the design. You can then compare your design against the target. The differences often reveal mistakes you made (a great way to learn) or identify problems with the target system.

9) Is the Technology ahead of us?
by Coz

Thanks for letting us ask you these questions.

Over the last couple of decades, cryptography has gone from being the domain of major governments, big business, and the odd hobbyist and researcher to being a massive public industry that anyone can (and does) participate in, with new algorithms published and new applications announced almost every week. Meanwhile, we learn of vulnerabilities in various implementations of cryptosystems much more frequently than we hear of people discovering fundamental flaws in the cryptosystems themselves.

Given these facts, do you think we need to change focus, turning to validating and "approving" implementations of cryptosystems (such as your own SSL 3.0) or should the emphasis of the "crypto community" continue to be innovation in fundamentals of cryptographic systems and new applications for them? How important is it to have someone verify that a cryptosystem is implemented well?

Paul:

Validation is by far the most critical unsolved problem in security.

I view security as probabilistic: there is always some chance of failure, and validation is the only way to reduce the odds of failure. For example, a well-tested piece of code is more secure than an identical piece of code that hasn't been tested.

Although innovation is great on the research side, real-world systems should use well-tested techniques wherever possible. For example, on the algorithm side, we use RSA, triple DES, AES, and SHA-1 at Cryptography Research unless we have to use something else. (This is rare.) We use these algorithms because they are well reviewed, making the risk of an unexpected cryptanalytic attack low. In contrast, catastrophic flaws in new schemes are very common.

When you move beyond the basic algorithms, validation unfortunately becomes extremely difficult for many reasons:

  • The complexity of software is increasing exponentially, but the number of skilled security experts (and their intelligence and productivity) is staying roughly constant.
  • Many designs are so poorly architected or implemented that they are infeasible to validate.
  • Validation is much more difficult than writing new code (and it's less fun), so many people avoid it.
  • Engineers are cranking out such vast quantities of code that testing can't possibly keep up.
  • Existing validation tools are really quite poor.
  • The cost of security testing can be hard to justify because most users won't pay extra for better security.
  • There is no easy way for users to distinguish between well-tested products and those that aren't.
  • Testing takes a long time, slowing down product launches.
  • There is no easy way to standardize security evaluations because attackers don't limit themselves to standard attacks.
  • Catching 90% of the flaws doesn't help if attackers are willing to look 10 times harder to find flaws.
  • Developers don't have much incentive to make painful sacrifices for security because they aren't the ones who incur the risk.
Long-term, I expect security will become like the pharmaceutical and aviation industries. Regulations and liability would improve safety, but would also make product development hugely expensive. Regardless of whether this would be better or worse than the current state of affairs, it looks inevitable.

10) Re:fhnlsfdlkm&5nlkd%Bvbcvbc
by Anonymous Coward

0eefa Uv, V'z jbaqrevat vs lbh guvax gurer'f n shgher sbe EBG13. V'ir urneq vg'f cerggl frpher...

Lbh pna ernq guvf? Qnza!

Paul:

Holy cow! Juvyr lbh znl unir svtherq bhg zl fhcre-frperg EBG13 pvcure, abobql jvyy rire penpx *guvf* zrffntr orpnhfr V fjvgpurq gb bhe hygen-frperg cyna O: nccylvat n Pnrfre pvcure 13 gvzrf :-).

cancel ×

227 comments

Sorry! There are no comments related to the filter you selected.

in case of /.ing (-1)

I Have a Hard (538104) | more than 11 years ago | (#5608076)

1) Serious Threats?
by Prizm

While studying cryptanalysis, I've been learning about a number of interesting attacks such as timing attacks and differential power attacks (your specialty, if I recall). While these attacks certainly seem to help cryptanalysis of various ciphers, how practical are they in terms of real security? That is to say, what are the chances that these methods are actively being used by attackers?

Paul:

It depends on the target. If the system you are trying to protect isn't worth an attacker's effort, or if there are easier ways to break in, the chances are small. On the other hand, if you are protecting extremely desirable data (money, data that will affect stock prices, Star Trek episodes, government secrets, etc.) you have to assume that smart people are going to attack your security. We spend a lot of time helping credit card companies and other smart card users build testing programs -- their products need to operate in high-risk environments where DPA, timing analysis, and other sophisticated attacks are a real problem.

2) Worst implementation?
by burgburgburg

In your consulting capacity (and without naming names), have you ever run across a companies security implementation that was so bad, so insecure, so open to exploitation that you felt an overwhelming compulsion to shut down the servers, lock the doors and call in a security SWAT team? That you actually felt like going out and shorting the companies stock? That you had to hold back from whomping someone upside the head? That you inquired about having the head of security investigated to make sure he wasn't a black hat hacker/competitor's security spy/foreign agent? How bad was the worst implementation you've ever seen?

Paul:

To save typing, can I make a list of the systems that don't make me uncomfortable?

A smart, creative, experienced, determined attacker can find flaws in just about any standard commercial product. Our security evaluations find catastrophic problems more than half the time, even though evaluation projects generally have very limited budgets.

The most common situation is where the systems' security objectives could theoretically be met if the designers, implementers, and testers never made any errors. For example, in a quest for slightly better performance, operating systems put lots of complexity into the kernel and give device drivers free reign over the system. This approach would be great if engineers were infallible, but it's a recipe for trouble if all you have are human beings.

What I find most frustrating isn't bad software -- it's situations where we tell a company about a serious problem, but they decide to ignore it because we're under an NDA and therefore the problem won't hurt sales. If your company is knowingly advertising an insecure or untrustworthy product as secure, try to do something about it. Intentionally misleading customers is illegal, immoral, and a gigantic liability risk. (Keywords: Enron, asbestos, cigarettes.)

It's also frustrating that users keep buying products from companies that make misleading or unsupported claims about their security. If users won't pay extra for security, companies are going to keep selling insecure products (and our market will remain relatively small :-).

As for the worst security, I nominate the following password checking code:

gets(userEntry);
if (memcmp(userEntry, correctPassword,
strlen(userEntry)) != 0)
return (BAD_PASSWORD);

ROT13 SPOILER: Na rzcgl cnffjbeq jvyy cnff guvf purpx orpnhfr gur pbqr hfrf gur yratgu bs gur hfre ragel, abg gur yratgu bs gur pbeerpg cnffjbeq. Bgure cbgragvny ceboyrzf (ohssre biresybjf, rgp.) ner yrsg nf na rkrepvfr sbe gur ernqre. [Funzryrff cyht: Vs lbh rawbl ceboyrzf yvxr guvf, unir fgebat frphevgl rkcrevrapr, pbzzhavpngr jryy, naq jnag n wbo ng n sha (naq cebsvgnoyr) pbzcnal, ivfvg uggc://jjj.pelcgbtencul.pbz/pbzcnal/pnerref.ugzy.]

3) Internet broken?
by bpfinn

The Internet was primarily designed for use by researchers who were collaborating on similar projects, and so security was not part of the design. Would you advocate designing and building another Internet where security was a major design goal? Or can we tweak the current Internet to reduce that amount of maliciousness that goes on now?

Paul:

I don't think the core Internet is the problem. While some protocols need upgrading, the Internet does a great job of providing untrusted, unreliable communications. Trying to impose security policies in the network layer would destroy the spontaneity and openness that make the Internet great. In other words, we need to find ways to cope with the fact that the Internet is always going to be dangerous.

The place where I see the real need for improved security is in the protocols, applications, and devices that use the Internet. For example, Moore's Law has made processing power so cheap that there is no reason why web pages aren't all encrypted. Similarly, IPSEC, VPN tunnels, and e-mail encryption should be used much more widely.

Of course, large networks are always going to have unpredictable complex security risks. As a result, if you are dealing with critical systems, they should be as disconnected as possible.

4) Dive Right In
by Accidental Hack

What does a newbie do? Having been put in a position where I'm partly responsible for server security, and having been put in that position without the proper background (and the responsibility is here to stay), how do I get my head straight on the core issues and make sure I'm not leaving the doors open for anyone to do whatever they want? Reading books/articles doesn't seem to be enough, but if that's the best place to begin, any recommendations?

Paul:

You are really asking two questions: how to learn about security, and what to do if you are put in situations where you don't know what to do.

For people wanting to learn about security or cryptography, I'm a big supporter of hands-on experience. When you hear about a security bug, go see what actually went wrong. Implement DES, AES, RSA, and your own big-number library. Set up a couple of poorly-configured Linux boxes and break into them. Install a sniffer and sniff your own network traffic. Observe and modify software programs. Learn C/C++. Study known bugs in open-source crypto code and hunt for new ones. If you have the budget at work, hire a security expert and ask lots of questions. Whatever you do, be careful to follow the laws (even if you disagree with them) and act ethically.

The question of what to do if you are put in a situation beyond your skill level ultimately depends on the risks involved. With ordinary servers (corporate e-mail and the like), occasional problems may not be that catastrophic if you have good backups.

On the other hand, if the chances or consequences of failure are severe, you can't just "give it a try" any more than I should try open heart surgery or piloting a 747. For example, if you are dealing with critical infrastructure, likely fraud targets, pay TV networks (or anything involving piracy), or large customer databases, get help. Even if you are experienced, you need to have someone check your work. When you do hire someone, make sure they will answer questions, educate you, and provide good documentation. Avoid mad scientists, people who have never done serious engineering, and anyone who views security audits as threatening or insulting.

5) Quantum Computing and Cryptography
by Nova Express

Will the advent of quantum computing render even current, state-of-the-art cryptography obsolete? Is there any way that cryptography can overcome the challenge presented by quantum computing? And how long will it be, if ever, until quantum computer's can break current, state-of-the-art cryptography?

Paul:

Quantum computing is possibly the coolest discovery in theoretical computer science in the last few decades because it completely changes the rules of computation.

As a practical matter, however, it's not a significant security risk compared to the other things we have to worry about. I think it's highly unlikely that quantum computers will overtake regular computers in the next 50 years at (for example) breaking RSA. The reason for my skepticism is that the challenges involved in building a useful quantum computer are staggering. For example, decoherence becomes a much greater problem as the computer gets larger, yet quantum computers have to be huge because they don't operate sequentially. (Imagine hardware design with no flip flops -- just combinatorial logic.) While error-correction techniques have been proposed, these further increase the complexity of the circuit.

If someone did find a way to build arbitrarily large quantum computers, it would be the end of most existing public key cryptographic schemes. Symmetric cryptography, however, would still work, though key lengths would need to be doubled to get the same level of security.

Note: Quantum computing is different from quantum cryptography. The latter is a method for preventing eavesdropping, typically using polarized photons and entanglement. While quantum cryptography is feasible to implement and is also neat research, I don't see any practical use for it because it requires that parties exchange photons directly. As a result, it won't work over packet switched networks. Furthermore, existing algorithms like AES can do all the same things, and much more. As a result, the only scenario I can see where quantum cryptography would be relevant would be unbelievably weird discovery that completely demolished cryptography, such as someone showing that P=NP.

6) SSL and Forward Security
by Effugas

Paul,

First of all, thank you for agreeing to be interviewed here. It's greatly appreciated.

I'm curious if you wouldn't mind elaborating a bit on the catastrophic failure of the SSL security architecture given the compromise of an RSA private key. An attacker can literally sniff all traffic for a year, break in once to steal the key, then continue to passively decrypt not only all of last year's traffic but all of next year's too. And if he'd like to partake in more active attacks -- session hijacking, malicious data insertion, etc. -- that's fine too.

In short, why? After so much work was done to come up with a secure per-session master secret, what caused the asymmetric component to be left so vulnerable? Yes, PGP's just as vulnerable to this failure mode, but PGP doesn't have the advantage of a live socket to the other host.

More importantly, what can be done for those nervous about this shortcoming in an otherwise laudable architecture? I looked at the DSA modes, but nothing seems to accelerate them (which kills its viability for the sites who would need it most). Ephemeral RSA seemed interesting, but according to Rescola's documentation it only supports a maximum of 512 bits for the per-session asymmetric key -- insufficient. If Verisign would sign a newly generated key each day, that'd work -- but then, you'd probably need to sign over part of your company to afford the service. Would it even be possible for them to sign one long term key, tied to a single fully qualified domain name, that could then sign any number of ephemeral or near-ephemeral short term keys within the timeframe allotted in the long term cert?

Thanks again for any insight on the matter you may be able to provide!

Yours Truly,

Dan Kaminsky
DoxPara Research

Paul:

I specifically designed the ephemeral Diffie-Hellman with DSA option in SSL 3.0 to provide perfect forward secrecy (PFS). While it used to be true that DSA's performance was a concern, it shouldn't be a problem anymore.

[*] If you want to avoid DSA, you can also do a normal RSA handshake then immediately renegotiate with an uncertified ephemeral Diffie-Hellman handshake. (SSL 3.0 and TLS 1.0 allow either party to request a renegotiation at any time, with the renegotiation process protected underneath the first handshake.) As your question mentions, short-lived certificates would work if a suitable CA provided them.

Making PFS mandatory wasn't feasible in SSL 3.0 because of performance requirements, the need to maintain compatibility with legacy RSA certificates, and licensing issues. (Back in 1996, RSA was patented and most companies only had limited RSA toolkit licenses, not patent licenses.)

Overall, I'm delighted so see how many ways SSL 3.0 is being used and that it's become the most widely deployed cryptographic protocol in the world. While there are reasons to debate design choices I made, I don't know that the protocol's handling of PFS is one of them. Although some implementations have had bugs and guidelines had to be added to address error-analysis attacks, the overall protocol has held up well.

[*] In 1996 (when the SSL 3.0 spec came out), computers were only 4% of their current speed. (Moore's Law predicts 4.67 speed doublings in 7 years.) Today, any modern CPU should give well beyond 200 2048-bit DSA verifies/second. Averaging 10 handshakes/second (5% load) = 864K connections daily per CPU. Unless you are running one of the largest web sites (or have your server misconfigured to disable session resumption), this isn't likely to be a problem. For really high-volume servers, SSL accelerators are affordable and very fast. In general, it's rare these days to find a situation where the speed of standard cryptographic operations is actually a problem.

7) trust in open p2p communities
by smd4985

as a software engineer building open source p2p applications (gnutella), we are faced with a huge problem: how do we establish trust in a open environment where any application that speaks the protocol can participate? we've thought of various cryptographic systems to establish trust, but they have several fatal flaws - they require some sort of centralization (a no-no in a p2p environment), they lock out 'untrusted' vendors, etc.

what can we do to maintain an open environment and establish trust between peers?

Paul:

There certainly are decentralized ways to establish trust (PGP's web of trust comes to mind), but you can't have trust and complete anonymity. The closest you'll be able to do is to evaluate participants based on their past actions and assertions. Before you can begin a design, you'll need to clearly define what you are trying to enable, what you are trying to prevent, and what automated rules can distinguish between legitimate and illegitimate actions.

(Note: While I presume that the question relates to legitimate P2P applications, piracy over P2P systems is driving copyright owners to seek legislative and legal relief. The fact that the Internet can be used to massively violate intellectual property rights doesn't make it moral to do so.)

8) How do you think?
by Charles Dodgeson

When I first read about some discovery of a weakness (for example, I know your name from your work on MD5), I am always struck by the thinking beyond the framework of the designer of the system and of the community to date. The same things strikes me about timing attacks and similar sorts of things. These are things that I wouldn't have thought of in a million years. Can you give any insight into how minds like yours work. And to what extent you think that this might be a trainable skill.

I normally hate the cliche of "thinking outside of the box", but here it is fully appropriate.

Paul:

Security work requires understanding systems at multiple levels. For example, differential power analysis involves transistor-level properties affecting logic units affecting microcode affecting CPUs affecting crypto algorithms affecting protocols affecting business requirements. For engineers who are used to working at only a single layer, security results often seem surprising. Broad experience is also important because the vast majority of security problems involve unintended interactions between areas designed by different people.

Two specific subjects that I think are often neglected are low-level programming and statistics. These are essential to understand how things actually work and to assess the likelihood that systems will fail. A skeptical mindset is also important. Try to assume things are bad until you are convinced otherwise.

Some specific questions that are helpful to ask include:

* information and capabilities are available to attackers?
* esoteric corner cases has nobody studied carefully?
* would a lazy or inexperienced designer have designed the system?
* states can each participant be in?
* e is the most complexity in the security perimeter? (Complex parts are the most likely to fail.)
* unwritten assumptions are being made, and are they correct?

If you aren't sure how to begin an evaluation, consider sketching out how you would have done the design. You can then compare your design against the target. The differences often reveal mistakes you made (a great way to learn) or identify problems with the target system.

9) Is the Technology ahead of us?
by Coz

Thanks for letting us ask you these questions.

Over the last couple of decades, cryptography has gone from being the domain of major governments, big business, and the odd hobbyist and researcher to being a massive public industry that anyone can (and does) participate in, with new algorithms published and new applications announced almost every week. Meanwhile, we learn of vulnerabilities in various implementations of cryptosystems much more frequently than we hear of people discovering fundamental flaws in the cryptosystems themselves.

Given these facts, do you think we need to change focus, turning to validating and "approving" implementations of cryptosystems (such as your own SSL 3.0) or should the emphasis of the "crypto community" continue to be innovation in fundamentals of cryptographic systems and new applications for them? How important is it to have someone verify that a cryptosystem is implemented well?

Paul:

Validation is by far the most critical unsolved problem in security.

I view security as probabilistic: there is always some chance of failure, and validation is the only way to reduce the odds of failure. For example, a well-tested piece of code is more secure than an identical piece of code that hasn't been tested.

Although innovation is great on the research side, real-world systems should use well-tested techniques wherever possible. For example, on the algorithm side, we use RSA, triple DES, AES, and SHA-1 at Cryptography Research unless we have to use something else. (This is rare.) We use these algorithms because they are well reviewed, making the risk of an unexpected cryptanalytic attack low. In contrast, catastrophic flaws in new schemes are very common.

When you move beyond the basic algorithms, validation unfortunately becomes extremely difficult for many reasons:

* complexity of software is increasing exponentially, but the number of skilled security experts (and their intelligence and productivity) is staying roughly constant.
* designs are so poorly architected or implemented that they are infeasible to validate.
* dation is much more difficult than writing new code (and it's less fun), so many people avoid it.
* Engineers are cranking out such vast quantities of code that testing can't possibly keep up.
* Existing validation tools are really quite poor.
* The cost of security testing can be hard to justify because most users won't pay extra for better security.
* There is no easy way for users to distinguish between well-tested products and those that aren't.
* Testing takes a long time, slowing down product launches.
* There is no easy way to standardize security evaluations because attackers don't limit themselves to standard attacks.
* Catching 90% of the flaws doesn't help if attackers are willing to look 10 times harder to find flaws.
* Developers don't have much incentive to make painful sacrifices for security because they aren't the ones who incur the risk.

Long-term, I expect security will become like the pharmaceutical and aviation industries. Regulations and liability would improve safety, but would also make product development hugely expensive. Regardless of whether this would be better or worse than the current state of affairs, it looks inevitable. ,p> 10) Re:fhnlsfdlkm&5nlkd%Bvbcvbc
by Anonymous Coward

0eefa Uv, V'z jbaqrevat vs lbh guvax gurer'f n shgher sbe EBG13. V'ir urneq vg'f cerggl frpher...

Lbh pna ernq guvf? Qnza!

Paul:

Holy cow! Juvyr lbh znl unir svtherq bhg zl fhcre-frperg EBG13 pvcure, abobql jvyy rire penpx *guvf* zrffntr orpnhfr V fjvgpurq gb bhe hygen-frperg cyna O: nccylvat n Pnrfre pvcure 13 gvzrf :-).

Re:in case of /.ing (-1)

Anonymous Coward | more than 11 years ago | (#5608110)

Go Butler!

laksdjf92e3ih12y (-1)

itallushrt (148885) | more than 11 years ago | (#5608085)

klsjadf92391j2h08u2oij12-90i12kh 09iu293u902uj3lkj1290

First Post

Not; was: Re:laksdjf92e3ih12y (0)

Anonymous Coward | more than 11 years ago | (#5608288)

Look again, dillwad. Maybe you meant first post in zero-base counting system?

I dig boners! (-1)

Anonymous Coward | more than 11 years ago | (#5608109)

I am most likely a gay homosexual faggot, and I read slashdot!

Re:I dig boners! (0)

Anonymous Coward | more than 11 years ago | (#5608946)

talk about being redundant..

Protected material (1)

jemnery (562697) | more than 11 years ago | (#5608130)

"money, data that will affect stock prices, Star Trek episodes, government secrets, etc"

This made me laugh; good to see the guy has a sense of humour. Then I realised that you can probably get all this stuff on Kazaa, anyway.

--
jc

Forget ROT13 (0)

Anonymous Coward | more than 11 years ago | (#5608131)

Let's go with ROT1 and build a company named eBooks around it.

For the security-lingo disadvantaged... (0, Troll)

TopShelf (92521) | more than 11 years ago | (#5608134)

Anybody care to play ROT13 translator???

Re:For the security-lingo disadvantaged... (0)

Anonymous Coward | more than 11 years ago | (#5608190)

An empty password will pass this check because the code uses the length of the user entry, not the length of the correct password. Other potential problems (buffer overflows, etc.) are left as an exercise for the reader. [Shameless plug: If you enjoy problems like this, have strong security experience, communicate well, and want a job at a fun (and profitable) company, visit http://www.cryptography.com/company/careers.html.]

Re:For the security-lingo disadvantaged... (1)

dylan_- (1661) | more than 11 years ago | (#5608191)

Anybody care to play ROT13 translator???
Try this site. [degraeve.com]

Re:For the security-lingo disadvantaged... (1)

Carbonite (183181) | more than 11 years ago | (#5608221)

ROT13 Spoiler:

An empty password will pass this check because the code uses the length of the user entry, not the length of the correct password. Other potential problems (buffer overflows, etc.) are left as an exercise for the reader. [Shameless plug: If you enjoy problems like this, have strong security experience, communicate well, and want a job at a fun (and profitable) company, visit http://www.cryptography.com/company/careers.html.]

Re:For the security-lingo disadvantaged... (1)

nachoboy (107025) | more than 11 years ago | (#5608240)

ROT13 is based on the fact that there are 26 alphabetic characters. By adding 13 to any character value, you get a letter exactly halfway 'later' in the alphabet. The advantage is that if you do it again, you get the original text.

See http://www.allthingsuseless.com/rot13.php [allthingsuseless.com] to play around with it.

The translation:
An empty password will pass this check because the code uses the length of the user entry, not the length of the correct password. Other potential problems (buffer overflows, etc.) are left as an exercise for the reader. [Shameless plug: If you enjoy problems like this, have strong security experience, communicate well, and want a job at a fun (and profitable) company, visit http://www.cryptography.com/company/careers.html.]

Re:For the security-lingo disadvantaged... (2, Funny)

Carbonite (183181) | more than 11 years ago | (#5608246)

Question 10:

0rrsn Hi, I'm wondering if you think there's a future for ROT13. I've heard it's pretty secure...

You can read this? Damn!

Cnhy:

Ubyl pbj! While you may have figured out my super-secret ROT13 cipher, nobody will ever crack *this* message because I switched to our ultra-secret plan B: applying a Caeser cipher 13 times :-).

The solution (1)

Nugget (7382) | more than 11 years ago | (#5608312)

Clearly the solution to ROT13 insecurity is to use dual rounds of ROT13!

double-ROT13 (2, Funny)

Thud457 (234763) | more than 11 years ago | (#5608721)

It has the added advantage of appearing to be cleartext, thus making the attacker think they've decoded the message!

Re:For the security-lingo disadvantaged... (1)

plcurechax (247883) | more than 11 years ago | (#5608254)

For Linux/Unix/BSD users:

tr 'a-zA-Z' 'n-za-mN-ZA-M'

Re:For the security-lingo disadvantaged... (1)

ddmckay (56023) | more than 11 years ago | (#5608259)

tr n-za-mN-ZA-M a-zA-z

Re:For the security-lingo disadvantaged... (1)

wangi (16741) | more than 11 years ago | (#5608268)

Perl script for you:

#!/usr/bin/perl -p
y/A-Za-z/N-ZA-Mn-za-m/;

Re:For the security-lingo disadvantaged... (1)

pldms (136522) | more than 11 years ago | (#5608336)

In emacs you might enjoy the raw power of:

M-x rot13-other-window :-)

Re:For the security-lingo disadvantaged... (2, Informative)

Enrico Pulatzo (536675) | more than 11 years ago | (#5608342)

Copy the text to ViM (not sure about Vi), then do a "g?" Works for me.

Re:For the security-lingo disadvantaged... (1)

ojplg (249361) | more than 11 years ago | (#5608842)

"g??" encrypts/decrypts one line in vim.

Re:For the security-lingo disadvantaged... (1)

rleibman (622895) | more than 11 years ago | (#5608419)

Am I the only one with Google access?
Among many others:
http://tools.geht.net/rot13.html [geht.net]

Re:For the security-lingo disadvantaged... (1)

Thud457 (234763) | more than 11 years ago | (#5608753)

I misread your statement at first and wondered where in google language tools it does ROT13.
That seems like an easy and useful tool for google itself to provide.

On another note, I don't recall ever running into ROT13 in dejaNews, er, google groups. Do they translate that at archival time?

Re:For the security-lingo disadvantaged... (1)

osgeek (239988) | more than 11 years ago | (#5608470)

Rot13.com [rot13.com] , dude.

Re:For the security-lingo disadvantaged... (1)

Hard_Code (49548) | more than 11 years ago | (#5608966)

ROT13 has already been cracked. EBG13 is MUCH more secure.

Re:For the security-lingo disadvantaged... (1)

Loopsnut (589418) | more than 11 years ago | (#5609037)

NDA Questions (1)

Blaine Hilton (626259) | more than 11 years ago | (#5608139)

What struck me reading this was he mentioned that he has worked under the terms of an NDA and the company decided not to fix thier software. How can this be discovered? If he goes to the police surly this goes beyond the NDA. If anyone could clarify this I would appreciate it.

The essence of the NDA ... (1)

burgburgburg (574866) | more than 11 years ago | (#5608343)

precludes him from going to the police or further identifying the offending company.

And don't call me Surly.

Re:The essence of the NDA ... (1)

NDPTAL85 (260093) | more than 11 years ago | (#5608379)

No contract, not even an NDA can prevent you from reporting a crime to the police.

Re:The essence of the NDA ... (1)

cyb97 (520582) | more than 11 years ago | (#5608486)

I guess priests would make good security-auditors as they are not obliged to disclose anything brought to them in confidence...

Re:The essence of the NDA ... (1)

Carik (205890) | more than 11 years ago | (#5609006)

Yes, but making insecure software is not a crime. Bad business practice, yes. Obnoxious, yes. Dangerous, yes. Illegal... sadly, no.

Re:NDA Questions (0)

Anonymous Coward | more than 11 years ago | (#5608418)

If there's a criminal case, NDA's don't mean shit - they`re purely civil law - its up to the company to sue him for breach of contract, and he has the defense that he had to obey the law.

Call Ashcroft! (-1)

Soko (17987) | more than 11 years ago | (#5608154)

There's terrarists right here on /.!!!!
10) Re:fhnlsfdlkm&5nlkd%Bvbcvbc
by Anonymous Coward

0eefa Uv, V'z jbaqrevat vs lbh guvax gurer'f n shgher sbe EBG13. V'ir urneq vg'f cerggl frpher...

Lbh pna ernq guvf? Qnza!

Paul:

Holy cow! Juvyr lbh znl unir svtherq bhg zl fhcre-frperg EBG13 pvcure, abobql jvyy rire penpx *guvf* zrffntr orpnhfr V fjvgpurq gb bhe hygen-frperg cyna O: nccylvat n Pnrfre pvcure 13 gvzrf :-).


These guys speak EBG13 crypto! Right in the open!!!! T3rr4r! ph34r!!

Anyone have a de-coder ring?

Soko

Decoder ring (1)

ergo98 (9391) | more than 11 years ago | (#5608235)

Sheeeit (-1)

Anonymous Coward | more than 11 years ago | (#5608256)

I feel almost embarrassed now. You see all of the 1337 have a rot13 utility already (or they convert in their mind), so I intended to post that anonymously but checked the wrong bloody box. Geez.

Re:Call Ashcroft! (1)

CyberBill (526285) | more than 11 years ago | (#5608428)

Anonymous Coward:

Hi, I'm wondering if you think there's a future for ROT13. I've heard it's pretty secure...


Paul:

While you may have figured out my super-secret ROT13 cipher, nobody will ever crack *this* message because I switched to our ultra-secret plan B: applying a Caeser cipher 13 times :-).


http://www.rot13.com/index.php [rot13.com]

obvious question not asked (-1)

neal n bob (531011) | more than 11 years ago | (#5608157)

what does slashdot suck so much ass?

SPOILER ALERT: ROT13 DECODED (1)

gnuadam (612852) | more than 11 years ago | (#5608182)

Here's the ROT13 message decoded:

An empty password will pass this check because the code uses the length of the user entry, not the length of the correct password. Other potential problems (buffer overflows, etc.) are left as an exercise for the reader. [Shameless plug: If you enjoy problems like this, have strong security experience, communicate well, and want a job at a fun (and profitable) company, visit http://www.cryptography.com/company/careers.html.]

This was courtesy of ROT13 JavaScript coder/decoder [geht.net]

Re:SPOILER ALERT: ROT13 DECODED (1)

MagikSlinger (259969) | more than 11 years ago | (#5608479)

This was courtesy of ROT13 JavaScript coder/decoder [geht.net]

Pfft! Real USENET old timers can read ROT13 without a fancy, shmancy Javascript applet. Or if we need to turn it into normal, we know the vi/ex command sequence that will do it.

For the lazy, we cut and past it into Vim and type g?G and use Vim's ROT13 function.

Re:SPOILER ALERT: ROT13 DECODED (1)

flandar (639569) | more than 11 years ago | (#5608669)

I'm sorry, but isn't true ROT13 only defined for the 26 characters (A-Z). I don't know how to ROT13 a paren. This looks like a binary shift.

ROT13? (2, Funny)

phraktyl (92649) | more than 11 years ago | (#5608188)

I'm never going to figure this out---damn those encryption experts!

Re:ROT13? (1)

cmburns69 (169686) | more than 11 years ago | (#5608440)

You can find a good ROT13 decoder here:

This link [degraeve.com]

An online Starcraft RPG? Only at [netnexus.com]
In soviet russia, all your us are belong to base!

To do rot13 from the command line (1)

mrflip (11712) | more than 11 years ago | (#5608198)

If you don't have a rot13 program, you can just do
echo "Grkg" | tr '[n-za-mN-ZA-M]' '[a-zA-Z]'

so, for instance, you would decode his hint above with the command

echo "Na rzcgl cnffjbeq jvyy cnff guvf purpx orpnhfr gur pbqr hfrf gur yratgu
bs gur hfre ragel, abg gur yratg u bs gur pbeerpg cnffjbeq. Bgure cbgragvny
ceboyrzf (ohssre biresybjf, rgp.) ner yrsg nf na rkrepvfr sbe gur ernqre.
[Funzryrff cyht: Vs lbh rawbl ceboyrzf yvxr guvf, unir fgebat frphevgl
rkcrevrapr, pbzzhavp ngr jryy, naq jnag n wbo ng n sha (naq cebsvgnoyr)
pbzcnal, ivfvg uggc://jjj.pelcgbtencul.pbz/pbzcnal/pnerref.ugzy." |
tr '[n-za-mN-ZA-M]' '[a-zA-Z]'

Of course, you can also go to http://www.rot13.com/ [rot13.com] and enter your text thar.

Re:To do rot13 from the command line (1)

91degrees (207121) | more than 11 years ago | (#5608257)

I hate to say this, but it's become obligatory.

I arrest you under the DMCA for trafficing in tools designed to circumvent a protection mechanism.

That's not it at all (1)

JUSTONEMORELATTE (584508) | more than 11 years ago | (#5608422)

echo "Grkg" | tr '[n-za-mN-ZA-M]' '[a-zA-Z]'
Hogwash. It should be
echo "Grkg" | tr [A-Za-z] [N-ZA-Mn-za-m]
--

Re:To do rot13 from the command line (1)

Evangelion (2145) | more than 11 years ago | (#5608474)

If you're using Mozilla (or, for some reason, NS7), you can go to here [squarefree.com] and bookmark the "ROT 13 selection" bookmarklet.

Re:To do rot13 from the command line (1)

Rudy Rodarte (597418) | more than 11 years ago | (#5608872)

C:\>echo "Na rzcgl cnffjbeq jvyy cnff guvf purpx orpnhfr gur pbqr hfrf gur yratg ubs gur hfre ragel, abg gur yratg u bs gur pbeerpg cnffjbeq. Bgure cbgragvnycebo yrzf (ohssre biresybjf, rgp.) ner yrsg nf na rkrepvfr sbe gur ernqre.[Funzryrff cyht: Vs lbh rawbl ceboyrzf yvxr guvf, unir fgebat frphevglrkcrevrapr, pbzzhavp ngr jryy, naq jnag n wbo ng n sha (naq cebsvgnoyr)pbzcnal, ivfvg Hggc://jjj.pelc gbtencul.pbz/pbzcnal/pnerref.ugzy." | tr '[n-za-mN-ZA-M]' '[a-zA-Z]'

'tr' is not recognized as an internal or external command, operable program or batch file.

Darnit!!

Which cryptography books to read (2, Informative)

c64cryptoboy (310001) | more than 11 years ago | (#5608212)

Reading books/articles doesn't seem to be enough, but if that's the best place to begin, any recommendations?



It may not be enough, but I perfer to believe that cryptography study should begin with books.

Here are 81 cryptography books I've reviewed [youdzone.com] .

With most I've included an associated set of prerequisite book reading, math, and computer language skills necessary to understand the book. Hopefully this will help the beginner hit the ground running, and the more experienced should discover a few hard-to-find books to start tracking down for their personal collections.

Editor: screwed up formatting (0)

Anonymous Coward | more than 11 years ago | (#5608225)

About 2/3 of the way down, someone forgot to close an tag, and the rest of the article is in all italics. I just wanted to give a heads up to whoever didn't bother to read the article before posting.

haha... (0)

}InFuZeD{ (52430) | more than 11 years ago | (#5608239)

"definitely one of the most fun interviews I've ever done." ... He obviously doesn't get out much.

Are We Ready? (-1)

Anonymous Coward | more than 11 years ago | (#5608248)

Speaking of security...

"Presidential candidate Howard Dean gave a talk at Harvard last night. He asked an interesting question. Next year, how will we feel when China invades Taiwan because they think they have weapons of mass destruction? Has the new Bush Doctrine, pre-emptive wars, unleashed a philosophy of world power that we may not be so comfortable with?" (reference [userland.com] )

Aggghhhhh! (1)

Boss, Pointy Haired (537010) | more than 11 years ago | (#5608263)

As for the worst security, I nominate the following password checking code [snipped]

I really hate it when head stuck so far up their own arses their head sticks out of their head security types assume most programmers are stupid.

Most programmers AREN'T that stupid, and you will never come across this code in the wild.

Just like the SQL injection attacks that security types get off on. Doesn't happen.

Re:Aggghhhhh! (0)

Anonymous Coward | more than 11 years ago | (#5608376)

You're right all those "buffer overflow" crap could never really happen either - I mean I have a whole office full of expert Visual Basic programmers and not one of them could do it! No one except some pansy left-wing liberal at some egghead institution does that "assembling" code stuff anymore.

Re:Aggghhhhh! (3, Informative)

evilpenguin (18720) | more than 11 years ago | (#5608450)

I assume you must be trolling, but I'll feed ya. I've been programming in C and C++ for 16 years and I have seen code this bad in production systems every single year of my career.

There are many more bad programmers than good programmers, and even good programmers occasionally make stupid mistakes. One of the biggest problems are the large software consulting businesses. They staff up large development projects at large companies by bringing in a handful of well seasoned architects and lead programmers and then a legion of fresh, inexperienced, and relatively cheap novice programmers. They spend 6-12 months spewing out massive amounts of code of highly variable quality and then leave, allowing staff programmers and consultants from smaller firms to clean up the mess.

Memory leaks, unbounded stack accesses, and outright logic flaws abound in code you are using today. I guarantee it.

You *will* come across that code in the wild. The only way you won't is if you don't look.

Re:Aggghhhhh! (1)

sporty (27564) | more than 11 years ago | (#5608460)

What's that about monkeys, typewriters and shakespear?

Btw, I have encountered such stuff before. So apparently the non-most-programmers are that stupid.

Re:Aggghhhhh! (2, Informative)

Outland Traveller (12138) | more than 11 years ago | (#5608461)

Heh, by your Nick I'll assume this a troll, but programmers are lazy above all things. They tend to consider a problem "solved" once it minimally works, and do not like to polish it off with things like error handling, documentation, security hardening, etc.

There's plenty of very talented programmers here who I constantly butt heads with because they do not want to update their apps which use rsh, rlogin, rwho, .rhosts files, and unauthenicated X sessions across the network, despite the fact that the risks are obvious and the solutions are relatively easy.

Re:Aggghhhhh! (1)

xanadu-xtroot.com (450073) | more than 11 years ago | (#5608528)

From Webster's Revised Unabridged Dictionary (1913) :

Example \Ex*am"ple\, n. [A later form for ensample, fr. L. exemplum, orig., what is taken out of a larger quantity, as a sample, from eximere to take out. See Exempt, and cf. Ensample, Sample.]

1. One or a portion taken to show the character or quality of the whole; a sample; a specimen.

Re:Aggghhhhh! (2, Insightful)

mOdQuArK! (87332) | more than 11 years ago | (#5608584)

Sorry, I've seen code like this on a pretty regular basis (not necessarily password checking, but this kind of defective logic).

Even a decent programmer might can flake out occasionally (thinking of variable name while typing in another for instance), and the dangerous thing about this kind of code is that the compiler won't catch it, and unless code reviewers are specifically keeping an eye out for this kind of thing, they'll probably overlook it as well (since it looks kind of right).

_You_ might be perfect, and never make a mistake, but by definition a typical" programmer is "average", and is quite likely to occasionally make mistakes like this one.

supporting evidence :) (1)

Bill Currie (487) | more than 11 years ago | (#5608690)

This particular not-so-typical (I'm no god, but I'm a fairly decent programmer (I'm generally better at debugging)) saw this code, freaked out, and went to check some password checking code I've worked on. It is as abysmally simple (passwords in the clear, non-trivial to fix that), but it doesn't have the gaping holes the sample code has. Why did I check? Because I have made mistakes like that in the past. I likely will in the future.

Everybody has brainfarts, no matter how good they are.

Re:Aggghhhhh! SQL Injection is real (2, Informative)

jpa5n (99653) | more than 11 years ago | (#5608840)

SQL injection *does* happen. I've seen it and plenty of web developers are not very SQL-savvy.

Try these two phpnuke sql injection vulnerabilities (1 [securityfocus.com] ,2 [securityfocus.com] ) for example from this week's securityfocus.com vulnerability list. Those are just a couple from the open source world.

In early 2000, my dotcom would allow points to be redeemed for Flooz (remember them?) which could then be used at among other place, Tower Records. Throw a single quote in the search page, it dumped SQL statements including tables, columns, and database names. Turns out the search function was vulnerable to TRUNCATE TABLE -- not that I ran it mind you :)

That doesn't even count the fact that the folks who handled the conversion of points to Flooz through their Java application forgot to check if you had the point you were converting in your account -- I converted 100,000 points ($1000) into real cash (well, real Flooz) from an account with 10 points in it.

No no, you're right. None of these problems are out there in the real world. Sure they aren't.

Re:Aggghhhhh! (0)

Anonymous Coward | more than 11 years ago | (#5609045)

Keep trollin', trollin', trollin',
Though the boards are swollen,
Keep them geeks a'trollin', slashdot.

ROT13 Translation (1)

zaphod.nu (100500) | more than 11 years ago | (#5608271)

An empty password will pass this check because the code uses the length of the user entry, not the length of the correct password. Other potential problems (buffer overflows, etc.) are left as an exercise for the reader. [Shameless plug: If you enjoy problems like this, have strong security experience, communicate well, and want a job at a fun (and profitable) company, visit http://www.cryptography.com/company/careers.html.]

10) Re:fhnlsfdlkm&5nlkd%Bvbcvbc
by Anonymous Coward

0rrsn Hi, I'm wondering if you think there's a future for ROT13. I've heard it's pretty secure...

You can read this? Damn!

Paul:

Holy cow! While you may have figured out my super-secret ROT13 cipher, nobody will ever crack *this* message because I switched to our ultra-secret plan B: applying a Caeser cipher 13 times :-).

Re:ROT13 Translation (1)

Sheetrock (152993) | more than 11 years ago | (#5608415)

Didn't Windows 95 networking have a flaw along these lines? It sounds pretty familiar, and I remember thinking at the time that it was astonishing that such a bug wasn't noticed until years after it was introduced...

Anyone? (1)

Apreche (239272) | more than 11 years ago | (#5608283)

Anyone care to decrypt the last question for us lazy folk?

For the rot13 challenged (4, Informative)

Froze (398171) | more than 11 years ago | (#5608295)

http://www.rot13.com/index.php

Re:For the rot13 challenged (1)

Froze (398171) | more than 11 years ago | (#5608323)

DAMN!!!
I need to learn to reload after reading the article, I just assumed that I was being helpful, not supercalifragilistically redundant!

Re:For the rot13 challenged and vim equipped (1)

enkidu (13673) | more than 11 years ago | (#5608886)

Vim will rot13 for you with g?{Motion} or {Visual}g?.

In perl/shell (1)

jjohn (2991) | more than 11 years ago | (#5609027)

$ cat <<EOT | perl -lpe 'tr/A-Za-z/N-ZA-Mn-za-m/;'

# Cut'n'paste away.

Security Flaws (1)

jetkust (596906) | more than 11 years ago | (#5608337)

A smart, creative, experienced, determined attacker can find flaws in just about any standard commercial product.

And if your determined enough, you probably don't even need the other 3 qualities.

Re:Security Flaws (1)

Mr_Dyqik (156524) | more than 11 years ago | (#5608494)

And if your determined enough, you probably don't even need the other 3 qualities.



Or even if your rich enough

Re:Security Flaws (0)

ThatMadeNoSense (651445) | more than 11 years ago | (#5608912)

Or even if your rich enough

That made no sense.

Re:Security Flaws (0)

ThatMadeNoSense (651445) | more than 11 years ago | (#5608895)

And if your determined enough

That made no sense.

THIS ARTICLE IS A DIE-IN!!! (0)

Anonymous Coward | more than 11 years ago | (#5608346)

EVERYBODY who doesn't support bush's imperialistaic policies and bloodlust for oil POST HERE and we'll clog the article!!!!

WE WILL BE HEARED!

Re:THIS ARTICLE IS A DIE-IN!!! (0)

Anonymous Coward | more than 11 years ago | (#5608745)

It's heard dumbass.

MOD PARENT DOWN! (1)

Phreakiture (547094) | more than 11 years ago | (#5608838)

I approve of the message, but not the tactic.

serious question here (0)

Anonymous Coward | more than 11 years ago | (#5608363)

hi, my cock is huge, and I want to blather on about crytography issues that I don't really understand because I will sound 'l33t' to my friends.

what are some of the key buzzwords that i need to employ in conversation so that my friends will know and understand that my cock is huge, without me actually having to say, 'hey, my cock is huge'?

btw, it is really huge, but i can't show anybody, that would be illegal.

ubj avpr! (1)

benson hedges (595198) | more than 11 years ago | (#5608364)

naq urer V jnf, guvaxvat gung abobql rira erzrzorerq ebg13, lrg nybar hfrq vg nalzber. nu, gur tbbq byq qnlf bs pelcgbtencul. naq abj, cenvfr gur yynzn! :) irel vagrerfgvat negvpyr. V jnf whfg jbaqrevat : vf gurer fhpu guvat nf n zbber'f ynj sbe vaabingvbaf? 50 lrnef gb tb sbe n jbexvat dhnaghz pbzchgre frrzf n ovg ybat gb zr.

Re:ubj avpr! (1)

Lumpy (12016) | more than 11 years ago | (#5608659)

naq urer V jnf, guvaxvat gung abobql rira erzrzorerq ebg13, lrg nybar hfrq vg nalzber. nu, gur tbbq byq qnlf bs pelcgbtencul. naq abj, cenvfr gur yynzn! :) irel vagrerfgvat negvpyr. V jnf whfg jbaqrevat : vf gurer fhpu guvat nf n zbber\\\'f ynj sbe vaabingvbaf? 50 lrnef gb tb sbe n jbexvat dhnaghz pbzchgre frrzf n ovg ybat gb zr.


Ab lbh whfg ner bar bs gur Hore Y33g gung fgvyy erzrzoref vg naq vg\'f hfrshyarff. Gbqnl crbcyr inyhr ehqrarff naq orvat n cynva byq choyvp nffubyr guna ebg-13 nalguvat gung znl bssraq bguref.

Zr? V whfg hfr pbzzba frafr.

For extra security... (1)

Boss, Pointy Haired (537010) | more than 11 years ago | (#5608378)

I always ROT13 my secret messages twice.

Question #7 intrigues me. (1)

Sheetrock (152993) | more than 11 years ago | (#5608389)

Can the fellow who asked it please clarify what is meant by 'trust' in a Gnutella environment -- what features are being thought about?

Re:Question #7 intrigues me. (1)

AndrewRUK (543993) | more than 11 years ago | (#5608655)

I imagine it's "is the file person X is sending me the file they claim it is?" style trust.

Re:Question #7 intrigues me. (1)

UltraOne (79272) | more than 11 years ago | (#5608930)

Here is a (non-exhaustive) list of possibilities:
1. Cuckoo's egg attacks where file is not what its name (or other metadata) claims it to be.
2. Denial of service (DOS) attacks where a node tries to overwhelm the P2P system by sending a ridiculous number of queries. This is especially a problem with Gnutella since the initial search protocol is so inefficient.
3. Corrupting or not passing data - Many P2P architectures call for nodes to relay or aggregate information from other nodes. If a node drops or corrupts data, the prototcol won't work or will be much less efficient.

Thanks, interesting answers (1)

plcurechax (247883) | more than 11 years ago | (#5608401)

I was most interested in your answers to "How do you think?" and "Is the Technology ahead of us?" Unfortunately I think there was some formatting problems with both of these questions, that altered your answers.

E.g. (for "How do you think?")

states can each participant be in?

e is the most complexity in the security perimeter? (Complex parts are the most likely to fail.)
and (for "Is the Technology ahead of us")

dation is much more difficult than writing new code (and it's less fun), so many people avoid it.

Anyway, thanks for the interesting answers.

Since Paul couldn't tell us ... (1)

burgburgburg (574866) | more than 11 years ago | (#5608466)

Can we get some names of "companies that make misleading or unsupported claims about their security" that people keep buying (other than Microsoft, which is too obvious to list)?

copying (0)

Anonymous Coward | more than 11 years ago | (#5608490)

Note: While I presume that the question relates to legitimate P2P applications, piracy over P2P systems is driving copyright owners to seek legislative and legal relief. The fact that the Internet can be used to massively violate intellectual property rights doesn't make it moral to do so.

Uh oh, sounds like he thinks there will actually come a day when people don't copy stuff over the Internet, just because it's "wrong mmkay".

He's got it backwards: Because technology today can be used to make copies easily, copyright infringment will occur on a massive scale, no matter what. Technology today is exposing the fundamental flaws of copyright, which have always been there under the surface (when I was in HS, I owned one CD for every five copies I had, but the **AA couldn't track it as easily as they can P2P).

The only solution is to immediately and loudly proclaim that copying is okay and that we have to tailor our laws to that reality. Leave the statements of "morality" to RMS and the like.

Terng, gunaxf n ybg crbcyr... (1)

Jargon Scott (258797) | more than 11 years ago | (#5608566)

uggc://jjj.pelcgbtencul.pbz is /.ed

quantum cryptography (1)

xpl_the_myst (612106) | more than 11 years ago | (#5608578)

What he says about quantum computing sounds reasonable. Though there exists a known algorithm to factorise primes in polynomial time, which would certainly make almost all cryptographic systems obsolete (of course there are others which will still work but ...), there's almost no decent working quantum computer that can approach the number of bits that a practical application of this sort will involve.

However, the stuff about quantum cryptography is too pessimistic, imho. Quite recently scientists have achieved quantum entanglement over decently usable distances - this (http://www.scienceagogo.com/news/20030126213558da ta_trunc_sys.shtml ) is a link for starters). And because quantum entanglement allows u to transfer bits across in total secrecy (at least u definitely know if somebody eavesdrops), quantum cryptography involving just a few bits is also important.

Anyway, it's one hot field for theoretical research right now, so that probably implies that practical applications are years away. ;-)

sorry for the plain text.

the REAL reason most webpages are not encrypted (2, Insightful)

realdpk (116490) | more than 11 years ago | (#5608602)

The Microsoft/Netscape/Mozilla/Verisgn "conspiracy"(for lack of a better term) made the cost barrier far, far too high by requiring that certificates be issued only by "trusted" authorities for encrypted web pages. (And requiring that if the website owner doesn't fork out the cash, the user gets prompted with an ugly/annoying dialog suggesting that something may be wrong, causing confusion.)

It's unfortunate that MS/NS (and now Mozilla) went along with this. A better system would allow for unauthenticated SSL (with no CA warning), for sites you just don't care so much about, like /. :-), and then authenticated SSL for banks, porn, etc important things.

Re:the REAL reason most webpages are not encrypted (1)

SquadBoy (167263) | more than 11 years ago | (#5608866)

Except then you train people to do the wrong thing. In other words ignore the fact that a given cert means nothing and then they start ignoring it everywhere and then man-in-the-middle attacks become trivial. How does the browser know what you care about and don't. Cause I gurantee that the user does not know what they care about and why.

Re:the REAL reason most webpages are not encrypted (3, Insightful)

Beryllium Sphere(tm) (193358) | more than 11 years ago | (#5608950)

What good would it do anyway?

How many people, besides security consultants and compulsive look-under-the-hood types, ever look at the certificate validation chain? When's the last time you checked your browser settings to be sure that malware hadn't added a new trusted root cert? Have you ever read a certification practice statement to be sure it provides the level of verification you think is appropriate?

For that matter, how many people check certificate revocation lists? That check is turned *off* by default in one widely used web browser.

Something is going unsaid. (1)

Futurepower(R) (558542) | more than 11 years ago | (#5608652)


I very much liked reading the interview.

I noticed that something is going unsaid, though. Breaking a cipher through cryptographic analysis only works if the attacker knows or can guess the algorithm. If data is encrypted and then encrypted again with another algorithm, and in between the bytes are scrambled, no mathematical attack can ever be successful.

This method of encryption does not allow public-key encryption, of course, but it is 100% secure if only the sender and receiver know the encryption and byte-scrambling algorithms.

Re:Something is going unsaid. (1)

samhalliday (653858) | more than 11 years ago | (#5608713)

i thought it was also unbreakable without the start and end encryption you mention, but just filtered through random data which both parties know (a one-time key), but nobody else knows.

this is how the american and russian presidents used to communicate by telephone, they may still do?

if only the 2 copies of the key exist, it is truly unbreakable, as there is no bounds checking on a cracked key, you can recover anything you like. i may be wrong, but i cant see any way to break this kind of system; which is not in regular use since it is inconvenient and requires safe travel of the one-time key to the recipient.

Re:Something is going unsaid. (2, Insightful)

Beryllium Sphere(tm) (193358) | more than 11 years ago | (#5609031)

The reason the conventional wisdom tells you not to rely on secret algorithms is that the algorithm is a widely distributed piece of information (every sender and receiver uses the same one) and it's permanent.

For example, the Enigma machines were supposed to be secret, but over the course of an entire war it was probably inevitable that one got captured. Then it was a key recovery problem.

BTW, a typical modern block cipher works a lot like what you suggested, often with 16 or 32 rounds of scrambling, each round doing a different operation from the others controlled by the current key. They're still susceptible to mathematical attacks.

Standard implementations (1)

Coz (178857) | more than 11 years ago | (#5608724)

Yippee! Yahoo! He picked my question and answered it! (does happy joy dance)

Now that that's over with... I think his answer makes projects like OpenSSL [openssl.org] more important. We can all look over the implementations, they're thrashed by the community at large, and they've proven to be quite responsive when someone does find a vulnerability.

Now, off to my next assignment - writing an access rights repository using the M$ Foundation Classes Crypto API. *sigh*

Worst code? (1)

ERJ (600451) | more than 11 years ago | (#5608862)

As for the worst security, I nominate the following password checking code:

gets(userEntry);
if (memcmp(userEntry, correctPassword,
strlen(userEntry)) != 0)
return (BAD_PASSWORD);


Oh oh.....*runs off to check code*

VA FBIVRG EHFFVN... (1)

Rudy Rodarte (597418) | more than 11 years ago | (#5608915)

uggc://jjj.tbngfr.pk IVFVGF LBH!!! hehehe.

I'm so ashamed... (3, Funny)

Tomster (5075) | more than 11 years ago | (#5608927)

"As for the worst security, I nominate the following password checking code:

gets(userEntry);
if (memcmp(userEntry, correctPassword,
strlen(userEntry)) != 0)
return (BAD_PASSWORD);
"

I just want everyone to know I wrote that code years ago and would never do something like that again. Really!!

-Thomas
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>