Security Expert Paul Kocher Answers, In Detail

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 :-).

Comments

Protected material

[jemnery]

"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

Re:Protected material

[rbook]

You can get money on Kazaa?!?!?!?

Re:Protected material

[jemnery]

Nah, but have your ever tried searching for a few common filenames on a P2P network?

"credit card.txt"; "visa.txt" etc....

--
jc

Forget ROT13

[Anonymous Coward]

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

For the security-lingo disadvantaged...

[TopShelf]

Anybody care to play ROT13 translator???

Re:For the security-lingo disadvantaged...

[Anonymous Coward]

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...

[dylan_-]

Anybody care to play ROT13 translator???

Try this site.

Re:For the security-lingo disadvantaged...

[Carbonite]

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...

[nachoboy]

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 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...

[Carbonite]

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 :-).

Re:For the security-lingo disadvantaged...

[plcurechax]

For Linux/Unix/BSD users:

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

Re:For the security-lingo disadvantaged...

[ddmckay]

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

Re:For the security-lingo disadvantaged...

[wangi]

Perl script for you:

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

Re:For the security-lingo disadvantaged...

[pldms]

In emacs you might enjoy the raw power of:

M-x rot13-other-window :-)

Re:For the security-lingo disadvantaged...

[Enrico Pulatzo]

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

Re:For the security-lingo disadvantaged...

[rleibman]

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

Re:For the security-lingo disadvantaged...

[SecGreen]

http://www.geocities.com/killereaglesoftware/archi ve/rot13.htm

Re:For the security-lingo disadvantaged...

[osgeek]

Rot13.com, dude.

Re:For the security-lingo disadvantaged...

[Thud457]

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...

[ojplg]

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

Re:For the security-lingo disadvantaged...

[Hard_Code]

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

Re:For the security-lingo disadvantaged...

[Loopsnut]

http://www.rot13.com

Re:For the security-lingo disadvantaged...

[gmack]

I would laugh but I found a small variation on that code in a project I was working on.

It was only a tad more secure because it used strcmp and the original coder added a NULL check to prevent it from crashing on an empty password

Unfortunatly you still only needed to get the first letter right.

strcmp unfortunatly seems to be the logical eqivelant of strncmp(string1,string2, strlen(string1)) And many coders think at first glance that it will not return a match if the strings aren't the same length.

I've since started wrapping it in a function that compares the lengths first for any projects I work on.

Re:For the security-lingo disadvantaged...

[titaniam]

I sure hope that all of you nasty hackers are fined and jailed! This interview is copyrighted material, and by decrypting certain portions of the interview you may be commiting an illegal act under the DMCA. Have a nice day :)

Re:For the security-lingo disadvantaged...

[ejasons]

strcmp unfortunatly seems to be the logical eqivelant of strncmp(string1,string2, strlen(string1)) And many coders think at first glance that it will not return a match if the strings aren't the same length.

This is simply not true. Not that a counterexample disproves your statement (but this, combined with the manual page pretty much does), but this program:

#include <stdio.h>
#include <string.h>

int main(int argc, const char *argv[])
{
printf("Compare is %d\n", strcmp("a", "ab"));
return 0;
}

Produces the output:

Compare is -1

which is correct. Remember that "strcmp" produces a trinary output!

Re:For the security-lingo disadvantaged...

[Old Wolf]

Ternary output :)

Re:For the security-lingo disadvantaged...

[gmack]

On my system compare is -98..

Now I'm curious. The original password check code was if(!strcmp(str1,str2)) successpath()

And I know I watched it fail.

Re:For the security-lingo disadvantaged...

[iabervon]

I understood most of question 10, but what the heck is "Ubyl pbj!" supposed to mean? It sounds like he was interrupted in the middle of lunch or something.

Re:For the security-lingo disadvantaged...

[mistered]

Yep, the return value is either <0, 0, or >0. There's no requirement on what actual values have to be returned for the <0 or >0 cases.

Re:For the security-lingo disadvantaged...

[The Viking]

$ echo "" | /usr/games/caesar 13

Re:For the security-lingo disadvantaged...

[Ed Avis]

Er no, strcmp() will compare two strings lexicographically, whether or not they are the same length. For example

int main(void)
{
const char *a = "hello";
const char *b = "hello there";
printf("%d\n", strcmp(a, b));
}

This prints -1 as you'd expect (a comes before b). Change both strings to "hello" and it prints 0.

Re:For the security-lingo disadvantaged...

[Anonymous Coward]

It was already plaintext in the original.
"Holy cow!"

Re:For the security-lingo disadvantaged...

[Ciaran_H]

Um, that bit isn't encoded. It reads "Holy cow!".

Re:For the security-lingo disadvantaged...

[iabervon]

Dang, this guy is tricky. I have to not only be able to read ROT-13, I have to be able to read plain text?

Re:For the security-lingo disadvantaged...

[Anonymous Coward]

> (Score:1, Troll)

Moderators on crack, AGAIN. How is this possibly a troll?!?!

NDA Questions

[Blaine Hilton]

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.

Re:NDA Questions

[Anonymous Coward]

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.

Re:NDA Questions

[Hanashi]

Don't assume that he should go directly to the police. After all, in most cases it's not a crime to be insecure. True, you might be opening yourself up for a civil suit later, probably for failing to exercise due diligence, but that doesn't imply an obligation for a consultant to report anything to anyone.

Re:NDA Questions

[Paradise Pete]

If he goes to the police surly this goes beyond the NDA.

Scene: Blaine Hilton, ace security expert, enters a police station. He approaches a police seargent at the desk.

Hilton: I've been advising this company about their software. I've pointed out where it is vulnerable, but they haven't fixed it.
Seargent: That's not illegal.
Hilton: Oh yeah.

Re:NDA Questions

[Blaine Hilton]

Not fixing itsn't illegal in upon itself. However if the company knows about the flaw(s) and continues to market the product and not inform the public about that flaw then I'm pretty sure they are legally responable. Although it may be only after a civil suit, which comes to the root of the problem. Noone will know until there is a major problem. Then the user will sue the company and the company will sue the security consultant. Who loses? Well at least the security guy it seems like to me.

Re:NDA Questions

[t0ny]

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 their 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 police only handle criminal matters. You don't 'go to the police' (or go to jail, for that matter) for civil violations. There is a difference between being "not legal" and "illegal". Illegal means you are prohibited from doing something. Not Legal means you could be held financially liable for something.

To illustrate, in many states driving a car without insurance is "illegal", and carries the risk of jail time. In any case, it is "not legal" to cause accidental property damage.

Anyway, to the point, he was hired to give security advice. What they do with that advice is their responsibility. However, they ARE negligent once they are made aware of the problem; like the tobacco companies suppressing their studies. The difference in the two cases are whether that knowledge will cause actual harm (to lungs and health, to property or data, etc), or meerly increase risk of SOMEONE ELSE doing that harm (like unsecure code). Its like leaving a door unlocked- you didnt steal their stereo, but if you are paid to watch the door you could be held liable.

Re:NDA Questions

[Blaine Hilton]

Thanks for the clarifciation!

Re:NDA Questions

[Paradise Pete]

So you still think he should tell the police?

Re:NDA Questions

[Blaine Hilton]

No, I never did really, I understand its not a criminal matter, but consultants should do something to protect themselves in these types of situations.

Re:NDA Questions

[Paradise Pete]

No, I never did really

I don't believe you.

SPOILER ALERT: ROT13 DECODED

[gnuadam]

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

Re:SPOILER ALERT: ROT13 DECODED

[MagikSlinger]

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

[flandar]

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.

Re:SPOILER ALERT: ROT13 DECODED

[Anonymous Coward]

Thanks for the spoiler alert, so we wouldn't miss out on the pleasure of ROT13-ing it ourselves. I'm being sarcastic.

Re:SPOILER ALERT: ROT13 DECODED

[JebusIsLord]

I am so reporting you under the DMCA.

Re:SPOILER ALERT: ROT13 DECODED

[jolshefsky]

Man, mod this one up. I know that Froze (and followers) think it's awsome fun to waste time hunting down a ROT-13 translator, pasting something in, and getting the results. Maybe they're too dumb to cut and paste the results which would be _actually useful_ .

Thanks, gnuadam.

Re:SPOILER ALERT: ROT13 DECODED

[Anonymous Coward]

Is there a "-INF lame" moderation tag? There should be one. I mean, please! It's rot13. It doesn't get any more complicated than this:

$ tr A-Za-z N-ZA-Mn-za-m

honest. You need javascript for the one liner? Really?

Now I remember why I stopped loggin in.

Switching karma bonus off and posting anonymously to avoid karma whoring.

ROT13?

[phraktyl]

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

Re:ROT13?

[cmburns69]

You can find a good ROT13 decoder here:

This link

An online Starcraft RPG? Only at
In soviet russia, all your us are belong to base!

To do rot13 from the command line

[mrflip]

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/ and enter your text thar.

Re:To do rot13 from the command line

[91degrees]

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.

Re:To do rot13 from the command line

[Evangelion]

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

Re:To do rot13 from the command line

[Rudy Rodarte]

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!!

Re:To do rot13 from the command line

[mrflip]

Got Cygwin?

bash, {bin,file,sh,text}utils, gcc et al., X windows -- all for free from redhat and your friendly neighborhood free software hackers. Most any X or command line utility will respond to the standard "./compile; make" dance.

Just because you use Windows doesn't mean you don't deserve a real commandline...

Which cryptography books to read

[c64cryptoboy]

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.

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.

Re:Which cryptography books to read

[ordinarius]

Probability and Statistics appears, um, almost all the time in your reviews as a prereq. I'm about to take some classes in this area but the field seems to be divided into mathematical vs. applied (a two course series appears for both). Which is more applicable towards cryptography?

Thanks.

- ordinarius

Re:Which cryptography books to read

[c64cryptoboy]

I don't know, but I'll give it a shot: If your emphasis is on pure crypto (cryptanalysis, algorithm design, etc.) I'd definitely go with the more mathematical route. But if you're a software engineer, and want to find secure ways of using existing cryptography in your systems and protocols, I'd go with the applied statistics. The later is easier, pays better, and doesn't require post-graduate work.

Editor: screwed up formatting

[Anonymous Coward]

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.

Decoder ring

[ergo98]

http://www.alliancestudio.com/tk/rot13.html

haha...

[}InFuZeD{]

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

Aggghhhhh!

[Boss, Pointy Haired]

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!

[Anonymous Coward]

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!

[evilpenguin]

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!

[sporty]

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!

[Outland Traveller]

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!

[xanadu-xtroot.com]

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!

[mOdQuArK!]

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.

Re:Aggghhhhh!

[Anonymous Coward]

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

Re:Aggghhhhh!

[cant_get_a_good_nick]

I think he couched this well. Programmers just don't think in terms of security, and tend to make the same mistakes over and over.

I remember a story of some programmer that was going to a crypto class. He thought of a cool encryption algorithm, essentially:

char c, encrypted_c;
encrypted_c = (c + rand(SOMETHING) ) % SOMETHING;


His first homework assignment? Was to break that encryption. Programmers just don't think that way sometimes.

Re:Aggghhhhh!

[gmack]

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

Boy are you wrong. Heres a small improvement on the afformentioned code I found in the wild(comments are mine).

if(password==NULL) /*strcmp cores if you feed it a null arg */
return(-1) ;

if(!strcmp(password,user->password))
return(-1) ;

Re:Aggghhhhh!

[Anonymous Coward]

We have way more then a thousand monkeys with typewriters already and Slashdot is nothing like Shakespeare.

Re:Aggghhhhh!

[Anonymous Coward]

I like pie. My favorite flavor is Boston Cream. What's yours?

(-1, Informative)

Re:Aggghhhhh!

[homebru]

... that the risks are obvious ...

OK. I've tried asking before and never gotten a straight answer. Maybe you can/will provide one. What's wrong with r* and .rhosts?

I grant that they are problems in shops with low-give-a-shit about password sharing and other such social problems. But are the r* commands technically insecure? .rhosts means that they don't send passwords so what's the technical problem?

What am I missing here? Please?

Re:Aggghhhhh!

[Anonymous Coward]

I myself have written: gets(mypasswd); mywrite(rot13(mypasswd),fd1); analcheck(rot13(mypasswd)); A wonderful world awaits us beyond the CRT. Explore, before bush nukes it.

Re:Aggghhhhh!

[DuckDodgers]

At the shop I'm at, the boss has written device drivers, tweaked compilers and filesystems, you name it... He's forgotten more about C than I'm likely to ever learn.

And I still found a loop he wrote that crashed when it tried to compare a string with a NULL string. Nobody's perfect.

Re:Aggghhhhh!

[Old Wolf]

I cannot think of a reason someone would use memcmp(,,strlen()) instead of strcmp() . It's inconceivable that they would have learned about mem functions but not string functions. Can you?

Re:Aggghhhhh!

[Anonymous Coward]

I like pie. My favorite flavor is salmon-tasting in flavor, but shaped like a camel toe. What's yours?

(-1, Not Gayness)

Re:Aggghhhhh!

[Outland Traveller]

I'm really not qualified to give a comprehensive analysis of how the r* programs and .rhosts files are insecure. If you're looking for that check out CERT's web site, or read the entry-level books about computer security. I do know of a few of the major issues, however:

The major problems with the r* applications is that all network traffic between hosts is unencrypted. This makes it trivial for someone on the network to sniff passwords and command text. This is a whoppingly huge vulnerability, because people are inherently lazy and they will eventually do something over an r* command that compromises security to other systems. I know people that use rlogin to get to a machine that supports ssh, which they then use to get into a 3rd system... there's not much point in that. It's like taping a bunch of copied keys next to the lock they goes into. r* applications are the proverbial weakest link that undermines the security of everything attached to them.

Using ethernet switches instead of hubs doesn't fix the problem - There are large numbers of attack vectors for that setup as well. The r* protocols are very vulnerable to spoofing and man-in-the-middle attacks at multiple network layers.

The same applies to .rhosts. Yes, it may be technically true that your "not transmitting the login password over the network", but you've pretty much opened the machine wide for anyone who can spoof an IP connection or manipulate the .rhosts file. Once again, you're creating a weak link that can bring down every system connected to it.

The r* protocols are vulnerable by their very design, not just from the usual buffer overruns and code logic errors (although there are those too).

Even looking at the problem from a practical point of view, the number of reported system compromises due to the use of the r* protocols is so staggering that people now assume that everyone understands not to run these services.

ROT13 Translation

[zaphod.nu]

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

[Sheetrock]

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?

[Apreche]

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

Not; was: Re:laksdjf92e3ih12y

[Anonymous Coward]

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

For the rot13 challenged

[Froze]

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

Re:For the rot13 challenged

[Froze]

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

[loftwyr]

I'm the paranoid type, I encode all my messages (like this one) with Double ROT13.

THat way I can feel secure.

Re:For the rot13 challenged

[DChristensen]

perl -np -e 'y/A-Za-z/N-ZA-Mn-za-m/'

Re:For the rot13 challenged

[Paradise Pete]

I'm the paranoid type, I encode all my messages (like this one) with Double ROT13

I see that you also follow Mr. Kocher's advice on using old, well-reviewed material.

Re:For the rot13 challenged

[bill_mcgonigle]

Great, so the guy intentionally obscures some answers because he doesn't want the total lamers to read it, and a karma whore goes and posts a tool for the lamers to use... or maybe there was some other reason for him to ROT-13 his explanation of the code failure and I'm amazingly dull today.

Re:For the rot13 challenged

[Glorat]

But to answer the question of the last question submitted
"Uv, Vz jbaqrevat vs lbh guvax gurer'f n shgher sbe EBG13. V'ir urneq vg'f cerggl frpher..."

The answer to his question seems obvious to me... read on

Vgf cebonoyl gur zbfg fgenvtugsbejneq jnl bs bofphevat na nafjre
fb gung lbh qba'g nppvqragnyyl ernq gur nafjre orsber lbh unir
gubhtug nobhg gur dhrfgvba. Orfg rknzcyr orvat uvf ercbafr gb
dhrfgvba 2. Naq guvf pbzzrag bs pbhefr!

Re:For the rot13 challenged

[daeley]

Isn't double ROT13 what old-timers used to call ROT26? ;)

Re:For the rot13 challenged

[Elwood P Dowd]

The reason to obscure it was so that he could post the answers, and you could do the problem without knowing the answers ahead of time. Think of it like a "For the answers, flip to page 31337."

Re:For the rot13 challenged

[Kevin DeGraaf]

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

Or, for those on a *nix system:

$ tr 'a-zA-Z' 'n-za-mN-ZA-M' < message

Alternatively, for greater ease of use, add this:

alias rot13="tr 'a-zA-Z' 'n-za-mN-ZA-M'"

into your shell init file (e.g. .bashrc).

The solution

[Nugget]

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

Re:The solution

[MarkGriz]

Of course, Triple ROT13 would be even more secure than standard ROT13, much like Triple DES is more secure than standard DES. Right???

Re:The solution

[MrHanky]

I use 13 rounds of ROT1 (my own secret algorithm which I'm not giving away to the public yet). It has the advantage of being compatible with ROT13, while being 13 times harder to brute-force attack.

It takes a whole loaf of bread just to crack a four letter word on my toaster.

Try www.rot13.com

[burgburgburg]

http://www.rot13.com/index.php gives you the awesoma powa of rot13.

Security Flaws

[jetkust]

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

[Mr_Dyqik]

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

Or even if your rich enough

Re:Security Flaws

[ThatMadeNoSense]

And if your determined enough

That made no sense.

Re:Security Flaws

[ThatMadeNoSense]

Or even if your rich enough

That made no sense.

The essence of the NDA ...

[burgburgburg]

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 ...

[NDPTAL85]

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

Re:The essence of the NDA ...

[cyb97]

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 ...

[Carik]

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

Re:The essence of the NDA ...

[cyb97]

Depends what your software is supposed to protect I guess. If a court could prove that your sloppy coding made the black-hats able to gain access to 2.5M VISA-numbers and you knew about it...

Shit on you!

Re:The essence of the NDA ...

[drudd]

Only when acting in their capacity as a priest. This case hardly qualifies as religious.

Doug

Re:The essence of the NDA ...

[j-beda]

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

Granted, my knowledge comes to me from episodes of "Law & Order", but my undersanding is that these yptes of confidentiality agreements are only applicable when they involve information that comes up while caring out pristly (or doctor or lawyer) duties. Hiring a priest to perform an audit is not going to get you the same level of privledge as if you went to one for absolution and talked about whatever crimes you did.

Re:The essence of the NDA ...

[NDPTAL85]

Never heard of the crime of fraud? Telling your customers your software is one thing when you clearly know its another is fraud.

Re:The essence of the NDA ...

[jcast]

Then the Catholic church should make bad security practices a sin. That way companies can bring code to them as part of confession.

Re:The essence of the NDA ...

[Anonymous Coward]

You have not seen some of the systems I have done security audits on. How many times can you say "Oh my god!" and not be religious?

Re:The essence of the NDA ...

[cyb97]

I, for one, know several people who are religious about their security, both on a real-life and technological level...

;-)

Re:The essence of the NDA ...

[caelyx]

IANAL, but from what I understand of contract law (in common law countries like the US, CA, AU), a contract can't be declared void unless its *intent* was criminal (or a few other things).
So you're bound by the NDA. They can't stop you going to the police, but they can sue your butt off when you do. And you can bet that's not going to be a small lawsuit... :)

THIS ARTICLE IS A DIE-IN!!!

[Anonymous Coward]

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!!!

[Anonymous Coward]

It's heard dumbass.

serious question here

[Anonymous Coward]

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!

[benson hedges]

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!

[Lumpy]

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.

Re:ubj avpr!

[Jerf]

50 lrnef gb tb sbe n jbexvat dhnaghz pbzchgre frrzf n ovg ybat gb zr.

a.k.a

50 years to go for a working quantum computer seems a bit long to me.

Not if they're completely impossible. Personally, I think they are; to get a real quantum computer working requires near complete isolation of the computer from the rest of the universe on a quantum mechanical level, and you need to be able to switch that isolation on and off like a switch (set up the problem, isolate the system to compute, unisolate to get the answer). Error correction can alleviate that requirement a little, but only a little. As the problems get harder (i.e., go from "toy" to even slightly useful), the errors stack up exponentially but the error correction doesn't scale anywhere near that well, and I see no reason to think it ever will.

Obviously I can't say this is totally true. But if I had to lay money, this is where I'd put it. And I'm generally an technology optimist; quantum computing is different in that it requires fairly specific science advances in isolating system that strike me as being quite likely impossible. This is very different from techs like "speech recognition" that "merely" require much better processers and algorithms. (I'd bet on Strong AI before I'd bet on quantum computing.) As I like to say, it will take Nobel Prize-winning physics to make this work, and it's not good to depend on that. (Even warp drives seem more realistic to me, for what it's worth.)

Also, this goes for "strong" quantum computing, where some significant calculation is done entirely in a quantum machine. This has nothing to do with merely harnessing quantum mechanical effects on otherwise conventional chips, the somewhat misnamed "quantum encryption" (really should be called "quantum intrusion detection"), or other weaker uses of QM that may be useful.

For extra security...

[Boss, Pointy Haired]

I always ROT13 my secret messages twice.

Question #7 intrigues me.

[Sheetrock]

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.

[AndrewRUK]

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.

[UltraOne]

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.

Re:Question #7 intrigues me.

[smd4985]

First off, I'm very happy my question was sent to Mr. Kocher. I was hoping for a little more from his answer, but it is a hard problem that lacks easy answers.

Secondly, I want to make it clear that we are not trying to validate content. Gnutella implementations are by nature content-agnostic - we have no prior knowledge of what a node may share or download and we have no way to control these things. Gnutella simply sets up a communications medium - what is said is up to the individual user.

The features we are trying to implement relate to trust between nodes at either end of a connection - how can a node know that it can 'trust' who it is connected to? 'trust' may denote inclusion in a group of vendors (i.e. LimeWire, BearShare, etc.) or some other delineation. This is a problem because nodes cannot certify who is on the other side of a connection UNLESS the network is fully locked out (i.e. only nodes with proof of access to a secret private key). This has lately become a problem because badly coded clients (that issue too many queries, that send spammy results) have been abusing the open nature of Gnutella.

Re:Question #7 intrigues me.

[elmegil]

you can't have trust and complete anonymity.

I thought that this problem was resolved by the "who's paid for dinner" scenario.

Re:Question #7 intrigues me.

[Sheetrock]

I want to make it clear that we are not trying to validate content. Gnutella implementations are by nature content-agnostic - we have no prior knowledge of what a node may share or download and we have no way to control these things. Gnutella simply sets up a communications medium - what is said is up to the individual user.

I'm not a Gnutella user, but I did fire up gtk-gnutella today to check things out and I do have a pretty good idea of what you're talking about. One of the things I noted was a number of machines from the same IP class giving me results for a query -- after looking them up and doing a bit of searching on Google I found out those belonged to an odious company named Overpeer, who according to Wired is actively attempting to corrupt P2P networks (does that count as immoral?) And of course I got all sorts of results that were obviously worms or spam.

But I understand your question now, and agree with your assessment of the situation. For what it's worth coming from someone with unknown credentials, I'd say trust of the sort you're mentioning isn't something you're going to achieve on a free open decentralized network. As with USENET, there is a certain element of chaos that is going to come with the territory.

What can cryptography buy you? Perhaps some form of distributed user ranking system could be designed into the protocol. I have an identity (public/private keypair) generated by my client the first time I run it (hopefully with the abilities to backup that identity and later if I choose to generate a new one). This identity is used with Gnutella transactions. If I'm sharing corrupted files from my incomplete/ directory, anybody who notices this marks my identity as a loser in their client. If somebody has just downloaded successfully one of Richard Stallman's speeches from my system and actually approves of it, they have the option to mark my identity as a good sharer in their client. A web of trust is then formed by Gnutella users choosing identities whom opinions of traders they can respect. These identities can then be slowly queried over the network when a client is started and if a node is up corresponding to an identity, a fresh list of opinions can be retrieved from said node (signed with its identity's secret key for identification, of course). It is important that users can see what the rankings are in the list and to be able to remove identities from their 'trust' list if they disagree with them in the future.

There are of course issues with this concept if it isn't flawed outright, but I hope it's helpful.

Re:Question #7 intrigues me.

[Sheetrock]

Perhaps, although I can't help but wonder how many unbiased coin flips it would take to retrieve a DVD rip of the widescreen version of Clue.

Kind of wierd that I never noticed the connection between the author of the Dining Cryptographers Problem and the creator of the (appropriately named) Chaum mix. I always thought both were a neat idea.

Thanks, interesting answers

[plcurechax]

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.

Re:Thanks, interesting answers

[carlos_benj]

My guesses:

First one could add the word 'What' at the beginning.

Second one I'm guessing is 'Wher' just before the 'e' making the first word 'Where'.

The last one just needs 'vali' prepended to 'dation' to make sense.

I thought it was more likely a hasty cut and paste rather than format problems.

That's not it at all

[JUSTONEMORELATTE]

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:Call Ashcroft!

[CyberBill]

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

Since Paul couldn't tell us ...

[burgburgburg]

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

[Anonymous Coward]

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...

[JargonScott]

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

quantum cryptography

[xpl_the_myst]

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.

Re:quantum cryptography

[Anonymous Coward]

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 ...)

I'm having difficulty working out whether this statement is more daft than it is redundant. Thoughts?

Re:quantum cryptography

[Bert690]

Though there exists a known algorithm to factorise primes in polynomial time, which would certainly make almost all cryptographic systems obsolete..

Huh? There is a polynomial time algorithm for determining primality (if that's what you mean by "factorise primes"). But this can only *help* cryptographic algorithm relying on hardness of factoring. It renders nothing obsolete because there is no known poly-time algorithm for factorizing numbers in general.

the REAL reason most webpages are not encrypted

[realdpk]

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

[SquadBoy]

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

[Beryllium Sphere(tm)]

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.

Re:the REAL reason most webpages are not encrypted

[jooniqzb1tch]

it's not that bad with mozilla, I only have to click accept certificate once whereas I always see that security popup again and again in IE, even after having tried to install it in every possible location ..

Re:the REAL reason most webpages are not encrypted

[sjames]

It really has to give some sort of notification since it won't know what sites you consider authentication important for.

However, that notification (in the early days) really need not have required clicking through 3 dialogs that seemed to be worded in the most alarming way possible (and convieniantly didn't mention that only the authentication was in question, not the encryption).

Then, there's the issue of chain of trust. Am I really all that secure because one company I've never heard of (at that time anyway, now I've heard enough to be even less trusting) says another company I just heard about from a search engine really does go by the name they told me? (Worse, all it really means is that sombody was able to come up with a convincing letterhead).

It doesn't help that the blasted things are quite expensive for what little work goes into generating one. To further the problem, some browsers can't handle wildcard certs.

Something is going unsaid.

[Futurepower(R)]

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.

[samhalliday]

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.

[Beryllium Sphere(tm)]

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.

Re:Something is going unsaid.

[plcurechax]

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.

Wrong. Allied cryptanalysis were able to successfully attack cryptosystems without knowing what it was they were attacking. Originally they did not have a device, an Enigma, or Purple, cipher machine, and were able to attack them based on ciphertext only attacks.

Superencryption (the re-encrypting of one cipher with another) is difficult and annoying, but can be overcome with various analytic techniques. An example was The Register's crypto-contest.

No known encryption algorithm is 100% secure, though an one-time pad offers perfect secrecy and an opponent with infinite computational resources cannot be certain of the decryption beyond guessing at what the message is.

The one-time pad can be attacked by various methods such as a cut and paste attack to make undetected changes to a ciphertext.

There is no known perfect security.

Re:Something is going unsaid.

[blair1q]

One Time Pad is the only fully secure communications encryption method, and it's still not necessarily physically secure. And when it is used in any non one-time-use protocol, e.g. VENONA, it is no longer perfectly cryptic, either.

All other forms of encryption are less secure, such that the economics of the subjective or objective value of decrypting the message and the cost of doing so dictate whether it remains secure.

Re:Something is going unsaid.

[rossifer]

Actually, that turns out not to be the case. What you've described is "security through obscurity", which is vulnerable to lots and lots of kinds of attack.

Many encryption attacks are against the encrypted text alone, and if your encryption approach sucks, most tools will go right through it.

Some of the better decryption systems will then proceed to describe which long ago cebunked algorithms you used or which algorithms you tried to implement but messed up in some fairly pedestrian way.

Security through obscurity, isn't. If your system can't stand to have the algorithm exposed and studied, the algorithm is as likely a point of attack as the key. And you probably didn't do as good a job as people who have subjected their algorithms to public review.

Regards,
Ross

Re:Something is going unsaid.

[sjames]

Gotta be careful with that! What you get from all of that is a complex composite of the two functions and keys, but it might still be broken.

It is even possible in bad cases that you will manage to combine the weakneses of both algorithms. and end up with something really weak.

supporting evidence :)

[Bill Currie]

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.

double-ROT13

[Thud457]

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

Standard implementations

[Coz]

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 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*

MOD PARENT DOWN!

[Phreakiture]

I approve of the message, but not the tactic.

Re:Aggghhhhh! SQL Injection is real

[jpa5n]

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,2) 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:For the rot13 challenged and vim equipped

[enkidu]

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

I'm so ashamed...

[Tomster]

"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

Re:I'm so ashamed...

[Anonymous Coward]

"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!!

Hey, you have the copyright for it? We need a quick way to check passwords - nothing too secure, you know - and would rather buy a well established piece of code than have programmers in house writing something rotten. Send your contact info, this kind of deal should not be discussed in public!

Re:I'm so ashamed...

[Old Wolf]

Maybe you can answer my question for me then -- why on earth would you use memcmp(,,strlen()) instead of strcmp() ?

Re:I dig boners!

[Anonymous Coward]

talk about being redundant..

In perl/shell

[jjohn]

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

# Cut'n'paste away.

Re:In perl/shell

[Tomun]

Thats beautiful. Thanks.

Re:In perl/shell

[Anonymous Coward]

Isn't it kind of silly to use perl's tr to simulate tr itself?

Okay, besides the fact that tr is seriously broken on some systems (*cough*IRIX*cough*)...

Have a little bone to pick

[argoff]

He Said ...The fact that the Internet can be used to massively violate intellectual property rights doesn't make it moral to do so.

I would assert that Intellectual Property is immoral, and that people trade freely on p2p networks and the internet, in part, to undo the damage caused by immoral copyright monopolies.

The moral and historical foundation of property derives from the fact that property has tangable limits - not from a King who granted publishers monopolies in return for not publishing bad things about the monarchy. Incentive does not a property right make.

Just because an institution calls something a property, does not mean that it is - any more that it did in 1850, where if you freed a slave you were called a thief - and could even be hanged.

As society enters the information age it is becomming apparent that the right to copy is a moral right that exists above government, like freedom of speech, religion, and the right to bear arms.

Re:Have a little bone to pick

[salesgeek]

If you don't like the law, change the law.

Re:Have a little bone to pick

[argoff]

If you don't like the law, change the law.

The best way to change this law is by open disrespect for copyrights and civil disobedience.

Re:Have a little bone to pick

[salesgeek]

The best way to change this law is by open disrespect for copyrights and civil disobedience.


I'm not sure what country you are from, but I know here in America, we have better ways. Civil Disobedience is the step that is usually taken prior to revolt. I just wish that people understood that Civil Disobedience is a limited form of civil warfare. It was called by someone "civilized civil war" after the the Marcos regime was toppled by the people of the Phillipines.

Back to IP Law. First, I'm not sure that the anti-IP camp and the IP Limits camp have done very well in selecting court battles. I followed the last couple of DCMA fiascos and was very unimpressed at the case laid before our appealate courts.

I haven't seen any lobying efforts that are worth mentioning. In fact, we're not getting the word out. Most people when they understand what we are talking about get it. Right now, the public thinks we're a bunch of scofflaws looking to rip DVDs, pirate software and snarf pr0n. Reality is that a more limited form of Copyright would make a huge difference and an imporvement in patent approval would really help change a great many things. For the better.

Re:Have a little bone to pick

[argoff]

I'm not sure what country you are from, but I know here in America, we have better ways. Civil Disobedience is the step that is usually taken prior to revolt. I just wish that people understood that Civil Disobedience is a limited form of civil warfare. It was called by someone "civilized civil war" after the the Marcos regime was toppled by the people of the Phillipines.

I am from America too, but in America there are large multi billion dollar media companies that will eternally kick your ass unless you stand up for yourself. People have a moral right to copy things wether or not they hire an armada of lawyers and full time staff to lobby their congressman. Since the technology exists for people to copy without limit, and without any violence or coercion whatsoever - I would say that there is now a pretty good argument for the civil disobedience case.

Now don't get me wrong. I love America, and I like politics. The whole idea behind politics is that it is better to fight wars of words than of bloodshed. But politics is not an end in itself, individual liberty is, and this time we can achieve liberty without harming anyone.

It is in our best interests to create a situation where they half to choose between copyrights and shutting down the internet. When that happens, then we will have plenty of BIG interests on our side that will be happy to fight the political battles and rally popular support.

My thought process

[debrain]

Something like this:

/me thinks ROT13? WTF is that.
/me googles ROT13.
/me finds http://www.alliancestudio.com/cgi-bin/rot13.cgi
/me sends: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.]
/me receives english translation.
/me acquires 31337ness.
/me goes to shameless plug for job, only to find it slashdotted.
DAMNIT
/me feels 31337 status drain away.

Re:My thought process

[rbenech]

ROTFL! ditto. exactly!

Made me smile

[jedrek]

The fact that the Internet can be used to massively violate intellectual property rights doesn't make it moral to do so.

I'm sure Paul doesn't remember me, but I remember Paul. When I was all of 13 (this was arround '90) Paul Kotcher and I both lived in Corvallis, OR. IO didn't know Paul, met him only once (knew his brother Scott a bit better though) but he was the geek star of Corvallis, the only teenager we even knew about who could program assembler and crack copy protection. I remember playing a 'warezed' (didn't have that word back then) version of Test Drive cracked by Paul.

Anyway, each time I see Paul's name come up in the news, it reminds me of those days and it brings a smile to my face.

Re:Made me smile

[cpeikert]

I remember playing a 'warezed' (didn't have that word back then) version of Test Drive cracked by Paul.

This is interesting, considering Paul's assertion:

The fact that the Internet can be used to massively violate intellectual property rights doesn't make it moral to do so.

Paul, you got some 'splainin' to do!!

Encryption chaining & byte-scrambling is pract

[Futurepower(R)]

The problem with one-time keys is that they must be as long as the data to be encrypted.

The encryption chaining with byte-scrambling in between allows unbreakable encryption with only 3 passwords of perhaps 50 digits each. That's much more practical for people who have gigabytes to encrypt.

Somebody get a Venture Capitalist!

[hobbit]

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.

Crikey! You've cracked it! You're going to make a fortune!

Either you mean 'one-time pad' when you say 'byte-scrambling algorithm', or you are the sort of layman for each of which cryptanalysts wish they had a penny.

Re:I dig boners!

[Anonymous Coward]

I am most likely a gay homosexual faggot,

what, was the test inconclusive or something? let me help you out: it is very, very, very "most likely"

Re:Sheeeit

[Anonymous Coward]

Good thing you posted your follow-up anonymously, or I'd have thought it was really ergo98 posting it. Or something.

Excellent

[Anonymous Coward]

Thanks, I'm heading out to the bookstore to grab a book based on one of your reviews. Is it possible for you to list various favourable higher-level mathematics textbooks (i.e. course books that universities would use)? I never did well in university mathematics but would like to teach myself all over because I find myself actually loving math and appreciating its elegance!

Re:Excellent

[eXtro]

I enjoyed Neal Koblitz' text A Course in Number Theory and Cryptography (Graduate Texts in Mathematics, No 114).

Re:Excellent

[H*(BZ_2)-Module]

The Chicago undergraduate mathematics bibliography is a pretty good collection of mathematics texts on moderately advanced topics with some commentary.

Re:Excellent

[c64cryptoboy]

Crypto-math often implies discrete math (as opposed to continuous mathematics, like Calculus). So if by "higher level mathematics" you mean math that is traditionally taught after calculus, but is not necessarily calculus dependent, then you're probably talking about set theory, group theory, number theory, complexity theory, information theory, etc. The following are books that you can teach yourself from, that don't demand graduate level backgrounds in mathematics:

1) A nice introduction to Group Theory is:
"A First Course in Abstract Algebra" 6th Edition, by Joyhn B. Fraleigh

2) A much more fun but slightly more difficult introduction to Group and Set Theory is:
"Adventures in Group Theory" by David Joyner. The 2nd edition is not quite out yet, so you'll have to make sure to check his errata web page, as there are lots of bugs (I sent in most of them).

3) For number theory, I recommend:
"Number Theory in Science and Communication" 3rd Edition, by M. R. Schroeder
The little calculus that there is in this book can be skipped without missing too much.

4) For Information Theory, try:
"Introduction to Coding and Information Theory", by Steven Roman

Happy reading.

Can I see a proof, please?

[rjh]

We're fortunate that cryptography is a mathematical discipline. That way, whenever anyone makes claims about "no mathematical attack can ever be successful", we can say "great--prove it."

There is only one cipher out there nowadays which has been formally proven to be totally immune to mathematical attack: the Vernam Cipher, which is conceptually brilliant but too impractical to use.

Everything else (so far) has been proven susceptible.

I would suggest reading Knuth's The Art of Computer Programming, where he does basically exactly what you suggest except with random numbers. And yes, he successfully cryptanalyzes the output.

Prime factorization

[smcv]

Whenever /. has a crypto story, someone posts something like this:

there exists a known algorithm to factorise primes in polynomial time

which is perfectly true. Even better, it works in constant time:

def factor(prime):
return (prime, 1)

(translation into languages other than Python is left as an exercise to the reader)

Factorizing composites efficiently is how you break RSA and related cryptographic algorithms.

Re:Prime factorization

[twd20]

The fastest algorithm to factor composites is the number field sieve for which the complexity is:

$e^{c(\log n)^{1/3} (\log \log n)^{2/3}}$

IIRC the smallest value of c is around 1.9

What is unchecked buffer size problem?

[tungwaiyip]

The memcmp() bug in the interview seems simple enough. May I ask a novice question? What is unchecked buffer size problem? How can you take over a system because of an unchecked buffer? Is it a C/C++ specific problem? Thanks for enlighting me.

Re:What is unchecked buffer size problem?

[Old Wolf]

gets() lets the user type as much as they like. But in your program you can only have allocated a set size for the password (eg 100 bytes). So if they type for long enough they can go past the end of the password space, and their typing will start overwriting other parts of memory. If they know what they are doing they can type the right control characters and give themself a root shell.

It's a problem when you have programmers who don't understand buffers, using a language without buffer checking.

Re:What is unchecked buffer size problem?

[McLae]

Most buffer problems are caused by programmers who do not remember that memory is full of many items, not just the item they are working with NOW. There is data before a buffer, and there is data after a buffer. Filling a 10 byte buffer with 11 bytes puts garbage in some other buffer or variable. If buffers are on the stack, extra data flows over onto the stack, which causes many problems. (Google searach 'Wild Pointer')

Re:What is unchecked buffer size problem?

[janda]

To blockquote/italic the parent poster:

The memcmp() bug in the interview seems simple enough.

There are many things that are too subtle to see at first glance. The memcmp() problem is not (always) the issue, the gets() is the major problem that I first saw.

The original code was written as:

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

I didn't decrypt the DMCA-compliant ROT-13 code, but I would say that at a first glance the following problems exist from a security perspective:

1. gets() allows an arbitrary input length. This allows buffer overflows, with all of the attendant problems.
2. There is no hash/encryption/non-reversable transformation between the gets() and the memcmp(). This implies that what is stored in the correctPassword buffer is in plaintext. This allows another vector of attack.
3. Even if the password in correctPassword is encrypted in the {password file used by this system}, the fact that you compare the input to correctPassword[] without modification implies that correctPassword has been decrypted, so if you can get access to {password file used by this system} you can decrypt the passwords without using a brute-force attack.
4. The memcmp() call should be for something that ensures you have entered the same number of characters as correctPassword before it compares them. If you compare strlen(userEntry) to correctPassword, anybody who has has the first "correctPassword" characters (e.g. correctPassword is "azigy", the userEntry string is "azi") will match the password. If you match strlen(correctPassword) to userEntry, then all you need is to find out the maximum password length, and start a brute-force attack from that point down.

5. May I ask a novice question?

   As a novice myself (I've only been programming professionally since 1980), feel free.

   What is unchecked buffer size problem?

   A buffer overflow (or, as you call it, an "unchecked buffer size problem") occurs when you create (for example) a buffer of
   
   char InputBuffer[100];
   
   And then use a function that does not allow you to specify how long the buffer is, for example:
   
   gets(InputBuffer);
   
   If the user types more than 100 characters, they will overflow the buffer (do a google search for "fandango on core", "going to la-la-land", or other things from "the hacker's dictionary"), which can cause multiple issues, such as providing invalid data on the return from the call, creating a shell (or even worse, a root shell) on return, corrupting data on the stack from previous functions calls (e.g. rc=GetInptut(InputBuffer), which calls gets(InputBuffer)), as well as other things.

   How can you take over a system because of an unchecked buffer?

   Given the correct circumstances, anytime you can overflow a buffer you can take over the system. For examples, see almost any microsoft, apache, linux kernel, bind, sendmail, or other package vulnerability notice in the last 30 years.

   Thanks for enlighting me.

   You're welcome.

Re:What is unchecked buffer size problem?

[Anonymous Coward]

Here's possibly a dumb question related to buffer overruns:

So someone who has access to a text editor and a compiler on a system can possibly gain root access? Seems to me they could use the following procedure:
(1) Write small program that has unchecked buffer size problem.
(2) Compile and run program.
(3) Exploit unchecked buffer size problem in program they just wrote.

???

Re:What is unchecked buffer size problem?

[0x7F]

(1) Write small program that has unchecked buffer size problem.
(2) Compile and run program.
(3) Exploit unchecked buffer size problem in program they just wrote.
(4) Compromise your own user account.
(5) ...
(6) Profit!

Buffer overflows are only useful when the program has privileges you want. The only way your exploit would work is if you could run your program as root, in which case you're done before you've started.

Re:What is unchecked buffer size problem?

[loraksus]

also its pretty common to run progs as root in a chroot jail, google for more info.

Non-perl method...

[Anonymous Coward]

tr A-Za-z N-ZA-Mn-za-m
<paste text to console>

BUT NO!

[Proaxiom]

That's exactly what he wants you to think! You see, if you realize that this really isn't a ROT13 encoded message, that was just to throw off the amateur cryptanalysts. The truly insightful, such as myself, would have thought to treat this as a one-time pad, encrypted with the following key (in hex):

070F00335427494C12525E57463D031751570B05591B450407 080849091258466331252631316E5552270609125248060502 150C4E526D2D253A276E2E3648002A1D0C11051A441B535302 0152551846071600060902450E434D03422870222733743620 5B5430100005165447061B471E030945313137742227285C4A 350D105A01622825373761372D3548412A170717001006100A 1C1C5A12555A01481C1D522661323D332C3D434223120B5352 3E1F5B08014E2633742A48532F4F1946411C04000B04074517 1308064C160F004E47545300241E02510B0A5B527B24141D1F 5218000346420615071A5D00221C00191146002B0E02420D11 00420017520E0E455901190B00131A56024953011C1C11540F 080B42223570323339265F56300441064B1A1D105601000952 0D0150213B2E3B5B5629011252480B041C59424F4E02194104 0D044754010004171D560711454E4D12030400510114034311 0B1E13472D2E2D21130038235A2B2F41246D0021374858490E 5B4949633A2F2F6A6A6A2E70656C63676274656E63756C2E70 627A2F70627A636E616C2F706E65727265662E75677A792E5D

Which, of course, decodes the message to:

In A.D. 2101 War was beginning. CAPTAIN: What happen? MECHANIC: Somebody set up us the bomb OPERATOR: We get signal CAPTAIN: What! OPERATOR: Main screen turn on CAPTAIN: It's You!! CATS: How are you gentlemen !! All your base are belong to us. You are on the way to destruction CAPTAIN: What you say !! CATS: You have no chance to survive make your time CATS: HA HA HA HA.......

A devious one indeed, that Paul Kocher!

Rot13 security?

[ak_hepcat]

My next license plate will read (only 6 char's)

"shpx h"

yeah, it's an obscene turn of the phrase, but nobody will understand it.

the new fad in custom licenses!

or maybe l33t-speak? Oh, wait, no special chars..
1]4m!+ !!

Comment removed

[account_deleted]

Comment removed based on user account deletion

YOU ROCK

[Anonymous Coward]

MY HERO!

more secure than an identical piece of code?

[darthwader]

When I first saw that comment, I thought "Hah, of course not. It's exactly as secure, since it's identical code.". But after a moment or two of thinking, I realized that he's right.

A good working definition of "Secure" can be "does what the user expects it to do (and nothing else)".

With this definition, well-tested does mean more secure, simply because a well-tested bit of code is much less likely to surprise you.

Simple substution cypher generator in 48 bytes

[Michael Woodhams]

For those who enjoy solving simple substitution
cyphers, the following command will encypher a file for you:

perl -0777pe'$a="a";s/[a-z]/$b{lc$&}||=$a++/gei' filename

I also have a program to help solve these cyphers, but it is too long to fit into the margin of this post.

(And if you don't like solving alphametics problems (e.g. SEND+MORE=MONEY), I have a program that will do it for you in 135 bytes.)

Re:Encryption chaining & byte-scrambling is pr

[mistered]

It's true that using a one time pad has the disadvantage that you need a key as big as the data to encrypt.

Your other statement is just completely untrue, although there is a big market selling dubious encryption software employing such techniques. Well, I guess there's a big market for dubious encryption software of all types.

Meganet (www.meganet.com) is one of my favourites.

More on q7 (trust in P2P networks)

[Peter Eckersley]

Came across this problem whilst brainstorming for The Circle.

There is no way to verify that a peer is running some genuine/particular client or other (at least, not without DRM hardware).

The only way to make sure that you're not uploading fies to RIAA dupes is to have a real-life web-of-trust amongst your users. Unless your web of trust is a serious conspiracy, it's unlikely to be effective.

It *is* (theoretically) possible to detect misbehaving clients, though. Imagine you require all participants to sign each of their transactions, and there are particular pairs of transactions which are inconsistent (such as, reply to a search for file X, but then claim not to have X when a download is requested). Nodes which see such behaviour can compile cryptographicaly secure evidence that a node has bisbehaved (the node can then be temporarily blacklisted).

On Paul's comment that copyright infringement is unethical, here is the (usually neglected) rule-of-thumb:

1. If, absent piracy, you would have bought it anyway, then you owe the artist (and maybe the publisher?) some money.

2. If you wouldn't have shelled out to purchase a copy, then copyright infringement is ethical.

Re:More on q7 (trust in P2P networks)

[janda]

The previous poster is "blockquoted/italic":

There is no way to verify that a peer is running some genuine/particular client or other (at least, not without DRM hardware).

Sure there is. PGP/GPG sign everything, and do an exchange of newly-generated keypairs for each site.

On Paul's comment that copyright infringement is unethical, here is the (usually neglected) rule-of-thumb: 1. If, absent piracy, you would have bought it anyway, then you owe the artist (and maybe the publisher?) some money. 2. If you wouldn't have shelled out to purchase a copy, then copyright infringement is ethical.

Incorrect. The rules of thumb are:
If you would have brought it anyway, you owe the "owners" money.
If you would not have brought it, you owe the "owners" money.

Re:More on q7 (trust in P2P networks)

[Peter Eckersley]

Sure there is. PGP/GPG sign everything, and do an exchange of newly-generated keypairs for each site.

The question I was addressing was, is it possible to tell if someone else on gnutella is running LimeWire (for example)? Of course, you can demand a secure hash of the peer's code, but someone trying to create a "fake LimeWire" can do so by copying LimeWire's hash.

Incorrect. The rules of thumb are:
If you would have brought it anyway, you owe the "owners" money.
If you would not have brought it, you owe the "owners" money.

I presume you're being humourous (I wouldn't assume anyone is a deluded ethical absolutist without more solid evidence ;)

Mixed algorithms prevent mathematical attacks.

[Futurepower(R)]

Every decryption article I've seen involved knowing what you are looking for. Every cryptographer seems to look for mathematical shortcomings that would not be valid if several algorithms were mixed. Mixing algorithms (say AES and DES) prevents attacking using a knowledge of the underlying mathematics of each algorithm.

It is still possible to try a statistical attack, on anything, of course. But, with mixed algorithms you are preventing an attack using some mathematical weakness that may be discovered in the future.

This is what I'm saying: Mixed algorithms prevent the success of any kind of mathematical analysis that is based on a knowledge of the underlying algorithms.

Re:I've seen worse...

[pHDNgell]

I was doing a bit of security consulting at a hospital once a long time ago and they had a system in place to prevent people from logging in. Unfortunately, I didn't notice it.

It turns out, the security system used /etc/profile to figure out if you were authorized based on an entry in a text file somewhere...all written in bourne shell. It had the appropriate traps in place to prevent ^C and stuff working.

The reason I didn't notice it, however, was that I had requested my account be created using tcsh.

After discovering this, I had them create me a bourne shell account and was still able to bypass the system by hitting ^C soon enough after entering my password that it could break out of the profile before getting to the trap line (helped that it was still paging in at the time).

Personally...

[Anonymous Coward]

I'll laugh my cock off.

The chimp's so scared of North Korea, there's no chance he'd piss China off - he's just happy that China is best mates with India rather than Pakistan, 'cause if the Pakis got hold of an ICBM platform, the US would be under a death sentence.

Still, our poodle might be more mad - I think he's nearly lost it.

Re:Call Ashcroft!

[Anonymous Coward]

First I post it in a beer-fuelled moment to the questions thread...

Then it makes question 10...

Now I'm a terrorist?

Qnza! :o(

Consider what I said more carefully.

[Futurepower(R)]

Ross,

Here is a better explanation:

#5610902, Mixed algorithms prevent mathematical attacks.

The method I mentioned prevents attacks based on knowing the mathematics of the algorithm.

It's a groaner

[Anonymous Coward]

I didn't decrypt the DMCA-compliant ROT-13 code, but I would say that at a first glance the following problems exist from a security perspective...

That's what I thought too, but then I checked the answer (see why I'm posting anonymously, don't want the phone cops at my door...) I wanted to smack my forehead. Think way way wayyy dumber than that.

Rot13 translator

[Anonymous Coward]

#!/usr/bin/perl
while(<>)
{
tr/a-zA-Z/n-za-mN-ZA-M/;
print $_;
}

Enjoy.

ROT13

[fungai]

To decode/encode ROT13 save the text in a file called foo. Open your Mac OS X terminal an type:

tr A-Ma-mN-Zn-z N-Zn-zA-Ma-m < foo

No need to mess with Google and other fancy things.

You can do other fun things with tr, like if you want to be the 1337357 dude on the block, type your text and save it in a file called foo, then run:

tr aeios 43105 < foo

Have fun!

Re:I've seen worse...

[bears]

Early VMS (I'm thinking VMS 1.0, circa '80?) had a similar problem. The login was done by a DCL script. Wander up to your friendly VT100, hit Return to wake it up and them hammer it with ^Y (==^C). With a few tries you'd break into the login script and be dumped at a root prompt.

The Uni got an upgrade PDQ once us young 'uns had discovered that...

Re:Call Ashcroft!

[Perdo]

I am not answering you in the thread where I read your post, because I'm moderating that thread. So, go buy a new Alpha here

The company has government contracts that say it must produce the alpha untill 2006. It is alive and well. In fact it is 10% faster than HP's Itanium offering, the superdome line of servers.

Since HP's intent is to comply with the government contract but not reduce sales of their high margin, larger investment and similar contract with intel Itanium systems, they are not advertising it, posting benchmarks or supporting it (theoreticly they are supporting the hardware mut their support for TRU-64 is minnimal at best).

Prices of the 8 processors at 1224 mhz w/256 GB of ram start at 1/4 million dollars. The DS20E is a desktop workstation running dual 833mhz EV 68 processors.

The 8p version will finish a seti@home work unit every 4 minutes.

If you have the cash, enjoy the power.

Not when you are scrambling the bytes...

[Futurepower(R)]

Not when you are scrambling the bytes in between encryptions. That destroys any possibility of a mathematical attack.

Each different password has a different scrambling, anyway.