Cryptography-Digest Digest #513, Volume #9 Fri, 7 May 99 12:13:03 EDT
Contents:
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (Mok-Kong Shen)
Re: Random permutation (Mok-Kong Shen)
Re: Random permutation ([EMAIL PROTECTED])
Re: Random permutation (Mok-Kong Shen)
Re: The simplest to understand and as secure as it gets. ([EMAIL PROTECTED])
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO ([EMAIL PROTECTED])
Re: Roulettes ([EMAIL PROTECTED])
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (Mok-Kong Shen)
Re: Random permutation (Volker Hetzer)
Re: The simplest to understand and as secure as it gets. (SCOTT19U.ZIP_GUY)
Re: Random permutation ([EMAIL PROTECTED])
Re: Random permutation (Jon Haugsand)
Re: Shamir's TWINKLE Factoring Machine (Robert Harley)
Re: Pentium3 serial number is based on who you [server/exterior] claimed
([EMAIL PROTECTED])
Re: Books (John Savard)
Re: Roulettes ([EMAIL PROTECTED])
Bricklaying DES (Piso Mojado)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (Mok-Kong Shen)
Re: Random permutation ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Fri, 07 May 1999 13:42:46 +0200
SCOTT19U.ZIP_GUY wrote:
>
> Like I said these are my comments internal to the program. The
> Flag or flags was for various states internal to the program and
> not actaully an EOF symbol being written out. That being said there
> are several basic ending to the file. The comment "case 1 added .."
> does happen to be in the code path where padding can occur. The
> Huffman tree is not a typical tree. For example there is never a
> token that can have more than 8 one's connected in series. The tree
> is built so that there is never a single tokem made up of all
> zero's such that the symbol could can less than 8 zero's.
> in other words when one compresses there is never a token of exactly
> one zero or two zeroes or three zeroes up to seven. There might be
> one that has exactly 8 but in most cases when real compression takes
> place there may not even be one with 8 zeros. Though there is in the
> very begining and for certain special cases. That being said.
> For a large number of cases when compression occurs and does not end
> of a byte boundary. The last byte is padded with zeros. This padding
> would consist of one (or zero if you think about it) to seven zeros.
> Note this is not a token since the smallest all zero token can only
> be 8 or more bits in length. Know some of the specail cases.
> Suppose the last symbol being written crosses a byte boundary and
> on the last byte boudary it would have written only 1's and on the
> token before the spanning it is not all zeros. In this case I don't
> even write the last byte at all. The flags and such where to keep
> track of conditions as I did testing. You may want to edit out
> all comments. But what I hope works is that for any file X if you
> decompress it to Y and then recompress it to Z then file X and Z
> are exactly the same. But note the EOF or zeros in my code are not
> always there. And when using even just ascii many differet cases
> can pop up. The trick is since any file can be a valid compression
> there is no easy handle for the attacker to use when he guess a key
> to an encrypted file that was compressed by my method.
You never know what kind of files are going to be compressed by
your program. Someone might try to compress ANY binary file with
that. So you can't ignore some cases because they are rare in your
opinion. Consider an extremely unbalanced tree with 8 nodes such
that each right branch (taking 1) leads to a terminating node. Then
8 0's is a valid symbol. Well, in this case you could mirror the
tree and avoid the situation. But you are handling 256 symbols and
the tree is constantly being updated. Of course, you could build
in a barrier while building the tree in order to avoid 8 0's being
the code of a valid symbol. But is then the tree optimal? Perhaps
you could find some way in arbitrairy situations to achieve
that similar to what I illustrated above. But that would make your
program logic unnecessarily complicated. And I am not sure that you
can easily show that the optimality is always preserved.
The second point is that you are (explicitly or implicitly) using
8 0's as EOF. If instead of that you simply have another group
of bits (also not in the Huffman tree) as EOF for termination there
can be no functional difference I can see, excepting that your trick
of leaving out the last byte (under certain circumstances) cannot
be applied. (This EOF will be hanging around during updates of the
Huffman table and will have different codes assigned to it at
different time points. It is only the last version that you output.)
I am not sure of having time to do extensive tests of your program,
for I am mainly interested in the principles of doing compression
and in that direction my doubts concerning your program have not
yet been eliminated, as argued above. But my argument points out
at least that one useful way to test your program is to feed it with
files having very extreme frequency distributions (one should also
take care to have all 256 symbols, thus forcing the tree to be
as big as possible).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random permutation
Date: Fri, 07 May 1999 13:57:35 +0200
[EMAIL PROTECTED] wrote:
>
> This returns a uniform choice from [0, 16!-1], which
> we cam map one-to-one to the possible permuations. It's
> optimal in the expected number of calls to rand16().
Suppose you have computed x as a uniform choice. How do you get from
x to the permutation desired? Do you maintain a table of all
permutations and use x as index to it?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Random permutation
Date: Fri, 07 May 1999 11:09:30 GMT
<snip>
Bisection method:
y = (x = S) + h;
for (t = r = 0; r < h; r++) {
temp[t++] = deck[(x + r) % n]
temp[t++] = deck[(y + r) % n]
}
memcpy(deck, temp, sizeof(deck))
Where n = number of cards, h = n/2. As long as you don't repeat a patern (S
values) such that w*n < n! or w*n < 2**wlog2n.
In other words, the number of S values (before repeat) times n less then n
factorial OR less then the complexity of the key used (small w for words per
key with log2n bits...)
For the S values a Linear Congruetial will work (discarding the lower order
bits because they are not random).
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random permutation
Date: Fri, 07 May 1999 14:15:46 +0200
[EMAIL PROTECTED] wrote:
> Bisection method:
>
> y = (x = S) + h;
> for (t = r = 0; r < h; r++) {
> temp[t++] = deck[(x + r) % n]
> temp[t++] = deck[(y + r) % n]
> }
>
> memcpy(deck, temp, sizeof(deck))
>
> Where n = number of cards, h = n/2. As long as you don't repeat a patern (S
> values) such that w*n < n! or w*n < 2**wlog2n.
>
> In other words, the number of S values (before repeat) times n less then n
> factorial OR less then the complexity of the key used (small w for words per
> key with log2n bits...)
>
> For the S values a Linear Congruetial will work (discarding the lower order
> bits because they are not random).
Is this your own method or is there literature where the method
is dealt with in more detail? I have never heard of the name
bisection method in the present context.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The simplest to understand and as secure as it gets.
Date: Fri, 07 May 1999 12:11:35 GMT
> I use scott16u for most of my stuff that is passed to others
> it is kind of a block cipher but the block size is the size of
> the file.
So it's a OTP cipher? Hmm not really secure then... or is it something else?
(OTP are not secure, because they are impractical at best, i know they are
provably mathematically secure....)
I wouldn't mind seeing a description of your cipher, like you I like playing
around with ideas. Maybe I could find something you may have missed. Do you
have a paper (or just a text file) describing your cipher online?
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Fri, 07 May 1999 12:55:00 GMT
> You never know what kind of files are going to be compressed by
> your program. Someone might try to compress ANY binary file with
> that. So you can't ignore some cases because they are rare in your
> opinion. Consider an extremely unbalanced tree with 8 nodes such
> that each right branch (taking 1) leads to a terminating node. Then
> 8 0's is a valid symbol. Well, in this case you could mirror the
> tree and avoid the situation. But you are handling 256 symbols and
> the tree is constantly being updated. Of course, you could build
> in a barrier while building the tree in order to avoid 8 0's being
> the code of a valid symbol. But is then the tree optimal? Perhaps
> you could find some way in arbitrairy situations to achieve
> that similar to what I illustrated above. But that would make your
> program logic unnecessarily complicated. And I am not sure that you
> can easily show that the optimality is always preserved.
I agree that not all files will compress, that's why compression and
encryption are different fields. Although diffusion is used to hide the
statistical side of things (confusion obviously confuses the output from the
input) and compression is an effective way of removing such influences, it is
only usefull if used with encryption in conjunction.
That's why ciphers that use huffman coding (with private trees) are not very
effective. You can tell which symbols are more frequent then others.
I think that you should actually separate the compression from encryption in
your program, and in your description. They are not comutable, and shouldn't
be treated as so.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Roulettes
Date: Fri, 07 May 1999 12:18:23 GMT
<snip>
Random value try this...
Setup a RC4 array from 0..15 (not to 255), then perform the rng function
(which produces the output) repeatedly (mod 16) until the user hits a key.
The last output made will be the 'dice face'.
You can readily change the algorithm, and it's easy. You could have the last
n outputs tapped. But this would only make 4 bit results, for a marginal key
of 64 you would need to tap the last 16 outputs, which will most likely just
be a 'shuffle' of [0..15].
You could then try the Bisecting method using the top 4 bits from rand(), as
long as you don't leave the program run for 16 * l (l = cycle length of the
top 4 bits of rand()) iterations you are set. usually the cycle length is
the size of the rand() arugment, or 2**32 so you could let this program go
for 2**36 iterations, or about 10 minutes... To ensure that each output is
'random' you could save the current state and use it as a starting spot
later.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Fri, 07 May 1999 15:22:04 +0200
[EMAIL PROTECTED] wrote:
>
>
> That's why ciphers that use huffman coding (with private trees) are not very
> effective. You can tell which symbols are more frequent then others.
>
> I think that you should actually separate the compression from encryption in
> your program, and in your description. They are not comutable, and shouldn't
> be treated as so.
Scott does separate compression from encryption. He uses adaptive
Huffman. There is no key involved in the compression process.
Combination of compression and encyption is indeed possible but
then your frequency argument doesn't hold.
M. K. Shen
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Random permutation
Date: Fri, 07 May 1999 15:20:53 +0200
Mok-Kong Shen wrote:
>
> A problem raised in another thread is whether it is possible e.g.
> to generate a random permutation of [0, 15], given only a random
> generator for [0, 15] and no generator for [0, 14], etc. One way I
> can think of is quite trivial: One obtains successive outputs from
> the generator and discards duplicates until one gets 16 numbers.
>
> Question: Are there more efficient ways of achieving the same goal?
Like modulo?
Greetings!
Volker
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The simplest to understand and as secure as it gets.
Date: Fri, 07 May 1999 13:19:17 GMT
In article <7gul9l$1k9$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> > I use scott16u for most of my stuff that is passed to others
> > it is kind of a block cipher but the block size is the size of
> > the file.
>
> So it's a OTP cipher? Hmm not really secure then... or is it something else?
> (OTP are not secure, because they are impractical at best, i know they are
> provably mathematically secure....)
>
No it is not a OTP but there is a write up by a guy at my site.
There are links to the code at my webpage. I hope your in the
US so you can get scott19u it is better. But the main difference
is I use 19 bit fields in it while the 16u uses 16 bit fields.
> I wouldn't mind seeing a description of your cipher, like you I like playing
> around with ideas. Maybe I could find something you may have missed. Do you
> have a paper (or just a text file) describing your cipher online?
>
> Tom
Tom if you are in the free west or anyone in that area. You have
more blessings if you export the code. Since it may be legal in
the far west to do so. Note the Ninth Court disicion.
David A. Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Fri, 07 May 1999 11:04:44 -0400
From: [EMAIL PROTECTED]
Subject: Re: Random permutation
[EMAIL PROTECTED] wrote:
>
> Mok-Kong Shen wrote:
> > A problem raised in another thread is whether it is possible e.g.
> > to generate a random permutation of [0, 15], given only a random
> > generator for [0, 15] and no generator for [0, 14], etc. One way I
> > can think of is quite trivial: One obtains successive outputs from
> > the generator and discards duplicates until one gets 16 numbers.
> >
> > Question: Are there more efficient ways of achieving the same goal?
>
> If efficient means we want to use the fewest calls to our
> random number generator, use the same idea as we used to generated
> a uniform choice in [0..n) given a uniform and independent bit
> source. Suppose rand16() returns a random choice from [0..15].
>
> endRange = 1
> randInRange = 0
> while true
> while endRange < 16!
> endRange = endRange * 16
> randInRange = randInRange * 16 + rand16()
> if randInRange < 16!
> return randInRange
> else
> endRange = endRange - 16!
> randInRange = randInRange - 16!
>
> This returns a uniform choice from [0, 16!-1], which
> we cam map one-to-one to the possible permuations. It's
> optimal in the expected number of calls to rand16().
I question the characterization of this approach as efficient. It
requires use of numbers well over 32-bits in length due to the
computation of 16 factorial. It will work on a 64-bit machine, but not
on a 32-bit machine. And even on a 64-bit machine it does not scale
well at all.
>
> --Bryan
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Jon Haugsand <[EMAIL PROTECTED]>
Subject: Re: Random permutation
Date: 07 May 1999 16:30:02 +0200
* [EMAIL PROTECTED]
> One way to do this is to discard samples over the largest multiple of
> the subset size, and use modulus on the samples less than that
> multiple. Thus you'll discard only a few samples. This requires a
> division, a multiplication, and a modulus but it is useful if samples
> are expensive.
You could still improve if you do not discard the excess information,
but stores it for later use. E.g. If you need a random number lower
than 7, you take your random number x. If it is lower than 14, you
divide by 2 and get your result. Further you store the fact whether it
was lower or higher than 7. If it was 14 or 15, you store this fact
also, and repeat the process.
When you later need a number, say, below 6, you can use the above
information and ask for a number below 3.
There is one reason not to use this. The risk of a programming error.
--
Jon Haugsand
Norwegian Computing Center, <http://www.nr.no/engelsk/>
<mailto:[EMAIL PROTECTED]> Pho: +47 22852608 / +47 22852500,
Fax: +47 22697660, Pb 114 Blindern, N-0314 OSLO, Norway
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: Shamir's TWINKLE Factoring Machine
Date: 07 May 1999 16:51:57 +0200
[EMAIL PROTECTED] (Bruce Schneier) writes:
> >Could there be mathematical advances which make the matrix problem for
> >the discrete-log problem equivalent to the factoring one?
>
> I don't think so. For RSA, you can solve the linear equations in mod
> 2. For discrete log systems, you have to work modulo the
> chracteristic of the field.
No, for DL you have to solve modulo the prime factors of the field
size minus one. These factors can be just about anything *except* the
characteristic!
Bye,
Rob.
------------------------------
Date: Fri, 07 May 1999 11:37:19 -0400
From: [EMAIL PROTECTED]
Crossposted-To: alt.security
Subject: Re: Pentium3 serial number is based on who you [server/exterior] claimed
Paul Koning wrote:
>
> RD OMeara wrote:
> > ...
> > Tamper-resistant software is a "black art," Abbott said, and several
> > companies in the security industry have tried their hand at it.
> > "Think of them [tamper-resistant agents] as armor around something.
> > They can always be taken apart and defeated, but the effort becomes
> > too much," he said.
>
> I think a more accurate statement would be "tamper-resistant software
> is non-existent".
>
> The whole concept is utterly nonsensical.
What is the basis for your conclusion?
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Books
Date: Fri, 07 May 1999 15:33:46 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>The real reason it doesn't have "earth-shattering revelations" is
>that basically it's just an intranet, which is pretty ho-hum.
>The only really interesting thing about Intelink is the "content".
Yes, the content is doubtless highly interesting - on occasion. The
technology needed to achieve the required security, of course, has its
interest too.
And metadata (SGML, XML) is the "future of the Web"...within limits.
To the extent it increases the effort required to create a Web page,
it will be slow of adoption where no requirement is felt.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Roulettes
Date: Fri, 07 May 1999 13:40:44 GMT
> Mmm. You need at least a palmtop. Wouldn't dice be more handy
> for you?
>
Given the money, I could build a large stamp size computerized dice (for about
100 dollars)... Using a small AVR cpu and some leds...
Of course my method (bisecting) outputs 16 values at once, and requires a long
RNG (probably a LFSR of at least 2**128 complexity).
Alas poor york :), you are right. Thine method of using a dice would most
likely be 'random' enough. Of course you can always use more then one die at
a time. You would have to check to make suer the dies are weighted
correctly... Hmm reminds me of a game of monopoly which I cheated in by
putting extra 'paint' on the dies... :)
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Piso Mojado <[EMAIL PROTECTED]>
Subject: Bricklaying DES
Date: Fri, 07 May 1999 08:48:12 -1000
To make DES have a wider Block, it could be staggered like
a brick wall:
Left1a Right1a Left2a Right2a Left3a Right3a first round
Right1b Left2b Right2b Left3b Right3b Left1b second round
Left2c Right2c Left3c Right3c Left1c Right1c third round
..
..
..
A DES block has a Left and Right half so in the second round
the inputs are the ciphertexts from the first round, but shifted
to the left by half a block. This has a block size of 192 bits
and new keys for each DES brick. The advantage is in the diffusion
of text bits through the whole block and in longer keys. This
may be generalized for any block size and key size by parameters
which are easily communicated.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Fri, 07 May 1999 15:56:40 +0200
SCOTT19U.ZIP_GUY wrote:
>
> > You never know what kind of files are going to be compressed by
> > your program. Someone might try to compress ANY binary file with
> > that. So you can't ignore some cases because they are rare in your
> > opinion. Consider an extremely unbalanced tree with 8 nodes such
> > that each right branch (taking 1) leads to a terminating node. Then
> > 8 0's is a valid symbol. Well, in this case you could mirror the
>
> It handles the case of 8 0's. The tree is such that there is
> never a symbol made up of all zeros less than eight.
(I suppose you wanted to say 'never a symbol containing 8 or more
zeros as prefix.)
>
> > tree and avoid the situation. But you are handling 256 symbols and
> > the tree is constantly being updated. Of course, you could build
> > in a barrier while building the tree in order to avoid 8 0's being
> > the code of a valid symbol. But is then the tree optimal? Perhaps
>
> Yes the tree is optimal since there is always more than tree that
> preserves same symbol lengths.
>
> > you could find some way in arbitrairy situations to achieve
> > that similar to what I illustrated above. But that would make your
> > program logic unnecessarily complicated. And I am not sure that you
> > can easily show that the optimality is always preserved.
>
> Yes I am sure the logic is somewhat complicated but that is
> what computers are made for.
This effort to check for avoiding the occurence of 8 0's as prefix
can be saved if you have an EOF in my sense.
> >
> > The second point is that you are (explicitly or implicitly) using
> > 8 0's as EOF. If instead of that you simply have another group
> > of bits (also not in the Huffman tree) as EOF for termination there
> > can be no functional difference I can see, excepting that your trick
> > of leaving out the last byte (under certain circumstances) cannot
> > be applied. (This EOF will be hanging around during updates of the
> > Huffman table and will have different codes assigned to it at
> > different time points. It is only the last version that you output.)
>
> No there is no EOF hanging around in the tree. However many times
> like you note above O to 7 zeros could be thought of as the effective
> EOF in many of the cases. But not all. If you can code an EOF such
> that any file could be treated as decompressed file of another then
> fine.
This 'hanging around' is meant for my EOF. One assumes from the
very beginning that the input file contains such an EOF (outside of
0 -255) with the lowerst frequency than any actual symbols. In
all the updates of the Huffman table one takes that into consideration.
As the tree gets dynamically modified, it may or may not have
the code assigned to it changed. But that doesn't matter. At end
of the input file one then output the code of EOF and fill with
anything after that to byte/word boundary. This would be my scheme.
What do you mean by 'any file could be treated as decompressed file
of another'? Do you mean that the code of my EOF has no correspondence
to any actual symbol in the range [0, 255]? But neither does the
ensemble of filling bits of 0's that you introduce at the end.
> >
> > I am not sure of having time to do extensive tests of your program,
> > for I am mainly interested in the principles of doing compression
> > and in that direction my doubts concerning your program have not
> > yet been eliminated, as argued above. But my argument points out
> > at least that one useful way to test your program is to feed it with
> > files having very extreme frequency distributions (one should also
> > take care to have all 256 symbols, thus forcing the tree to be
> > as big as possible).
>
> I have tested all 2 byte files and only a few that use all 256
> symbols. So you may have a point but the tree is consturcted such
> that there are "always exacatly 256 symbols" I start with a very
> small weight for unused symbols. Then when a symbol occurs its weight
> is greatly increased so that if one looks at node on top of unused
> symbols it would be the node that the old code uses as a NOT YET
> OCCURED symbol. But when all 256 synbols have occured then you
> just have a normal looking huffman tree of 256 symbols. My method
At your place I would try to use, as said, a file of extreme
(the opposite of uniform) frequency distribution to 'exercise'
the program to its limit.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Random permutation
Date: Fri, 07 May 1999 13:51:49 GMT
> Starting with A[i] = i for i=0...15,
>
> for(i=0; i<n; i++)
> Interchange the value of A[i] and A[r(i)]
>
> where r(i) is a random number from 0...15. Make n at least 16.
Swaps are slower then my bisecting method (is it mine?) and it would require
more random information. Given the same size LFSR for the RNG your method
has a shorter cycle then mine.
Not to be picky... BTW this is in theory RC4, but more generalized. Yeah!
RC4 is a cool method, albeit slow though.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
