Cryptography-Digest Digest #445, Volume #10 Mon, 25 Oct 99 05:13:04 EDT
Contents:
Re: Some humble thoughts on block chaining
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
Posting Anonymously ("entropy")
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: Newly Encountered Crypto System
Re: Another newbie question (JTong1995)
cert. length (Gao Qing)
Re: REWARDS FOR INFORMATION
Re: Unbiased One to One Compression (SCOTT19U.ZIP_GUY)
Re: Newly Encountered Crypto System (wtshaw)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (wtshaw)
Re: Key size vs number of rounds (Jerry Coffin)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Vernon
Schryver)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Vernon
Schryver)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Some humble thoughts on block chaining
Date: 25 Oct 99 02:16:55 GMT
Mok-Kong Shen ([EMAIL PROTECTED]) wrote:
: But the whitening e.g. in DESX is supposed to add some security, I
: suppose. Is there any clear ground that DES shouldn't be combined
: with a stream encipherment, excepting the belief
which, of course, is now known to be false
: that DES alone is
: unbreakable and hence self-sufficient?
No.
The reason why it is currently being sought to replace DES with a better
block cipher, again intended to be used alone, rather than merely being
advocated to combine DES with some relatively trivial stream encipherment
are very difficult to justify
but what I believed to be those reasons were mentioned in a post of mine
some time ago. Basically, because a block cipher is a nice, self-contained
black box (except for the key, it is _stateless_) it is felt to pose fewer
problems to designers.
Output feedback and counter mode are assumed to produce satisfactory
stream ciphers for anyone who wants one from a block cipher.
My earlier post stating the rationale which I believed operating here
received a reply which noted that BEAR and LION illustrated that stream
ciphers were more useful than this rationale admitted. (Perhaps this will
help you find it on DejaNews.)
It might also be noted that the statelessness of a block cipher means that
its key size is genuinely bounded; a stream cipher might have a short key,
but a large internal state, and admit of being used in a nonstandard way
that would increase the key size to that of the internal state.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
Date: 25 Oct 99 02:25:06 GMT
Anthony Stephen Szopa ([EMAIL PROTECTED]) wrote:
: You don't have to buy the software. It is shareware.
That is all very well. However, the criticisms of your software that have
appeared in this newsgroup were not complaints about its ease of use, or
its speed.
Your program may well be a joy to use. This can be determined by trying
it.
But what people have criticized about Original Absolute Privacy is that,
for various reasons, they feel they do not have adequate reasons to
believe that it will genuinely securely encrypt their messages. (I
understand that it may be frustrating to you that these reasons appear to
be chiefly _ad hominem_ reasons rather than technical ones.)
Whether or not these criticisms have validity, it _is_ a fact that by
trying and using your software, they will not learn anything about whether
it is secure or not. Basically, that is because they are looking for
encryption that is many times more secure than anything they can crack
themselves, so not being able to crack a code is not sufficient to prove
it is adequately secure.
John Savard
------------------------------
From: "entropy" <[EMAIL PROTECTED]>
Subject: Posting Anonymously
Date: Sun, 24 Oct 1999 22:27:36 -0400
How do people post anonymous messages to alt.anonymous.messages? Looking at
the header, they come from nym.alias.net. How do I set up an account with
nym.alias.net? (everything I've found has been in German) Are there other
(free) services that post anonymously?
Thanks
--
a.
:::entropy:::
ktheory.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 25 Oct 1999 02:35:01 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
> On Sun, 24 Oct 1999 03:39:23 GMT, in <7utv1b$ldc$[EMAIL PROTECTED]>, in
> sci.crypt [EMAIL PROTECTED] wrote:
>
>>[...]
>>Observe that in my discussion above, the choosing of the cipher
>>depends on they key. It is not done randomly which would requiere us
>>to add information to the ciphertext about which cipher has been
>>used.
>
> Something seems wrong with this observation: Keys we use for actual
> data encryption generally are *message keys*, and in fact *should* be
> random values. Using a random message key value to select a cipher
> sounds rather similar to using a random value to select a cipher.
Well, I meant this: If you choose ciphers from the pool in a way that
depends on the key then, by definition, the attacker will not know a
priori which cipher is being used for each block. If you choose the
ciphers by any other method then, by definition, the attacker will
always know which cipher is being used: the attacker can know
everything except the key.
Now if the attacker *does* know which cipher has been used for each
ciphertext block, then he can attack the ciphertext encrypted by the
weakest cipher. Consider this: even though we in the public don't know
the lower bound of security of the individual ciphers we must assume
that a powerful attacker does know. We also can assume that these lower
bounds vary a lot - it would be strange indeed if different ciphers
were very similar in their lower bound of security. So in a pool of
four ciphers it is quite probable that one (the "lemon") is orders of
magnitude weaker than the others and that the attacker knows this. Let
us assume the lemon falls to a known plaintext attack that requires a
small number of known plaintexts. It is true that the attacker will now
have to collect four times more data for the lemon, but this quantity
will be a trifle compared to the plaintext that must be known for
attacking any of the other three ciphers. Therefore the attacker will
easily break 25% of the communications recovering almost all
intelligence. Instead of using this method, we would be better off
choosing one cipher by chance sticking to it.
The situation is very different is the choice of ciphers is unknown to
the attacker, and for that it is necessary that the choice of the
ciphers depend on the key. (There is curious exception: to encrypt the
next block choose the cipher completely at random and send only the
resulting ciphertext. To decrypt, try in sequence the various ciphers
until you get intelligible plaintext.)
> We certainly would hope that any attacker could not distinguish
> between ciphertexts produced by one cipher and another. One might
> even think that an ability to identify a particular cipher from its
> ciphertext alone would be a straightforward indication of cipher
> weakness.
I agree.
> Obviously an attacker could try all ciphertexts under the weakest
> cipher first, but if the attack requires messages from only a
> particular cipher, how would the attacker know which messages to use?
>
> When the cipher itself is changed dynamically on a message-by-message
> basis, there should be no way to distinguish the subset of ciphertexts
> produced by a particular cipher. It would thus seem to be hard for an
> attacker to even collect the required amount of single-cipher
> ciphertext, let alone start any actual attack.
When the cipher choice is changed dynamically in a way that the
attacker cannot predict, then we do get some very interesting
properties even if the pool contains only two or three ciphers: It
seems a ciphertext only attack on the weak cipher will not work,
because the attacker will not know which ciphertext blocks belong to
it. Known or chosen plaintext attacks will apparently not work either
and for the same reason: even if the attacker chooses the entire
plaintext stream, he cannot collect and analyze the ciphertext blocks
that have been encrypted with the lemon. It does appear that mixing
ciphers can be very useful, but only if the attacker cannot predict
their sequence.
How does one achieve this? Using a few bits of the key to index one in
a pool of N ciphers is not the best way, because then all blocks will
be encrypted with the same cipher. The attacker applies the lemon-
attack and with 1/N probability it will work. Using the key to start a
PRN sequence is not the best solution either: If the key is reused then
the first block will always be encrypted with the same cipher. I think
the best solution is to use an IV as well as the key to start a PRN
sequence. One possibility:
Pool N ciphers.
Define random IV and add it to the ciphertext.
T(0) = IV
H(0) = Key
To encrypt the i-the block T(i):
H(i) = Hash( H(i-1) xor T(i-1) )
index(i) = H(i) mod N
C(i) = encrypt( index(i) ) ( T(i), Key )
Here is another possibility. Let us assume we trust four of the AES
finalists (which use 128 bit blocks).
index = least significant 2 bits of key
H = IV
Step A: H = encrypt( index ) ( H, Key)
Step B: Use 63 groups of 2 bits of H to index a cipher and encrypt the
first 63 blocks of plaintext.
Step C: index = last 2 bits of H
Step D: go to Step A
The ciphertext increases in one block and speed decreases about 2%
One more thought. Mixing ciphers in a secret sequence seems to be
useful even if only two ciphers are used. What about using only one
cipher while changing the direction of the encryption, i.e. use it
sometimes to encrypt and sometimes to decrypt depending on the secret
sequence?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Newly Encountered Crypto System
Date: 25 Oct 99 02:35:17 GMT
Melinda Harris ([EMAIL PROTECTED]) wrote:
: Has anyone out there heard or read about A.N.E.C?
: and what does this acronym mean?
I haven't.
: Cryptographers worldwide would concede that this encryption technique called
: A.N.E.C, does not conform to the traditional practices, beliefs or standards
: within the cryptographers profession and has an innovative idiosyncratic,
: uncanny technique unlike any cryptosystem I have ever encountered.
They would. Does that mean they've heard about it, or that you've heard
about it?
Is the first paragraph your own words, and is the rest of this posting a
quote? If not, well, now it's starting to read like ad copy.
: For hackers its a cryptographic poison without a crypto-analytic antidote.
That remains to be seen, particularly if we haven't heard what it is.
: The self-proclaimed crypto-eccentric remains anonymous,and has aliases such
: as prodigy of encryption, and cipher man. His methods of concepts encompass
: arbitrary ciphers consisting of letters, infinite numbers, characters and
: symbols manipulated and transposed by constant movement and a fluent
: shifting strategy. A variety of unique, alternative flowcharts and
: predetermined cipher strip base charts followed by a complex algorithm, He
: uses uncanny techniques, such as simultaneous triple cross
: transposition,multi-hieroglyphic cipher charts, idiosyncratic inverse
: ciphers,E.T cipher base charts,kanji cipher base charts,columnar
: transposition ,multi-algo applications and something called the
: "clairvoyance of recursive computational processes". Interplanetary cipher
: symbols. And what about this" optional arbitrary multilevel priority,
: alternative and secondary base chart transition processes?"
That is certainly quite a list. It may even have produced a genuinely
secure cipher, but some of its elements are of a kind to provoke
skepticism.
: It supposedly has superior standard validation protocol? If so this is
: unprecedented.
It seems pointless to comment.
John Savard
------------------------------
From: [EMAIL PROTECTED] (JTong1995)
Subject: Re: Another newbie question
Date: 25 Oct 1999 02:55:10 GMT
>frequency analysis of the letters and I believe it is english and has
>> >just been encrypted by using a transposition cipher.
Typically you do an Index of Coincidence test to determine if the ciphertext is
enciphered via a transposition, monalphabetic substitution, or polyalphabetic
substitution. If the values is running around 1.73, rather than around 1.00,
then it is likely one of the first two rather than the latter. Next, examine
the ciphertext via frequency count, and look for the presence for large numbers
of lower frequence letters (q,z,j,k,x) and low counts of what should be high
frequency letters (e,t,n,o,r,a,i,s).... this would indicate substitution vice
transposition. If the reverse is observed, the ciphertext will closely follow
expected English plaintext letter frequencies and is likely a transposition.
If you look at a copy of Friedman and Callimahos' Military Cryptanalytics
Part 1, pages 34 - 37 show a series of tables that are useful for comparing the
frequency of occurance of ciphertext letters versus message length that shows
the upper and lower theoretical amount of variation to be expected by catagory.
E.g., a message of 150 - 200 letters is expected to have between 0 and 4
occurances of low frequency consonants (JKQXZ). The more the deviation from
the expected, the more likely it is that a substitution is involved.
Jeffrey Tong [EMAIL PROTECTED]<Jeffrey Tong>
PGP 5 Key available for download at WWW.PGP.COM Key ID: BFF6BFC1
Fingerprint: 6B29 1A18 A89A CB54 90B9 BEA3 E3F0 7FFE BFF6 BFC1
------------------------------
From: Gao Qing <[EMAIL PROTECTED]>
Subject: cert. length
Date: Mon, 25 Oct 1999 10:43:03 +0800
Could anyone kindly tell me how long a typical x.509 certificate is,
say, the key length is 512bit or 1024bit?
Thanks!
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: REWARDS FOR INFORMATION
Date: 25 Oct 99 04:08:55 GMT
Melinda Harris ([EMAIL PROTECTED]) wrote:
: I am willing to pay for books, manuals, instruction pamphlets,
In general, the sort of information you are requesting is not legally
available to members of the general public.
However, an older introductory manual about cryptanalysis used officially
by the U.S. Army is available at
http://www.und.nodak.edu/org/crypto/crypto/
and they also have the Zendian problem there, used instructionally at the
NSA.
Also, something purporting to be a welcome handbook to NSA employees is
available at
http://www.fas.org/
John Savard
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Unbiased One to One Compression
Date: Mon, 25 Oct 1999 05:49:03 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] () wrote:
>Tim Tyler ([EMAIL PROTECTED]) wrote:
>: I have a high opinion of John Savard, based on his usenet contributions.
>
>Why, thank you.
>
>: However, I'm not sure I've done as well as I could have done in explaining
>: why having one - and only one - decompressed file for every compressed one
>: is potentially important to security.
>
>: If you *don't* have this, then the compressor, when compressing, can
>: choose more than one compressed file to compress to.
>
>: If the compressor chooses between these files at random, then there's no
>: security problem - you just wind up with fatter compressed files than you
>: need to.
>
>Yes, you need to choose between those files at random.
>
>: Making the cypher "one-on-one" avoids the possibility of any information
>: or regularity *added* by the compressor being used in the attack on the
>: cypher - since no information has been added.
>
>: Attacks can still be based on any regularities left by sub-optimal
>: compression, though.
>
>There is a problem with one-to-one compression.
>
>As I recently noted, I had found a way to perform Huffman compression so
>as to approximate the one-to-one condition between the files to be
>compressed, and strings of bits of arbitrary length.
>
>But the next step, converting to a message that is a whole number of bytes
>in length, is the problem.
You are wrong. I have solved the problem but you to lazy to look at what I
did and you can't even grasp the code. I have it really sovles the problem
if you would only open your mind and look at it.
http://members.xoom.com/ecil/compress.htm
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Newly Encountered Crypto System
Date: Sun, 24 Oct 1999 23:47:31 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] () wrote:
> That is certainly quite a list. It may even have produced a genuinely
> secure cipher, but some of its elements are of a kind to provoke
> skepticism.
>
> It seems pointless to comment.
>
Sounds fishy. I would applaud serious efforts to delve into the crypto
unknown, but not efforts in mindless speculation as this seems more
appropriate for recreational daydreams.
--
Sometime ago, Gates bought lots of shares of Apple.
My preference is to keep the Worm out of the Apple.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 24 Oct 1999 23:58:48 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
> On Thu, 21 Oct 1999 13:11:31 +0100, in
> <[EMAIL PROTECTED]>, in sci.crypt
> "Brian Gladman" <[EMAIL PROTECTED]> wrote:
>
> >If we postulate that all ciphers achieve a strength implied by their
> >keyspace,
>
> That is a ridiculous postulation in any case.
Keyspace depends on what you do with it.
>
....
> The primary advantage of choosing among multiple ciphers is NOT to
> provide keyspace, but instead to allow changing to a new cipher. This
> is an advantage because changing to a new cipher obviously terminates
> any break which had been applied to the old cipher. You can claim all
> the analysis you want, but you cannot claim a known strength. And
> without that, you *cannot* depend upon that cipher.
>.....
> The issue in breaking ciphers is only rarely keyspace.
Ah..so much depends on the meaning of strength.
--
Sometime ago, Gates bought lots of shares of Apple.
My preference is to keep the Worm out of the Apple.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Key size vs number of rounds
Date: Mon, 25 Oct 1999 00:51:10 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Thank you for the explanation. The question may be asked whether
> the realizablity of an increase of diffusion rate per round is
> dependent on the increase of the key and block size.
I wouldn't want to say that it can't _possibly_ be, but it's certainly
not the general rule. Usually the diffusion rate depends primarily on
the size and number of S-boxes and bit manipulations you do. In
theory, you could achieve 100% diffusion with a single round if you
have enough (and large enough) S-boxes. Adding rounds mostly allows
you to reduce the internal state of the cipher by re-using the same S-
boxes repeatedly -- if you wanted to you could implement DES (for
example) as a single round with LOTS of S-boxes, in which it just
happens that every 16th S-box happens to be identical (in fact, if you
wanted to maximize speed in a hardware implementation, this would be
effective, if perhaps inelegant, approach to use).
> If the answer
> is yes, then it is at least conceivable that the round number could
> under circumstances be decreased as the key and block size increases.
> If the answer is no, then the diffusion rate is to be considered
> as another design dimension to be optimized. Anyway, I guess it is
> probably correct to say that Massey's statement does not have general
> coverage.
Not as stated, no. You want enough diffusion so that changing one bit
of the key or one bit of the input will change roughly half the bits
in that block of the output (obviously it should be as difficult as
possible to figure out WHICH output bits will be affected by changing
any particular input bit). If you leave everything else alone, then
increasing the block size will increase the number of rounds necessary
for each bit of input to affect all the bits in the output. Offhand I
can't see any way that would work in reverse. At least for me it's
harder to comment on the possibility of changing the key size while
keeping everything else the same: in most cases, there's simply no way
to utilize different sizes of keys without at least changing your key-
schedule along with the key size.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 25 Oct 1999 00:51:22 -0600
In article <[EMAIL PROTECTED]>,
wtshaw <[EMAIL PROTECTED]> wrote:
> ...
>Well, how clean can it be: Figure that you have a list of ciphers which
>you will accept. It is up to the sender to speak in one or them, at
>least.
> ...
>To change cryptosystems, just do it; at the other end, detection falls out
>of lock as the current system fails to recover reasonable output, and go
>back to checking the various algorithms, getting the new system, locking
>until unlocked.
>
>Sounds simple enough to me, but who am I to judge?
Look at PPP compression for examples of complications. Compression
is very much like encryption, as has been pointed out here many times,
so you can't just shrug off the PPP compression follies.
For example, what you do when both peers can handle both A and B, but one
strongly prefers A while the other prefers B. Say one peer has AES type
I hardware but does type II in 8-bit 3 MHz software, and vice versa for
the other peer. What do you do, and why?
For another example, look at the last ten (10) years of complications
in the PPP IPCP IP address negotiations.
In the initial theories, those problems were too trivial to worry about.
It wasn't until systems got into the field that our noses were rubbed in
the holes in the theories.
The worst result of the compression negotiation complications (as well as
egregious bugs by a large vendor or two, and a dose or two of
embrace-and-extend by a very large software outfit) is that you can't
count on your PPP data being compressed. The equivalent result for
negotiating ciphers, not being able to count on your data being encrypted,
strikes me as a little more serious.
--
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 24 Oct 1999 10:13:34 -0600
In article <[EMAIL PROTECTED]>,
Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
> ...
>> Only salescritters or people with no technical knowledge can claim that
>> either PPP or modems are examples that could cause a working engineer to
>> be enthusaistic about negotiating ciphers. Sane, technically inclined
>> people who look at modems, PPP, or any other "standardized", dynamic
>> negotiating network protocol must be very skeptical of the idea.
>
>Any other? I think not.
>
>You can pick on negotiation failures typically those that evolved over time, which
>usually means layers of kludge upon kludge, sometimes driven by commercial issues
>(PPP),
Base on that statement, you have no idea of the history or even nature of
PPP. PPP in general and PPP negotiating in particular are as much as was
possible the exact opposite of something "that evolved over time."
(Before you argue with me about the history of PPP, please tell me under
what name I can find your words in the IETF PPP WG archives.)
> and sometimes driven by technological advances (modems).
That notion of the history of modems is also as wrong, based on what I've
observed since before dial-up 1200 bit/sec modems were available
(1,200 bit/sec, not 12,000 bps).
>OTOH, you have failed to note the cases in which negotiation is so successful that
>it is almost invisible. Consider DECnet. Once a machine is configured there is
>little chance of failure. You hook up the wires and the machine figures out wht
>topology necessary to communicate with other machines. This is a negotiation
>protocol that works.
Have you ever worked inside a DECnet implementation? I have been paid to
port and hack code that implemented Phase IV, and then to deal with problem
reports from customers that the technical support people could not answer.
To say the least, I do not agree with your claim that DECnet "is a
negotation protocol that [always] works."
Even the claim that DECnet was a "negotation protcol" is not quite true
in my view.
>Note that this class of error, noticing only the problems, is a basic wheel
>approach which causes sampling error.
>There is no alue to this sort of anecdotal horror story. If you want to address
>the topic of negotiating protocols, please produce an issue that you believe will
>be difficult to solve and lead to negotiation failures.
You're evidently as much of a "practicing engineer" as Terry Ritter.
My point is that in theory, there are no non-trivial problems that would
need attention, but in practice there always are.
In theory, there are no anecdotes that do not conform to theory.
Practice consists of anecdotes.
> ...
>Not relevant. We aren't faced with "complicated network stuff" or anything
>similar. Anyone adding one or more AES ciphers to an existing multi-cipher
>product already the the problem and a solution. Adding several AES ciphers to an
>existing single-cipher product is no harder than adding a single ("the") AES
>cipher; negotitaion is required.
That is wrong. Negotiation is not necessarily required, although the
receiver does need to figure out or know by prior configuration which
cipher is in use. "Negotiation" involves proposing, rejecting,
counter-proposing, and accepting. "Negotiation" is not inolved in asking
the wire for a network address and accepting whatever you get. It is also
not merely looking at a header to identify a packet format or cipher.
Asking for a DHCP or BOOTP address or picking a decryption scheme and key
based on a packet header has as much to do with "negotiating" as buying
groceries in a typical American supermarket, nothing whatsoever.
> creating a new product is the only case in which
>the requirement to negotiate cipher selection is an issue. Note that this is
>going to be common for reasona of backward compatibility during the
>changeover/upgrade period.
Nonsense. Upward compatiblity does *not* need negotiating, but merely
recognizing the old form. Negotiating is required if you want to
have the sender and receiver have potentically non-overlapping sets
of ciphers and to discover and agree on the best common cipher.
It is also required by Terry Ritters proposals.
Moreover, the "changeover/upgrade period" for protocols invariably lasts
a very long time. A case study of how long that can be is in the endurance
of DECnet Phase IV which has been officially obsolete and deprecated for
more than 10 years, but which is still a common form of DECnet (where
DECnet still exists).
Because of embedded systems, changes in cipher protocols take even longer.
> ...
>You cannot just wish this requirement away. Nor can you ignore the ubiquity of
>the issue and claim that multiple AES selections creates an abnormal condition.
>As discussed above it is probably normal to have multiple ciphers.
> ...
And you cannot just wish requirements into existence.
AES is not the first new cipher in history. Ciphers have been coming and
going for decades. Still, negotiating ciphers is not universal, and
where it is done, not without significant security problems in
practice but not theory (e.g. SSL).
Vernon Schryver [EMAIL PROTECTED]
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
