The Crypto Gardening Guide and Planting Tips 91
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."
Also available on... (Score:2, Informative)
Re:Why do I find that so funny? (Score:5, Informative)
If you're reading about crypto, and you have not heard of Peter Gutmann, then you are either just *starting* to read about crypto, or you have missed out some of the most important *practical* parts of your reading!
Check also the X509 Style Guide [auckland.ac.nz]. Outstanding and insightful. Trust no one claiming to know about PKI unless they have read and understood this :-)
Re:Why do I find that so funny? (Score:1)
There are some online copies knocking around, because the CCITT temporarily made there stuff publicly available over the Internet, but now you have to pay.
What I have done is just to use code examples from open source software and hope the author got things right. Many people do this but they may steal stuff that is at best partially working. This is one way that bugs with certificate handling can propagate.
security thru obscurity, anyone? (Score:5, Funny)
uh...no, sorry, you have me mixed up with some other cryto guy. My name is, uh, Chuck...Chuck Laylow. I don't know squat about anything dealing with secrets, really...now, please go away before someone sees you talking to me, and don't tell anyone you talked to me...ever...thanks.
ow (Score:2, Funny)
Glossary (Score:1, Insightful)
Stefan
DevCounter [berlios.de] - An open, free & independent developer pool
created to help developers find other developers, help, testers and new project members.
Re:Glossary (Score:2, Funny)
Re:Glossary (Score:2, Insightful)
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.
Yes but... (Score:2, Funny)
Version: PGP 7.0.4
qANQR1DBwU4DyuYN9AlBSc8QB/4gR8MbVCSKYkdpb2j3EFa
t81BHPhHLZbHV7+EmRS8rrCwyjITGQ9fw
r7SeQa3S24JC1WB4cEgZpcKtxw18LSPoL
oQrI/H87V2fq7RLuAWbXUVbnQ9R7sIPp+
GLBa4YNADCh2lbXzCUxzbmJA/Ij5bIGuq
3Ngbwzu5n+uh8Fw2VO2ReGSbekWJhiMWJ
wZaxn19e3h2RHEvkwO8BVVDHkKVWdYT/7
VL+PjUx8fo1X6w9dYsT1/nVGkWqv1W+MM
LZxEsAvsQdBmS1ugA0hbUZyuKxRZ4ej8d
B+e/Idqd7WKiN/SLrHRNHo76p/0NIiClk
J3FW68e49jJHn01VvWAw3fLmWN97WQYLW
r1cK33rqyTued/PJyfvKwGd2WyInyCZdz
OX1a8Rxru+pwG3gqrhRrEMcLGQ==
=c9
-----END PGP MESSAGE-----
Makes sense I think, don't you ?
One of the problems with crypto (Score:1, Insightful)
Re:One of the problems with crypto (Score:3, Informative)
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.
Data encrypted with secure methods does NOT depend on the underlying OS. Why encrypt anything, if you can just crack the OS?
Oh, wait, I forgot that encrypted data gets sent plain through emails, and is posted publically, and is used on public, non-secure systems. Doesn't dnet post the encrypted message, and offer rewards for cracking?
It doesn't matter is you crack the OS because properly secured data is not dependent on anything else.
This means that running it on anything but Linux is a bad idea, b/c you cannot read the source...
You realize Linux is just a kernel, right?
And not the only one [dmoz.org]?
(I realize I've probably been trolled, but...)
Re:One of the problems with crypto (Score:2, Insightful)
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:One of the problems with crypto (Score:2)
Re:One of the problems with crypto (Score:2)
Will your (Score:1)
I laughed, I cried! (Score:5, Funny)
(Note: If you're in the media or telecoms industry this becomes "Get there
first with something patented, proprietary, and broken, then send lawyers
after anyone who points out problems", but this is a special case).
Heh! What a wag!
But... (Score:2, Funny)
Says Nigel... (Score:2)
Says Nigel... "But ours goes up to 65."
Very readable.. (Score:1, Interesting)
..except for all the acronyms!! MAC, HMAC, PRF, IV.. is there a glossary somewhere for this??
Re:Very readable.. (Score:5, Informative)
Hashed Message Authentication Code
Pseudo Random Function
Initialization Vector
Re:Very readable.. (Score:1)
http://www.google.com/search?sourceid=navclient
yadda yadda, get with the google
The Real Question (Score:5, Interesting)
Suggestions from the floor?
Re:The Real Question (Score:5, Funny)
"If you would like to stop me reading your mail like this, give me a ring and I'll tell you how. If I find anything good in next month, I'll print it out and pin it up on everyone's messageboard. Give Janice a kiss from me, sugarplum."
Re:The Real Question (Score:1, Insightful)
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:The Real Question (Score:1)
The PHB and I were discussing this the other day. I have a little keychain password tool [mandylionlabs.com] (since I can't remember aysh7aAS3 x 10 systems), but its worthless for passphrases or other more complex authentication systems.
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. The passphrase would biometrically authenticated (small thumbpad) and have an LCD screen that would display an alphanumeric fingerprint which would match a printed fingerprint and a small B&W version of a printed photo, making it difficult to counterfeit.
Since these would be government issued, they would be *universal* and could be used as an access token for encryption systems. They would also have an open implementation so that anyone could interface with them.
Encryption is complicated now because the key management systems are either proprietary or too complex for ordinary users, or just involve too many steps. Authenticating yourself with your biometric ID to your desktop would make it far easier for businesses to use such systems and would make them ubiquitous. Nobody is born knowing how to lock their house or car, but since everyone does it from an early age it becomes trivial. If public/private key crypto could be implemented universally, people would learn it and get used to it quickly.
The bonus is with an open implementation of the card's interface, it could be used everywhere. Your public key could be used on your hotel door, your car, your office, your house. Want to give the neighbor access to your house while you're gone? Don't give them a key, have them swipe their biometric authcard in your lock -- grant access to that public key for X days and you don't have to worry about the key getting lost or copied.
The big challenge is universality. I'm sure privacy nuts would chafe at this, but I don't think it would work without being a federal ID system. You wouldn't have to have one, but like a bank account or a credit card life might be a little awkward. The bonus would be you wouldn't need a passport or any other government issued ID and it would be a huge fraud deterrent. A government system could also be an open standard.
Re:The Real Question (Score:4, Insightful)
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.
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.
Re:The Real Question (Score:2)
The problem right now is that there's so much bitching about how any new system wouldn't be 100% secure that we're forced to live with a system we know right now is 100% INSECURE and offers ZERO protection; or we duplicate it with layers of complicated stuff that no one users, or neutralizes with post-it notes on monitors.
Re:The Real Question (Score:2)
How are cards created? Well, the smart cards are made at the factory under security similar to handling printing currency. Then they are sent to government agencies which initially record the details of an indiviual using a standard smart card reader (and writer).
So the fraudster needs to bribe a clerk at a government office to record the details he has to a "virgin" smart card. Not hard, not high tech. Costs less $50 per card in quantity.
With a turnaround of $10,000s to $100,000s of damages currently by identity fraud, I hate to imagine how much bad debt could be accumilated by using "high security but easily bribed" id cards.
Currently if one of my security devices or passwords fails, my entire life is not compromised, thats what an universial-use / "national" id card proposed to do.
Re:The Real Question (Score:2)
And its not meant to eliminate other security mechanisms, but to provide a very secure base crypto element so that people can more easily crypto in every day life.
Re:The Real Question (Score:2)
They don't.
Once the forger has his own fake keypair for you, that is signed by the government Certificate Authority (CA) his keypair are legally binding as proof that he is you, until it is proven in a court of law that the card, keypair, and peronsal details have been forged.
Like cheque forgers; who don't break into banks, they withdraw the money by asking the bank tellers nicely. The smartcard forgers don't break the cryptography, they attack the system.
P.S. The forger would know your public key, you give it away, in every transaction. I suspect you mean how do they fake your private key. Same answer, they work around it.
Re:The Real Question (Score:2)
But my biometric identity is part of my keypair, and if the keypair is validated with each transaction, how does he fake my biometric identity? If your argument is based on the fact that the computer system is compromisable and my entire identity record (public keys) is replaced with a fake identity record, I'll notice within the day and/or hour that this has taken place and can quickly stop it. Plus I don't believe that a public keyserver that stores biometrically authenticated data would necessarily be so easily compromisable. Not impossible, but very difficult.
Like cheque forgers; who don't break into banks, they withdraw the money by asking the bank tellers nicely. The smartcard forgers don't break the cryptography, they attack the system.
If the system is never perfectable, is that a reason not to try improve on it with systems that depend more highly on cryptographic identity verification?
This is where I get lost in all this. The system is always attackable, always will be, but shouldn't the parts of the system make those attacks far more expensive, complicated and difficult? I'll accept that the system can be compromised by Mitnick, but right now we have a system that's compromisable by any street thug with a fourth-grade education.
Upgrading the "system" so that it is highly reliant on cryptographic verification increases the difficulty of scamming it by at least an order of magnitude. What's wrong with that?
Re:The Real Question (Score:2)
The attacker doesn't fake your biometrics. He bribes a government clerk to produce a genuine government card with your stolen details such as SSN, bank accounts, credit card numbers, medical records, etc. and his fingerprint or retinal print. Similar to current credit card cloning, jus t a different procedure to produce the cloned card.
BTW using your biometrics as the actual public/private key data is very bad, and hopefully no system uses it. Because nearly every biometrics system is thought of as producing a small amount of random data, ie. a shared secret, which cannot withstand attacks if the validation system is compromised. A organized crime owned storefront could gather biometric data/keys as well as legimate banking details for the valid customer transaction.
More common designs involve the biometrics info as a symmetric (key-wrapping) key to protect the private key as it is stored on the smartcard. This means the biometrics never leave the smartcard if the smartcard can collect the biometrics directly itself.
There is also the issue that biometrics are harder (and limited) to revoke in the event of a compromise. You have a very small finite number of fingers and eyes.
If your argument is based on the fact that the computer system is compromisable and my entire identity record (public keys) is replaced with a fake identity record, I'll notice within the day and/or hour that this has taken place and can quickly stop it. Plus I don't believe that a public keyserver that stores biometrically authenticated data would necessarily be so easily compromisable. Not impossible, but very difficult.
The forged card is an duplicate, not a replacement. Your card is still valid, and you will be able to withdraw from the ATM as long as there is still money in your bank account / credit limit. Like a forged plastic credit card with magstrip, your card is still accepted as long as your account is less than your credit limit.
This is where I get lost in all this. The system is always attackable, always will be, but shouldn't the parts of the system make those attacks far more expensive, complicated and difficult?
Give the professional criminal some credit, they will use the path of least resistance, and often of least sophistication.
It doesn't matter if the front side of your house has reinforced armoured doors and windows, if the burgular can simply go in the unlocked patio door in the backyard. So why expect any less of the forger / identity thief?
This is covered in the archives if RISKS digest [ncl.ac.uk], Secrets and Lies [counterpane.com], and Security Engineering [cam.ac.uk].
Re:The Real Question (Score:2)
This is exactly what I had in mind.
The mechanics of it would be something like this, say at an ATM machine: I put my thumb on the biometric reader, which then issues a signed request for my bank account number. The biometric authentication unlocks my private key in the card, and my request is signed by both my biometric private key and my stored private key.
At the bank end my request is validated against their records of my public key and my biometric public key. Any mismatch and the transaction is rejected.
Any response I get can also be validated by the card as matching the card's stored version of the banks public keys.
The ATM machine is merely a transmission point for my signed requests and reciept of signed replies. All of the signing and validation is done in the card or at the bank, not in the machine (although the machine will probably rely on validating a second, parallel reply from the bank to spit out dollar bills).
In this scenerio, how can someone have a 'cloned' card? Unless they have totally cloned my card and my thumb, they're out of luck.
Perhaps this seems so strong to me because its possible to distribute my public keys and let each individual institution keep their own local copies, mitigating a single-source compromise. This could even be coupled with a cross-validation with a third party key server to be sure that someone else agrees with the keys being presented (ie, you can't just alter the keys at the bank). As long as the remote end validates the signed request, a cloned card would be worthless since the requests for my account wouldn't have the right signer and would be rejected.
Although now that I've managed to design a card with LCD display, biometric authenticator and computational power to calculate keys and validations, I might have to design a back pocket big enough to carry it.
Thanks for the informative discussion. I've at least learned that even complicated systems can have simple faults, and this is much more complicated than an armchair security expert can design!
Re:The Real Question (Score:2, Insightful)
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 (Score:4, Insightful)
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...
Re:The Real Question (Score:4, Interesting)
Re:The Real Question (Score:2, Interesting)
why isn't an implementation standard? (Score:4, Interesting)
Crypto designs are often described as mathematical abstractions that, while easy to work with mathematically, require a significant amount of work to translate into an actual implementation.
i'm surprised by this, why can't the crypto whizzes put together a few lines of math.h and networking code to be a proof of concept? crypto is very much an applied field, so the theorists should include example source in their papers.
Re:why isn't an implementation standard? (Score:5, Interesting)
Er.. security is an applied field. Crypto is applied non-applied mathematics, basically. I don't
There's also not generally room in a paper for source. Rigorous proofs and definitions can take up a LOT of room. (Everyone who's read the 5x page HILL paper, or one of Dan Boneh's 3x page papers, raise your hand if you want to see source at the end of it.)
Lea
Re:why isn't an implementation standard? (Score:1, Insightful)
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? (Score:1)
Still, it's a different skillset, and it's a bit odd to assume that cryptographers code, or code well. I certainly know some who do, but many don't like to or simply can't.
Lea
You've never had to publish for a living. (Score:2)
Thank you, drive through.
I'm not saying that's right or proper, but it is a fact.
Re:why isn't an implementation standard? (Score:4, Interesting)
Well, There is nothing to be surprised about. Many theoretically secure encryption schemes have been broken in practice because the implementation is very difficult. One common pitfall: in theory, often, we assume the existance of a perfect source of random bits. Practically it is very very very difficult to ensure this (remember that part from cryptonomicon - where the encryption is broken because the keys were not perfectly random and there was a slight statistical anomaly ?).
Also in theory, some schemes are secure only if the keys have some mathematical property. In practice, someone who does not understand this subtle point might make a horrendous implementation. (I dont want to go into the gory details about the field from which the keys should be chosen in the diffie-hellman scheme).
Even with a perfect implementation, the user is also a very weak link in the chain.There is this famous incident of the more secure german naval enigma getting broken because some ship tranmitted using the new enigma scheme and the same message using the old enigma scheme (which was already broken).
Re:why isn't an implementation standard? (Score:3, Interesting)
Nearly all cryptographers do write reference implementations of their cryptographic algorithms. Rivest (RSA, MD4, MD5?, RC4, RC5, many more), Schneier (Blowfish, Twofish), Daemen (AES), Rijmen (AES), and many others write their own code AFAIK.
The issue that Peter Gutmann is focusing on (cryptographic) security protocols and systems, not cryptographic primitives like encrypting, signing which can be insecure when used incorrectly. E.g. A working RSA implmentation can be written in about 100 lines of C and a multi-percision interger library like GMP or MPI. The problem is that unless you do message padding following a scheme like OEAP your security is not as strong as expected / advertised.
crypto is very much an applied field, so the theorists should include example source in their papers.
Cryptography / cryptology falls into a relation with number theory and abstract algebra and computation computer science. Security Engineering [cam.ac.uk] is the practice of building secure systems including using cryptographic algorithms and protocols.
not RC4 (Score:2)
Re:not RC4 (Score:2)
Early on there was both an anonymous Usenet posting,and something to cypherpunks mailing list. One may of been reserved engineered, but one was claimed by those with access to RSA Inc.'s BSAFE library to be leaked from RSA Inc.'s code.
Anyhow, AFAIK Rivest wrote the first implementation of RC4 algorithm himself. I never said it was published or public knowledge.An internal reference implmentation is still a reference.
Re:why isn't an implementation standard? (Score:3, Insightful)
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.
What about the other side? (Score:3, Interesting)
I'm no crypto expert, and many of those suggestions make perfect sense. But I wonder if some of those suggestions decrease the strength of encryption? Perhaps there should be a paper that tells hardware makers how to create hardware to support some of these features that the cryptogaphers want. Or better yet, if the cryptographers could do whatever they want, but then somehoe make multiple versions of their algorithms that follow various subsets of these rules. Then list the drawbacks to using each one. Of course, this would probably create way too much work for those guys.
Re:What about the other side? (Score:2)
I missed a point. This is for existing hardware already deployed. Takes a bit of wind out of my comment. But still, for future hardware, why not something like that.
Re:What about the other side? (Score:4, Interesting)
Most modern cryptography is based on a variety of problems which are believed -- NOT known -- to be hard in certain contexts. Factoring, RSA, CDH, DDH, bilinear maps over CDH/DDH gap groups, braid factoring, CVP, etc. There are people who believe that factoring (and thus RSA) may be poly-time solvable, and thus cryptosystems based on it may be insecure. Cryptosystems based on different hard problems are important for that reason. It's a hedge bet.
There are also interesting things which come "for free" with certain types of hard problems, which may be very expensive to add on to more common cryptosystems. These properties, for example committment, are used in protocols like Deniable Ring Authentication. This sort of thing follows your suggestion of "a variety of rules", but it's really not possible to list every single cryptosystem in existance and how well it fits in. The authors simply say "(E,D) is a cryptosystem with the following properties", and leave anyone who wants to use it to find the best such cryptosystem, as it may change over time. (They usually do provide a trivial example or a reference, though)
Of course, if one-way functions don't exist, we'll all be back to information-theoretically secure stuff, and some of these problems will go away
Lea
for beginners i totally recommend this: (Score:3, Informative)
(http://www.amazon.com/exec/obidos/tg/detail/-/
excellent book on crypto and security basics. also contains basic concepts of avoiding general security issues.
nico
It is a great book. But... (Score:2)
That book is a nice read. One should know going into reading it that it is an ad for his company. I don't think Bruce saw it happening that way, but it did. I do think he's telling the truth as he sees it.
Sorry I can't give a black-and-white comment here.
It is still a great book.
Re:It is a great book. But... (Score:2)
It's intended for management types (though their lips will get tired by the end of it) but crypto-geeks and other propeller heads are about the only ones properly interested in the topic. If you find yourself running into blank looks when you try to explain that security is a "process, not a product" this might help.
Incidentally, the author contributed the deck of cards crypto system in "Cryptonomicon" Serious geek points for that!
Not just cryptlib (Score:2)
Top 5 reasons to use cryptography (Score:5, Funny)
5 -- At least your mom will think you're 1337
4 -- You need a BFS (Big Fucking pgp Sig) for all those blogs you waste your time on
3 -- To avoid letting the FBI know that Dear Matt, I you thought the last comp sci lab was hard and will probably just wait until Punjab Moltisontorilho hands his in and then we can steal his answers From Peter
2 -- Its geek factor will offset the fact that you still run Windows 95
... and the number 1 reason to use cryptography
1 -- Get that "terrorist feel" without all the violence
Copyright Eric Krout, Editor of *nix.org [starnix.org]
False advertising! (Score:5, Funny)
Kinda like steganography, but with flowers.
Now *that* would be news for nerds.
Re:False advertising! (Score:2)
Well Feb 14 is coming up.
Maybe that's not news for nerds tho
Re:False advertising! (Score:2)
Nothing too secret about that, though, I suppose.
Re:False advertising! (Score:1)
I think I remember something about in the past, way way in the past, when Japanese (I think) women weren't really allowed to talk/natter/gossip, they used to communicate with each other via flower arrangements.
Different flower have a number of different meanings, so a flower on its own probably didn't have much meaning (bar probably a single red rose -> love) but in an arrangement, their juxtaposition in relation to the other flowers and their meanings could allow those who knew the secrets to pass on messages.
I think it simply was a way passing messages back and forth between lovers who weren't supposed/allowed to talk to/acknowledge each other
Let me be the first to coin itfa2fap - flower arrangement to flower arrangement protocol.
Missing: PROVIDE TEST VECTORS! (Score:1)
This is very annoying for everybody who has to make an implementation from a paper, especially when the paper is new and there's no previous work on sci.crypt and the usual sources.
Follow the money (Score:2, Insightful)
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:Follow the money (Score:2)
Threshold cryptography is one of the easiest sells to banks. They all know about dual keys already from their safes, and the old Swift codebooks would come in two parts. However, if it isn't actual cash (say securities), it is remarkable how lax they are.
The fact is that a lot of advanced crypto is unsellable as it is. However, it may be used to improve an application to give it an edge the competition. The problems here lie not with fundemental cryptographic algorithms but with the implementations, especially the protocols.
Political problems just as complex (Score:2, Interesting)
The technical environment seems considerably less fuzzy to me than the political and regulatory environment. I have a hard time believing that amateur crypto development within the U.S. is virtually nonexistent, but if you go surfing for code and software, that seems to be the case. Do all amateur crypto people in the U.S. have to send emails off to crypt@bis.doc.gov and enc@ncsc.mil before they can talk to anyone?
Cryptography is a unique area of computing in that free speech rights don't fully apply. I'd love to be able to post my SHA-based symmetric encryption algorithm and app that even grandmoms can use to sci.crypt and ask many people much smarter than I how much of an idiot I am, but I don't know how to do that without jumping through a byzantine array of frightening federal hoops.
Re:Political problems just as complex (Score:2)
Incidently there is a formeral disclosure address that someone set up. I forget what it is, but the author send of an Email to the authorities and told them that he was running an archive. Otherwise, it isn't really a problem if it isn't a product (i.e., for free discussion purposes). If it is a commercial product then it is a little more complicated.