Cryptography-Digest Digest #232, Volume #11       Thu, 2 Mar 00 01:13:01 EST

Contents:
  Re: Processor speeds. ("Clockwork")
  Re: Processor speeds. ("Clockwork")
  Re: Processor speeds. ("Clockwork")
  Re: Visual C++ Decompiling Service/Software Needed (JPeschel)
  Re: First contact, establishing password without public keys (Paul Rubin)
  Re: very tiny algorithm - any better than XOR? (David A. Wagner)
  Re: very tiny algorithm - any better than XOR? (David A. Wagner)
  Re: brute force attack on a 128 bit SSL key? (Michael Sierchio)
  Re: very tiny algorithm - any better than XOR? (David A. Wagner)
  Re: ...but what about my cipher? ("Harvey Rook")
  Re: brute force attack on a 128 bit SSL key? (Jerry Coffin)
  Re: Plain-text attack on ZIP file (Nemo psj)
  Re: very tiny algorithm - any better than XOR? (Paul Rubin)
  Re: https (Paul Rubin)
  Re: very tiny algorithm - any better than XOR? ("Harvey Rook")
  Re: Best language for encryption?? ("Douglas A. Gwyn")
  Re: Best language for encryption?? ("Douglas A. Gwyn")
  Re: Best language for encryption?? ("Douglas A. Gwyn")
  Re: Passwords secure against dictionary attacks? (jungle)
  Re: Best language for encryption?? ("Douglas A. Gwyn")
  Re: Crypto.Com, Inc. ("Douglas A. Gwyn")
  Re: Can someone break this cipher? ("Douglas A. Gwyn")
  Re: On jamming interception networks ("Douglas A. Gwyn")
  Re: On jamming interception networks ("Douglas A. Gwyn")
  Re: On jamming interception networks ("Douglas A. Gwyn")
  Re: And when you read my postings since April, 1999 .. you find out one  ("Douglas 
A. Gwyn")
  Re: Q: 'Linear encipherment' ("Douglas A. Gwyn")

----------------------------------------------------------------------------

Reply-To: "Clockwork" <[EMAIL PROTECTED]>
From: "Clockwork" <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Date: Thu, 02 Mar 2000 02:09:45 GMT

"_Andy_" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Thu, 24 Feb 2000 17:53:21 -0700, "John E. Kuslich"
> <[EMAIL PROTECTED]> wrote:
>
> >No problems.
> >
> >Do these things come with ethernet and TCP/IP stacks??
> >
> >I really know nothing about them, but the idea seems very exciting.
> >
> >I would like to hear more.
> >
> >JK
>
> Me too.
>
> I've not seen one of these consoles yet. I think I'll take a trip to
> the Trocedero and chat to the 2600 junkies this week - they play a lot
> of games.
>
> How would one go about connecting a hard-drive (or am I being stupid)?
>
> As a general rule of thumb, I don't really like the idea of forking
> out money for brand new hardware only to open it up immediately and
> start playing around with the guts... I have the Medusa touch when it
> comes to such things. ;)
>
>

If we filled the volume of the Moon with Atari 2600s, we would have just
about enough horsepower to crack XOR encryption :)

Clock



------------------------------

Reply-To: "Clockwork" <[EMAIL PROTECTED]>
From: "Clockwork" <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Date: Thu, 02 Mar 2000 02:13:05 GMT

"John E. Kuslich" <[EMAIL PROTECTED]> wrote in message
news:2scv4.535$[EMAIL PROTECTED]...
> Just as a benchmark, how many polygons per second can a pentium III 500Mhz
> do using a standard video card?

You should post that question in a different news group... You will pay
++more++ to do it is the bottom line.

Clock



------------------------------

Reply-To: "Clockwork" <[EMAIL PROTECTED]>
From: "Clockwork" <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Date: Thu, 02 Mar 2000 02:13:51 GMT


"_Andy_" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Wed, 23 Feb 2000 01:18:03 -0000, "Joseph Ashwood"
> <[EMAIL PROTECTED]> wrote:
>
> >> Another question: When was the last time your console
> >crashed?
> >You don't really want me to answer that, my console is 9 1/2
> >years old and has slowly developed a hardware problem.
> >                Joe
>
> Really? This sounds like an interesting idea. Someone could have a go
> using my old Atari console if they wish. There's only one knob on it
> that you turn. Perhaps a distributed key generation system over 30
> consoles, and with mine playing Tennis... :)
>
>

<Sigh>



------------------------------

From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Visual C++ Decompiling Service/Software Needed
Date: 02 Mar 2000 02:40:23 GMT

[EMAIL PROTECTED] writes:

>Decompiling copyrighted software is a crime (as long as you don't do it only
>to correct errors or need to make changes for compatibility reasons).

Interesting. Where is "decompiling" software a crime? Europe?
In the US, "decompiling," disassembling, or reverse-engineering
is only illegal in a few specific instances.

[EMAIL PROTECTED]'s project does sound unethical, but
I think he would face only a civil suit. 

There is only one decompiler project that I know of, and the
decompiled text generated by the program is not terribly close
to the original C source code. Of course, with a good disassembler,
and knowledge of Assembly and C you could reproduce
something close to the original source.

Joe


__________________________________________

Joe Peschel 
D.O.E. SysWorks                                 
http://members.aol.com/jpeschel/index.htm
__________________________________________


------------------------------

From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: First contact, establishing password without public keys
Date: 2 Mar 2000 03:07:08 GMT

In article <89k38j$c9g$[EMAIL PROTECTED]>,
Bill Unruh <[EMAIL PROTECTED]> wrote:
>In <[EMAIL PROTECTED]> Ken Savage <[EMAIL PROTECTED]> writes:
>>away with this.  Alice can relatively easily find a pair of strings
>>whose partial-MD5 is mmmmmmmm, but Eve would have to try out many
>>many strings to find even ONE string whose MD5 is mmmmmm, yet alone
>>a pair of them.
>
>No. It is as hard for Alice to find a second string as it is for Eve to
>find one string. That is precisely the point of those cryptographic
>hashes. It is supposed to be very difficult to find a collision even if
>the original is known.

The idea is that Eve must find a targeted collision while Alice need
only find a free collision.  Alice has much less work to do.

------------------------------

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 1 Mar 2000 18:37:31 -0800

If I understand the proposal correctly,
this is grossly insecure.
It is basically a simple substitution cipher
(think of those crypto-puzzles at the back of the newspaper)
operating on two-byte blocks.  There is no diffusion between
the two-byte blocks.
Consequently, one can most likely break the system using
purely classical techniques, perhaps from ciphertext only.
I would strongly recommend against using this cipher.

Have you looked at GOST or Treyfer?  These are remarkably
good for 8 bit processors.  (Treyfer may be exactly what you
are looking for, because it doesn't require space for any
S-boxes: it uses existing data in your ROM, whatever you
may already have in place, code or whatever, as a replacement.)

------------------------------

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 1 Mar 2000 18:40:36 -0800

In article <[EMAIL PROTECTED]>, John Myre  <[EMAIL PROTECTED]> wrote:
> The traditional Feistal structure uses two halves, invertably modifying
> one half using the other half.  Extending this to more subblocks, doing
> the modification in a circular pattern, seems straightforward.  Can you
> get good security if you use enough rounds?

I think so.
See the Treyfer proposal (some
recent FSE proceedings) for a
very nice example of this idea.

But do be careful about asymmetry:
if you code it the naive way, one direction
(either encryption or decryption)
is likely to be much weaker against
differential attacks than the other.

An elegant countermeasure is to use the
Skipjack ABAB trick: run the first quarter
of the rounds in the forward direction,
the second quarter in the reverse
(decryption-ish) direction, etc.

------------------------------

From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: brute force attack on a 128 bit SSL key?
Date: Wed, 01 Mar 2000 19:14:45 -0800

Randy Given wrote:

> There are many things to account for.  You mention
> Moore's law.  You don't mention breakthrough
> technologies nor breakthrough algorithms and
> certainly did not mention possible flaws in the
> algorithms.

I normally don't suffer fools gladly -- but, what the heck.
The question was about a brute force search in the keyspace.

The simple fact that, on average,  a brute force key search
would require enormous computation assets and many years,
means that other forms of attack become more interesting
(linear cryptanalysis, differential cryptanalysis, protocol
attacks, etc.).  

It's always more interesting to answer a question other than
the one that was asked,  though this isn't universally deemed
as helpful.

------------------------------

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 1 Mar 2000 18:56:50 -0800

In article <[EMAIL PROTECTED]>, John Myre  <[EMAIL PROTECTED]> wrote:
> #define KS(k,i,j)  k[(i+j)&15]
> #define FBOX(w,i,j,sk)  rotate_left(w+j+sk)
> #define ROUNDS 40 /* for example */
> encrypt (word8 *k, word8 *v)
> {
>    int i, j;
>    for( j = 0; j < ROUNDS; j++ )
>       for( i = 0; i < 8; i++ )
>          v [(i+1)&7] ^= F( v[i], i, j, KS(k,i,j) );
> }

A very small observation:

You might want a slightly more sophisticated key schedule.
The above looks suspiciously similar to SAFER+'s original
key schedule, which was found to harbor some weaknesses.

------------------------------

From: "Harvey Rook" <[EMAIL PROTECTED]>
Subject: Re: ...but what about my cipher?
Date: Wed, 1 Mar 2000 17:49:54 -0800

Look again. David A. Wagner post a reply. Your cipher can be cracked in
O(2^33) time

Harv.


<[EMAIL PROTECTED]> wrote in message
news:89k4il$o3n$[EMAIL PROTECTED]...
> ..but??...Hello!
>
> I must say I am a bit surprised that noone has replied to my post "How
weak is
> WeakCipher?", whilst a whole bunch of people, including myself, have
posted
> messages in the thread "Can someone break this cipher?"
>
> It seems like you don't get any reviews even if you DO supply the
algorithm
> etc. ;-)
>
> In case you don't find my previous post on the matter you might also have
a
> look at http://w1.462.telia.com/~u46205672/FHH.htm
> I supply a sample application and Delphi 4 dcu's and documentation.
>
> My e-mail address is for real.
>
>      -----  Posted via NewsOne.Net: Free Usenet News via the Web  -----
>      -----  http://newsone.net/ --  Discussions on every subject. -----
>    NewsOne.Net prohibits users from posting spam.  If this or other posts
> made through NewsOne.Net violate posting guidelines, email
[EMAIL PROTECTED]



------------------------------

From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: brute force attack on a 128 bit SSL key?
Date: Wed, 1 Mar 2000 21:03:49 -0700

In article <89jrge$[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] says...
> > Assume the following:
> 
> That's the problem.  You remember what
> "assume" represents, right?
> 
> For example, wasn't it 30 years ago that
> some "expert" said it would take 40 quadrillion
> years (40,000,000,000,000,000 years) to break
> DES.

I doubt it -- the small key size of DES has been a subject of 
discussion (and considerable complaint) since before the ink dried on 
the proposal to use only 56 bits.

To put things in mathematical terms, 40 quadrillion years would mean 
testing just over 18,000 keys per year.  That's about 49 keys a day, 
or just over 2 keys an hour.  I suspect somebody who was careful 
could encode one block with DES _almost_ that fast by hand.  Even the 
simplest hardware (e.g. the Eniac) could certainly test keys a LOT 
faster than that, and hardware that was common when DES was invented 
was a LOT faster.

>  Hmmm.  Was he right?  I don't think so.

If anybody really said that, they were clearly wrong.  I seriously 
doubt anybody did, because if anybody did so, s/he was obviously a 
LONG ways from being an expert in much of anything, down to and 
including arithmetic on the level I seem to recall learning before I 
was a teenager.
 
-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.

------------------------------

From: [EMAIL PROTECTED] (Nemo psj)
Subject: Re: Plain-text attack on ZIP file
Date: 02 Mar 2000 04:10:29 GMT

because its compressed there for some bites are missing resulting in the
incorrect keys.


-Pure

------------------------------

From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: very tiny algorithm - any better than XOR?
Date: 2 Mar 2000 04:13:17 GMT

Carl Byington <[EMAIL PROTECTED]> wrote:
>Consider an 8 bit processor that does not have enough code space memory
>to run TEA. This processor only needs the decrypt side - it never encrypts
>any output. We have about 50 bytes of code space, which should be enough
>for something like the algorithm below. This is probably grossly insecure,
>but it should be better than a simple XOR. The question is - is this any
>better than the trivial XOR? Note that all the operations are byte wide,
>and the rotate_left() is a single bit byte wide rotate.

1. Are you sure you can't code TEA in 50 bytes?  I seem to remember though
that TEA needs around a dozen bytes of RAM, which might also strain your
hardware, depending.

2. If your application can get by with a stream cipher instead of a block
cipher, there are several that should fit in 50 bytes whose security
might not be the greatest, but is probably not terrible.  You might look
at Ross Anderson's PIKE, described in AC2.

------------------------------

From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: https
Date: 2 Mar 2000 04:19:03 GMT

In article <89ivs5$bmc$[EMAIL PROTECTED]>,
KSF <[EMAIL PROTECTED]> wrote:
>Could any one help me and telle me how I can use https. I am making a samll
>webshop, where I send personal information over the www. I have been told,
>that it is free to get a certificat. Is it true? If yes how and where can I
>get it and how do you use it?

I've never heard of anyone issuing free certificates that are recognized
by most browsers.  The usual supplier of low-cost certificates is Thawte
(www.thawte.com), which is now part of Verisign but will continue to 
issue certificates for 125 USD til the end of this year.  Some certificate
vendors offer "free trial certificates", but those are only recognized
by browsers that you specially set up to accept them.  That's really
no better than issuing your own certificates.

For HTTPS server info, see the usual places: www.modssl.org, 
www.c2.net, www.covalent.net, and so forth.

------------------------------

From: "Harvey Rook" <[EMAIL PROTECTED]>
Subject: Re: very tiny algorithm - any better than XOR?
Date: Wed, 1 Mar 2000 18:33:25 -0800

Hmmm. Speaking of Tiny Algorithms. How effective is RC-4 with only 16, 24,
or 32 bytes in the SBox. To save memory, the key would be the permutation,
rather than a the standard RC-4 key hash.

32! ~= 2^117
24! ~= 2^79
16! ~= 2^44

So unless there is something structurally wrong with reduced a RC4, this
system should be safe
Since RC-4 is a stream cipher, encyption and decyption are the same.

off the top of my head....

char sbox[16] = { The key, a permutation of the integers 0...15}
int i=0;
int j=0;

char KeyMaterial()
{
    i=i+1 mod 16 ;
    j = (j+sbox[i]) mod 16;
    char n=(sbox[i] + sbox[j] ) mod 16
    char temp = sbox[i]; sbox[i] = sbox[j]; sbox[j]=temp
    return n;
}

char Encrypt( char Text )
{
   // Have to do it twice since the Sbox only generates 16 bits of key
material
    Text ^= ( Keymaterial() << 4  ^ KeyMaterial() );
    return Text;
}




"Carl Byington" <[EMAIL PROTECTED]> wrote in message
news:89jinl$pts$[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Consider an 8 bit processor that does not have enough code space memory
> to run TEA. This processor only needs the decrypt side - it never encrypts
> any output. We have about 50 bytes of code space, which should be enough
> for something like the algorithm below. This is probably grossly insecure,
> but it should be better than a simple XOR. The question is - is this any
> better than the trivial XOR? Note that all the operations are byte wide,
> and the rotate_left() is a single bit byte wide rotate.
>
> Is there anything that can be done to make it significantly stronger
> without adding more than a few instructions?
>
>
> /**********************************************************
>    Input values:    k[16]   128-bit key
>                     v[8]    64-bit plaintext block
>    Output values:   v[8]    64-bit ciphertext block
>  **********************************************************/
>
> void encrypt(word8 *k, word8 *v)
>

>     int i, j;
>     for (i=0; i<8; i+=2)

>         for (j=0; j<16; j++)

>             // feistel network v[i], v[i+1] form the 16 bit block
>             // L = v[i]
>             // R = v[i+1]
>             word8 t = v[i+1];
>             v[i+1]  = v[i] ^ ((rotate_left(t) + k[j]) & 0xff);
>             v[i]    = t;
>         }
>     }
> }
>
> void decrypt(word8 *k, word8 *v)
>

>     int i, j;
>     for (i=0; i<8; i+=2)

>         for (j=15; j>-1; j--)

>             // feistel network v[i], v[i+1] form the 16 bit block
>             // L = v[i]
>             // R = v[i+1]
>             word8 t = v[i];
>             v[i]    = v[i+1] ^ ((rotate_left(t) + k[j]) & 0xff);
>             v[i+1]  = t;
>         }
>     }
> }
>




------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Thu, 02 Mar 2000 04:59:03 GMT

wtshaw wrote:
> <[EMAIL PROTECTED]> wrote:
> > Even compiled BASIC doesn't support efficient linked data structures,
> > etc.  (Or if it does, it's via a nonstandard extension, not BASIC.)
> You are going out of you way to qualify Basic as not being extendable.

No, but if it looks like Ada, then you shouldn't be calling it BASIC.

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Thu, 02 Mar 2000 05:07:48 GMT

"SCOTT19U.ZIP_GUY" wrote:
> I had coded in assembly that I don't think C can come close to

The main thing that C doesn't provide convenient access to that
can be taken advantage of in assembly-language coding is the
carry/shift bit.  There are certain idioms in C that a good
compiler can optimize into using the carry/shift bit, but many
compilers don't exploit this, probably because it is too much
work for the small number of applications where it could make a
significant difference.

Of course, almost every ISA has its own weird feature(s) that
aren't fully exploited by compiler-generated code.  The PDP-11
had a MARK instruction that was even meant to help compilers
generate activation records, but was used in only one compiler
that I recall.  Many DSPs these days have special instructions
to assist in Viterbi decoding; the ones I have seen don't help
in general, but can be used for a few commercially important
codes (e.g. in cell phones).  One can get at such instructions
via assembly language, if necessary, but often it really isn't
necessary.

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Thu, 02 Mar 2000 05:14:23 GMT

wtshaw wrote:
> <[EMAIL PROTECTED]> wrote:
> > Adam Durana wrote:
> > > BASIC is great for learning structured programming, ...
> > That's certainly not the consensus opinion in the computing
> > science community!
> If you write a fully function application, structure is important.  The
> fact that the best type of event loop and use of subroutines, globals,
> multiple windows, etc. can be done in extended Basic is no surprize to
> lots of folks.

"Structured programming" denotes a specific programming style,
typified by limiting control flow to the use of sequencing,
alternation, and repetition.  It also has a heavy emphasis on
functional modularity, for which BASIC's GOSUB is woefully
inadequate.

I don't know where you get the idea that BASIC involves event
loops, etc.; perhaps by confusing it with Microsoft's so-called
"Visual Basic"?

------------------------------

From: jungle <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passwords secure against dictionary attacks?
Date: Thu, 02 Mar 2000 05:16:25 GMT

Not big deal, I like to be corrected ...

It does not pay to cut text for responding, when the cut will put respondent in
the state that he not relate sentences together.
When you will not delete the most important part, you will be not confused by
partial quotation.

Example of magic : distorting original by quoting selectively ...

The text, when any ambiguity is not possible ... at least when you do not like
to create one artificially ...
==================================
Dave Howe wrote:
> >> How about ten English words with different punctuation symbols
> >> as word separators?

> Hmm. if I had to come up with a rule of thumb here, I would count any
> english word (or $LANGUAGE word for that matter)
> as being two random characters; 

for me it is 4 random characters ...

> so ten english words with non-space separators would be
> equivilent to a 29-character truely random password - which is
> definitely non-trivial to crack.

my assumption [ 4 random characters ] provide key space of 10 to power of 48

==========================================

Johnny Bravo wrote:
> 
> On Wed, 01 Mar 2000 09:12:35 GMT, jungle <[EMAIL PROTECTED]> wrote:
> 
> >Johnny Bravo wrote:
> >>
> >> On Wed, 01 Mar 2000 01:31:20 GMT, jungle <[EMAIL PROTECTED]> wrote:
> >> >my assumption [ 4 random characters ] provide key space of 10 to power of 48
> >> >I will leave you for evaluation ...
> >
> >read the message that I responded to ...
> 
>   I was responding to you, not the original poster.  You stated the above
> and I corrected you on it.


------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Thu, 02 Mar 2000 05:18:42 GMT

wtshaw wrote:
> ...  I notice that C does not easly allow goto's to be as effective
> as they would be in Basic.  I see that as a weakness of C, not a
> strength.

If only it were so, but that's contrary to your promotion of BASIC
for structured programming.  However, it is *easy* to write a C
program to mimic all of the GOTOability of BASIC *except* for the
ability to branch into the middle of a subroutine -- which isn't
something that should be encouraged (for reasons that were evident
in the 1960s).

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Crypto.Com, Inc.
Date: Thu, 02 Mar 2000 05:26:16 GMT

Mok-Kong Shen wrote:
> Another possibility: Telepathy! Believe it or not, it was only
> a few days ago that pre-cognition of animals and such stuffs
> were earnestly discussed in a French radio broadcast.

They were discussed today in Moe's Bar.  So what?

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Can someone break this cipher?
Date: Thu, 02 Mar 2000 05:30:41 GMT

John wrote:
> I see. Then where to I go to have an objective-look at an
> encryption system. I think many people fear that their work will
> be stolen, so they argue that they can never devulge the source.
> Is it always necessary to devulge the source-code?

That's why Patents and Non-Disclosure Agreements were invented.
As legal contracts, NDAs provide incentive for people you let
in on the secrets to keep the secrets, and compensation should
they not do so.

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Thu, 02 Mar 2000 05:33:48 GMT

[EMAIL PROTECTED] wrote:
> "... NSA's signals analysts are ..."

I thought we were speaking about intelligence analysts,
not signals analysts.

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Thu, 02 Mar 2000 05:36:21 GMT

Mok-Kong Shen wrote:
> I am ignorant of whether
> any historian has found the real facts in these cases.

Yes, they have; in fact there have been official investigations.
But that apparently doesn't put an end to the spread of rumors.

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: On jamming interception networks
Date: Thu, 02 Mar 2000 05:40:18 GMT

Mok-Kong Shen wrote: 
> Douglas A. Gwyn wrote:
> > Mok-Kong Shen wrote:
> > > Ah, I understand that you mean that ...
> > No, you don't show signs of understanding my meaning at all.
> This is a typical kind of behaviour of those who simply 'kill' a
> discussion ...

No, it was a simple statement of fact.
When you repeat what you understand that I mean and it
doesn't at all match what I meant, then you don't show
signs of understanding my meaning at all.
And the sarcastic tone you used convinced me that you
weren't interested in understanding what I was saying.
So it *is* a good idea to terminate the thread,
because a discussion requires listeners as well as talkers.

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: And when you read my postings since April, 1999 .. you find out one 
Date: Thu, 02 Mar 2000 05:43:58 GMT

"Markku J. Saarelainen" wrote:
> 
> "Markku J. Saarelainen" wrote:

[nothing has been excised from the cited posting]

That has to be his most informative posting ever --
it is even (nearly) self-referential!

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Q: 'Linear encipherment'
Date: Thu, 02 Mar 2000 05:51:09 GMT

Mok-Kong Shen wrote:
> Douglas A. Gwyn wrote:
> > ... it is stronger because it uses 4 key constants per CT value
> > instead of 2 key constants per CT value; in other words, it mixes
> > together 4 PT values into one CT value, rather than just 2 PT
> > values.
> > Key length has no direct bearing on this.
> But 16 key values are used in the one case, compared to only 4 key
> values in the second. Forgetting about the internal working of
> the two schemes, do you think that it is a 'fair' (from the
> very beginning) comparison to say that the 16 key values scheme
> is stronger than the other one that uses only 4 key values? To
> consider a bit different context, do you think that comparison of
> strength of a 128 bit key algorithm with a 64 bit key algorithm
> to be sensible in the first place? This is the essence of my
> critique about Kahn's statement.

As I said in a previous posting in this thread, it is a matter
of density, not length.  If the two keys were equally long,
the "linear" (vector) method would still be somewhat "stronger"
than the matrix method, for the reasons that I explained.  However,
I think Kahn and you have both placed too much importance on this.
This isn't really a good measure of "strength" anyway, and the
specific encryption methods are of little practical interest.
Historically these systems are of interest for being (perhaps)
the first encryption systems to be *explicitly* based on a
mathematical approach.

------------------------------


** 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
******************************

Reply via email to