The Crypto Gardening Guide and Planting Tips

ncostigan writes "Peter Gutmann of cryptlib fame has written a very readable paper on real-world constraints for cryptographers, and points out problems that their designs will run into when attempts are made to deploy them. Also included is a motivational list of extremely uncool problems that implementors have been building ad-hoc solutions for since no formal ones exist."

Comments

Glossary

[Mas3]

Would be nice if the terms & abbreviations are explained at the end of the text ....

Stefan

DevCounter - An open, free & independent developer pool
created to help developers find other developers, help, testers and new project members.

Re:Glossary

[ideonode]

Would be nice if the terms & abbreviations are explained at the end of the text ....

Really? To me, the paper reads like it's a set of questions to prompt cryptographic systems designers to look at the overall architecture of their design. Thus the intended audience is quite specialised, and will almost certainly know most, if not all, of the terms and abbreviations used. If you have difficulty in understanding the terms, there are other resouces out there to assist. Including terms and abbreviations would be -redundant.

One of the problems with crypto

[Anonymous Coward]

Is that the data is only as secure as the OS it is on - at some point, the OS' protections become the only thing protecting the data from being decrypted. This means that running it on anything but Linux is a bad idea, b/c you cannot read the source...

Re:One of the problems with crypto

[Anonymous Coward]

You are missing something. You are assuming that it is possible for you to even get to "properly secured data" on a cracked OS.

If the OS has been compromised, how do you know that every call that your application makes into the crypto library isn't intercepted? You statically link? How do you guarantee that the loader didn't patch your own internal calls? Too difficult to be practical, you say? Isn't that sort of thing exactly what keeps some viruses going?

The only situation where a compromised OS doesn't matter is when that machine is being used to temporarily store or pass encrypted data. You cannot safely encrypt or decrypt anything on a compromised OS.

Re:The Real Question

[Anonymous Coward]

First off, get legal paperwork authorizing you to do this, otherwise forget it:

sniff their traffic. Dump out the good bits and present it to their honchos. Or better yet, do a live demonstration of how this is done, and how it doesn't take a genius. Also, how easy it is to forge email headers.

Re:why isn't an implementation standard?

[Anonymous Coward]

There's also not generally room in a paper for source.

People who write code for a living never print out code. Why would you ever include full code with a crypto paper? So I could read the dvi/ps/pdf and then type it into a computer? Just mention a URL at the end. Think a little bit and try to be pragmatic.

Re:why isn't an implementation standard?

[Bishop]

the theorists should include example source in their papers

There is no need. In the mathematical world the paper is the "proof of concept." The problems hinted at in the paper go far beyond source code. It is implementation problems such as algorithms requireing a trusted channel for the initial key exchange, and tying a public key to a real person. Other problems are processor issues. Algorithms that are only practical with non existant processors such are requireing 512bit registers, or unrealistic numbers of registers. Source code would not solve these types of issues as math lib can use arbitrary persision. If the source code is slow it will be explained as "it is only sample code." Finally Cryptologists are theoritical mathematicians, not computer scientists. Many modern crypto designs require a real Computer Scientist to implement, not a passing knowledge of C. This is probably the way it should be. Let the cryptologist concentrate on what they are good at.

Re:The Real Question

[plcurechax]

What I'd advocate, and I'm sure that privacy nuts and other security wonks would hate, would be government-issued smart cards that contain a user's private key.

Security wonks hate it because it is insecure. It links the security of everything you authenicate to, from your parking permit, or restaraut reservation, to your root password to the corporate servers you maintain, to your personal financial details. So if the bus boy at the restaraut gets your details, clones them onto a forged card, and saves a "snapshot" of your biometric details, that bus boy can get your SSN, credit report, and likely get credit cards in your name as well as commit government mandated identity theft.

That sounds like a stupid idea. Bypassing the Chinese Wall of everyday life, is a dumb idea. A single id card is as stupid as Microsoft's universial id system formally known as Passport.

... key management systems are either proprietary or too complex for ordinary users, or just involve too many steps ...

You are right, it is too complex, hard to use, and security engineers need to work on building better systems, and customers need to demand and pay for better systems.

Or you'll have an Oracle/Microsoft/US Government national id card secured by MS Windows, and Oracle's nearly unbreakable database.

Follow the money

[c64cryptoboy]

Gutmann writes "cryptographers don't work on things that implementors need because it's not cool, and implementors don't use what cryptographers design because it's not useful or sufficiently aligned with real-world considerations to be practical."

Last decade's crypto research tends not to be used, not because the research is not applicable or practical to the company/government/end user, but because it doesn't fit well into any cryptography business model. Threshold cryptography schemes (key splitting), zero knowledge proofs, identity based encryption, etc. are very useful, but it is difficult to make $$$ developing any of these. And if it made $$$, cryptographers would work on it, even if "it's not cool".

Re:The Real Question

[lenski]

Having only *one* token/object/system for all of a person's access means that only one thing needs to be hacked to gain access to that person's stuff: Not Good.

Having only *one* token/object/system for all of a person's access means that the person cannot (easily) grant a subset of their secured "capabilities" to another person (think "power of attorney" as a similar concept).

Finally, I would want the issuer of such a token/object/system to be a Disinterested Third Party. No single organization can be disinterested for long, they would become the target of all sorts of human-hacks: Payoffs, "standard hacking", etc. And worst of all, the government is not under any circumstances a disinterested third party! "The government" is not a monolith, "it" consists of lots of departments/divisions/people, many of whom love power.

In entirely too many situations, some entity would claim "legal right" to use their information/influence, sometimes for "good", sometimes for a rather narrower or shortsighted "good", as defined by them, not me. It is those people that I worry about. (Too tinfoil-hat? Maybe. But I know lots of people who cannot see past the ends of their noses, and some of them are in government. It's not so much paranoia as it is a recognition that pelple can be real assholes, and I have already given them too much influence over my life already!)

Re:The Real Question

[angst_ridden_hipster]

Three cards for police choppers in the sky
Seven for politicians in their halls of stone
Nine for Justices doomed to lie
One for the President on his dark throne
In the Land of DC where the lobbyists vie.
One card to rule them all, one card to find them,
one card to track IP, and in a lawsuit bind them...