|
From: Joe Pluta <joepluta@PlutaBrothers.com> > How does this apply to the conversation? More importantly, how does it > help? It's a nice quote, but not particularly helpful. > > Are you saying proprietary protocols are NOT more secure than published > protocols? Or are you saying that there is a protocol that matches the > analogy Mr. Schneier uses? If so, what is it, and how easy is it to > implement? Rather than tell me what you DON'T like about my approach, tell > me what yours is. > > Criticism without alternative, especially second-hand criticism, is > intellectually lazy, and I expect better from you, Leif. > > Joe > Being intellectually lazy, I'll answer first with yet another second-hand quote (at least I'm into re-use here): Since it is difficult to design good security, and since this is very expensive, a lot of work has been done recently to try to standardize security. Even as I speak the International Standards Organization is meeting to decide on this very issue. Since there is a lot of confusion on this point I have been asked to make the position clear. The purpose of language is to convey information. This only works if both sender and receiver of information both use the same system. In other words, language only works precisely because it is standardized. The purpose of cryptography on the other hand is to make the message unintelligible except to one person. In other words cryptography only works precisely because it is NOT standardized. So what they do is to make most of the cipher standardized, and to concentrate the non-standardization into one part called the key. So far so good. But of course the key, the non-standardized part, must be nonstandard in only standardized ways. And also key management must conform to certain standards. In other words standards are being formulated whereby the nonstandard parts, which must conform to certain standards of non-standardization are also to be handled only in a standardized nonstandard way in order to standardize on the overall non-standardization. John Gordon http://www.conceptlabs.co.uk/alicebob.html ======> but, (and this is me now, not second-hand or anything less than what one might expect of me) I think that a well-designed and well-documented proprietary protocol is good because it lets you retain control over your application, not because it is used as a substitute for active security measures. One can combine the proprietary protocol with strong security: use of e.g. AES, use of good sources of entropy, etc. Such use, of course, depending on the specific requirement for security. Using an AS/400 is already a step in the right direction all in itself. Now, you can easily nullify that advantage by having e.g. a 3-tier application: Windoze <-> Micro$oft server <-> As/400 unless you build in your own security. > > > From: Joe Pluta <joepluta@PlutaBrothers.com> > > > > > As the script kiddies get more sophisticated, Leif, I think you > > need both > > > strong network policy procedures and proprietary protocols > > > > To quote Bruce Schneier (Preface to Applied Cryptography): > > > > "If I take a letter, lock it in a safe, hide the safe somewhere > > in New York, > > then tell you to read the letter, that's not security. That's obscurity. > > On the other hand, if I take a letter and lock it in a safe, and then > > give you the safe along with the design specifications of the safe > > and a hundred identical safes with their combinations so that you > > and the world's best safecrackers can study the locking mechanism > > - and you still can't open the safe and read the letter - that's > > security." > > > > Just make sure that having a proprietary protocol (which has other > > problems such as finding people to maintain it after you are gone) > > does not become a convenient "pillow of complacency". >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.