Cryptography-Digest Digest #494, Volume #12 Mon, 21 Aug 00 05:13:00 EDT
Contents:
Re: Bytes, octets, chars, and characters (Richard Heathfield)
Re: Bytes, octets, chars, and characters (fvw)
Re: blowfish problem (Richard Heathfield)
wrong timing results on Twofish? ("Miki Watts")
Re: Lehmann Primality Test (Mack)
Re: wrong timing results on Twofish? ("kihdip")
Re: Bytes, octets, chars, and characters ("Clark S. Cox III")
Re: Bytes, octets, chars, and characters (John Winters)
Re: IDEA algorithm - how to license? ([EMAIL PROTECTED])
Re: OTP using BBS generator? (Bryan Olson)
Re: OTP using BBS generator? (Bryan Olson)
CRC? (Mario Tonni)
Re: Breaking Simple XOR Encryption (Eric Hambuch)
Re: OTP using BBS generator? (Bryan Olson)
Re: CRC? (S. T. L.)
Re: News re annotated version of "Fire Upon the Deep" (Paul Rubin)
SHA-1 program (S. T. L.)
Re: OTP using BBS generator? (Mok-Kong Shen)
On pseudo-random permutation (Mok-Kong Shen)
Re: OTP using BBS generator? (Mok-Kong Shen)
Re: Proposal of drafting rules of conduct of posting (Mok-Kong Shen)
Re: Question on Decorelation Theory (Mok-Kong Shen)
Re: How Many? (Mok-Kong Shen)
----------------------------------------------------------------------------
Date: Mon, 21 Aug 2000 06:38:11 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Guy Macon wrote:
>
<snip>
> Did you know that "Computer" was a job title long before the
> "mechanical computer" and "electronic computer" were developed?
Yep.
>
> (In case anyone doesn't know, the definitive and canonical version of
> the Jargon File is at [ http://pebbles.eps.mcgill.ca/jargon/ ]. There
> are a LOT of outdated versions on the 'Net, so bookmark this one.)
Well, perhaps not. FWIW www.tuxedo.org/~esr/jargon is the definitive
location (since it's the site actually maintained by Eric Raymond (who
is the current custodian of the Jargon File).
<snip>
>
> 2 bits:
> crumb, quad, quarter, tayste, tydbit
<grin> I knew about "tayste", but I'd either forgotten, or never come
across, "tydbit".
>
> 4 bits:
> nybble
I wonder. Is that, or the preceding, number of bits correct in C? I'd
argue 'yes', i.e. that a nybble is always four bits - but there's an
argument for a nybble being half a byte (i.e. potentially any of many
values).
>
> 5 bits:
> nickle
I don't understand this one. Locale-specific reference?
>
> 10 bits:
> deckle
Same here.
<snip>
Isn't this terribly off=topic over in sci.crypt? Followups set.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
65 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (32
to go)
------------------------------
From: [EMAIL PROTECTED] (fvw)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Reply-To: [EMAIL PROTECTED]
Date: Mon, 21 Aug 2000 05:51:52 GMT
<8nq0uk$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
>playte, chawmp (on a 32-bit machine), word (on a 16-bit machine),
>half-word (on a 32-bit machine).
Ok, I'm confused now. I though a word was always 2 bytes on whatever
architecture you happen to be living?
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
Date: Mon, 21 Aug 2000 07:02:46 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
"Trevor L. Jackson, III" wrote:
>
> Gergo Barany wrote:
>
> > Daniel Leonard <[EMAIL PROTECTED]> wrote:
> > > I do not want to be rude, but there are some "errors" in your code.
> >
> > I do not want to be rude, but your news software posts in some
> > funky "Quoted-Printable" encoding. It makes your posts hard to read
> > because it replaces many characters such as '=' with a code like
> > "=<hex>", where <hex> is a character's ASCII code in hexadecimal.
> > This stinks, please turn it off.
> >
> > > On 17 Aug 2000, John Hascall wrote:
> > > > =09out =3D malloc(inLen * 2 + 1);
> > >
> > > shouldn't it be:
> > > out =3D malloc((inLen * 2 + 1) * sizeof(char));
> > > /* a char could be more than 1 byte */
> >
> > No, a char is always one byte in C.
>
> No it's not. A character is the minimum unit of addressability, which may be
> other than a byte. Espcially on older machines, making this assumption is an
> error.
Not if you're writing in ISO C, which is the topic of comp.lang.c.
This is a cross-posting issue. The ISO C Standard defines the language
as far as comp.lang.c is concerned, and that is whence Gergo's point of
view springs.
I suggest that, for the sake of peace, harmony, and love between
sci.crypt and comp.lang.c, we agree to differ on this point.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
65 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (32
to go)
------------------------------
From: "Miki Watts" <[EMAIL PROTECTED]>
Subject: wrong timing results on Twofish?
Date: Mon, 21 Aug 2000 09:17:44 +0200
Hi!
I've been trying to measure Twofish performance, but i think that my results
are wrong in someway. I ran the source over a P II 400 mhz, 64 mb, and used
MSVC++ 6.0. I took the timing counters from the internal ticks counter.
I then generated a random message and encrypted and decrypted it. My results
show for 10,000 message, each size 1024, with the key being changed every 10
messages, to get an output of only 6.5 mb - 8 mb per sec.
I don't think those results are correct, so if someone can tell me how i can
measure it properly or find timings, i'd be most grateful.
TIA
Miki Watts
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Lehmann Primality Test
Date: 21 Aug 2000 06:35:00 GMT
>
>Wasn't that paper by Rivest? And wasn't it shown that the Fermat
>method is wrong with a higher probability?
>
>Tom
>
>
ack ... sorry thinking rabin should be Rivest.
In that paper it was shown that all random 256 bit numbers that
had no factors less than 10,000 and passed the Fermat test
also passed the Rabin-Miller test.
Stats from the paper:
43,741,404 numbers passed the small factor test
4,058,000 numbers passed the fermat test
4,058,000 numbers passed the rabin-miller test
Meaning that Fermat Pseudoprimes are evedently a
small fraction of numbers and carmicheal numbers
are an even smaller fraction.
The paper goes on to say that only 1 in 10^22 numbers
that passes the small factor and fermat tests is pseudoprime
for 256 bit numbers.
Since we are now using larger primes the margin is increased.
Yes, the Rabin-Miller test is more reliable. By how much I won't
venture a guess. The theory says that RM is wrong no more than
1/4 of the time. Empirical evidence says that it is wrong only 1/10^22
of the time or less.
Of course if you are worried about carmicheal numbers don't use
a probabilistic test.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: wrong timing results on Twofish?
Date: Mon, 21 Aug 2000 08:39:27 +0200
I'm using the optimised code from the AES homepage, and running this on my
Pentium 166 MHz with WIN NT, I get 16 Mbit / sec.
However, this is with a fixed key!
On a Athlon 700 MHz the throughput was approx. 80 Mbit / sec. - Still with a
fixed key and the optimised code. (Not using the assembler code though).
Kim
Miki Watts wrote in message <[EMAIL PROTECTED]>...
>Hi!
>I've been trying to
------------------------------
From: "Clark S. Cox III" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: Mon, 21 Aug 2000 02:40:48 -0400
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> <8nq0uk$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
> >playte, chawmp (on a 32-bit machine), word (on a 16-bit machine),
> >half-word (on a 32-bit machine).
>
> Ok, I'm confused now. I though a word was always 2 bytes on whatever
> architecture you happen to be living?
I was under the impression that a word was 16-bits on a 16-bit
machine, 32 on a 32-bit machine, etc. And that in C/C++, 'int' usually
corresponded to a word.
--
Clark S. Cox, III
[EMAIL PROTECTED]
If youčre not part of the solution, youčre part of the precipitate.
-- Steven Wright
------------------------------
From: [EMAIL PROTECTED] (John Winters)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 21 Aug 2000 07:53:14 +0100
In article <[EMAIL PROTECTED]>, fvw <[EMAIL PROTECTED]> wrote:
><8nq0uk$[EMAIL PROTECTED]> ([EMAIL PROTECTED]):
>>playte, chawmp (on a 32-bit machine), word (on a 16-bit machine),
>>half-word (on a 32-bit machine).
>
>Ok, I'm confused now. I though a word was always 2 bytes on whatever
>architecture you happen to be living?
Definitely not - a word is the natural size of number for manipulation
of the machine - sometimes a little hard to pin down. The misconception
that a word is two bytes comes from the every-computer-is-a-PC-running-DOS
brigade.
John
--
John Winters. Wallingford, Oxon, England.
The Linux Emporium - the source for Linux CDs in the UK
See http://www.linuxemporium.co.uk/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: IDEA algorithm - how to license?
Date: Mon, 21 Aug 2000 07:00:44 GMT
In article
<[EMAIL PROTECTED]>, "David
Thom" <[EMAIL PROTECTED]> wrote:
> We've been trying to contact Ascom, the people who claim to license the IDEA
> algorithm (http://www.ascom.ch/infosec/), for the past 2+ weeks.
>
> We've send emails repeatedly to the addresses on their web site
> ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) and
> have even filled-in their web form asking for information...no response (the
> emails are returned after 5 days as undeliverable).
>
> Is Ascom the correct company? Is this a for-real business?
>
> David Thom
> NPSi Houston
>
IDEA licensing has been transferred from Ascom to iT_Security Ltd. Technical
and Licensing information is available on their web site: www.it-sec.com.
Peter Hartmann
oT_SEC
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 21 Aug 2000 07:33:33 GMT
John Savard wrote:
> Bryan Olson wrote, in part:
> >Using the OTP, the chance of any message given the
> >ciphertext is the same as the chance of that message when
> >not given the ciphertext. That follows from the uniform
> >keyspace; if you try instead the conditional probabilities
> >given specific keys, the secrecy of the system vanishes, as
> >Shannon warns up front.
>
> Now, this doesn't seem to say more than that even the OTP is not
> secure if the attacker _knows_ the key, so that doesn't seem to be
> germane. Whatever the problem is, it isn't that the attacker *knew*
> you were going to use an OTP with 000...000 on it.
Even if we accept that the attacker doesn't get any
information on the choice we make, we lose the proof of
secrecy. The attacker knowing the distribution from which
the key was drawn is no longer the worst-case assumption.
> >An attacker's chance of factoring a known modulus given BBS
> >output (from a random starting point) is the same as his
> >chance without the generator output. Again, that follows
> >from the space of possible choices.
>
> >The two systems certainly are different, and the title of
> >this thread is unfortunate, since BBS has nothing to do with
> >the OTP. The issue that secrecy comes from the keyspace and
> >not the key applies to all secrecy systems.
>
> But that is what the *other* poster said, in effect. The fact that the
> OTP value didn't *have* to be zero is claimed to give secrecy - even
> in the case where the key happened to be zero.
But claiming it's secure in the case when one chooses the
zero key is wrong. It is not the individual cases that are
secure - secrecy is only provable for the set of cases with
their probabilities.
The belief that each key is equally likely is not a
limitation that we get to impose upon the attacker as some
seemed to think. It is, when considering the uniform
keyspace, the worst-case assumption and thus our system is
as secure no matter what the believes the keyspace to be.
> Besides rejecting the all-zero pad, how far should one go, though?
>
> Presumably, on the basis that the attacker does not know that an OTP
> is being used, but will consider other, lesser, systems, one should
>
> (!)
> reject all pads that correspond to any XOR stream cipher that could be
> solved on the basis of a single message of the same size as the pad.
> (!)
>
> Thus, for example, a pad consisting entirely of a short, repeated,
> sequence of bytes should also be rejected.
No, no, no. Choose the keys uniformly. One might well
reject the generator on this basis, but equally probable
keys are the ideal.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 21 Aug 2000 07:46:47 GMT
Mok-Kong Shen wrote:
> So it appears that in the proof of security of OTP one
> needs an additional assumption:
>
> The opponent knows (and is convinced) that the
> sender uses an OTP.
The proof holds for the keyspace, so the assumption is the
worst case and any violation can only hurt the attacker.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mario Tonni <[EMAIL PROTECTED]>
Crossposted-To: alt.msdos.programmer,comp.lang.c,comp.lang.c++,comp.os.msdos.programmer
Subject: CRC?
Date: Mon, 21 Aug 2000 03:13:10 +0200
Hi there.
Often I hear the term "CRC", which I know that means
"cyclic redundancy check".
What I wonder instead is if CRC's are error-recovering
methods, or simply a more reliable way to calculate a
checksum?
If so, could anybody provide me a C code to calculate the
32 (or better 64) bits CRC?
I know that checksums are simply a serie of ADD or XOR
on all your data.. but CRC (in case it's not a more
sophisticated error-recovering scheme, as the ones used
e.g. on Compact Discs) seems more complicated to calculate
than checksums, could anybody help, please?
Thanks!
Mario
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: Breaking Simple XOR Encryption
Date: Mon, 21 Aug 2000 10:15:04 +0200
Peter wrote:
>
> After unsuccessfully searching the deja.com usenet archives
> for a relevant thread I have decided to post my (mundane) question to
> the forum.
>
> I would appreciate an explanation of the attack that is used against
> simple XOR "encryption" schemes.
>
> I have read section 1.2.3 of Schneier (1994) which is (understandably)
> curt and I do not understand the method explained.
A fast algorithm is described in:
T. Jakobsen, Thomas Jakobsen, A Fast Method for Cryptanalysis of
Substitution Ciphers, Cryptologia 19(3), July 1995.
(see http://www.counterpane.com/biblio/all-by-author.html)
Eric
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 21 Aug 2000 08:07:58 GMT
Mok-Kong Shen wrote:
> To put the assumptions explicit:
[...]
> (3) The apriori
> probability of the opponent guessing the message is zero.
How could that ever hold?
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Date: 21 Aug 2000 08:20:52 GMT
Subject: Re: CRC?
<<What I wonder instead is if CRC's are error-recovering
methods, or simply a more reliable way to calculate a
checksum?
If so, could anybody provide me a C code to calculate the
32 (or better 64) bits CRC?>>
I much prefer the SHA-1 algorithm for error detection. It absolutely
guarantees error detection if you use the full 160 bits, and even 64 bits of
output is quite strong. And the best part is that it makes sense.
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
Optimized pngcrush executable now on my Download page!
Long live pngcrush! :->
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: rec.arts.sf.written
Subject: Re: News re annotated version of "Fire Upon the Deep"
Date: 21 Aug 2000 08:24:07 GMT
Eric Lee Green <[EMAIL PROTECTED]> wrote:
>I have to laugh at all the so-called "secure" digital media initiatives.
>No matter how deeply you encrypt things, sooner or later your software
>has to decrypt them in order to display them or shove them into the
>music hardware.
If and when the Intel TCPA stuff becomes real, you'll be laughing out
the other side of your face. It's worse than you're imagining. :(
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Date: 21 Aug 2000 08:26:30 GMT
Subject: SHA-1 program
I've programmed a little thing that calculates the SHA-1 hash of a given file;
it's the first real thing I've done in C, so the source code is probably ugly,
but it's there. It's available at http://members.aol.com/stl137/download.html
. Both the binary (29KB) and the C source code (13KB) are provided, and are
distributed under the GNU GPL. I never did find a quick utility to calculate
an SHA-1 hash, so I made my own. :-P Most of the code is crufty; the one
thing I'm sort of proud of is the part that pads the message on the fly (no
temp files!). Perhaps someone on sci.crypt will find it useful or hilarious,
though I'd prefer the former to the latter. Heh.
Enjoy!
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
Optimized pngcrush executable now on my Download page!
Long live pngcrush! :->
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 21 Aug 2000 10:50:41 +0200
"D. J. Bernstein" wrote:
>
> Mark Wooding <[EMAIL PROTECTED]> wrote:
> > Make N large enough that factoring N is impractical.
>
> Where do people get this idea? If you want to apply the theorems, you
> need _much_ larger values of N.
>
> Consider, for example, the Alexi-Chor-Goldreich-Schnorr theorem, which
> tells you how to factor N using 10^54 (lg N)^3 applications of an
> algorithm that has a 1/1000 chance of seeing a pattern in a billion bits
> produced by a BBS generator mod N. The theorem doesn't say that
> predicting the generator is as hard as factoring N; it allows a ratio of
> speeds as large as 10^54 (lg N)^3.
>
> This tells you nothing if you merely assume that the attacker needs
> practically forever to factor N. You have to assume that the attacker
> needs 10^54 (lg N)^3 times practically forever. That assumption is false
> if N has, say, 3000 digits.
Thank you very much for the valuable information.
Having only humble math knowledge, I find it often very
difficult to really comprehend certain modern literatures
in cryptology, where much math knowledge is assumed, the
argumentation is very condensed, quite a lot is based on
other publications of equally high level and (probably)
the implications of certain assumptions being made are
not sufficiently heavily stressed by the authors. I
conjecture, however, that I am not the single person in
the group facing such difficulties. That the topic BBS
has frequently recurred and each time resulted in
voluminous discussions is a clear indication of this,
I suppose.
How are those like myself having difficulties with very
deep literatures going to do? I guess that there are
three ways. The first is to catch up with the high math.
That's certainly the best. But that can take time and
presumably not everyone is good at that. (At least I
doubt very much my ability in this direction.) The
second is to rely completely on the claims of the
experts. But this is by nature not very satisfying and
sounds like plain religious belief. The third is to take
a conservative standpoint in applying the results that
are based on theories that one has not been able to
completely understand. I believe that this last is
probably a sufficiently practical and realistic path
that the majority of persons of the category delineated
above could advantageously follow. This means in the
particular context of the present thread that we
conduct sufficient amount of tests on the bit sequences
obtained with test methods that are known and available
and feasible to us, in order to compensate the potential
(unkown) risk of insecurity resulting from eventual
misunderstanding or inappropriate application of the
theories involved. This may be considered to be another
essential reason supporting my suggestion in previous
follow-ups of having extensive statistical tests done
before BBS is used in one's own applications.
I have the (maybe wrong) impression that hardly anyone
of us has currently very essential practical experiences
with BBS. While this thread is now seemingly approaching
its quiesence point, I like to take the opportunity to
express my humble and sincere hope to be able to hear
from experts reporting on their experiences in real-life
applications, in particular results of investigations
of various statistical qualities of LSB of the generator,
when someday BBS is once again on the agenda of the
group.
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.programming
Subject: On pseudo-random permutation
Date: Mon, 21 Aug 2000 10:50:36 +0200
Note: The following is related to an article on application
of the Feistel encryption method that I posted sometime ago
in sci.crypt.
Pseudo-random permutation is commonly done with a PRNG giving
real values in [0,1) according to an algorithm due to
Durstenfeld (see Knuth vol. 2). Sometimes one has, however,
a pseudo-random bit sequence given, instead of a PRNG of
the said kind. In that case, I suggest that it is more
convenient to do the following, instead of trying to contruct
from the given bit sequence a PRNG for use:
Let A[1..n] be the array to be permuted, B[1..n] be an array
of records of two unsigned integers, with the first component
of each record filled with the pseudo-random bits (m bits
are used for each unsigned integer of size m, which is thus
a random number in [0, 2^m-1]) and the second component of
the records set consecutively to 1..n. We sort the array B
according to the first component of the records in ascending
order so that the second component now gives the original
(i.e. before sorting) array-index of the individual records.
With these indices, which form edivently a random permutation
of 1..n, the array A can be re-ordered.
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Mon, 21 Aug 2000 10:50:52 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
>
> > To put the assumptions explicit:
> [...]
> > (3) The apriori
> > probability of the opponent guessing the message is zero.
>
> How could that ever hold?
You are right in questioning that. A contrived 'theoretical'
case is that the spy cast a perfect die to determine (out
of the blue) what he wants to talk to his colleagues. Note
that the condition (1) that the agency CAN generate an
ideal OTP is also purely hypothetical, there be no
practical means of knowing that a given source indeed
produces an ideal OTP, as far as I am aware.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Proposal of drafting rules of conduct of posting
Date: Mon, 21 Aug 2000 10:50:29 +0200
Mok-Kong Shen wrote:
>
> I have a suggestion. Wouldn't it be nice that we have
[snip]
As I already anticipated previously, my proposal failed
and in fact very heavily.
The opinion of the absolute majority of the group to maintain
the status quo in the present issue is thus entirely clear.
I have no personal comment on the result, having had ample
opportunities to express my humble viewpoints on the matter
in a number of previous follow-ups in this thread.
Thanks to everyone who has participated in discussions.
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Question on Decorelation Theory
Date: Mon, 21 Aug 2000 10:50:57 +0200
[EMAIL PROTECTED] wrote:
>
> In the paper "Provably Security for Block Ciphers by Decorrelation" by
> Serge Vaudenay. Page 5, Section 2 "Basic Constructions" and I quote
Could you also give the name of the journal? Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: How Many?
Date: Mon, 21 Aug 2000 10:50:48 +0200
"David A. Wagner" wrote:
>
> I agree that complication can often be used to enhance security.
> At the same time, it is worth remembering the usual argument against
> unnecessary complications: complexity makes gaining confidence in a
> design substantially more costly. Given that we, the open community,
> are working with very limited cryptanalysis resources, this is is a
> reasonable concern.
On the other hand there are (intuitively) fairly safe means
of introducing complications, like increasing the number of
rounds (which the block ciphers have actually done in fact,
there being no one-round block cipher, as far as I am aware)
or employing more S-boxes or similar functions/constructs
that are excluded from the designs simply because of
external requirements of running on low-end hardware etc.
and not because of inherent crypto reasonings.
M. K. Shen
------------------------------
** 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
******************************
