Cryptography-Digest Digest #901, Volume #12 Thu, 12 Oct 00 00:13:01 EDT
Contents:
Re: Storing an Integer on a stream (SCOTT19U.ZIP_GUY)
Re: Storing an Integer on a stream (SCOTT19U.ZIP_GUY)
Re: Storing an Integer on a stream (SCOTT19U.ZIP_GUY)
Re: What is "freeware"? (was: Re: Any products using Rijndael?) (Peter Fairbrother)
Re: Dense feedback polynomials for LFSR (Joaquim Southby)
Re: The science of secrecy: Simple Substition cipher (David Hopwood)
Re: Rijndael test vectors (David Hopwood)
Re: AES Runner ups (David Schwartz)
Re: A new paper claiming P=NP (Eric Cordian)
Re: Comments on the AES winner ([EMAIL PROTECTED])
Re: Comments on the AES winner (David Schwartz)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Storing an Integer on a stream
Date: 12 Oct 2000 02:01:17 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY wrote:
>>
>> [EMAIL PROTECTED] (Andras Erdei) wrote in
>> <[EMAIL PROTECTED]>:
>>
>[snip]
>> >The method i like most is fibonacci coding:
>> >
>> >- start with the largest fib number smaller than your integer
>> >
>> >- if the current fib number is smaller than your number
>> > substitute it and write down 1
>> > else
>> > write down 0
>> >- take the next fib number
>> >
>> >Example:
>> >
>> >number: 15
>> >fib: 1,1,2,3,5,8,13
>> >encoding: 13+2 -> 0010001
>> >
>> >This way you encoded your (arbitrarily big number) in a way that
>> >there are *no consecutive 1s* in the encoding, and it ends with 1;
>> >so you can append an additional 1 and thus make it a prefix code.
>> >
>> >result: 00100011
>> >
>> >IIRC this encoding is asimptotically optimal.
>>
>> This may be asimptotically optimal for certain cases. But
>> it is not optimal if you have a set of data and which to add
>> a pointer to one of the data bytes my DSC program is optimal
>> for that use.
>> it at my site on the compression pages.
>
>Mr. DS, it makes no sense whatsoever to say it "may be" asymptotically
>optimal. It either is or it isn't. In point of fact, if I remember the
>math for fibonacci sequences correctly, for increasingly large numbers,
>the length of this representation of a number approaches a small
>constant (approaching 1) factor of the length of the binary
>representation of the number.
I like the wording I choose. If you don't like the wording to bad.
Mine is a optimal encoding. Not asymptotically optimal but purely
optimal for the job it was intended, Namely adding an integer to a
file which represents. pointer to one the preceeding bits.
>
>Also, if the "pointer" you are talking about is in some cases a large
>number, and in some cases a small number, then a variable length
>representation is optimal. In your DSC program, how is the pointer
I guess that means your like Mok its there to test. But in general
the larger the value the longer the file will be when it is added to
it. Like I said its optimal. For example one may wrongly think
that if one had a data file of 256 bytes. You might think one needs
a file of 257 bytes. This is the maximun you need but sometimes you
can get by with less.
>stored? As a fixed sized integer, in base 128, in base 255, using a
>fibonacci coding, or something else? *What* the integer means isn't
>particularly important to this discussion, but *how* it's stored on the
>stream/in the file *is*.
The way it is stored is rather complicated. ANd as sure as hell
I will tell you wrong. But my code is there you can test it and see
for itself. Its thousands of C code character long. Take a look if
you want an example give me a set of data and I can give you the set
with the pointer added.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Storing an Integer on a stream
Date: 12 Oct 2000 02:18:36 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY wrote:
>> [EMAIL PROTECTED] (Benjamin Goldberg) wrote in
>> <[EMAIL PROTECTED]>:
>> >> You can use my DSC program.
>> >
>> >If I could find it. You didn't give a URL.
>>
>> SORRY http://members.xoom.com/ecil/compres8.htm
>>
>> >> If the file data is in whole bytes. and the padding starts on a
>> >> word boudary.
>> >
>> >That sentence no verb.
>> >
>> >> You can use my code without any modification at all. However the
>> >> format of your file would have to change. Instead of a length
>> >> field followed by data followed by random padding.
>> >
>> >This sentence also no verb.
>>
>> But where you able to figure it out?
>
>Could talk way that wanted to if I, but look like imbecile would.
>
>> >> You would have the data followed by random padding followed by a
>> >> pointer that points to the start of the random padding.
>> >
>> >In terms of amount of information, there is no difference between
>> >length + data + padding and data + padding + length. Also, either
>> >way, I asked how write a length value as some number of bytes. My
>> >post was asking what is the best way to do that.
>>
>> Good the code does that.
>
>It would be nice, if you said HOW the code does that. I'm writing this
>message offline, and won't have the opportunity to look at the web page
>until my parents don't need the phone line. Describing how the integer
>is stored would be much more intelligent than telling me to look at the
>code. Also, what proof do you have that your way is BEST, hmm?
THe proof is exactly the same as my adaptive huffman coding being
optimal in that any binary 8 bit file can be uncompressed and recompressed
back to same file and that any file can be compressed.
Example for any file X then compress( decompress( X )) = X
and dcompress( compress(X)) = X
for the method that adds a pointer to a file I use a special input
file that has a long attached at end for the pointer. My code DSC
takes any file of this form converts it to a binary file X
such that for any file X then DSC( UNDSC (X)) = X
and any file X that is a 8bit byte binary. will be converted to
a underlying data file. with a long attached that represents a pointer
to a byte in the file.
>
>For the 4 methods discussed so far (fixed # of bits, base 255, base 128,
>fibbonacci), each of them has a particular range of values / set of
>conditions where they are optimal. Consider that the fib encoding
>produces a bit string, and won't always be a multiple of 8 bits: If we
>are immediately following it with compressed data (the output of a
>huffman or arithmetic encoder), then the fact that it doesn't end on a
>byte boundary is not particularly important. If a fib encoded integer
>is followed by data that needs to be interpreted as bytes, then there's
>a 7/8 chance that we'll waste part of a byte (or else have to shift all
>following data 1..7 bits, which would be computationally expensive). In
>that scenario, one of the other 3 formats would be better, since they
>*do* use an integral number of 8-bit bytes.
>
>What method of encoding does your DSC program use?
It used none of the above. But is truely optimal as is
my huffman coding.
>
>
>If you can't explain the algorithm, why should I have any faith at all
>in the code? For that matter, if you can't explain it, why should I
>even believe that you wrote it? You might have stolen it and claimed
>that it's yours, for all I know.
I explain it in C code and with example. I don't have to explain
it any more than that. I don't see the point to write a long paper
only to have you or MOK argue about the details. WHen is is a simple
matter to just test the dam code. I can see arguing with some people
if they don't have code. Like John is always hand waving. I am not
good at BS talking. But I code the crap others just attempt to talk
about.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Storing an Integer on a stream
Date: 12 Oct 2000 02:20:06 GMT
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in
<[EMAIL PROTECTED]>:
>[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
><[EMAIL PROTECTED]>:
>
>>SCOTT19U.ZIP_GUY wrote:
>>>
>>> [EMAIL PROTECTED] (Andras Erdei) wrote in
>>> <[EMAIL PROTECTED]>:
>>>
>>[snip]
>>> >The method i like most is fibonacci coding:
>>> >
>>> >- start with the largest fib number smaller than your integer
>>> >
>>> >- if the current fib number is smaller than your number
>>> > substitute it and write down 1
>>> > else
>>> > write down 0
>>> >- take the next fib number
>>> >
>>> >Example:
>>> >
>>> >number: 15
>>> >fib: 1,1,2,3,5,8,13
>>> >encoding: 13+2 -> 0010001
>>> >
>>> >This way you encoded your (arbitrarily big number) in a way that
>>> >there are *no consecutive 1s* in the encoding, and it ends with 1;
>>> >so you can append an additional 1 and thus make it a prefix code.
>>> >
>>> >result: 00100011
>>> >
>>> >IIRC this encoding is asimptotically optimal.
>>>
>>> This may be asimptotically optimal for certain cases. But
>>> it is not optimal if you have a set of data and which to add
>>> a pointer to one of the data bytes my DSC program is optimal
>>> for that use.
>>> it at my site on the compression pages.
>>
>>Mr. DS, it makes no sense whatsoever to say it "may be" asymptotically
>>optimal. It either is or it isn't. In point of fact, if I remember the
>>math for fibonacci sequences correctly, for increasingly large numbers,
>>the length of this representation of a number approaches a small
>>constant (approaching 1) factor of the length of the binary
>>representation of the number.
>
>
> I like the wording I choose. If you don't like the wording to bad.
>Mine is a optimal encoding. Not asymptotically optimal but purely
>optimal for the job it was intended, Namely adding an integer to a
>file which represents. pointer to one the preceeding bits.
ACTAULLY I MEANT BYTES NOT BITS IN LAST LINE SORRY NOT PERFECT
>
>>
>>Also, if the "pointer" you are talking about is in some cases a large
>>number, and in some cases a small number, then a variable length
>>representation is optimal. In your DSC program, how is the pointer
>
> I guess that means your like Mok its there to test. But in general
>the larger the value the longer the file will be when it is added to
>it. Like I said its optimal. For example one may wrongly think
>that if one had a data file of 256 bytes. You might think one needs
>a file of 257 bytes. This is the maximun you need but sometimes you
>can get by with less.
>
>
>>stored? As a fixed sized integer, in base 128, in base 255, using a
>>fibonacci coding, or something else? *What* the integer means isn't
>>particularly important to this discussion, but *how* it's stored on the
>>stream/in the file *is*.
>
> The way it is stored is rather complicated. ANd as sure as hell
>I will tell you wrong. But my code is there you can test it and see
>for itself. Its thousands of C code character long. Take a look if
>you want an example give me a set of data and I can give you the set
>with the pointer added.
>
>
>David A. Scott
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
Subject: Re: What is "freeware"? (was: Re: Any products using Rijndael?)
From: Peter Fairbrother <[EMAIL PROTECTED]>
Date: Thu, 12 Oct 2000 03:31:00 +0100
Freeware is copyrighted.
--
Peter Fairbrother
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Date: 12 Oct 2000 02:37:35 GMT
In article <[EMAIL PROTECTED]> Tim Tyler, [EMAIL PROTECTED] writes:
>zapzing <[EMAIL PROTECTED]> wrote:
>
>: On another note, it seems to me that making the
>: polynomial itself a part of the key would
>: greatly increase security, but that possibility
>: is barely mentioned in his book.
>: Do you have any info on that?
>
>Using an LFSR alone is not at all secure. Using a key-dependent
>polynomial with an unknown tap sequence isn't at all secure either - you
>can figure it out from the output using the Berlekamp-Massey algorithm.
>
>In both cases there's little or no security. Consequently, whether one is
>an improvement over the other seems of marginal interest.
>
I disagree. There is almost always a tradeoff between the strength of
the encipherment and how long it has to last. If I was passing a hot tip
on a horse race that was due to start in 10 minutes, what good would an
11-minute crack be?
Many of the attacks mentioned in this newsgroup are actually quite labor
intensive, yet they are mentioned as if they are available through
pull-down menus. I believe that's because the contributors want to err
on the side of caution should they err at all. Not knowing exactly what
the questioner is after, they give the safest answer.
The B-M algorithm requires at least 2n bits of output from an n-bit
register for the attack. IIRC, that's 2n bits of the *register* output,
not what has been produced by the XOR of the register output and the
plaintext. Some assumptions can be made as to the plaintext content and
the attack can be made based on those assumptions. This, however, will
take some time and I refer you to the point I made in my first paragraph.
As to the original question, the Hughes XPD device does something similar
to what was asked -- an input to the device chooses both a particular tap
sequence and an init vector. Someone else mentioned this technique as
having the key be an index into a list of possible tap sequences. This
could be workable as long as the list is held very closely -- once it is
compromised, a large portion of your encipherment scheme is broken.
All that said, I would agree with Tim in the general case: a single LFSR
is not a good cipher engine. It has its uses in special cases and, when
multiple LFSR's are combined, can be the root of a very good cipher
engine.
------------------------------
Date: Thu, 12 Oct 2000 00:57:29 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: The science of secrecy: Simple Substition cipher
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> I couldn't agree more. The code took me at most 3 minutes to crack and
> the answer was way too obvious. After all, how many five letter
> composers are there with an 'L' in their name?
The other one is Liszt :-)
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOeTYhTkCAxeYt5gVAQF+CAf/YFkOuJ4vat8Ss4S63zXSDZ+p7flbTJIw
VsukJF5NORl3lhv9gQo6vzF60f5oCc/izAhIv2kCy/aR8jL0dVoQLLoPKw5uLYg4
D65RpNBYb1201HATfPZoAuQaQolV+uz0bSgmvnkJ4TtIDWmiAHoIXtHqcJvOEZJn
TD3RBdlQCVzYbGPNWAmn2MPjhO33hAzAOU7DGmwUfldKnjQPpuBxQrgHbb/Azvov
WTCNPMNy/STc7CB/ajHLB4Rif9i9LMwDGTaOEJ2TRXeoi59xRkYVSrK8eMXETrB5
0tnhAjybFqwSnwZeKPr+IT+NvVk95ARRzkMyulg1Acj2WqmvKJkgnQ==
=0ArV
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 12 Oct 2000 00:56:07 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Rijndael test vectors
=====BEGIN PGP SIGNED MESSAGE=====
Roger Schlafly wrote:
> Brian Gladman wrote:
> > Welcome to the endian world of AES!
> > A world I hope we can remove by getting the specification right on
> > such matters.
>
> Yes. I once implemented DES based on the spec, and then discovered
> that others used the bits in a different order. It seems the
> official spec talked about bits, but not bytes, leaving the
> order of bits in a byte ambiguous.
I was going to say that the Rijndael spec is clear about bit and
byte ordering, but on closer examination it never explicitly says that
the mapping of the key bytes to words follows the same convention as
the plaintext/ciphertext bytes (although that's obviously supposed to
be the case).
It would also be better to define explicitly how the bits b_0 to b_7
map to byte values in section 2.1, i.e.:
_7_
byte(b_0, .. b_7) = \ (b_i * 2^i)
/__
i=0
rather than relying on the example to make this clear.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOeT95DkCAxeYt5gVAQHAKQgAnzqcPjhPdgGrDXowCczr/7OOLj+nltmc
xeiMgcty+lI8zETbz9nYFSf8k4Q6CLBvQGwWbybVJGELJWrSv1k5svfCUB8xHalu
Ei9p+vnI8AjXyOQvQ6nKEw/KCe9Lns0lEMS/THysCG4b2iaz9/11v4R+paiJ4eHr
c7EzGXCmutEw+jPyqWO5vwCLYjl860rIv9jMFm5KxUGPib5q8GxHuaBkxlwkP5bH
qvc8aqfol2ksz18QzMVLM01rt//Dxc1qotV/JBSMEPYhVzqiV6TFI2oGzKR1xWmC
uPf6dABYiQ3BsNCGEgbAOIilNyGNULajlDheYdVC4ZyNxSlRIoKpeg==
=0L3P
=====END PGP SIGNATURE=====
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: AES Runner ups
Date: Wed, 11 Oct 2000 20:06:13 -0700
Greggy wrote:
> Well, now that is the most logical answer I have heard yet, but what
> does the government do if the AES is found weak? Do they step back and
> use 3des? Do they say we have to go back to something that we tried to
> obsolete? That makes no sense to me at all, but then 3des was exactly
> that for des, so I suppose it does make sense after all...
If some defect is found in the AES that makes it unsuitable for use in
its intended purpose, a new standard would have to be chosen. During the
AES process, effort was put into working out a way to select multiple
algorithms or backups or variable rounds, and all of these schemes were
rejected. Many of the reasons have been explained in this thread. Many
of them are in the rationale document.
It's really hard to create a standard that takes unknown future changes
into account. The probability that a substantial new weakness would be
found was taken into account in the AES process.
Unfortunately, the simple, obvious solutions tend to have
not-so-simple, not-so-obvious defects. For example, if the number of
rounds are negotiable, whole new types of attacks (on the negotiation
phase) have to be analyzed. Complexity is the enemy of security.
DS
------------------------------
From: Eric Cordian <[EMAIL PROTECTED]>
Subject: Re: A new paper claiming P=NP
Crossposted-To: comp.theory,sci.math,sci.op-research
Date: Thu, 12 Oct 2000 03:14:29 GMT
In comp.theory Paul Rubin <[EMAIL PROTECTED]> wrote:
> Anyway, getting away from the digression on what P and NP are and how
> to convert postscript to pdf, there's a discussion thread on Slashdot
> about this paper and it sounds like a false alarm. Someone over there
> who seemed to know what he was doing started reading it, and found
> enough mistakes in the first few pages that he didn't feel it necessary
> to bother reading further.
I'm in the process of digesting it thoroughly, and got the same impression
after reading a few pages. However, I'm willing to consider the
possibility that the author was the victim of a poor translation.
Russian notation and ways of thinking about mathematical things sometimes
differ from the presentations we are used to in the West.
O(N^6) sounds ballpark were such an algorithm to exist, once one starts
doing transitive closures while iterating over graph structures, and the
other types of operations such an algorithm would likely involve.
If it had been O(N^2) or O(N^3), it would have been far less credible a
claim.
I will probably try coding it in APL and see what it does on a real-world
problem that has been given a polynomial reduction into the realm of
minimal cliques. Testing such a program on random data is generally
useless for determining an upper bound on running time, as lots of these
NP-Hard problems have a trivial average case.
I'm hoping this is for real. If it isn't, maybe it's still some sort of
insight into doing Combinatorial Optimization efficiently.
--
Eric Michael Cordian 0+
O:.T:.O:. Mathematical Munitions Division
"Do What Thou Wilt Shall Be The Whole Of The Law"
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Comments on the AES winner
Date: Thu, 12 Oct 2000 03:16:08 GMT
In article <[EMAIL PROTECTED]>,
Jim Gillogly <[EMAIL PROTECTED]> wrote:
> Future Beacon wrote:
> > If I were in charge of government communication and I was also
> > interested in reading certain transmissions, I would encourage the
> > world to standardize on something I could crack and put a layer
> > under it for the really important stuff the government needs to
> > transmit; but I didn't intend to argue that with my question. There
> > are, no doubt, other opinions.
>
>Try it this way. Suppose you personally had set up an AES-like
>competition, and had gotten the same submissions and the same feedback
>from the best interested academic cryptographers in the world, as well
>as the same hardware implementation support from the NSA, any of which
>you are free to ignore. Suppose further that you have free choice to
>pick the next Future Beacon Encryption Standard. Given that feedback
>and your own native decision-making abilities and intelligence, how
>different would your choice have been, and why? Are you ready to
>declare the new FBES?
Just a minute. He is not questioning NIST's administration of the AES
process or their choice of the winner. I agree, and he may also agree,
that NIST has done an excellent and transparent job. His question is
whether the US government can break the AES. NIST is not the US
government.
I think that the original question is valid. For example there exists
industrial espionage. If you were the security expert of the Airbus
consortium (the big competitor of Boing) would you recommend to use the
AES for encrypting internal communications related to a one billion
dollar bid?
I would like to suggest an answer of sorts: AES will probably be the
best cipher available for years to come. It is possible that the US
government is able to break the AES, but in this case it can probably
break any other publicly available cipher too. So, if one needs the
speed or the inter-connectivity, the AES will be the best choice. If
you need a stronger cipher, you can always try super-encipherment using
several ciphers in series. Most specialists claim that the symmetric
cipher is the strongest link in a system anyway, and even with several
ciphers in series the government will probably be able to read the
plaintext by other means, including defects in the security protocol or
in the application, weaknesses in the operating system, electromagnetic
radiation of the equipment used, and so on. And that is just as well:
it would be a pity if security technology could be easily abused by tax
cheaters, thieves, terrorists and so on.
What should preoccupy us the most is the possibility of somebody in the
future discovering in the open a catastrophic break of the AES. That is
why I suggest that standard protocols should be in place that would
allow the AES algorithm to be substituted by another one in an
efficient manner if need should arise.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Comments on the AES winner
Date: Wed, 11 Oct 2000 20:49:21 -0700
[EMAIL PROTECTED] wrote:
> What should preoccupy us the most is the possibility of somebody in the
> future discovering in the open a catastrophic break of the AES. That is
> why I suggest that standard protocols should be in place that would
> allow the AES algorithm to be substituted by another one in an
> efficient manner if need should arise.
These protocols and substitution mechanisms then become a link that is
likely to be weaker than the AES. You can't make a system more secure by
adding another link to the chain.
DS
------------------------------
** 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
******************************
