Cryptography-Digest Digest #678, Volume #13 Mon, 12 Feb 01 02:13:00 EST
Contents:
Re: Universal Maurer-Test ([EMAIL PROTECTED])
Re: What is kerebos? (B. Wooster)
Re: Fractal encryption? (Tom St Denis)
Re: What is kerebos? ("Sam Simpson")
Re: (Wolfgang C)
Sorry! (Wolfgang C)
Re: Multiple-Key RSA cryptosystem ("Augusto Jun Devegili")
Re: ith bit of an LFSR sequence? (Benjamin Goldberg)
Re: What is kerebos? (John Savard)
Re: What is kerebos? (B. Wooster)
Re: Office / Excel encryption ("CMan")
Re: What is kerebos? (B. Wooster)
Re: RSA is not secure in many instances... ([EMAIL PROTECTED])
Re: Steganography with ASCII text files (Nicholas Sheppard)
Re: Password authentication with symmetric key exchange (Thomas Wu)
Re: Scramdisk, CDR and Win-NT ("Keith Wilkinson")
Re: CipherText patent still pending ("Douglas A. Gwyn")
Re: Steganography with ASCII text files ("Douglas A. Gwyn")
Re: CipherText patent still pending (Terry Ritter)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Universal Maurer-Test
Date: Mon, 12 Feb 2001 00:34:40 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I get a 404...
> --
> __________
> |im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
Sorry, I move the page and forgot about the link in that message. Try
http://www.streamsec.com/downloads.asp
Sent via Deja.com
http://www.deja.com/
------------------------------
From: B. Wooster <[EMAIL PROTECTED]>
Subject: Re: What is kerebos?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 12 Feb 2001 01:17:17 GMT
Thanks. After that I'll make sure to search on 'jackass'.
===========================
> On Sat, 10 Feb 2001 15:03:57 -0000, "Sam Simpson" <[EMAIL PROTECTED]> wrote:
>The internet has a great feature called a 'search engine'. Typing Kerberos
>into Google (http://www.google.com/search?q=kerberos ) gives a whole page of
>directly links to extremely useful and pertinent information in respect of
>your search term(s).
>
>Welcome to the internet experience.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Fractal encryption?
Date: Mon, 12 Feb 2001 01:11:27 GMT
In article <1iFh6.6017$[EMAIL PROTECTED]>,
"S. Welsh" <[EMAIL PROTECTED]> wrote:
> Group,
> I am not a crypto expert, indeed I have only basic knowlege of
> encryption techniques. However, I am curious to know if such a programme
> exists that allows one to use a fractal rather than a textual code to
> encrypt a document. If this sort of thing is purely Star Treknology, then
> please tell me, likewise if it is not!
>
> Thanks in advance,
Pure star trek dude.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: What is kerebos?
Date: Mon, 12 Feb 2001 01:29:36 -0000
Hopefully you'll manage to spell that right though, eh? ;)
--
Regards,
Sam
http://www.scramdisk.clara.net/
B. Wooster <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Thanks. After that I'll make sure to search on 'jackass'.
>
> ---------------------------
>
> > On Sat, 10 Feb 2001 15:03:57 -0000, "Sam Simpson" <[EMAIL PROTECTED]>
wrote:
>
> >The internet has a great feature called a 'search engine'. Typing
Kerberos
> >into Google (http://www.google.com/search?q=kerberos ) gives a whole page
of
> >directly links to extremely useful and pertinent information in respect
of
> >your search term(s).
> >
> >Welcome to the internet experience.
------------------------------
From: Wolfgang C <[EMAIL PROTECTED]>
Subject: Re:
Date: Mon, 12 Feb 2001 09:47:37 +0800
That was a mis-addressed mail. Sorry for the disturbance.
------------------------------
From: Wolfgang C <[EMAIL PROTECTED]>
Subject: Sorry!
Date: Mon, 12 Feb 2001 09:50:07 +0800
That was a mis-addressed mail. Sorry for the disturbance.
------------------------------
From: "Augusto Jun Devegili" <[EMAIL PROTECTED]>
Subject: Re: Multiple-Key RSA cryptosystem
Date: Sun, 11 Feb 2001 21:51:58 -0300
My purpose is a joint signature scheme.
"Roger Schlafly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> You have a system where 2 parties can collaborate to use their
> secret into to produce a message that anyone can decrypt. Why?
> Are you trying for a joint signature scheme? If you state what
> you really want to accomplish, you might get some help.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: ith bit of an LFSR sequence?
Date: Mon, 12 Feb 2001 02:33:00 GMT
Simon Johnson wrote:
>
> In article <[EMAIL PROTECTED]>,
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > Douglas A. Gwyn wrote:
> > >
> > > Benjamin Goldberg wrote:
> > > > If we know x (or know n bits starting at i), and know y, and
> > > > want to know i, what do we do? This is the second thing Bob
> > > > asked about.
> > > > THIS problem is exactly equal in difficulty to the discrete log
> > > > problem.
> > >
> > > This suggests the possibility of fast hardware DLP solvers...
> >
> > Maybe, maybe not. However, the discrete log problem needed to solve
> > this is the one over the field of GF(2)[x]/p(x), not over the field
> > of Z/Zp. What forms of encryption [if any] use GF(2)[x]/p(x) type
> > discrete logs as their strength?
>
> Hrm, as a side track i was wondering if all discrete logs in p^x where
> x is an integer greater than 1 and where p is a prime, is actually
> easier than computing a discrete logrithm in q, where q is a prime of
> the roughly the same size as p?
>
> I'm really not sure if that question even makes sense :)
It does make sense, though a bit awkwardly worded. You want to know
which is faster:
a) calculating n bit discrete logs in GF(2)[x]/p(x) or
b) calculating n bit discrete logs in Z/Zp
The answer is: (a) is easier.
On the other hand, exponentiating in GF(2)[x]/p(x) can be faster than
exponentiating in Z/Zp.
A real useful question to ask is the following: if an N bit polynomial
modulo and an M bit integer modulo are chosen such that taking discrete
logs in the groups they produce take equal time, in which group is
exponentiating faster?
For a given size, polys are faster to exponentiate, and faster to take
discrete logs of. Are both "faster" adjectives the same amount?
--
A solution in hand is worth two in the book.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: What is kerebos?
Date: Mon, 12 Feb 2001 02:12:53 GMT
On Sat, 10 Feb 2001 14:49:20 GMT, B. Wooster <[EMAIL PROTECTED]>
wrote, in part:
>Can someone fill me in as to what Kerebos (Cerebos?)
>security/encryption is? I'm sure others would be interested in
>knowing, too.
Well, there's a description of Kerberos on my web page, at:
http://home.ecn.ab.ca/~jsavard/crypto/mi060702.htm
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: B. Wooster <[EMAIL PROTECTED]>
Subject: Re: What is kerebos?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 12 Feb 2001 03:21:44 GMT
Many thanks. I'll take a look.
=========================================
> On Mon, 12 Feb 2001 02:12:53 GMT, [EMAIL PROTECTED] (John Savard)
>wrote:
>On Sat, 10 Feb 2001 14:49:20 GMT, B. Wooster <[EMAIL PROTECTED]>
>wrote, in part:
>
>>Can someone fill me in as to what Kerebos (Cerebos?)
>>security/encryption is? I'm sure others would be interested in
>>knowing, too.
>
>Well, there's a description of Kerberos on my web page, at:
>
>http://home.ecn.ab.ca/~jsavard/crypto/mi060702.htm
>
>John Savard
>http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: Re: Office / Excel encryption
Date: Sun, 11 Feb 2001 20:28:59 -0700
Ok, here's the deal:
Learn about structured storages. You will need to know this to be able to
access the "1Table" structure in the Excel file. The 1Table structure
contains three 16 byte numbers. The first is a random salt. The second is
a an MD5 hashed nonce encrypted using RC4 with a key (K). This encrypted
hash is stored as a second 16 byte number in 1Table. The nonce is encrypted
using key (K) and MD5 hashed then stored as a third 16 byte number in
1Table.
The key (K) is calculated in the following way:
The password (expressed in unicode) is MD5 hashed. The first five bytes of
the password hash are put into an array with the 1st 16 byte number (the
salt) stored in the 1Table structure. The salt is repeatedly concatenated
with the password and then padded according to the MD5 algorithm. The MD5
hash is taken. The first five bytes of this hash are saved and then padded
and MD5 hashed again. The first five bytes of this hash along with a counter
byte become the RC4 key for encrypting/decrypting the document. The counter
periodically re-keys the RC4 engine by incrementing the counter byte modulo
8.
This key is first MD5 hashed before RC4 key scheduling. This hash is the key
(K).
An approach to guessing the password is thus to brute force guess the
password and decrypt the second and decrypt and hash the third 1Table number
until there is a match. (The MD5 hash of the decrypted third number when MD5
hashed should equal the RC4 decrypted second number). This will work for
short, poorly chosen passwords. It will not work for well chosen passwords
because there is not enough time in the universe to do all the math
required.
There is a better way to recover the document. This is to recover the five
byte value which is the document key, add the counter byte and decrypt the
document. This method will always recover the document and can be
accomplished on hardware costing less than $1200 in a few days.
Use four Abit BH6 motherboards, four overclocked Celeron 300A processors.
Boot the motherboards disklessly from your network (use Linux of course, you
will have to recompile the kernel to get the NFS to mount properly...)
Make sure you have the eproms on the network cards properly configured to
run bootpd on start-up.
You will need to run PVM software or just manually divvy up the keyspace by
telneting to the individual motherboards and running shell scripts. If you
want to get fancy, you can run a free X-Windows client on a Windows machine
and control the whole shebang from your windows machine. Of course you will
have to cnt-alt-del occasionally on the windows unit but Linux will just
keep going and going and going...
On the second day, you can write Windows software to create a Word process,
jam load the recovered key and make Word do the document decryption.
Oh, the whole thing will run faster if you optimize your MD5 and RC4 code
taking into consideration the dual pipelined Celeron architecture and use
assembler code optimized for instruction pairing.
That's all there is to it. Good luck.
John E. Kuslich
--
CRAK Software
http://www.crak.com
Password Recovery Software
QuickBooks, Quicken, Access...More
Spam bait (credit E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
webmaster@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Try www.crak.com.
------------------------------
From: B. Wooster <[EMAIL PROTECTED]>
Subject: Re: What is kerebos?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 12 Feb 2001 03:26:52 GMT
Actually, I did. The dictionary has it as 'jackass' not 'jack ass'
<g>.
======================================================
> On Mon, 12 Feb 2001 01:29:36 -0000, "Sam Simpson" <[EMAIL PROTECTED]> wrote:
>Hopefully you'll manage to spell that right though, eh? ;)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA is not secure in many instances...
Date: Mon, 12 Feb 2001 03:42:20 GMT
> Very unlikely. See Section 9 of <http://eprint.iacr.org/2001/007/>.
That paper says strong prime is not needed. I don't think so. If
(p-1)(q-1) does not contain any large factor, it will be a disaster.
Try pick 2 (or 200) messages, call them m1 and m2
Suppose T=(p-1)(q-1) = 20 * p2 * ... * pk, all small primes
With certain probability, m1 = g^(p2 *... * pj)
With certain probability, m2 = g^(p_j+1 * ... * pk)
Then (m1 * m2) = g^(T/20)
(m1 * m2)^20 = g^T = 1
(m1 * m2)^20e = 1
If there's no large prime, the probability will be very favorable...
Spare my typing. You can figure out the rest.
(How come nobody sees what I really did with the theorem in my last
post? Again the answer is just one sentence long.)
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Mon, 12 Feb 2001 15:48:29 +1100
From: Nicholas Sheppard <[EMAIL PROTECTED]>
Subject: Re: Steganography with ASCII text files
On Sun, 11 Feb 2001, Mok-Kong Shen wrote:
> I think therefore that it may be valuable to investigate the
> possibility of using the normally more easily available ASCII
> text files (as cover) instead.
If all you want to do is transmit some information that is not obvious to
someone who isn't looking, this is easy using any number of simple schemes
such as the one you described, using variations on line-spacing,
word-spacing, etc. to encode information. Furthermore, if you want to keep
your message secret even from someone who discovers that the file contains
a message, combining the encoding with encryption will do this.
One encoding is probably as good as the other in terms of security,
though obviously some encodings will embed more information than others.
However, it is trivial for someone who knows (or suspects) that a secret
message exists to destroy the message by simply re-typesetting the HTML
file. E.g. these methods won't work for embedding a watermark, or if the
data is being intercepted by a paranoid censor.
--
Nicholas Sheppard | Ph: +61 2 4221 5290
Research Fellow | Fax: +61 2 4221 4170
School of Information Technology & Computer Science | E-mail: [EMAIL PROTECTED]
The University of Wollongong, Australia | WWW: www.uow.edu.au/~nps
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Password authentication with symmetric key exchange
Date: 11 Feb 2001 21:42:44 -0800
[EMAIL PROTECTED] writes:
> In article <[EMAIL PROTECTED]>,
> Thomas Wu <[EMAIL PROTECTED]> wrote:
> > Perhaps you'd get a better response if you could say how this protocol
> > is an improvement over the existing standard strong password
> authentication
> > protocols like SRP, SPEKE, or PAK, in any way, such as security or
> > performance. From glancing at your brief description, it appears to
> > use a "public system key", so it doesn't offer any performance
> > advantage over the status quo, and it appears to be breakable by an
> > eavesdropper with a dictionary.
>
> For short, the server challenges the client with a 64-bit salt, and the
> client replies with the correspondingly salted hash value of the
> password. The improvement is that Steak is MAC (or rather something
> similar) and cipher two-in-one, so you should get a performance
> benefit.
Can you give a performance comparison of your protocol compared to,
say, HMAC-SHA1? For authentication, the combination of "MAC and
cipher two-in-one" doesn't make sense, because a MAC is what accomplishes
the task of password authentication. One might use an encryption
algorithm to construct the MAC, but usually not both. Is Steak
faster than a pure MAC?
> Furthermore, since Steak is error propagating and the hash value is
> salted, an eavesdropper would not necessarily be helped by a dictionary.
But an eavesdropper can still conduct a brute-force guessing attack
if he captures the challenge and response. If Steak is faster than
HMAC-SHA1, it'll be that much faster to brute-force.
> Sent via Deja.com
> http://www.deja.com/
Tom
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
Crossposted-To: alt.security.scramdisk
Subject: Re: Scramdisk, CDR and Win-NT
Reply-To: [EMAIL PROTECTED]
From: "Keith Wilkinson" <[EMAIL PROTECTED]>
Date: Mon, 12 Feb 2001 06:02:54 GMT
In article <[EMAIL PROTECTED]>, Jungle wrote:
> thanks for warnings ...
> are you relying others stories or mostly your own horror ?
>
> normally past stories are from "past", where all just started to emerge,
> IMO almost all are the result of inappropriate use / abuse + low quality of media
> [ it's generalization but people are paying top money for hardware & save on media,
> you can see this when people are describing they HI-FI equipment,
> ask them what percentage of overall cost, the speakers weight, you will be
>suprice ]
>
> the new technology which I'm calling "don't run on empty stomach"
> is eliminating all these stories, as long as people don't have it,
> it's would pay to understand how & why these "flaky, ... not very robust"
> situations are present
>
I've used the packet writing software "PacketCD" from CeQuadrat - it came with my Sony
CDW/R drive. In theory it looks very good, although the capacity of a 650MB CD is
reduced
to 500+MB, but I have found it to be definitely flaky to the extent I no longer use
it.
I use either Kodak or Sony CDRs/CRWRs and have no problems with burning and reading
ISO/Joliet file systems but I have had lots of failures with packet writing/UDF.
Keith
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Mon, 12 Feb 2001 01:18:26 -0500
Mok-Kong Shen wrote:
> ... On the other hand, there is some
> chance, I believe, that the novices occassionally by
> chance/luck come upon some eventually useful ideas about
> cipher constructs that others have not reflected upon before.
It wouldn't matter, because the rare accidental improvement
would be lost in the sea of bad ideas not worth spending
time analyzing. There are *already* several *important*
cipher systems for which no practical method of attack is
(publicly) known. Anyone who can perform analysis at the
frontiers of knowledge will find it more rewarding to spend
his time working on *those* systems, rather than on some
unknown system, devised by an amateur, that is unlikely ever
to play an important role in science, commerce, or society.
Occasionally it is instructive to examine how such a system
can be attacked; e.g., many years ago in response to a
proposed amateur system named "crypto", I quickly wrote a
small program "otpryc" that performed automatic C/A of it
as an illustration of a couple of points that ought to be
understood before even starting to design any cryptosystem.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Steganography with ASCII text files
Date: Mon, 12 Feb 2001 01:25:40 -0500
Mok-Kong Shen wrote:
> I think therefore that it may be valuable to investigate the
> possibility of using the normally more easily available ASCII
> text files (as cover) instead.
Indeed, several people have already done just that.
As you observe, HTML allows one enough flexibility
to exploit steganographically. The same is true for
PDF, Word, and other common formats. Plain (ASCII)
text is trickier since there is less that can be
varied without affecting the appearance; even adding
spaces at the ends of text lines is easily seen by
many methods of viewing the files.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: CipherText patent still pending
Date: Mon, 12 Feb 2001 06:29:06 GMT
On Fri, 9 Feb 2001 17:13:38 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>> In some ways, the pharmaceutical analogy to cryptography is good. But
>> our situation is that *we* *really* *don't* *know* the dangers of
>> *any* of the ciphers we use, yet we use them anyway.
>
>However, we have the analogue of clinical trials and feedback from
>actual use by physicians. To continue the analogy, we don't throw
>drugs out to the physicians expecting them to perform the clinical
>trial phase for us. Prefiltering the possibilities is an
>essential function that the pharmaceutical companies perform.
One problem with analogies is that they can be subtle when they lead
us into false reasoning, as is the case here:
First, drugs are a profitable business which financially supports tens
of thousands of careers in extensive analysis and testing; ciphers are
not. The importance of financial support can scarcely be overstated.
Some consequences include: 1) there is no developed process of cipher
testing which in any way compares to the controlled trials of drug
tests; 2) drug test results are published independent of outcome,
while crypto results are normally published only when the cipher
fails; 3) failure in drug tests generally leads to a sequence of
different compounds and new tests, an iterative process much
deprecated in cryptography.
Basically, the drug business has the goal of finding or making a new
profitable drug and they go about it to achieve success. In contrast,
the major result of a new cipher is more likely to be argument than a
step in product development. These are wholly different processes.
Next, drugs have a scientific basis for extrapolating results from
some humans to others, and that basis is a common biology. But with
ciphers, it is wrong and unscientific to claim that our opponents must
have the same limitations as the academics who make up our ad hoc
voluntary tests. In reality, we can't even expect to predict what a
good friend could or could not do against a cipher, let alone an
unknown but highly-motivated and well-supported professional group.
Yet we do expect our ciphers to defeat just such a group.
Finally -- and this is critical -- when we give drugs, we know who got
them and can see the ultimate results. But when we use ciphers, the
critical issue is what happens *with* *the* *opponents*, where we
cannot see the outcome. We thus have no way to validate our
extrapolations, which makes them just superstitious dreams and not
science.
If the goal is to use a cipher to protect information from hidden
knowledge, no testing whatsoever can achieve that goal. Yet drug
testing does tell us what we need to know about drugs. That means the
drug analogy to ciphers is tricky, needing caution when drawing
conclusions.
>> Over 50 years of mathematical cryptography and 20+ years of intensive
>> DES analysis have yet to produce *EVEN* *ONE* practical cipher in
>> which there is a mathematical basis for knowing and trusting strength.
>> That includes the OTP.
>
>That only includes OTP because it might not be "practical" due
>to its key distribution requirements. The OTP *algorithm* is
>provably secure if its key is uniform-random.
I would say that nobody can *use* an "algorithm" itself. To use an
algorithm we must first implement it in our minds, or have an
implementation in a computer or whatever. These implementations are
not the algorithm, but are only implementations of the algorithm, and
are vulnerable to imperfect reality in many ways. Unfortunately, only
implementations of algorithms can protect real data.
If we are talking about actual use, then the "OTP" is only provably
secure if its key is *provably* unpredictable (no matter how "random"
it looks or tests; no matter how unpredictable it really is). And
keystream unpredictability is something which generally cannot be
proven, and certainly cannot be tested.
It seems to me that the theoretical OTP proof has created far more
confusion than clarity or insight.
>In fact it is not hard to create secure crypto algorithms with
>provable level of security (in terms I've described long ago).
>What is hard is coming up with *practical* systems using such
>algorithms. There is the fundamental problem that a short key
>used for encryption of a long plaintext from a source with high
>redundancy *must* be "insecure" according to information theory.
There are various types of insecurity. Practical ciphers generally
*are* insecure against infinite computational resources. Fortunately,
nobody has such resources.
A satisfactory solution might be to have a proof which requires some
known amount of computation to break a ciphering technique, and then
design the particular cipher so that amount of computation is "large
enough." (That is the classic argument for key size, and also one of
the classic RSA strength arguments, so there is no "fundamental
problem" with the approach.) The "fundamental problem" thus does
*not* prevent us from achieving provable strength in practice, in a
statistical sense.
It may be attractive to consider information theory with respect to
hashing and modern combiners: We know how much information is needed
to reconstruct an internal RNG state. If we can show that the needed
amount is simply not available to the opponent, we might prove whole
classes of attacks impractical.
Consider the case where we transfer new key material frequently,
during a message. That is, we re-key after producing some amount of
ciphertext. Clearly, if we transfer as much key as data, the system
is as secure as the key. But if instead we first expand the key into
a large internal RNG state, and then hash some function of that state,
we might be able to show that a huge amount of ciphertext would be
needed to solve the internal state. So as long as we never produce
that amount of ciphertext before re-keying, the system might be
provably secure in practice against such attack. Messages with less
than that amount of ciphertext would not even need additional keying.
>What one would like is to thwart all practical methods of attack
>against the system; what one typically sees instead is a design
>that thwarts just certain specific methods of attack *known* to
>the designer.
Without some proof which applies in practice to all possible attacks,
I would say that dealing with known attacks is the best any cipher
designer anywhere can do. That would include all the cipher designers
in NSA, for example, excepting only that they probably have a much
better understanding of attacks than we do.
Lacking proofs, addressing known (or suspected) attacks is all any
designer can do.
As far as I can see, this cannot be a controversial issue, because the
logic of the situation admits only these solutions. So if you know of
something beyond this, or some limitation of this reasoning, it is
time to trot it out. Otherwise, it is time to stop hinting about a
better way that can have no logical basis.
>> Is it really rational to wait and hope that the math guys will
>> eventually find techniques to handle the ciphers we already have? Or
>> is it more rational to continue to design new ciphers, thus opening
>> the possibility that easier math can do what no math has so far done?
>
>I don't see how continual design of new ciphers contributes
>much to progress in the general theory of cryptanalysis, which
>is after all what is essential for designing good cryptosystems.
>It is *possible* that a radically new design will inspire some
>breakthrough in cryptanalytic theory, but one can't count on it.
On the contrary, it is the cryptanalysis which cannot be counted on.
In application, cryptanalysis is how we understand a cipher. It
allows us to know weakness with respect to particular attacks --
except that most "attacks" are general concepts which require a person
for elaboration. We don't see many academic papers saying, "I looked
at such and such attack, and it won't work on this cipher," because
such a statement is too easily wrong. Yet that is precisely the kind
of statement we need.
Cryptanalysis can address the currently known attacks, but does not
say anything about the strength of a cipher given the hidden knowledge
of our opponents. Cryptanalysis simply does not address whether our
cipher will protect our data from our opponents, unless our opponents
are academics. And that seems odd, because cipher strength with
respect to real opponents is the only thing that matters.
New ciphers provide new opportunities for proof. The goal is to get
both a cipher and a proof. We know that 25 years of Feistel ciphers
and related proof approaches have not achieved the goal. If we are to
achieve success, we should expect to have to work with new ciphers.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
