Cryptography-Digest Digest #480
Cryptography-Digest Digest #480, Volume #10 Mon, 1 Nov 99 07:13:04 EST
Contents:
Re: Doesn't Bruce Schneier practice what he preaches? ("Adam Durana")
Re: Newly Encountered Crypto System
Boring Web Site and Kerberos News
Re: MBR / FAT encryption (Dave Hazelwood)
Re: Doesn't Bruce Schneier practice what he preaches? (Scott Fluhrer)
Re: Doesn't Bruce Schneier practice what he preaches?
Re: Proposal: Inexpensive Method of "True Random Data" Generation (David Bernier)
Re: Symetric cipher ("Douglas A. Gwyn")
Re: Bruce Schneier's Crypto Comments on Slashdot ("Rick Braddam")
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: the ACM full of Dolts? (SCOTT19U.ZIP_GUY)
Cryptography FAQ (01/10: Overview) ([EMAIL PROTECTED])
Cryptography FAQ (02/10: Net Etiquette) ([EMAIL PROTECTED])
From: "Adam Durana" [EMAIL PROTECTED]
Subject: Re: Doesn't Bruce Schneier practice what he preaches?
Date: Sun, 31 Oct 1999 22:18:34 -0500
Hi,
I think you guys are missing the real point Schneier was trying to get
across. He was not saying give out the source code to your software, he was
saying that the encryption methods used in your software should be public.
You have to trust that the designers and coders of the software correctly
implemented it. Thats a lot of trust to put in someone, but you can test
the software to make sure it is correctly implemented in most cases. (Test
vectors?) There is a great deal of software that uses secret methods and
there is no way to tell if it is secure, until someone breaks it or reverse
engineers it. What Schneier was saying is that the encryption methods used
in software should be public, because the strength of a method should rest
in itself, not in its obsurcity.
-- Adam Durana
--
From: [EMAIL PROTECTED] ()
Subject: Re: Newly Encountered Crypto System
Date: 1 Nov 99 03:25:50 GMT
John Kennedy ([EMAIL PROTECTED]) wrote:
: It's a pure snake-oil pitch, obviously.
Well, it has *one* difference from the usual snake-oil pitch.
There are as yet no details on how to get in contact with this reclusive
eccentric who has produced an unbreakable cipher that breaks all the
rules.
Shall we call it a snake-oil teaser? And the description of A.N.E.C.
sounds hauntingly familiar, but web and news searches turn up nothing.
John Savard
--
From: [EMAIL PROTECTED] ()
Subject: Boring Web Site and Kerberos News
Date: 1 Nov 99 03:27:01 GMT
Yes, I *finally* broke down and dashed off a page that actually *says*
something about Kerberos for my web site.
John Savard
--
From: [EMAIL PROTECTED] (Dave Hazelwood)
Subject: Re: MBR / FAT encryption
Date: Mon, 01 Nov 1999 01:39:23 GMT
Sounds like win thinks your handler is managing those drives but
it is not so it drops them.
Go here and get secdr14a.zip (the one by Edgar Swank) and try
it out. See if you still lose your other drives. All source is
included.
I used to work with Edgar at IBM and he has written a number
of useful tools.
Like what?
This is what I did: I implemented complete disk encryption (except
the very first track, where the MBR resides), and a decryption
algorithm stored in the MBR (and a few more sectors, since all didn't
fit within one sector). Encrypting the disk using this worked fine
on plain DOS and Win 3.x. On Win-95 it worked too, but disk access
reverted back to 13-bit compatibility mode -- and I also lost access
to the IDE CD-ROM. Next, I implemented a Win-95 VSD (a VxD for block
device drivers on WIn-95) which performed the encryption in 32-bit
protected mode. WHen this VSD loaded, disk access was all 32-bit --
and I also got my lost IDE CD-ROM back.
--
From: Scott Fluhrer [EMAIL PROTECTED]
Subject: Re: Doesn't Bruce Schneier practice what he preaches?
Date: Mon, 01 Nov 1999 04:57:51 GMT
In article oE7T3.2615$[EMAIL PROTECTED],
"Adam Durana" [EMAIL PROTECTED] wrote:
Hi,
I think you guys are missing the real point Schneier was trying to get
across. He was not saying give out the source code to your software, he was
saying that the encryption methods used in your software should be public.
You have to trust that the designers and coders of the software correctly
implemented it. Thats a lot of trust to put in someone, but you can test
the software to make sure it is correctly implemented in most cases. (Test
vectors?) There is a great deal of software that uses secret methods and
there is no way to tell if it is secure, until someone breaks it or reverse
engineers it. What Schneier was saying is that the encryption methods used
in software should be public, because the strength of a method should rest
in itself, not in its obsurcity.
If that's all Schneier meant, then he's wrong. Just knowing the algorithms
used is not enough. You have to know that they were put
Cryptography-Digest Digest #481
Cryptography-Digest Digest #481, Volume #10 Mon, 1 Nov 99 07:13:04 EST Contents: Cryptography FAQ (03/10: Basic Cryptology) ([EMAIL PROTECTED]) Cryptography FAQ (04/10: Mathematical Cryptology) ([EMAIL PROTECTED]) From: [EMAIL PROTECTED] Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers Subject: Cryptography FAQ (03/10: Basic Cryptology) Date: 1 Nov 1999 11:28:27 GMT Reply-To: [EMAIL PROTECTED] Archive-name: cryptography-faq/part03 Last-modified: 93/10/10 This is the third of ten parts of the sci.crypt FAQ. The parts are mostly independent, but you should read the first part before the rest. We don't have the time to send out missing parts by mail, so don't ask. Notes such as ``[KAH67]'' refer to the reference list in the last part. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, sci.answers, and news.answers every 21 days. Contents: 3.1. What is cryptology? Cryptography? Plaintext? Ciphertext? Encryption? Key? 3.2. What references can I start with to learn cryptology? 3.3. How does one go about cryptanalysis? 3.4. What is a brute-force search and what is its cryptographic relevance? 3.5. What are some properties satisfied by every strong cryptosystem? 3.6. If a cryptosystem is theoretically unbreakable, then is it guaranteed analysis-proof in practice? 3.7. Why are many people still using cryptosystems that are relatively easy to break? 3.8. What are the basic types of cryptanalytic `attacks'? 3.1. What is cryptology? Cryptography? Plaintext? Ciphertext? Encryption? Key? The story begins: When Julius Caesar sent messages to his trusted acquaintances, he didn't trust the messengers. So he replaced every A by a D, every B by a E, and so on through the alphabet. Only someone who knew the ``shift by 3'' rule could decipher his messages. A cryptosystem or cipher system is a method of disguising messages so that only certain people can see through the disguise. Cryptography is the art of creating and using cryptosystems. Cryptanalysis is the art of breaking cryptosystems---seeing through the disguise even when you're not supposed to be able to. Cryptology is the study of both cryptography and cryptanalysis. The original message is called a plaintext. The disguised message is called a ciphertext. Encryption means any procedure to convert plaintext into ciphertext. Decryption means any procedure to convert ciphertext into plaintext. A cryptosystem is usually a whole collection of algorithms. The algorithms are labelled; the labels are called keys. For instance, Caesar probably used ``shift by n'' encryption for several different values of n. It's natural to say that n is the key here. The people who are supposed to be able to see through the disguise are called recipients. Other people are enemies, opponents, interlopers, eavesdroppers, or third parties. 3.2. What references can I start with to learn cryptology? For an introduction to technical matter, the survey articles given in part 10 are the best place to begin as they are, in general, concise, authored by competent people, and well written. However, these articles are mostly concerned with cryptology as it has developed in the last 50 years or so, and are more abstract and mathematical than historical. The Codebreakers by Kahn [KAH67] is encyclopedic in its history and technical detail of cryptology up to the mid-60's. Introductory cryptanalysis can be learned from Gaines [GAI44] or Sinkov [SIN66]. This is recommended especially for people who want to devise their own encryption algorithms since it is a common mistake to try to make a system before knowing how to break one. The selection of an algorithm for the DES drew the attention of many public researchers to problems in cryptology. Consequently several textbooks and books to serve as texts have appeared. The book of Denning [DEN82] gives a good introduction to a broad range of security including encryption algorithms, database security, access control, and formal models of security. Similar comments apply to the books of Price Davies [PRI84] and Pfleeger [PFL89]. The books of Konheim [KON81] and Meyer Matyas [MEY82] are quite technical books. Both Konheim and Meyer were directly involved in the development of DES, and both books give a thorough analysis of DES. Konheim's book is quite mathematical, with detailed analyses of many classical cryptosystems. Meyer and Matyas concentrate on modern cryptographic methods, especially pertaining to key management and the integration of security facilities into computer systems and networks. For more recent documentation on related areas, try G. Simmons in [SIM91].
Cryptography-Digest Digest #482
Cryptography-Digest Digest #482, Volume #10 Mon, 1 Nov 99 07:13:04 EST
Contents:
Cryptography FAQ (05/10: Product Ciphers) ([EMAIL PROTECTED])
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers
Subject: Cryptography FAQ (05/10: Product Ciphers)
Date: 1 Nov 1999 11:28:38 GMT
Reply-To: [EMAIL PROTECTED]
Archive-name: cryptography-faq/part05
Last-modified: 94/06/07
This is the fifth of ten parts of the sci.crypt FAQ. The parts are
mostly independent, but you should read the first part before the rest.
We don't have the time to send out missing parts by mail, so don't ask.
Notes such as ``[KAH67]'' refer to the reference list in the last part.
The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu
as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography
FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto,
sci.answers, and news.answers every 21 days.
Contents:
5.1. What is a product cipher?
5.2. What makes a product cipher secure?
5.3. What are some group-theoretic properties of product ciphers?
5.4. What can be proven about the security of a product cipher?
5.5. How are block ciphers used to encrypt data longer than the block size?
5.6. Can symmetric block ciphers be used for message authentication?
5.7. What exactly is DES?
5.8. What is triple DES?
5.9. What is differential cryptanalysis?
5.10. How was NSA involved in the design of DES?
5.11. Is DES available in software?
5.12. Is DES available in hardware?
5.13. Can DES be used to protect classified information?
5.14. What are ECB, CBC, CFB, OFB, and PCBC encryption?
5.1. What is a product cipher?
A product cipher is a block cipher that iterates several weak
operations such as substitution, transposition, modular
addition/multiplication, and linear transformation. (A ``block
cipher'' just means a cipher that encrypts a block of data---8 bytes,
say---all at once, then goes on to the next block.) The notion of
product ciphers is due to Shannon [SHA49]. Examples of modern
product ciphers include LUCIFER [SOR84], DES [NBS77], SP-networks
[KAM78], LOKI [BRO90], FEAL [SHI84], PES [LAI90], Khufu and Khafre
[ME91a]. The so-called Feistel ciphers are a class of product
ciphers which operate on one half of the ciphertext at each round,
and then swap the ciphertext halves after each round. LUCIFER,
DES, LOKI, and FEAL are examples of Feistel ciphers.
The following table compares the main parameters of several product
ciphers:
cipher | block length | key bits | number of rounds
LUCIFER 128 12816
DES 645616
LOKI 646416
FEAL 64 1282^x, x = 5
PES 64 128 8
5.2. What makes a product cipher secure?
Nobody knows how to prove mathematically that a product cipher is
completely secure. So in practice one begins by demonstrating that the
cipher ``looks highly random''. For example, the cipher must be
nonlinear, and it must produce ciphertext which functionally depends
on every bit of the plaintext and the key. Meyer [MEY78] has shown
that at least 5 rounds of DES are required to guarantee such a
dependence. In this sense a product cipher should act as a ``mixing''
function which combines the plaintext, key, and ciphertext in a
complex nonlinear fashion.
The fixed per-round substitutions of the product cipher are
referred to as S-boxes. For example, LUCIFER has 2 S-boxes, and DES
has 8 S-boxes. The nonlinearity of a product cipher reduces to a
careful design of these S-boxes. A list of partial design criteria
for the S-boxes of DES, which apply to S-boxes in general, may be
found in Brown [BRO89] and Brickell et al. [BRI86].
5.3. What are some group-theoretic properties of product ciphers?
Let E be a product cipher that maps N-bit blocks to N-bit blocks.
Let E_K(X) be the encryption of X under key K. Then, for any fixed K,
the map sending X to E_K(X) is a permutation of the set of N-bit
blocks. Denote this permutation by P_K. The set of all N-bit
permutations is called the symmetric group and is written S_{2^N}.
The collection of all these permutations P_K, where K ranges over all
possible keys, is denoted E(S_{2^N}). If E were a random mapping from
plaintexts to ciphertexts then we would expect E(S_{2^N}) to generate
a large subset of S_{2^N}.
Coppersmith and Grossman [COP74] have shown that a very simple
product cipher can generate the alternating group A_{2^N} given a
sufficient number of rounds. (The alternating group is half of the
symmetric group: it consists of all ``even'' permutations, i.e., all
permutations which can be written as an even number of
Cryptography-Digest Digest #483
Cryptography-Digest Digest #483, Volume #10 Mon, 1 Nov 99 07:13:04 EST Contents: Cryptography FAQ (06/10: Public Key Cryptography) ([EMAIL PROTECTED]) Cryptography FAQ (07/10: Digital Signatures) ([EMAIL PROTECTED]) From: [EMAIL PROTECTED] Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers Subject: Cryptography FAQ (06/10: Public Key Cryptography) Date: 1 Nov 1999 11:28:42 GMT Reply-To: [EMAIL PROTECTED] Archive-name: cryptography-faq/part06 Last-modified: 94/06/07 This is the sixth of ten parts of the sci.crypt FAQ. The parts are mostly independent, but you should read the first part before the rest. We don't have the time to send out missing parts by mail, so don't ask. Notes such as ``[KAH67]'' refer to the reference list in the last part. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, sci.answers, and news.answers every 21 days. Contents: 6.1. What is public-key cryptography? 6.2. How does public-key cryptography solve cryptography's Catch-22? 6.3. What is the role of the `trapdoor function' in public key schemes? 6.4. What is the role of the `session key' in public key schemes? 6.5. What's RSA? 6.6. Is RSA secure? 6.7. What's the difference between the RSA and Diffie-Hellman schemes? 6.8. What is `authentication' and the `key distribution problem'? 6.9. How fast can people factor numbers? 6.10. What about other public-key cryptosystems? 6.11. What is the `RSA Factoring Challenge?' 6.1. What is public-key cryptography? In a classic cryptosystem, we have encryption functions E_K and decryption functions D_K such that D_K(E_K(P)) = P for any plaintext P. In a public-key cryptosystem, E_K can be easily computed from some ``public key'' X which in turn is computed from K. X is published, so that anyone can encrypt messages. If decryption D_K cannot be easily computed from public key X without knowledge of private key K, but readily with knowledge of K, then only the person who generated K can decrypt messages. That's the essence of public-key cryptography, introduced by Diffie and Hellman in 1976. This document describes only the rudiments of public key cryptography. There is an extensive literature on security models for public-key cryptography, applications of public-key cryptography, other applications of the mathematical technology behind public-key cryptography, and so on; consult the references at the end for more refined and thorough presentations. 6.2. How does public-key cryptography solve cryptography's Catch-22? In a classic cryptosystem, if you want your friends to be able to send secret messages to you, you have to make sure nobody other than them sees the key K. In a public-key cryptosystem, you just publish X, and you don't have to worry about spies. Hence public key cryptography `solves' one of the most vexing problems of all prior cryptography: the necessity of establishing a secure channel for the exchange of the key. To establish a secure channel one uses cryptography, but private key cryptography requires a secure channel! In resolving the dilemma, public key cryptography has been considered by many to be a `revolutionary technology,' representing a breakthrough that makes routine communication encryption practical and potentially ubiquitous. 6.3. What is the role of the `trapdoor function' in public key schemes? Intrinsic to public key cryptography is a `trapdoor function' D_K with the properties that computation in one direction (encryption, E_K) is easy and in the other is virtually impossible (attack, determining P from encryption E_K(P) and public key X). Furthermore, it has the special property that the reversal of the computation (decryption, D_K) is again tractable if the private key K is known. 6.4. What is the role of the `session key' in public key schemes? In virtually all public key systems, the encryption and decryption times are very lengthy compared to other block-oriented algorithms such as DES for equivalent data sizes. Therefore in most implementations of public-key systems, a temporary, random `session key' of much smaller length than the message is generated for each message and alone encrypted by the public key algorithm. The message is actually encrypted using a faster private key algorithm with the session key. At the receiver side, the session key is decrypted using the public-key algorithms and the recovered `plaintext' key is used to decrypt the message. The session key approach blurs the distinction between `keys' and `messages' -- in the scheme, the message includes the key, and the key itself is treated as an encryptable `message'.
Cryptography-Digest Digest #484
Cryptography-Digest Digest #484, Volume #10 Mon, 1 Nov 99 07:13:04 EST Contents: Cryptography FAQ (08/10: Technical Miscellany) ([EMAIL PROTECTED]) Cryptography FAQ (09/10: Other Miscellany) ([EMAIL PROTECTED]) From: [EMAIL PROTECTED] Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers Subject: Cryptography FAQ (08/10: Technical Miscellany) Date: 1 Nov 1999 11:28:51 GMT Reply-To: [EMAIL PROTECTED] Archive-name: cryptography-faq/part08 Last-modified: 94/01/25 This is the eighth of ten parts of the sci.crypt FAQ. The parts are mostly independent, but you should read the first part before the rest. We don't have the time to send out missing parts by mail, so don't ask. Notes such as ``[KAH67]'' refer to the reference list in the last part. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, sci.answers, and news.answers every 21 days. Contents 8.1. How do I recover from lost passwords in WordPerfect? 8.2. How do I break a Vigenere (repeated-key) cipher? 8.3. How do I send encrypted mail under UNIX? [PGP, RIPEM, PEM, ...] 8.4. Is the UNIX crypt command secure? 8.5. How do I use compression with encryption? 8.6. Is there an unbreakable cipher? 8.7. What does ``random'' mean in cryptography? 8.8. What is the unicity point (a.k.a. unicity distance)? 8.9. What is key management and why is it important? 8.10. Can I use pseudo-random or chaotic numbers as a key stream? 8.11. What is the correct frequency list for English letters? 8.12. What is the Enigma? 8.13. How do I shuffle cards? 8.14. Can I foil S/W pirates by encrypting my CD-ROM? 8.15. Can you do automatic cryptanalysis of simple ciphers? 8.16. What is the coding system used by VCR+? 8.1. How do I recover from lost passwords in WordPerfect? WordPerfect encryption has been shown to be very easy to break. The method uses XOR with two repeating key streams: a typed password and a byte-wide counter initialized to 1+the password length. Full descriptions are given in Bennett [BEN87] and Bergen and Caelli [BER91]. Chris Galas writes: ``Someone awhile back was looking for a way to decrypt WordPerfect document files and I think I have a solution. There is a software company named: Accessdata (87 East 600 South, Orem, UT 84058), 1-800-658-5199 that has a software package that will decrypt any WordPerfect, Lotus 1-2-3, Quatro-Pro, MS Excel and Paradox files. The cost of the package is $185. Steep prices, but if you think your pw key is less than 10 characters, (or 10 char) give them a call and ask for the free demo disk. The demo disk will decrypt files that have a 10 char or less pw key.'' Bruce Schneier says the phone number for AccessData is 801-224-6970. 8.2. How do I break a Vigenere (repeated-key) cipher? A repeated-key cipher, where the ciphertext is something like the plaintext xor KEYKEYKEYKEY (and so on), is called a Vigenere cipher. If the key is not too long and the plaintext is in English, do the following: 1. Discover the length of the key by counting coincidences. (See Gaines [GAI44], Sinkov [SIN66].) Trying each displacement of the ciphertext against itself, count those bytes which are equal. If the two ciphertext portions have used the same key, something over 6% of the bytes will be equal. If they have used different keys, then less than 0.4% will be equal (assuming random 8-bit bytes of key covering normal ASCII text). The smallest displacement which indicates an equal key is the length of the repeated key. 2. Shift the text by that length and XOR it with itself. This removes the key and leaves you with text XORed with itself. Since English has about 1 bit of real information per byte, 2 streams of text XORed together has 2 bits of info per 8-bit byte, providing plenty of redundancy for choosing a unique decryption. (And in fact one stream of text XORed with itself has just 1 bit per byte.) If the key is short, it might be even easier to treat this as a standard polyalphabetic substitution. All the old cryptanalysis texts show how to break those. It's possible with those methods, in the hands of an expert, if there's only ten times as much text as key. See, for example, Gaines [GAI44], Sinkov [SIN66]. 8.3. How do I send encrypted mail under UNIX? [PGP, RIPEM, PEM, ...] Here's one popular method, using the des command: cat file | compress | des private_key | uuencode | mail Meanwhile, there is a de jure Internet standard in the works called PEM (Privacy Enhanced Mail). It is described in RFCs 1421 through 1424. To join the PEM mailing list, contact [EMAIL PROTECTED] There is a beta version of PEM being tested at the time of this writing. There are also two
Cryptography-Digest Digest #485
Cryptography-Digest Digest #485, Volume #10 Mon, 1 Nov 99 07:13:04 EST Contents: Cryptography FAQ (10/10: References) ([EMAIL PROTECTED]) From: [EMAIL PROTECTED] Crossposted-To: talk.politics.crypto,sci.answers,news.answers,talk.answers Subject: Cryptography FAQ (10/10: References) Date: 1 Nov 1999 11:28:57 GMT Reply-To: [EMAIL PROTECTED] Archive-name: cryptography-faq/part10 Last-modified: 94/06/13 This is the tenth of ten parts of the sci.crypt FAQ. The parts are mostly independent, but you should read the first part before the rest. We don't have the time to send out missing parts by mail, so don't ask. Notes such as ``[KAH67]'' refer to the reference list in this part. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, sci.answers, and news.answers every 21 days. Contents 10.1. Books on history and classical methods 10.2. Books on modern methods 10.3. Survey articles 10.4. Reference articles 10.5. Journals, conference proceedings 10.6. Other 10.7. How may one obtain copies of FIPS and ANSI standards cited herein? 10.8. Electronic sources 10.9. RFCs (available from [FTPRF]) 10.10. Related newsgroups 10.1. Books on history and classical methods [FRIE1] Lambros D. Callimahos, William F. Friedman, Military Cryptanalytics. Aegean Park Press, ?. [DEA85] Cipher A. Deavours Louis Kruh, Machine Cryptography and Modern Cryptanalysis. Artech House, 610 Washington St., Dedham, MA 02026, 1985. [FRIE2] William F. Friedman, Solving German Codes in World War I. Aegean Park Press, ?. [GAI44] H. Gaines, Cryptanalysis, a study of ciphers and their solution. Dover Publications, 1944. [HIN00] F.H.Hinsley, et al., British Intelligence in the Second World War. Cambridge University Press. (vol's 1, 2, 3a, 3b 4, so far). XXX Years and authors, fix XXX [HOD83] Andrew Hodges, Alan Turing: The Enigma. Burnett Books Ltd., 1983 [KAH91] David Kahn, Seizing the Enigma. Houghton Mifflin, 1991. [KAH67] D. Kahn, The Codebreakers. Macmillan Publishing, 1967. [history] [The abridged paperback edition left out most technical details; the original hardcover edition is recommended.] [KOZ84] W. Kozaczuk, Enigma. University Publications of America, 1984 [KUL76] S. Kullback, Statistical Methods in Cryptanalysis. Aegean Park Press, 1976. [SIN66] A. Sinkov, Elementary Cryptanalysis. Math. Assoc. Am. 1966. [WEL82] Gordon Welchman, The Hut Six Story. McGraw-Hill, 1982. [YARDL] Herbert O. Yardley, The American Black Chamber. Aegean Park Press, ?. 10.2. Books on modern methods [BEK82] H. Beker, F. Piper, Cipher Systems. Wiley, 1982. [BRA88] G. Brassard, Modern Cryptology: a tutorial. Spinger-Verlag, 1988. [DEN82] D. Denning, Cryptography and Data Security. Addison-Wesley Publishing Company, 1982. [KOB89] N. Koblitz, A course in number theory and cryptography. Springer-Verlag, 1987. [KON81] A. Konheim, Cryptography: a primer. Wiley, 1981. [MEY82] C. Meyer and S. Matyas, Cryptography: A new dimension in computer security. Wiley, 1982. [PAT87] Wayne Patterson, Mathematical Cryptology for Computer Scientists and Mathematicians. Rowman Littlefield, 1987. [PFL89] C. Pfleeger, Security in Computing. Prentice-Hall, 1989. [PRI84] W. Price, D. Davies, Security for computer networks. Wiley, 1984. [RUE86] R. Rueppel, Design and Analysis of Stream Ciphers. Springer-Verlag, 1986. [SAL90] A. Saloma, Public-key cryptography. Springer-Verlag, 1990. [SCH94] B. Schneier, Applied Cryptography. John Wiley Sons, 1994. [errata avbl from [EMAIL PROTECTED]] [WEL88] D. Welsh, Codes and Cryptography. Claredon Press, 1988. 10.3. Survey articles [ANG83] D. Angluin, D. Lichtenstein, Provable Security in Crypto- systems: a survey. Yale University, Department of Computer Science, #288, 1983. [BET90] T. Beth, Algorithm engineering for public key algorithms. IEEE Selected Areas of Communication, 1(4), 458--466, 1990. [DAV83] M. Davio, J. Goethals, Elements of cryptology. in Secure Digital Communications, G. Longo ed., 1--57, 1983. [DIF79] W. Diffie, M. Hellman, Privacy and Authentication: An introduction to cryptography. IEEE proceedings, 67(3), 397--427, 1979. [DIF88] W. Diffie, The first ten years of public key cryptography. IEEE proceedings, 76(5), 560--577, 1988. [FEI73] H. Feistel, Cryptography and Computer Privacy. Scientific American, 228(5), 15--23, 1973. [FEI75] H. Feistel, H, W. Notz, J. Lynn Smith. Some cryptographic techniques for
Cryptography-Digest Digest #486
Cryptography-Digest Digest #486, Volume #10 Mon, 1 Nov 99 13:13:03 EST Contents: Notes on Substitutions (Mok-Kong Shen) Re: Build your own one-on-one compressor (Mok-Kong Shen) Re: the ACM full of Dolts? (Mok-Kong Shen) Re: Build your own one-on-one compressor (Mok-Kong Shen) Re: Newly Encountered Crypto System (John Kennedy) Re: Doesn't Bruce Schneier practice what he preaches? (Larry Kilgallen) Re: Re: announcement: steganography program "steghide" (CoyoteRed) Re: Doesn't Bruce Schneier practice what he preaches? (SCOTT19U.ZIP_GUY) Re: Doesn't Bruce Schneier practice what he preaches? (SCOTT19U.ZIP_GUY) Re: Doesn't Bruce Schneier practice what he preaches? (SCOTT19U.ZIP_GUY) Re: the ACM full of Dolts? (SCOTT19U.ZIP_GUY) Re: Build your own one-on-one compressor (Tim Tyler) From: Mok-Kong Shen [EMAIL PROTECTED] Subject: Notes on Substitutions Date: Mon, 01 Nov 1999 12:25:02 +0100 The now classsical polyalphabetical substitution uses a key to choose from a set of (in the general case independent, i.e. not merely rotated or Vigenere type) monoalphabetic substitutions. Implemented on a computer, the substitution table provides a set of bijective mappings of [0, 2^n-1] to itself (with e.g. n=8) with the mappings being used in a fixed cyclical order determined by the key. Partly stimulated by some recent discussions on compression in sci.crypt, I like to point out the following possibilities of generalization of encipherment with polyalphabetical substitutions. 1. The key, customarily fairly short, may be extended (in the sense of avoiding short periodicity of processing), if one uses it as a seed of a PRNG and let the output of the PRNG to choose from a set of mappings (which themselves can be conveniently generated with the PRNG). Thus the PRNG 'drives' the polyalphabetical substitution, analogously to my recent suggestion to use a PRNG to drive modern block ciphers for the purpose of defeating differential analysis of these. (I employed this technique in my humble algorithm WEAK3-EX.) Through the 'indirectness' (i.e. the PRNG output is not 'directly involved' with the ciphertext like in cases where XORing of PRNG output with the plaintext is employed) the inference of the PRNG is difficult to perform. 2. One need not confine oneself to using bijective mappings of [2, 2^n-1] to itself, where the input and output symbols are all of constant size, i.e. all of n bits. One can use Huffman codes instead. This immediately enables one to obtain a plethora of essentially different mappings. (Note that a short code symbol can be mapped to a long one and vice versa. This huge 'variability' can serve to greatly confound the analyst.) Firstly, for m terminal nodes there is a large number of possible binary trees (of different shapes), giving rise to a large number of sets of Huffman code symbols. Secondly, given two such Huffman trees, their terminal nodes can be mapped in m factorial different ways, i.e. leading to m! different mappings. Note again that in both these aspects a PRNG can be utilized to advantage. Of course, these mappings can be dynamically chosen as described in item 1 above and even created (possibly also in plaintext dependent ways) as the encryption processing goes on. Further, encryptions of such nature employing different mappings can be advantageously concantenated (superencipherment). To avoid eventual misunderstandings, it is to be remarked that this article does not touch on the topic of compression, even though Huffman encoding is generally associated with the field of compression. In fact, encryption using suggestions given in item 2 above may even often lead to outputs that are longer than the inputs. I like also to acknowlege that an essential part of the ideas in item 2 stems from Serge Hallyn. M. K. Shen === http://home.t-online.de/home/mok-kong.shen -- From: Mok-Kong Shen [EMAIL PROTECTED] Crossposted-To: comp.compression Subject: Re: Build your own one-on-one compressor Date: Mon, 01 Nov 1999 12:25:22 +0100 SCOTT19U.ZIP_GUY wrote: To quote the section from http://www.alife.co.uk/securecompress/ that I quoted in the post at the head of this thread: ``* No string in the tables should contain another such string as a substring; * No leading symbols in any string should exactly match the trailing symbols in a different string.'' Side1Side 2 ABCD HG HTHN UK XYZ PQ XYZABCDABCD goes to PQHGHG. I modify this to PQHTHN. It comes bach to XYZHTHN. Now this goes to PQUK. Or do I again miss You mean it comes back as XYZUK which goes back to PQHTHN no problem. SO maybe you did miss something. Sorry, I erred with the example. But the impossibility of constructing a dictionary of the art of Tim Tyler in practice
Cryptography-Digest Digest #487
Cryptography-Digest Digest #487, Volume #10 Mon, 1 Nov 99 15:13:04 EST
Contents:
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
Re: Scientific Progress and the NSA (was: Bruce Schneier's Crypto Comments...)
(SCOTT19U.ZIP_GUY)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Bill McGonigle)
Re: Boring Web Site and Kerberos News (John Savard)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Paul Koning)
Re: Kerberos Question (David P Jablon)
Re: Symetric cipher ("Joseph Ashwood")
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: the ACM full of Dolts? (Mok-Kong Shen)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Mon, 01 Nov 1999 17:25:41 GMT
In article [EMAIL PROTECTED], Mok-Kong Shen [EMAIL PROTECTED]
wrote:
SCOTT19U.ZIP_GUY worte:
Addendum: Corrected example:
Side1Side 2
ABCD HGF
HS Z
FTGF MM
XYZ PQ
How many times are you going to so this this list does not much
his result in at least to seperate places?
Now XYZABCDABCD -- PQHGFHGF. A modification of the string on
side2 to PQHSFTGF gives PQHSFTGF -- XYZHSFTGF --PQZMM.
Besides using invalid dictionary you still are substituing wrong
PQHSFTGF - XYZZMM but your dictionary still worng. I am surprised
you don't see how to follow his rules. This in itself is very interresting.
Mmh. Did you write correctly above with your 'worng'?? Now, what
is wrong with my dictionary?
It is hard to say I meant "wrong" for "wrong" and I read it as "wrong"
but I could have made a mistake and wrote "wrong" as "worng". I sometimes
make those kind of mistakes. The mistakes are far worse when I write instead
of type. I think my brain is faster than my hand. And then I read what I
wanted to write insteand of what is there.
But you seemed sharp enough to know what I meant anyway. Or maybe
someone intercepts my posts and changes the spellings on purpose.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
--
From: "james d. hunter" [EMAIL PROTECTED]
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Mon, 01 Nov 1999 11:26:38 -0500
Reply-To: [EMAIL PROTECTED]
Tony T. Warnock wrote:
Uncle Al wrote:
The digits of pi are purely random (except for being pi). We've got
pi to about 50 billion decimal places. Nobody would suspect using the
digits of pi becaise it is not a random number. No problem. Use pi.
I would like some reference to this. As far as I know, no one has proved
that the digits of pi are purely random, quasi random, non random,
uniformly distributed, etc.
That's because nobody has proved than anything is random.
"Random" is usually defined in terms of things like pi,
so there's no reason to assume that pi isn't just simply
a well-known purely random number.
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Scientific Progress and the NSA (was: Bruce Schneier's Crypto
Comments...)
Date: Mon, 01 Nov 1999 17:38:10 GMT
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Doug Stell)
wrote:
We can't reliably tell, as it is not in their interest to let their
capability or lack thereof be known. However, those of us who work
with the NSA have plenty of hints that Bruce is quite right in his
estimation.
More Bull Shit. If you think they are telling you the truth
you are full of it. I think I can honestly say the higher the secrets
the more the lies. Lieing is very common and excepted in the governments
way of doing business. IF you think they would tell you the truth then
you are not very bright. I worked for the govenment 26 years. THe one
trend I noticed as time went on is that more and more lieing is the
standard way of the US government doing business.
rest snipped it just gragging about how the NSA shares above Top Secret
information to this guy and how the NSA needs help in creating crypto
By the way, don't expect anybody to tell you what areas they are ahead
in.
Gee I thought that is what you just claimed to do with all the
Cryptography-Digest Digest #488
Cryptography-Digest Digest #488, Volume #10 Mon, 1 Nov 99 17:13:02 EST
Contents:
Re: Re: Compression: A ? for David Scott (CoyoteRed)
Re: Kerberos Question ([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (David
Wagner)
Re: Kerberos Question (David Wagner)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Scott Nelson)
Re: Compression: A ? for David Scott (Tim Tyler)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: the ACM full of Dolts? (SCOTT19U.ZIP_GUY)
pwmbr ("Ran")
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Trevor Jackson,
III")
content type for PKCS#12 in NS ([EMAIL PROTECTED])
What is the deal with passwords? (Tom St Denis)
Re: Doesn't Bruce Schneier practice what he preaches? (Tom St Denis)
Re: content type for PKCS#12 in NS (Tom St Denis)
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Re: Compression: A ? for David Scott
Date: Mon, 01 Nov 1999 18:29:22 GMT
Reply-To: this news group unless otherwise instructed!
On Mon, 1 Nov 1999 15:15:59 GMT, Tim Tyler [EMAIL PROTECTED] wrote:
: If we can seed a random file from a key then both problems
: of message size and left over artifacts could be eliminated.
If you do this, you rest the strength of your system on the strength of
the PRNG.
Okay, I see your point.
: As to the question about getting the random file to my buddy (if I
: were to XOR the plaintext first) wouldn't it be easy to send the file
: encrypted because how would the analyst ever know he has a properly
: decrypted file?
By analysing it in conjunction with the message later encrypted by
XORing with it.
True. Like I said, there are probably things that I've overlooked.
So, if we go back to David's argument about one-to-one versus
non-one-to-one compression.
One argument presented was if we used one-to-one and the aggressor
attempted a key and decompressed, what's to stop him from looking at
the compression ratio to determine if it expanded out. (It was
mentioned something about output of /random data in/ (an unsuccessful
decryption) would be /random data out/ which, in turn, doesn't
compress well.) One of the answers that I saw was not all files are
compressible, but if the file is very small and if the aggressor is
looking for a text file then we would assume that the file /was/
compressible. Plus, if it /did/ expand out then we would almost
certainly have a /hit/ and a target for further analysis.
(You couldn't "pad" the output file in an attempt to fool him as he
would probably have written a custom program to analyze your messages
and the "pad" routine would immediately alert him of this. If the
"pad" routine is called he would know he had an invalid key, he
wouldn't even have to try a re-compress and compare. BAD NEWS)
Now, if the file didn't expand out much, we assume one of the
following:
1 - uncompressible file
2 - uncompressed file
3 - pre-encrypted file
4 - invalid key
A quick test for data for any headers and other known patterns for 1
2. Then when this fails we need to make a decision to further analyze
for 3 or assume 4 and toss the key and try the next one.
So, in this belief scenario, we might be able to assume that
one-to-one is not free of analysis. Granted, the Comp(DeComp(x))=x
attack is eliminated, but not all attacks.
What if we just compressed for size using the best algorithm available
and then generated a random file to XOR with the compressed data.
Encrypt the random file and package the encrypted random file with
XOR'ed data and send it on it's way.
We vastly suppress the ability to analyze from message to message,
because each message will be XOR'ed with a different file. The only
thing that would be the same is the public key and any assumed plain
text.
While we will vastly increase the size of our message, we would
eliminate any compression based attack or pattern attack angle. We'd
just have to sacrifice size for security.
Because, we've (I believe) have established that XOR'ing your data
with a sufficiently random file makes it /secure/. Our next attack
would come from trying to break the encryption on the random file and
because we have a random file as our "data," wouldn't he be forced to
use brute force and the strength of this would rely on the size of our
key?
If the above is true then the argument of one-to-one versus
non-one-to-one is mute. It would only apply if you wanted smaller
messages and still have high security. I'm not convinced, with
today's bandwidth, that the larger message size would be that
detrimental.
--
CoyoteRed
CoyoteRed at bigfoot dot com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
--
From: [EMAIL PROTECTED]
Subject: Re: Kerberos
Cryptography-Digest Digest #490
Cryptography-Digest Digest #490, Volume #10 Mon, 1 Nov 99 20:13:03 EST
Contents:
Re: announcement: steganography program "steghide" (John Kennedy)
Re: Doesn't Bruce Schneier practice what he preaches? (John Kennedy)
Re: announcement: steganography program "steghide" (John Kennedy)
Re: Doesn't Bruce Schneier practice what he preaches? (John Kennedy)
Re: Doesn't Bruce Schneier practice what he preaches? (John Kennedy)
Re: Doesn't Bruce Schneier practice what he preaches? (John Kennedy)
Re: Renouncing Uncensored-News (was:Biometric Keys are Possible) (John Kennedy)
Re: announcement: steganography program "steghide" (John Kennedy)
Re: Bruce Schneier's Crypto Comments on Slashdot (jerome)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Tony T. Warnock")
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
From: John Kennedy [EMAIL PROTECTED]
Subject: Re: announcement: steganography program "steghide"
Date: Mon, 01 Nov 1999 17:33:35 -0500
On Fri, 29 Oct 1999 21:10:41 GMT, [EMAIL PROTECTED] (jerome) wrote:
On Fri, 29 Oct 1999 18:09:31 GMT, Tom St Denis wrote:
In article [EMAIL PROTECTED],
Stefan Hetzl [EMAIL PROTECTED] wrote:
Hello,
I have written a steganography program called "steghide". It is
designed to be portable and configurable and features hiding data in
bmp, wav and au files, blowfish encryption, MD5 hashing of passphrases
to blowfish keys and pseudo-random distribution of hidden bits in the
cover-data. It is copyrighted under the GNU General Public License.
Steghide is written in ANSI C so the source code should compile on
many
systems. Binaries are available for Windows and Linux. It is available
from: http://www.crosswinds.net/~shetzl/steghide/index.html
Criticism is welcome.
While I couldn't get the binaries off your site (too slow) I will take
a peek at the source later. A quick comment or two..
1. It's not usefull for general run-of-the-mill daily messaging. You
need too many different pictures/sounds to make it usefull.
There are sources of pictures which can be automatically gathered.
Sex pictures from the news are good for this purpose. The observer
would probably think that you like to exchange sex picture with
your friends. If you try to hide it, he would interpret that you
are ashamed to be a 'pervert'.
As a bonus, this gives you great cover at home for downloading tons of
porn!
"I'm just trying to keep our personal communcations private honey!"
It's a dirty job, but somebody's gotta do it.
If you provide a simple answer, most people doesn't look deeper.
it is the aim of steganography. The psychologic part, lets say.
By the way these newsgroup is a very efficient way to avoid
traffic analysis, the sender is identifiable but not the
receiver (because of the number of readers).
-
John Kennedy
The Wild Shall Wild Remain!
http://members.xoom.com/rational1/wild/
--
From: John Kennedy [EMAIL PROTECTED]
Subject: Re: Doesn't Bruce Schneier practice what he preaches?
Date: Mon, 01 Nov 1999 17:33:39 -0500
On Mon, 1 Nov 1999 13:03:17 GMT, [EMAIL PROTECTED] (Larry
Kilgallen) wrote:
In article 7vj6c8$5pt$[EMAIL PROTECTED], Scott Fluhrer
[EMAIL PROTECTED] writes:
If that's all Schneier meant, then he's wrong. Just knowing the algorithms
used is not enough. You have to know that they were put together correctly,
for example, that any random number generators used were not chilled, that
any keys created were not chosen with malice, that no key bits were being
leaked somehow.
If viewing the source is the only basis for your trust, then you
have to know that you are better able than Bruce Schneier to tell
what constitutes proper construction of the software.
My personal viewing of the source has little to do with it. What would
be comforting is if the source were in plain view of the entire world,
where there are many talented people who could really make a name for
themselves by finding a security flaw in Counterpane Software.
This is one of the very greatest strenghts of PGP.
If you view malice from Bruce Schneier as a threat, they you have
to know that you are able to detect such malice better than Bruce
Schneier is able to hide that malice.
Sorry, this is nonsense. Microsoft sells security too. They don't
publish the implementation details. I wouldn't be at all surprised if
they have far better programmers than me working on it. Should I then
trust their software with my secrets?
Schneier says no.
He's right.
The same holds for Counterpane software.
I know more about Bruce Schneier than I do about you, and I would
not be inclined to bet on you in such a competition.
I have no intention of competing against him on those terms.
Should I be
Cryptography-Digest Digest #492
Cryptography-Digest Digest #492, Volume #10 Tue, 2 Nov 99 03:13:03 EST Contents: Re: Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY) Re: Kerberos Question Re: Doesn't Bruce Schneier practice what he preaches? (Jerry Coffin) Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY) Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY) Re: Long Signatures (was Re: Doesn't Bruce Schneier practice what he preaches?) (wtshaw) Re: Kerberos Question From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) Subject: Re: Re: Compression: A ? for David Scott Date: Tue, 02 Nov 1999 04:15:14 GMT In article [EMAIL PROTECTED], this news group unless otherwise instructed! wrote: On Mon, 1 Nov 1999 15:15:59 GMT, Tim Tyler [EMAIL PROTECTED] wrote: : If we can seed a random file from a key then both problems : of message size and left over artifacts could be eliminated. If you do this, you rest the strength of your system on the strength of the PRNG. Okay, I see your point. : As to the question about getting the random file to my buddy (if I : were to XOR the plaintext first) wouldn't it be easy to send the file : encrypted because how would the analyst ever know he has a properly : decrypted file? By analysing it in conjunction with the message later encrypted by XORing with it. True. Like I said, there are probably things that I've overlooked. So, if we go back to David's argument about one-to-one versus non-one-to-one compression. One argument presented was if we used one-to-one and the aggressor attempted a key and decompressed, what's to stop him from looking at the compression ratio to determine if it expanded out. (It was mentioned something about output of /random data in/ (an unsuccessful decryption) would be /random data out/ which, in turn, doesn't compress well.) One of the answers that I saw was not all files are compressible, but if the file is very small and if the aggressor is looking for a text file then we would assume that the file /was/ compressible. Plus, if it /did/ expand out then we would almost certainly have a /hit/ and a target for further analysis. That was an old thread. True a random file tends not to compress. Bad a random file also decompresses to a very large file with my method. Find Clintons last message. David A. Scott -- SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE http://www.jim.com/jamesd/Kong/scott19u.zip Scott famous encryption website NOT FOR WIMPS http://members.xoom.com/ecil/index.htm Scott rejected paper for the ACM http://members.xoom.com/ecil/dspaper.htm Scott famous Compression Page WIMPS allowed http://members.xoom.com/ecil/compress.htm **NOTE EMAIL address is for SPAMERS*** -- From: [EMAIL PROTECTED] () Subject: Re: Kerberos Question Date: 2 Nov 99 03:17:33 GMT John Savard ([EMAIL PROTECTED]) wrote: : [EMAIL PROTECTED] (David Wagner) wrote, in part: : I'm sure I'm missing something, but can't you trivially mount a : dictionary attack with the following technique? : Pick a random 64-bit xor mask M. Encrypt it with the server's public : key (pretending to be the legitimate client; remember, there is no : authentication yet). Capture the server's response, which will be : encrypted with K xor M. Now do a dictionary search for K using trial : decryption (which is easy, since you know M). : You're quite right: even in the case that seems the most secure, : encrypting the random mask with the user's secret key, the dictionary : attack is trivial. Hence, more complicated protocols such as EKE and : SPEKE. I did see in the documentation on Kerberos I found over the web that another proposal for modifying Kerberos was to have the user send an authenticator for his own secret key with the first message. If that authenticator as well as a session key for use with the Kerberos server were sent, encrypted with the Kerberos server's public key, _then_ one has protected against dictionary attacks (I think) without having to use the unconventional - and proprietary - privacy-amplification methods such as EKE and SPEKE. I think this method - unlike my mistake - has been proposed before by someone, and that again is something I'm looking for as I extend the web page. I also think, now, that I will mention EKE and SPEKE, and I will put them in the final conclusions part, as being among the things Kerberos and similar protocols have inspired people to come up with, by pointing out the need for them. John Savard -- From: [EMAIL PROTECTED] (Jerry Coffin) Crossposted-To: alt.security.scramdisk Subject: Re: Doesn't Bruce Schneier practice what he preaches? Date: Mon, 1 Nov 1999 21:16:18 -0700 In article [EMAIL PROTECTED], [EMAIL PROTECTED] says... [ ... ] I just find it puzzling, odd, inconsistent, by which I do not mean to imply fishy. ...as opposed to the algorithm itself, which clearly
