Crypto questions

Greg Broiles gbroiles at netbox.com
Tue Dec 19 22:23:02 PST 2000


On Tue, Dec 19, 2000 at 10:35:58AM -0500, Scoville, Chad wrote:
> 
> I've been actively reading posts on this list for about two years now, and
> I'm in he process of actually trying to design/implement a data network
> where security is of the utmost priority. Where is a good starting point to
> find out about packages using algorithms which are unbreakable as of yet.
> All of the traffic will remain domestically within the US. The traffic will
> be SMTP.

Several points come to mind -

"Unbreakable" algorithms are mostly a distraction. What's important is the
relationship between the cost of breaking them and the value of the data
you're protecting. Less familiar algorithms (like the new AES selection)
may sound exciting - their relative newness means that there aren't a lot
of known attacks or weaknesses, which is good and bad at the same time.
It's good because nobody can ambush you in a meeting by waving a copy
of a 10-year-old journal article discussing an obscure failure mode for
that algorithm/protocol. It's bad because you may install an expensive
system and then get ambushed with a journal article (or an exploit)
that hasn't even been thought of yet.

Still, attackers aren't likely to attack the strong part of your system,
they'll attack the weak part - so you can't really say "Well, I've got
4096-bit Blortifast, I'm safe", until you've secured the machines which
will run the system, the buildings they're in, and the people who run the
machines and the buildings. Even if a slow reference implementation of
your chosen algortithm is only vulnerable to brute-force cracks, you
can't assume that your implementation as installed is also that secure -
there may be implementation failures on the part of developers, installers,
administrators, or users which weaken security. 

I'd rather have a bulletproof DES implementation than an imperfect 3DES
implementation - with a known quantity, I can handle risks myself by
getting extra protection (like superencryption) or by not sending really
sensitive data. Hidden failures in apparently strong implementations trick
you into a false sense of security.

The other thing to consider is that even if you succeed in installing a
perfectly secure pipeline between two systems or locations, your 
organization (or your client's organization) hasn't necessarily met their
goals - you mention that you want to protect SMTP traffic. That's a good
goal - but you didn't mention making sure that the sender-side has good
security with its clients, or that the receiver-side has good security
with its clients .. which means that even if the SMTP boxes are themselves
secure, and the network connection between them is secure (and that's a
very generous assumption), the installation won't be secure from a user or
auditor's perspective if unauthorized people have access to the client
connections on either side to monitor or spoof in-bound and out-bound
mail traffic (via SMTP, POP, or IMAP). Securing communications with
clients - not just between mail servers - is somewhere between hard and
impossible, depending on how many people you're thinking of, and the
degree of security.

Some people have chosen to secure messages, not pipelines between 
machines, because then their security doesn't depend so much on the
integrity of the machines in between - they're still susceptible to
denial-of-service or replay attacks, but it's unlikely that the 
confidentiality or attribution of messages will be breached.

Having said all of that grouchy stuff, you probably won't get a lot safer
than picking a good IPsec implementation from a big vendor and keeping
its patches current - no need to dig into the guts of what protocol(s)
you're using. (Beyond that, you're working with political and financial
constraints, not primarily technical ones. If this were my problem, I'd
use OpenBSD on COTS PC hardware - but that's me.) 

> It would be illmatic if someone could reccomend a good reading list
> (current) on the bleeding edge of cryptography.

Have you joined the IACR? 

You also might find Schneier's _Secrets and Lies_ thought-provoking; I
think he's too pessimistic (which makes up for Applied Crypto's
excessive optimism) but it is certainly useful, and overdue. 
_Network Security_ by Kaufman, Perlman, and Speciner is not bleeding-
edge but is absolutely worthy of your attention anyway.

--
Greg Broiles gbroiles at netbox.com
PO Box 897
Oakland CA 94604





More information about the cypherpunks-legacy mailing list