Cryptography-Digest Digest #847, Volume #11      Wed, 24 May 00 01:13:00 EDT

Contents:
  Re: what is the status finite automata base cryptosystems? (Tim Tyler)
  Re: pentium timings (lordcow77)
  Musings... which is better in the end, a patent, or a brand? (Sundial Services)
  safer style sboxes (Tom St Denis)
  Re: Patent busting for AES usage (David A. Wagner)
  Re: Patent state of Elliptic Curve PK systems? (Scott Contini)
  Re: pentium timings (tomstd)
  pentium timings and RC5 code (tomstd)
  Re: Encryption within newsgroup postings (zapzing)
  Re: Patent busting for AES usage ("John Kaiser")
  Re: safer style sboxes (zapzing)
  Re: Crypto patentability (Bill Unruh)
  Re: Patent busting for AES usage (Bill Unruh)
  NSA Polygraph Screening: A Victim's Story (Anonymous)
  Re: pentium timings (Jerry Coffin)
  Re: Patent busting for AES usage (zapzing)
  Re: safer style sboxes (David A. Wagner)

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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: what is the status finite automata base cryptosystems?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 24 May 2000 00:27:51 GMT

Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:

[stuff about finite utomata not being described as such]

: Could this be because what are treated as finite automata in the texts
: and papers are only rather special cases of finite automata after all?

I'm not sure what to say to this question.  Here is my guess:

If you've got a complex algorithm which you want implemented as a finite
state machine, full of multiplications, divisions, trig or whatever,
there's probably a tendency to discuss it on its own level - rather
than the level of flip-flops and gates.  If you need a hardware
implementation, you let some program figure out how to synthesize,
place and route it.

So, perhaps the "finite automata" that get named as such in discussion
have someting in common - in that they're often comprehensible as
automata - and are not "ordinary software" transformed into computer
generated sphagetti.
-- 
__________  Lotus Artificial Life  http://alife.co.uk/  [EMAIL PROTECTED]
 |im |yler  The Mandala Centre   http://mandala.co.uk/  Goodbye cool world.

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

Subject: Re: pentium timings
From: lordcow77 <[EMAIL PROTECTED]>
Date: Tue, 23 May 2000 18:20:54 -0700

In article <[EMAIL PROTECTED]>, tomstd
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Jerry Coffin <[EMAIL PROTECTED]> wrote:
>>In article <[EMAIL PROTECTED]>,
>>[EMAIL PROTECTED] says...
>>
>>[ ... ]
>>
>Also I doubt much pairs with
>
>rdtsc
>push eax
>push edx
>
>So there won't be much clash with the code I am testing.

Pairing has very little to do with why the CPU must be
serialized before reading from the clock counter. I do not wish
to be insulting or offensive; it is simply that you seem to have
a flawed understanding of how modern processors work. The
assembler opcodes that you program in are internally translated
into much simplier RISC-like instructions. The order of the
instructions executed inside the processor is indeterminate,
subject to a single constraint: the programmer-visible state of
the processor must reflect that which would occur in a machine
that sequentially executed the opcodes.

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


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

Date: Tue, 23 May 2000 18:42:17 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Musings... which is better in the end, a patent, or a brand?

I sometimes wonder whether, say, RSA Data Security makes more financial
gain from enforcing their patents (which they do vigorously) ... or from
Joan.

C'mon, guys, you KNOW who Joan is, and you wonder just -where- she
intends to put those sparking jumper cables!  :->  From the looks on her
face it looks like she might just put them, ahh, anywhere.  ;-)

But that image, which is aggressively put out in the public's eye and
also encapsulated in a small trademark-image that easily fits onto a
tiny icon-bitmap, helps to reinforce the *brand name*, RSA.  It helps
anyone to "recognize" the name when they encounter it, and to remember
Joan.  

Some other well-known crypto brand-names actually fail to connect
themselves with a particular company:  for example, just who is behind
SSL2?  John-Q Public certainly does not know.

Oddly enough, some non-crypto company names are extremely effective in
building public trust:  Norton, McAfee.  Verisign and the other
signature companies are doing a good job of putting their label on
important sites -- building trust even though John-Q Public has no idea
how the technology works.

We are entering into a world where the public's trust in communication
security is being severely shaken, by Melissa, The Love Bug, you name
it.  This could be enormously profitable times for cryptographic brands.
Whether they own patents or not.

Well-positioned, well-branded companies that have tough (but not
necessarily "tough-est") brands which are clearly promoted as making a
difference in the current wounded-spot of communication security, stand
to make (earn...) a LOT of money.  

Maybe the money that's being poured into trying to patent algorithms,
and defend those patents against all comers -- is ultimately just being
thrown to the lawyers like so many pearls.  (Ahem...)  Maybe those folks
are "winning the battle but losing the war by failing to participate in
it while it's being fought."

Food for thought.

-Mike (trying hard to build a brand myself!) Robinson

==================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED]  (PGP public key available.)
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R):  "Click click, it's fixed!" {tm}
> http://www.sundialservices.com/products/chimneysweep

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

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: safer style sboxes
Date: Wed, 24 May 2000 01:41:49 GMT

I have tested all possible sboxes in GF(257) of the form

  S(x) = x^b mod 257
and
  S(x) = b^x mod 257

(fixed 'b' value)

And haven't found one that is ideally non-linear.  Which makes me ask,
how come ciphers like SAFER or E2 (uses x^255 right?) can get away with
that?

I use the WT to measure non-linearness and typically see -44/44 as the
WT output... I would expect at least -32/32, and at best -16/14
(matsui's sboxes do that well).

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Patent busting for AES usage
Date: 23 May 2000 19:01:50 -0700

In article <[EMAIL PROTECTED]>,
Sundial Services  <[EMAIL PROTECTED]> wrote:
> It seems to me that the Twofish people have the right idea:  no
> copyright, no patent, full disclosure.

Thanks!  We like to think so too. :-)

But, in all fairness, I should point out that Twofish is not the
only candidate to follow this approach.  For example, I believe
Rijndael and Serpent are also available under similar terms, if
I am not mistaken.  They surely have earned just as many kudos
for their policy...

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

From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: Patent state of Elliptic Curve PK systems?
Date: 24 May 2000 02:11:59 GMT

In article <[EMAIL PROTECTED]>,
Mike Rosing  <[EMAIL PROTECTED]> wrote:
>Roger Schlafly wrote:
>> 
>> Paul Rubin wrote:
>> > Are you sure of that?  The most interesting ECC variant is ECC over
>> > GF(2^n) with optimal normal basis representation, since you can do that
>> > in software without any multiplication.  But I thought it was patented
>> > by Certicom.  Is it not?  What about ECC over GF(2^n) in general, an
>> > obvious method if there ever was one?
>> 
>> Certicom says it has some patent applications pending, but
>> it is hard to see how they will stop anyone. Most people
>> get better performance in software with other bases, ie,
>> trinomial bases. Or one can use (non-optimal) normal bases.
>> Or use prime fields where you have more curves and fewer
>> known attacks.
>
>Certicom has hardware patents on ONB.  There are no software patents on
>ONB.
>The "all-ones-polynomial" is a cross breed between Type I ONB and
>regular
>polynomials, it's as fast as trinomials if not quicker.  The latter has
>been
>in the public domain for over a decade.  Not well publicized tho :-)
>
>GF(p) will remain more secure than GF(p^n) in any case.  If speed is
>less important than security, that's definitly a better way to go.
>
>Patience, persistence, truth,
>Dr. mike


There is a patent held on elliptic curves over  GF(p)  where  p  is
a special form.  I believe the form is  2^n +/- c  where  c  is
a small integer.  This is a patented that should really be fought,
since the ideas of doing fast arithmetic on these primes have been
well known for a long time.  (I think this patent is held by Apple).

However, there are other primes that one can do arithmetic on approximately
the same speed which fall outside this patent.  These are primes whose
signed binary representation is sparse.  I believe I have seen such
primes in some standard, but I do not know which one.

Scott



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

Subject: Re: pentium timings
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 23 May 2000 19:45:33 -0700

In article <[EMAIL PROTECTED]>,
lordcow77 <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, tomstd
><[EMAIL PROTECTED]> wrote:
>>In article <[EMAIL PROTECTED]>,
>>Jerry Coffin <[EMAIL PROTECTED]> wrote:
>>>In article <[EMAIL PROTECTED]>,
>>>[EMAIL PROTECTED] says...
>>>
>>>[ ... ]
>>>
>>Also I doubt much pairs with
>>
>>rdtsc
>>push eax
>>push edx
>>
>>So there won't be much clash with the code I am testing.
>
>Pairing has very little to do with why the CPU must be
>serialized before reading from the clock counter. I do not wish
>to be insulting or offensive; it is simply that you seem to have
>a flawed understanding of how modern processors work. The
>assembler opcodes that you program in are internally translated
>into much simplier RISC-like instructions. The order of the
>instructions executed inside the processor is indeterminate,
>subject to a single constraint: the programmer-visible state of
>the processor must reflect that which would occur in a machine
>that sequentially executed the opcodes.

I hate to claim magic, I am not denying my code could be/is
wrong, but it seems to give fairly usefull consistent output on
a variety of cpus and platforms.

e.g it does what I want, so it's perfectly fine.

Tom


* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


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

Subject: pentium timings and RC5 code
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 23 May 2000 19:46:29 -0700

Well since my code sucks, could someone with a K6-2 or PII time
my code (http://www.tomstdenis.com/rc5asm.zip) and tell me the
clocks per block they get?

Tom

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


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

From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Encryption within newsgroup postings
Date: Wed, 24 May 2000 02:46:40 GMT

In article <392a8e7a$[EMAIL PROTECTED]>,
  "Dave Jones" <[EMAIL PROTECTED]> wrote:
> Dear All,
>
> I have found a variety of newsgroup postings which have part of the
text
> encrypted.  There are no numbers or special characters used, it looks
> something like the following:
>
> yytjk y pltra........etc
>
> Has anyone come across this, and if so, can you please explain the
> encryption/decryption process used.
>

In a slightly different vein, have you
noticed all the stuff in alt.test
lately? If that's not encrypted
top secret plans to ake over the
world, I'm a monkey's uncle.

--
If you know about a retail source of
inexpensive DES chips, please let
me know,  thanks.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: "John Kaiser" <[EMAIL PROTECTED]>
Subject: Re: Patent busting for AES usage
Date: Wed, 24 May 2000 03:52:39 GMT

I have been involved in three successful efforts to invalidate
patents (and one unsuccessful) and I believe that this effort
has some merit.  The benefit will be to a company that attempts
to challenge a patent after it has been issued by finding
published material in places like sci.crypt where the original
inventor did not look.  The patent examiner only looks at the
material presented by the inventor, though the inventors are
required to disclose every relevant piece of prior art known
to them.

Interestingly enough, in the case of the unsuccessful patent
challenge, the inventor included a reference to a piece of prior
art that in my mind was identical to the main claims of the
patent, but the examiner at the time that the patent was granted
did not share my opinion, and that weighs heavily in a judges decision.
It was not obvious to the examiner at the time, even though it
seemed obvious now.

The historical precedent for an effort like this comes from Bell Labs
shortly after the transistor was invented.  At that time there were a
large number of patents on vacuum tube circuits.  They wanted to
avoid similar problems with transistor circuits, so they published a
massive set of circuit designs where they replaced tubes with
transistors.  Some of the circuits were amusing to electrical engineers
because they are meaningless in the transistor world, but Bell Labs
published them.

As far as the original request.  I consider it to be obvious that any
processor or method based on a sequence of steps involving a cipher
that has a 64-bit block and a 128-bit key (e.g., IDEA used to create
a one-way hash function via Davies-Meyer (tandem, abreast, or modified))
can be scaled up to use an AES cipher with a 128-bit block and
a 256-bit key.




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

From: zapzing <[EMAIL PROTECTED]>
Subject: Re: safer style sboxes
Date: Wed, 24 May 2000 03:52:22 GMT

In article <8gfc0q$d86$[EMAIL PROTECTED]>,
  Tom St Denis <[EMAIL PROTECTED]> wrote:
> I have tested all possible sboxes in GF(257) of the form
>
>   S(x) = x^b mod 257
> and
>   S(x) = b^x mod 257
>
> (fixed 'b' value)
>
> And haven't found one that is ideally non-linear.  Which makes me ask,
> how come ciphers like SAFER or E2 (uses x^255 right?) can get away
with
> that?
>
> I use the WT to measure non-linearness and typically see -44/44 as the
> WT output... I would expect at least -32/32, and at best -16/14
> (matsui's sboxes do that well).
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

I just wonder why cipher desighners don't start
using larger s-boxes. From what I understand, if
an s-box is large enough, say 16 bits, then just
about any randomly generated s-box will perform
adequately. With hardware improving by leaps
and bounds, this seems like it might be the
way to go.

I was also wondering about this method for
"generating" sboxes that are key dependent.
What about

s(x)=(((x+k1)^k2)+k3)^k4 ...
where + (now) indicates addition modulo whatever
and ^ indicates xor. One could also imagine
using other operations in this way, such as
the exponentiation you mentioned above.


--
If you know about a retail source of
inexpensive DES chips, please let
me know,  thanks.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Crypto patentability
Date: 24 May 2000 04:18:05 GMT

In <9wFW4.42057$[EMAIL PROTECTED]> "Paul Pires" <[EMAIL PROTECTED]> 
writes:

>    Now wait a minute here. I have listened to a lot of talk on patents from
>this group. You guys are real smart but I don't think you're up to
>re-inventing the patent.

...

>    Prior art is the big issue. The Patent must not be anticipated by any
>prior art. Most folks think that means previous patents. It does not. Any
>publication or offer for public sale is prior art. The examiner can only
>search and review what he can find and what the applicant supplies (he's
>legally obligated to fully disclose any he knows of). The patent grant isn't
>home free, any prior art found can invalidate an Issued patent. If you think
>this stuff was done before, find the publication or sale and link it to a
>date.

Yes, but the problem is that the granting of a patent carries with it
the presumption of validity. Ie, unless you can prove prior art, or
anything else that invalidates the patent, the patent stands. Thus, if
the patent examiners do a bad job, then they seriously harm the field,
by chilling out competition.

The problem is that to prove invalidity requires a court case, a very
long, very expensive court case if the patent holder has deep pockets.
Most people or companies are not up to that even if the patent is
patently invalid. It is thus crucial that the patent office do a good
job in assigning patents.

>    You folks have been doing the single most important thing all along.
>This is a public forum where issues described here become the very prior art
>that will keep a bad patent from being enforced. It won't keep it from being
>issued. I said the process was beautiful, not omnipotent.

The whole purpose of patents was to encourage the publication of the
patented material, rather than have people try to keep it secret with
trade secrecy laws. In the case of software, it is hard to keep stuff
secret anyway-- it is too easy to disassemble the stuff if you really
want to know. This removes a big reason why patents exist at all. 
They were never intended as a "reward" for invention.  It was purely a
very mercinary bargain-- you tell us what you have done, and we give you
a monopoly for X years. Whether patents on software serve that purpose--
ie whetehr the public gets a good deal out of such patents-- is highly
debatable. Thus so is allowing patents of software.

Copyright is similar. Copyright is another bargain-- you write or
produce something, we will give you a monopoly on copying that something
for X years ( where x is like 75 years or life+50) Again this makes
almost no sense with software. Software copyright should last a max of 5
yers, and then only if the source code is published. Otherwise that
monopoly should be granted. Many companies have become enamoured of the
soviet system, where the government granted monopoly rights to friends.
While good for the friends, it was not good for the society. Similarly
here.

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

From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Patent busting for AES usage
Date: 24 May 2000 04:24:35 GMT

In <02EW4.41300$[EMAIL PROTECTED]> "Lyalc" <[EMAIL PROTECTED]> writes:
]Two options that might work
]1. make implementaitons as specific or narrow as possible.
]2. do away with the concept of all intellectual  property.

]I'm not sure what effect either would have on the industry, but it seems
]unlikely to be positive to me.

Actually I suspect it would have very little impact on the output of
"the industry". It might have a large negative impact on certain aspects
of the industry which spends its time doing nothing useful except trying
to tie up "intellectual prperty" The Linux explosion is indicative of
the amount by which the industry would "suffer".

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

Date: Wed, 24 May 2000 06:35:15 +0200
From: Anonymous <[EMAIL PROTECTED]>
Subject: NSA Polygraph Screening: A Victim's Story
Crossposted-To: alt.politics.org.nsa,sci.math

The following is a first hand account of one man's experience with National Security 
Agency (NSA) polygraph screening, which was recently posted to the 
http://www.nopolygraph.com message board.

The original message, as well as comments posted in reply, may be read online at:

    http://www.nopolygraph.com/_disc1/0000012b.htm

For more on polygraph screening, see also:

    http://www.stoppolygraph.com

    http://www.polygraph.com

    http://www.fas.org/sgp/othergov/polygraph/

Knowledge is power. Inform yourself.

--


Twilight Zone

From: Gunrunner
Date: 20 May 2000
Time: 18:48:35
Remote Name: 216.164.234.105

Comments

As part of the process to upgrade my security clearance in the
military, I was required to take a polygraph exam at NSA
headquarters. I arrived, took the exam and was told all was
fine. Subsequently, I was contacted by military investigators
because they were conducting an "investigation." Why, I asked?
Because of the "inconclusive" result on my polygraph, they said.
So, with nothing to hide, and after a 20-year career, I went to
the headquarters of the investigators for another polygraph.
Oddly, it too, came back inconclusive. Weird since I indicate be
truthful when asked "Do you intend to answer truthfully" and
when asked "are you concerned I may ask about something we
have not discussed." But at the same time, I supposedly indicate
"nconclusive" when asked the question: "Have you disclosed
classified information to unauthorized personnel?" For the next
several months I was interrogated and accused of being, at best,
a security risk, and at worst, a threat to national security. They
even threatend my retirement and honorable discharge!! I
NEVER divulged classified information--EVER! Subsequent to
the investigation and allegations that "there are indications of
security violations" in my career (who doesn't after a 20-yr
career), I was removed from access to secure
information--BUT, I never had my security clearance revoked,
barred or terminated. If something was amiss or they thought I
was a security risk, they should have taken some action. Now,
for the second half of the story. Seems during this witch-hunt
and interrogations and polygraphs, I was suffering from a
gallstone I didn't know I had. I thought the pain and discomfort
was the result of bad posture or my big belly. However, come to
find out, gallstones are aggravated by stress and after you eat.
(All my polygraphs were just after I ate.) Now, the question is,
how do I get my reputation back? I have absolutely NO faith in
the polygraph and have NO FAITH in those that administer the
test since I was treated so badly. Therefore I am NOT willing to
take the test again! I will retire shortly rather than continue
serving under this cloud. 



Last changed: May 20, 2000 








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

From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: pentium timings
Date: Tue, 23 May 2000 22:48:28 -0600

In article <3ajW4.3929$[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] says...
> I think the boys are being overly pedantic.  For most applications the
> timing that is important is the timing you measure under real operating
> system conditions.  What the heck difference does it make if you wind up
> measuring some O/S overhead.  That overhead will be there in the real
> application so you might as well take it into consideration.

I'm NOT talking about measuring OS overhead.  I'm talking about the 
processor executing instructions out of order, and (in particular) 
executing the timing instructions out of order.  Assume you wanted to 
time the execution of a single NOP:

        rdtsc
        mov edi, edx
        mov esi, eax
        nop
        rdtsc

the second RDTSC could actually be executed _before_ the first, and 
it could end up indicating that that NOP (and the two mov's) took a 
_negative_ amount of time.  It could also execute the NOP before any 
of the other instructions in the sequence, so the code wouldn't time 
the execution of the NOP at all.  Other sequences are possible as 
well; the result is that there's NO relationship between the 
difference between the readings from the TSC and the actual amount of 
time taken by the instructions involved.

Eliminating OS overhead is a _completely_ separate issue.  It's often 
desirable to do so, but it's NOT what I was talking about at all.
 
> Taking averages of the results of GetTickCount() before and after execution
> of a subroutine ought to be good enough for about 99.99999% of the
> applications, provided you code takes longer to run than the ms resolution
> of this function.  

Under normal circumstances its real resolution is ~55 ms (for 
Lose95/98) or 10 ms (for NT/2000).  That, of course, is a major 
problem: it's difficult to find ANY cipher that has (for example) a 
round function that takes anywhere close to that long.

Of course, you can do a LOT better: if you have GetTickCount 
available, you probably also have QueryPerformanceCounter and 
QueryPerformanceFrequency available, and they're _much_ more precise 
(normally around 4 orders of magnitude more precise).

Of course, there are lots of other issues here as well -- just for an 
obvious example, GetTickCount doesn't work AT ALL under Linux...

In the end, it comes down to this: if you're going to go to the 
trouble of measuring things in clock ticks to start with, then it's 
FAR more sensible to do it so the results are meaningful in the same 
range.  As-is, Tom's code loses close to 2 orders of magnitude 
compared to what properly written code of the same general type can 
do.  IMO, that's a pretty lousy way of doing things.

> If it does not, then just run it inline several times to
> make it do so.

Sure...and instead of results that might be a little wrong, typically 
produce results that are certain to be _way_ wrong!  Worse yet, put 
yourself through extra work to collect results that won't help you 
anyway.

Don't get me wrong: collecting results on a larger piece of the 
system can be useful and meaningful, and when you're doing so, 
something higher-level than RDTSC can be useful.  GetTickCount is 
rarely the best alternative when it happens, but various other things 
can be useful anyway.  The question at the moment is whether the code 
Tom presented was useful in the basic range of things it attempted to 
cover -- a microscopic-level time attempting to collect data at the 
level of individual clock cycles.  IMO, the answer to that question 
is a resounding NO!  Likewise, if you're trying to optimize something 
like a round function, it's going to be a LOT more difficult to get 
useful results from something like GetTickCount than from a decent 
timer at the clock-cycle level.

-- 
    Later,
    Jerry.
 
The universe is a figment of its own imagination.

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

From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Patent busting for AES usage
Date: Wed, 24 May 2000 04:36:42 GMT

In article <02EW4.41300$[EMAIL PROTECTED]>,
  "Lyalc" <[EMAIL PROTECTED]> wrote:
> Need to be careful with 'ideas'.
> Patents cover implementations of 'ideas'- an idea alone generally
cannot be
> patented.

That is just not true.
RSA was patented, right?

--
If you know about a retail source of
inexpensive DES chips, please let
me know,  thanks.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: safer style sboxes
Date: 23 May 2000 21:50:59 -0700

In article <8gfjlh$ib5$[EMAIL PROTECTED]>, zapzing  <[EMAIL PROTECTED]> wrote:
> I just wonder why cipher desighners don't start
> using larger s-boxes.

Performance.  A 8x8 (or 8x32) S-box fits in the L1 cache.
A 16x16 S-box doesn't, and so lookups will be considerably slower.

> I was also wondering about this method for
> "generating" sboxes that are key dependent.
> What about
> s(x)=(((x+k1)^k2)+k3)^k4 ...

The high bits of x never affect the low bits of s(x).
You'll probably want better diffusion...

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


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