At 10:35 AM 12/19/00 -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.

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

You don't want to be on the bleeding edge of cryptography; you want to be on the calm, boring and stuffy edge. The bleeding edge is for academic mathematicians, not for people with high-importance security problems. You might want to be on the bleeding edge of firewalling and implementation - depends on your need for speed, number of locations you're supporting, and price-sensitivity. Unbreakable algorithms are easy, and have been for years. Triple DES or the newly certified Rijndael AES standard are both as strong as you need (if you're paranoid, stick to 3DES; Rijndael is newer, and while it's had just about everybody trying to crack it and survived, and the US NIST (and hence NSA) has certified it, newer isn't better in this business.) RC4 with 128-bit keys is also strong enough, if it's been implemented properly; if applied wrong, it fails badly, so make sure you're using a competent implementation. For public-key cryptosystems, either RSA or the Elliptic-Curve systems are strong enough, given sufficiently long keys, though the definition of "long enough" has grown by a few bits since then. 1024-bit RSA is fine for anything not involving decades of time or large numbers of dead bodies, but 2048 isn't hard either. For implementation, if you don't _really_ know what you're doing, and since you're asking about a good reading list, you don't, if this is for your business, you need to *hire* *somebody* who does know what they're doing, and you probably want them to buy commercial products backed by businesses with some development capital that will fix bugs and maintain stuff, and you need to look at the security of your processes. Because it doesn't matter how unbreakable your algorithms are if some insider has access to the router with the password written on a yellow sticky note, or if somebody can mail you a Microsoft Loves You virus that forwards your email inbox to kgb.com. At first glance, it sounds like your application probably calls for either Cisco routers using their IPSEC features (if your remote endpoints are big enough to use a router), or a Nortel or Cisco IPSEC box at your headquarters location with IPSEC client software running on your PCs or Linux boxes. But you haven't talked about network scale, speeds, sizes, number of locations, etc., so those are just generic guesses. Depending on what you're doing (user population, turnover, employees vs. customers, etc.), you may also want some kind of Public Key Infrastructure, or that may just be a bunch of bogus hype irrelevant to your needs. Another possible approach is PGP-encrypted email - PGP Inc. used to do gateway boxes that could forward and encrypt mail and enforce encryption policies; if they still do this, that may also be an answer. You could also see if SSH has anything to offer. The classic reading list on crypto starts with Bruce Schneier's Applied Cryptography, plus however much of it's 1000+ item bibliography makes sense for you. Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639

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@netbox.com PO Box 897 Oakland CA 94604

-----BEGIN PGP SIGNED MESSAGE----- On Tue, 19 Dec 2000, 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

If security is the utmost priority, you will not want "bleeding-edge" cryptography. You will want algorithms that have been tried and tested in the field already, and have not shown weaknesses. You will also want to use existing solutions, such as TLS, PGP, etc., if these will serve your needs. Developing new solutions to solved problems is not usually productive. If your interest is in deploying a system quickly, you will probably want to hire an independent consultant with background in email security. You may wish to have someone design the system architecture, detailing plans for implementation of all the necessary components to address your needs. Then you can build according to his or her spec in house. - -MW- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (GNU/Linux) Comment: No comment. iQEVAwUBOkL7NSsFU3q6vVI9AQHCtwgArBg5CizLz/v8eIZVVI0bcC1SkJBZDUSl vKP6lTDzIET042LaSHQXpdgLhcXfP/8iayjjdZPhuaEYap0zj+6NWjgF0qFAU5D/ 4nr6/Y8GCG2b9hJ2VY6s+jEXuSRjzkHKxKdOf1+Dz61+Eub5pBYEsOjaSbWygMy0 1sK+RjNXL1W8/ZmrgGNhLGoD/LZAowrvOiyi7mQZQLjvbFVYOvIaY1zT3u/3T9ga DRWrNpaUK/Qndj7KUptBouFu0CfYopRl+R8d3LuDW5XyO86Z+pPDZHXxYN0MOeYl gKgM3VX3/tu8jfMNpWHJEjHOK4b/QStEI31IiclWHlgP0tovjxDKMA== =E1c9 -----END PGP SIGNATURE-----