Cryptography-Digest Digest #185, Volume #12       Sun, 9 Jul 00 16:13:01 EDT

Contents:
  Re: Proposal of some processor instructions for cryptographical  (Mok-Kong Shen)
  Re: Proposal of some processor instructions for cryptographical  (Mok-Kong Shen)
  Q: Hadamard transform (Mok-Kong Shen)
  Yet another uncommon number system (Mok-Kong Shen)
  Re: Quantum Computing (Was: Newbie question about factoring) (Jerry Coffin)
  Re: Using CRC's to pre-process keys (Jerry Coffin)
  Re: Concepts of STRONG encryption using variable base http://www.edepot.com/phl.html 
("tok")
  Re: A thought on OTPs (Mok-Kong Shen)
  Re: Proposal of some processor instructions for cryptographical  (Samuel Paik)
  Advanced Cryptography FAQ ([EMAIL PROTECTED])
  Re: Proposal of some processor instructions for cryptographical  (Samuel Paik)
  Re: computer program:  extract consonants/vowels from input (JPeschel)
  Re: Proposal of some processor instructions for cryptographical    ("Trevor L. 
Jackson, III")

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical 
Date: Sun, 09 Jul 2000 20:18:06 +0200



Kasper Pedersen wrote:

> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote
> > I implicitly assume a common processor, e.g. what people normally
> > have access to, e.g. a PC.

> Aren't we already talking specialty items? Maybe people _will have_, but
> they certainly don't _have_

I mean crypto software that is to be used by common people, i.e.
without requiring them to purchase any special hardware.

> > The problem is with the size of the look-up table and quite probably
> > also the efficiency incurred thereby in case the permutation is
> dynamically
> > determined so that one has to recompute the look-up table frequently.

> Which is acceptable on fixed perms. A 32:32 mapping can be done in 4 clks on
> a modern CPU, the 16 kbit memory for the table the limiting factor as we
> assume 1 load per clock. But - that memory isn't much bigger than the 32:32
> switch matrix on the silicon, and it's a lot more powerful.
> Dynamically changing perms of this kind are fun - but you can probably find
> something that's more cryptographic value for the cost.

Well, if I don't err, for a given particular permutation one has to
have a look-up table of 2^32 words as an array. Isn't that fairly huge?
And one has to compute the contents of these, even if done only once
in a key dependent way.

> > Perhaps I misunderstood you. But it is not a matter of formal formulation,
> > it is a matter of implementation (with processor instructions).
>
> Which is why he's talking FIR filters. DSPs have special instructions for
> those, optimized to such a degree that they sometimes take up most of the
> silicon. Take the sample C code below
>
> for (i=0; i<n; i++)
> {
>    acc+=data[p1+base_p1]*data[p2+base_p2];
>    p1=(p1+1) mod size_p1;
>    p2=(p2+1) mod size_p2;
> }
>
> A typical low-cost DSP will do the above loop in 1+n clock cycles. The above
> {...} is one instruction in the CPU, and the for(;;) is free (typically 1
> clk setup).
> And with a little headache, it can be implemented in 3DNow! at 1 clock/round
> v. 32*32, for those running K6-x or K7's.
> Notice how well it moves bits around?

The context in the above case was computing the parity. Does
Data[index] of your code refer to a single bit? Thanks.

M. K. Shen




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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical 
Date: Sun, 09 Jul 2000 20:23:10 +0200



Thomas Womack wrote:

> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote
>
> > Transposition is one of the basic operations in cryptography.
>
> Is it, any more? Having a look at the AES candidates, most of them carefully
> refrain from calling for bit transpositions simply because they're rather
> hard to implement.

Given that, I think that one should get hardware support for transpositions.

> If you want byte transpositions, Altivec has a vector-permute instruction
> which considers one 128-bit register as a list of 16 bytes A[0..15],
> considers the lower bit of each byte as an index into a second register B
> (also considered as a set of 16 bytes B[0..15]), and sets C[i] = B[A[i]]. I
> don't know how long this instruction *takes* on a current G4, but someone in
> comp.arch surely does.

Anyway, byte transposition in memory is always supported, if I don't err.

> The bit scatter/gather technique you suggest seems to go very against the
> RISC philosophy by having a single instruction require hundreds of memory
> operations; I think you have to stick with permutations that can fit in a
> register, though there's nothing stopping you from suggesting a
> super-Altivec using 256-bit vector registers.

Actually I don't think that a general bit permuation instruction is very
extravagant. There is, if I don't err, normally a translate instruction that
does bytewise substitutions according to an array of 256 elements. So
an analogous instruction for permulation of bits of a word specified by
an array of length equal to the number of bits in the word would be
similarly realizable.

> If you don't mind a lower granularity, the Pentium 3 has instructions which
> can arbitrarily shuffle an array of 4 shorts or ints or floats (the Athlon
> can only do this for shorts at the moment), though this is based on an
> immediate operand rather than a register.
>
> Swapping small sections of words isn't that painful:
>
> C = 0xf0f0f0f0;
> A = X & C;
> B = X & ~C;
> X = A|B;
>
> and its obvious extensions. I can get bit-reversal of a 64-bit number to run
> in 24 ticks on a K6/2 without even trying, and I don't expect it to take
> much over 50 ticks to bit-reverse three 64-bit numbers in parallel.

Yet I think that there is material economy of execution time if one
has special instructions.

> > Another processor instruction that I think is desirable is
> > to obtain the parity of groups of bits (e.g. 4, 8, etc.) from
> > consecutive words in memory and accumulate these into a word.
>
> Why not rearrange the problem (especially if you're using a bit sequence
> with lots of entropy to begin with), assume some nice person has transposed
> the bit matrix for you, and just do V = U[0] ^ U[1] ^ U[2] ^ U[3]?

I need bit operations to rearrange, don't I?

M. K. Shen


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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Q: Hadamard transform
Date: Sun, 09 Jul 2000 20:28:25 +0200


There exists 2-D Fourier transform. Does anyone have literature
pointer of an analogous 2-D Hadamard transform? Thanks in advance.

M. K. Shen



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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Yet another uncommon number system
Date: Sun, 09 Jul 2000 20:28:37 +0200


Conversion of a number representing a bit sequence as digits
in a base b1 to another base b2 can be of some use for
encryption processing as advocated in the past by wtshaw in
the group. Generalizing (modifying) a little bit the underlying
idea, I have posted three related schemes, the first being
based on modular rests, the second on coding (up and down)
run lengths, and the third on continued fractions.

In this note I like to present set another uncommon number
system in which the digits are not coefficients of powers of a
constant number (the base) but otherwise analogous to the
common number systems.

Any number U in N can be represented in terms of factorials
as follows:

       U = a_j*j! + a_(j-1)*(j-1)! + ..... + a_1*1!

with 0 <= a_j <= j.

The coding of U is then the sequence a_i.

The above representation is unique, since

      m! = (m-1)*(m-1)! + (m-2)*(m-2)! + ..... + 1*1! + 1

as can be easily shown.

M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen



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

From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: comp.theory
Subject: Re: Quantum Computing (Was: Newbie question about factoring)
Date: Sun, 9 Jul 2000 12:22:56 -0600

In article <[EMAIL PROTECTED]>, roger_95073@my-
dejanews.com says...

[ ... possible creation of a 7 qubit computer ] 

>   Up to now, proposed "quantum error correction" schemes have shown
>   merely how to preserve the state of qubits. Now, Los Alamos
>   researchers (Raymond Laflamme, 505-665-3394) have developed an
>   algorithm for carrying out reliable calculations on a "qubyte"
>   made of 7 entangled qubits while accounting for the possibility
>   that one of the qubits is corrupt (upcoming paper in Phys Rev Lett).
> http://www.aip.org/enews/physnews/1996/physnews.293.htm
> 
> It seems they developed an algorithm, not a computer or
> actual physical qubits.

No -- the article in Nature specifically described the use of trans-
crotonic acids and a nuclear magnetic resonance spectrometer to 
create a 7-qubit computer.  They mentioned having managed to 
accomplish something with the system, and indeed it may have been 
getting it to execute the algorithm mentioned above (since Laflamme 
is mentioned in both cases) but seemed reasonably specific about 
having created a physical computer and manipulated qubits.

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

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

From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Using CRC's to pre-process keys
Date: Sun, 9 Jul 2000 12:22:58 -0600

In article <8kaaun$mhb$[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] says...

[ ... ] 

> Sure, it's plenty clear.  (It's also slightly wrong, because SHA1 produces
> a 160-bit output, so collisions only occur after 2^80 hashes.)

More accurately, collisions start to become reasonably likely after 2
^80 hashes -- in theory, you might accidentally find a collision 
after only 2, and you aren't really guaranteed to find a collision 
until you do 2^160+1 hashes.

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

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

From: "tok" <[EMAIL PROTECTED]>
Subject: Re: Concepts of STRONG encryption using variable base 
http://www.edepot.com/phl.html
Date: Sun, 9 Jul 2000 20:31:30 +0200

In fact 'Base encryption : unbreakable' is trivialy breakable :

it's only base transformation , some basic operations, and a new base
transformation

example on his web site :

Given cyphertext: nphiwva8nas4xf0u8kyuw1etq3hsxb0ks4qbrlr27b6dam8tu4bily.5i

Run Virtual Calc 2000
Click on BASE button.
Enter 36 into Custom Base Box (then press OK).
Enter the above Cyphertext into Expressions Box (you can paste it in).
Follow the message with +33*6/4.5
Press Calculate.
Click on Base Button.
Enter 62 into Custom Base Box (then press OK).




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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A thought on OTPs
Date: Sun, 09 Jul 2000 20:50:34 +0200



"Douglas A. Gwyn" wrote:

> Mok-Kong Shen wrote:
> > My point has been that it is an interesting fact that, while there is no
> > generally applicable test for independence (a correlation test can be
> > considered a pre-test to screen out unnecessary test candidates) in
> > practice, one nonetheless in quite a number of places of applied
> > statistics makes assumption of independence of random varaibles (and
> > deduces results, which are certainly theoretically interesting, but
> > .....).
>
> Your point seems to be confusion.  As I have repeatedly explained,
> independence is a (mathematically precisely defined) property that
> is used in the construction of a *model*.  It is no different from
> using the property that an unbiased cubical die has the probability
> 1/6 of showing a particular number 1..6 when rolled, or any similar
> theoretical property.  It allows us to make predictions, e.g. what
> the odds are for the total on N dice.  Whether or not the model is
> sufficiently accurate in describing a particular actual real-world
> experiment is a different matter; by having precise theoretical
> properties, we are able to make predictions and devise tests that
> measure how well the model actually fits the observations.  For
> randomized behavior, these (inherently statistical) tests cannot
> (for a potentially unbounded set of observations) *prove* with 100%
> certainty that the observed system is behaving *exactly* in
> accordance with the model; what such a test provides is a measure
> of the degree to which the observations are consistent with the
> model.  If we make enough observations and there is a large
> discrepancy between what the model predicts and what was observed,
> then our confidence in the model's predictive ability for this
> particular physical set-up becomes very low.  Pearson's chi-square
> is a typical classical test of this kind, although there are others.
> This whole area should be discussed in any decent textbook on
> statistics, typically under the heading "hypothesis testing" if
> not at the very beginning of the text.

The chi-square test can be used to test how well the hypothesis
that the die is unbiased, i.e. there is a test for the adequacy of
the model. There is no parallel in the case of independence of
random variables (there is no test).

M. K. Shen



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

From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: Proposal of some processor instructions for cryptographical 
Date: Sun, 09 Jul 2000 12:11:34 -0700

Mok-Kong Shen wrote:
> Actually I don't think that a general bit permuation instruction is very
> extravagant. There is, if I don't err, normally a translate instruction that
> does bytewise substitutions according to an array of 256 elements.

Can you name a general purpose CPU architecture introduced in the last
twenty-five years with such an instruction?

While we can imagine uses for a transposition instruction, a concrete
example of an algorithm implementation showing
  a) how it is implemented today,
  b) how it would be implemented with some specific proposal
  c) an argument on the performance and cost differences
     between the two (generally, performance = time, cost = memory space)

Note that there has been work on implementing permutation networks,
particularly in the context of a parallel computer with a crossbar
interconnect, so a lot of work on estimating the hardware cost might
be done by research.  I haven't looked at that stuff in a decade or
so.  A naive crossbar implemented (which would look a lot like a
single stage barrel shifter) is likely the worst case implementation.
-- 
Samuel S. Paik | http://www.webnexus.com/users/paik/
3D and multimedia, architecture and implementation



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

From: [EMAIL PROTECTED]
Subject: Advanced Cryptography FAQ
Date: Sun, 09 Jul 2000 19:31:27 GMT

=======================================================
Advanced Cryptography FAQ (Frequently Asked Questions)
=======================================================

The purpose of this FAQ is to inform the cryptographic community of
future (advanced) directions in the field of encryption as we
move into the new age of speedy computers and vast internet
interconnectivity.

=======================================================
Table of Contents:
1. What is cryptography?
2. What is wrong with it?
3. What is the solution to fixed keys?
4. What is the solution to fixed algorithms?
5. What is the solution to fixed symbols?
6. How is the internet going to change cryptography in the future?
7. What algorithms out there is going to take us there?
8. Where can I find documentation on Base Encryption?
9. Is it true Base Encryption is revolutionary?

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

1. What is Cryptography?

Cryptography is the study of encryption and its related components.

=====================================================================
2. What is wrong with it?

The current state of encryption these days have an inherent weakness
in that they are based on static keylength, static operators and
operations (algorithms), and a static symbol set (base).

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

3. What is the solution to fixed keys?

Dynamic length keys that cannot be permutated through.
=====================================================================

4. What is the solution to fixed algorithms?

Dynamic algorithms that are not fixed, so you can't attempt to
crack and find weaknesses in it like a cypherblock.


=====================================================================
5. What is the solution to fixed symbols?

Dynamic symbol sets (base).  Not knowing the base of a cyphertext
or plaintext prevents any initial basis for attacks.


=====================================================================
6. How is the internet going to change cryptography in the future?

The beginning of the computer industry started on mainframes and black
boxes that you put things into and obtain result.  This provided the
start of many-to-one relationships between user and machine.  As more
people wanted access to the machine, they either formed queues or
placed their computational inquiries into tickets to be batch processed
by the mainframes.  This eventually led to dumb clients and smart
servers.  But as things goes, some people wanted more power in their
clients (why do I always need to
connect to the mainframe?).  This led to client-server
architectures, and the boom to Solaris OS and Windows NT.
(but usually the servers just host the filesystem or some
critical database).  As things started picking up and people started
using their POWERFUL clients (PCs), the internet exploded.  Basically
the powerful servers that the clients communicated with got
replaced by websites.  Now everything is stored on the internet
and your PC became a dumb client again (just a browser to browse the
internet).  Well, you know how things go... what goes around comes
around.  History repeats itself.  So the browsers (dumb clients) became
more powerful and then had the ability to run applications (java
applets and ActiveX controls), and do client-side scrypting
(javascript, Vbscript).  Organizations like XML are popping up
to allow you to do client-side manipulation and rendering.
Do you know what this trend leads to?
Yes you guessed it...  Client-side webservers.  There will be more
powerful clients to the point where anyone with an internet connection
can use their browser to host data dynamically (without a registration
with DNS, or a dynamic way to register on the fly).  This is
basically to balance out the powerful webservers.  As clients
become internet-aware, they will serve as producers (not just
consumers of the internet like they are now).

The ability to use a website as a cryptographic
primitive is beginning to take shape.  We already have webservers
dedicated to servicing authentication (verisign is one).  There
are also servers connected to the internet that provided kerberos
authentication (built in most NT machines these days).

But the question comes to mind... Is it possible to use
webpages in hierarchical or maybe random order as a cryptographic
primitive?  Absolutely.  Most computers communicate
on the TCP/IP channel through ports.  There are special ports
that are dedicated to serving certain types of traffic.  They
are simply numbered...  It happens that telnet uses one port
and http (the browser protocol) uses another.  There are thousands of
these ports.  You can simply make one up and communicate through it
using any protocol you want.  Well, why not use http protocol as the
default protocol?  Why not?  The data can be in static
webpages or dynamically generated via asp, perl, or cgi programs.

The order of the links between webpages (if you want to use
w3c xhtml 4 conforming pages) can serve as indices to other
algorithms or segments of the cyphertext (base encryption
can utilize this concept mind you).
There are too many ways this can be approached.

Some questions that gives new directions...
Why does the cypherblock need to be on my local machine?
Why do I need to use a cypherblock?
Why not utilize webservers?
Why not use multiple webservers?
Why not utilize the whole internet as my algorithm?

See below...

=====================================================================
7. What algorithms out there is going to take us there?

Base Encryption.  Its the most revolutionary encryption algorithm
in existence.
=====================================================================

8. Where can I find documentation on Base Encryption?

http://www.edepot.com/phl.html

=====================================================================
9. Is it true Base Encryption is revolutionary?

Yes.  It utilizes the concepts of dynamic keys, dynamic algorithms,
dynamic base (symbol set), and many other advanced concepts that will
take cryptography into the future.  It breaks new ground and just
now are the community realizing its revolutionary impact on the
world.

Many people are now broken up into two groups...

1) Those that want to have something (anything!!!) to do with it
   to steal credit or get some personal gain as base encryption
   revolutionizes the cryptography world.
2) Those that are attacking it.

For people in group 1), there is nothing much to say but thanks
for confirming your acceptance of my revolutionary invention,
and no you don't get credit for it.  Simply do a deja.com search
and you will find my invention was created in 96 (the time
virtual calc was made).

For people in group 2), here are some interesting tidbits...

Many people are not able to think outside of the box.
They are limited by what they know, and are accustomed to.  Its
like the old story about the young elephant being tied with a
weak chain, and later in life thinks he can't break it (even
though he IS able to do it as an adult).

The first rejection of new concepts usually starts with violent
and aggressive attacks.  This is the customary reflex response to
protect the familiar.  It is an instinct inborn in most animals
against predators.  For example, most fishes swim in schools.  Most
animals (with the exception of primarily hunters like lions) gather in
groups.  When things out of the ordinary (a new species encountered)
happens upon the group, they will all retreat or attack.  This is in
response to the group's need to survive (we are surviving ok without
this new species, so as a group we want to keep things the same, and
this new specie is interrupting this balanced stability).  Think of the
spanish inquisition, and the death of many astronomers.

In a similar sense, if you are able to think outside of the box, you
will realize that what you reject most is usually what you
are most afraid of, or have least experience in.  It is the ego
of the mind to assure itself that the paradigm that it has built up to
label and categorize the world is correct.  Once a person
has spent a long time and effort on something, it would hurt to find
that what they studies was basically wrong or useless.

As for Base Encryption, for those that have read it, it simply
broke their traditional textbook trained mind.  They are afraid to
admit that it is true.  People started asking for source code.  They
could not find a fault with it. They simply just attacked with no
coherent reason why they are
rejecting it other than that it was different, and anything different
can't be right... can it?

Many have failed to even try to attack it because they can only
think in traditional ways learned from traditional textbooks
(fixed keylength and fixed algorithms confined in a cypherblock).

Base Encryption breaks new ground and provides future directions
for cryptography.

The whole base encryption can be found at
http://www.edepot.com/phl.html
There is also a tool that can be used to test encrypting and decrypting
of messages there: Virtual Calc 2000.





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

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

From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: Proposal of some processor instructions for cryptographical 
Date: Sun, 09 Jul 2000 12:43:32 -0700

My editing seems to have gone out the window.  Let me try again...

Mok-Kong Shen wrote:
> Actually I don't think that a general bit permuation instruction is very
> extravagant. There is, if I don't err, normally a translate instruction that
> does bytewise substitutions according to an array of 256 elements.

Can you name a general purpose CPU architecture introduced in the last
twenty-five years with such an instruction?

While we can imagine uses for a transposition instruction, a concrete
example of an algorithm implementation showing
  a) how it is implemented today,
  b) how it would be implemented with some specific proposal
  c) an argument on the performance and cost differences
     between the two (generally, performance = time, cost = memory space)
might be illuminating.

Note that there has been work on implementing permutation networks,
particularly in the context of a parallel computer with a crossbar
interconnect, so a lot of work on estimating the hardware cost might
be done by library research.  I haven't looked at that stuff in a decade
or so.  A naive crossbar implemented like a single stage barrel shifter
is likely the worst case implementation.
-- 
Samuel S. Paik | http://www.webnexus.com/users/paik/
3D and multimedia, architecture and implementation



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

From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: computer program:  extract consonants/vowels from input
Date: 09 Jul 2000 20:00:49 GMT

Jeff Mullen [EMAIL PROTECTED] writes, in part:

>There are arguments that "w" is a vowel when used
>in words like "own" and "skew," but a consonant in
>words like "Winter" (there is an argument that "w"
>is a vowel in "Edward" but not in "Walter").  There
>is an argument that "y" is a vowel in "sky" but
>not in "Yellow" (there is an argument that "y" is
>a vowel in "Jeffrey" :) :) :) but not in "Yosemmitie").

English vowels are A, E , I, O, U, and sometimes
Y,  which mimics the sound of a short or long "I,"
as in symmetric or rhyme.

The case for W as a vowel is probably made because
the letter was originally a double-u, written as
VV.  The case is a weak one, so you're better
of treating Ws as consonants.

Joe
__________________________________________

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


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

Date: Sun, 09 Jul 2000 16:21:10 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical   

Mok-Kong Shen wrote:

> Holger Bettag wrote:
>
> > Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> >
> > > Skipper Smith wrote:
> > >
> > > > Have you looked at the AltiVec instructions contained in the MPC7400?  You
> > > > can download the manual from:
> > > > www.mot.com/SPS/PowerPC/teksupport/teklibrary
> > >
> > > It would be nice, if you would give a list of instructions of that processor
> > > that are particularly relevant for crypto.
> > >
> > "Vector permute" would be the most outstanding candidate. Together with
> > "vector select" and the bitwise shifts/rotates, one can build almost arbitrary
> > bit permutations.
>
> Would you please explain a little bit these instructions and illustrate
> with a tiny (reduced) example of how to effect an arbitrary permuation?
> Thanks.

BIT REVERSAL

In the absence of bitfield addressability bit reversing bytes is not at all
difficult or slow given a 256-byte LUT and the equivalent of an XLAT instruction.
Even the XLAT is unnecessary.

Since bit reversal has a property of self similarity (larger entities can be
reversed by swapping and reversing their components), bit reversing words is not
much harder.  One performs the byte translation described above, and then swaps a
few bytes around.  For a 64-bit value the swapping can be performed inline given an
addressing mechanism of only mediocre flexibility.

On the x86 architecture one can perform the entire swapping process with three MMX
registers, and by interleaving the LUT access with the swapping I'd guess the whole
process should take under 20 clocks.  This ignores LUT cache latency because either
you need really high performance bulk bit reversal, in which case the LUT is
probably in cache, or you are using bit reversal infrequently, in which case there's
no reason to worry about bit reversal performance.

ARBITRARY PERMUTATION

Imagine an IO device which was a form of bitwise plugboard.  One could write an
arbitrary value to the input port (or memory location) and read back the permuted
value from the output port (or memory location).  Presumably this could operate at
full CPU speed.  With a third port to configure the permutation mechanism, you would
have a tiny crypto engine to prove the utility of your architectural comments.  If
you wanted to be thorough you would provide enough configuration storage to make
each output bit an arbitrary function of the input bits.

This kind of device is not hard to create.


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


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