crypto for the average programmer

[leichter_jerrold at emc.com]

On Mon, 12 Dec 2005, Steve Furlong wrote:
| > My question is, what is the layperson supposed to do, if they must use
| > crypto and can't use an off-the-shelf product?
| 
| When would that be the case?
| 
| The only defensible situations I can think of in which a
| non-crypto-specialist programmer would need to write crypto routines
| would be an uncommon OS or hardware, or a new or rare programming
| language which doesn't have libraries available from SourceForge etc.
| Or maybe implementing an algorithm that's new enough it doesn't have a
| decent free implementation, but I'm not sure such an algorithm should
| be used in production code.
I can tell you a situation that applied in one system I worked on:  You
could 
go with SSL, which gets you into GPL'ed code, not to mention the known
complexities of using the SSL libraries correctly (steep learning curve); or

we could go commercial code that had fairly steep license fees.  The
decision 
was to use off-the-shelf where completely unencumbered (e.g., Gladman's AES 
implementation), build the rest ourselves.

BTW, there are other issues with SSL.  We needed to fit this implementation
in 
to an already-running system with minimal effect - but try to get people to 
use it.  Having to get certificates for SSL was a big hurdle.  Even creating

self-signed certs was a hassle.  The existing code ran directly over TCP,
and 
assumed a byte stream.  SSL is record-oriented.  This shows up, for example,
when your 1-byte ACK (of which we send many) turns into a 32-byte block (or 
even larger).

We weren't interested in "complete" security - we just needed to raise the 
level considerably.  Given the nature of the application, message 
authentication was not *that* big a deal - it could be put off.

SSL is a fine protocol, and on theoretical terms, yes, you probably want 
everything it provides.  But in practice it's too much.

BTW, there are some interesting "social" issues.  Before we implemented our 
own crypto layer, we recommended people go through ssh tunnels.  The product

was set up to allow that.  I made the argument "Do you really want us to 
provide your crypto?  We're not crypto experts.  But this was perceived as 
clunky, complicated ... it didn't make it look as if the *product*.  Those 
factors were ultimately seen as more important than the very highest level
of 
security.  You can *still* use ssh, of course....  (In fact, I was in a 
discussion with a military contractor who wanted to use the product.  The 
question came up of exactly how our crypto worked, whether it would be 
approvable for their application, etc.  My comment was:  Isn't NSA providing

you guys with encrypted links anyway?  Answer - sure, you're right; we don't

need to do application-level encryption.  If IPSEC were actually out there,
all sorts of nasty issues would just magically go away.)

							-- Jerry


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com