Cryptography-Digest Digest #23, Volume #12 Wed, 14 Jun 00 04:13:01 EDT
Contents:
SBOX Bananza (tomstd)
Re: More papers online (David Hopwood)
Re: Is Gretchen down? (Patrick Farrell)
Re: Session key transmission (John Savard)
Re: matrix question (Benjamin Goldberg)
Re: Why the golden ratio? (lcs Mixmaster Remailer)
Re: Cryptographic voting (Greg)
Re: quantum cryptography at nytimes.com ("Douglas A. Gwyn")
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: Why the golden ratio? ("Douglas A. Gwyn")
Re: Multiple encryptions (Bryan Olson)
Re: Evidence Eliminator Dis-Information Center (EE Detractor)
Re: pentium timings (Mack)
Re: Random sboxes... real info (David Hopwood)
Re: Reasonably secure OTP passing (Mack)
Re: Question about recommended keysizes (768 bit RSA) (Bohdan Tashchuk)
Re: Thoughts on an encryption protocol? (Volker Hetzer)
Re: Card Shuffling Protocol (Baruch Even)
----------------------------------------------------------------------------
Subject: SBOX Bananza
From: tomstd <[EMAIL PROTECTED]>
Date: Tue, 13 Jun 2000 18:15:03 -0700
Using the exponentiation in GF(2^8) and a bit of ingenuity I
have created 20 "close to ideal" sbxes (in a moment...). I
essentially took the Affine Transform from Rijndael and made the
sboxes be the inverse exponentiation (i.e logarithm). I used
the logarithm to avoid having S(0) = 0 and S(1) = 1, which is
wierd because they should map onto themselves... basically I did
sbox[x^e mod p] = x, 0 <= x < 256
The sboxes all have '0' and '1' in the same place but at least
it is not in the first two entries.
The sboxes have a LPmax of 16/256 and DPmax of 4/256 which means
they are perfectly non-linear but a magnitude of '2' away from
being perfectly immune to differential cryptanalysis. They
fulfill SAC as well.
A eight round 16-bit Feistel should be immune to both forms of
cryptanalysis (assuming independant round keys). Giving a 16x16
sbox. Using four rounds of this 16-bit sbox to make a 32x32
sbox should be secure, and an addition four rounds of the 32-bit
sbox (making a 64-bit block cipher) should be secure as well.
This assumes all round keys are independant. This 64-bit sbox
(block cipher) would need 4*4*8=128 key bytes. An again this
could be expanded to a four round 128-bit feislte with 128*4=512
key bytes.
The 128-bit cipher would be very slow but at 256 bytes rom and
512 bytes ram it's very compact. And since it's all byte
oriented and the code is very simple (extremely simple) it
should be ideal for smartcards as well (with 512 bytes to
spare :) ).
The program that made the sboxes is at
http://tomstdenis.com/files/goodgen.c
And the sboxes are at
http://tomstdenis.com/files/good8x8.c
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!
------------------------------
Date: Wed, 14 Jun 2000 01:00:00 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: More papers online
=====BEGIN PGP SIGNED MESSAGE=====
tomstd wrote:
> I added a few more papers (not my own papers) to the website...
> you can find them at
>
> http://tomstdenis.com/crypto/
>
> A while back I found a nice site that had a list of all
> published crypto-authors and their papers.
I don't know about "all", but
http://www.users.zetnet.co.uk/hopwood/crypto/scan/
has links to various lists of on-line papers at Counterpane,
Cryptography Research, the Theory of Cryptography Library, and a few
others, as well as a comprehensive collection of papers that define or
cryptanalyse specific algorithms.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOUbK7jkCAxeYt5gVAQHrdwf+NEkf3E/JQE/cN39CwttMtZUylcVHiEFL
P6cepC60gn7CrY05NbLK7fgzwtxwR/B4/JgXX+mPt3oKWud2/wX/q4A3b1nxx74g
4vkwN1EQ1YVIhX4Csq6n+BYJLK+ZQGWXjD00lKRic9iZMQLus7bcRSL1VGWsW3JG
mgOUOdcCLV0Y+19C76ZUgzCxkNJz/YMcnieduk5Cx1tX4z6nFi/9ZsrmwueUFJHF
+OP+9HIm+i9KN9WxbzTzrAoHBFZMGOz9HqEmSthl/lXis1mssz2EQ9RRF6gWlwow
OMiNcg/EadzUSjQHzUrt4skEY8fFZxm1Hxsd0Ipb+cyp8ZqY7qPobA==
=HmXX
=====END PGP SIGNATURE=====
------------------------------
From: Patrick Farrell <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Is Gretchen down?
Date: Tue, 13 Jun 2000 21:19:53 -0500
Reply-To: [EMAIL PROTECTED]
Would you please explain to me how someone can have a supercomputer on the net
at any one point that can capture all of the traffic on the net?
A) you need a pipe equivilant to the sum of the major backbones.
B) you need a computer or cluster that can read and filter on the fly this
ammount of information
C) you need a network interface for a data pipe that doesn't exist.
D) how does a system with IP range A, on subnet B, see data between systems C
and D with completely seperate subnets when the data is never even routed across
A's network. Unless you are implying that they have a vampire tap on every
major circuit and subcircuit that duplicates all traffic and then reroutes it to
their hosts.
I fail to see how such a thing is possible, but I would be interested in someone
illustrating the concept if they think it can be done.
Patrick
Tommy the Terrorist wrote:
>
> In article <[EMAIL PROTECTED]>,
> Stray Cat <[EMAIL PROTECTED]> wrote:
>
> > >is it?
>
> > No, but it is slow today.
>
> Do these time delayed remailers have any defense against the following
> tactic:
>
> a) ECHELON spots a PGP-encrypted message from someone they're
> suspicious of going through a remailer chain
>
> b) they simply stop all the e-mail going to the remailer for 24 hours,
> except for some precoded messages of their own which they know where
> they're going
>
> c) they let through the curious message
>
> d) when an e-mail other than one of theirs comes out the remailer, they
> watch where it goes, and restore the e-mail stream
>
> The users each think their mail is simply time delayed - "maybe" past
> the 24 hour limit of randomization
>
> The E-mail goes to the next remailer in the chain, where it gets the
> same treatment.
>
> The spies eventually mark down that so-and-so is such-and-such, then
> pick the next "suspicious person" to go after, and do it all over
> again.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Session key transmission
Date: Wed, 14 Jun 2000 03:59:44 GMT
On Tue, 13 Jun 2000 00:58:16 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>I have difficulty to fully understand the following from
>Schneier's AC, p.33:
> With symmetric crpytography, the data encryption key
> sits around until it is used. If Eve ever gets her hand
> on it, she can decrypt messages encrypted with it. With
> the previous protocol [employing public key], the
> session key is created when it is needed to encrypt
> communications and destroyed when it is no longer needed.
> This drastically reduces the risk of compromising the
> session key.
You raise a legitimate question. What is the difference between being
able to grab a private key - which sits around for a while, and which
is generated by doing elaborate arithmetic - and being able to grab a
secret key? If the secret key is used as a key-exchange key, even the
mechanics of generating a different session key each time seem to be
the same.
But there is *one* difference.
The secret key is _shared_. That means there are two places to grab it
from. And one of those two places might be much easier to grab it from
than the other.
And there are protocols - the Key Exchange Algorithm used by the U.S.
Government is one example - where a session key is the XOR of two
conventional session keys, each one securely communicated using the
public key of one of the two parties. So one has to grab both keys to
compromise the communications.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: matrix question
Date: Wed, 14 Jun 2000 04:33:58 GMT
Matt Timmermans wrote:
>
> Benjamin Goldberg wrote in message <[EMAIL PROTECTED]>...
> > [...]
> > /* out = in1 x in2, with dimensions [a x c] = [a x b] x [b x c] */
> > [...]
> > out[ out_a*a + out_c ] = out_ac;
>
> column out_a, row out_c is out[out_a*c + out_c], because each of the a rows
> has c items.
>
> You did this everywhere, but when your matrices were square, c == a, so the
> problem didn't show.
Ah Ha! Thank you so much. After fixing that [and some similar errors]
I
got my test output to be correct.
------------------------------
Date: 14 Jun 2000 04:40:45 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Why the golden ratio?
> I'm just wondering, a silly thing I just noticed while trying to
> implement several encryption algorithms, is why the golden ratio
> (sqrt(5) - 1)/2, multiplied by 2^32, where it comes out to be
> 0x9e3779b9, is so popular to use in many encryption algorithms. It
> figures in Serpent, as part of the key schedule system, and in TEA as
> well, and even in SHA-1. I'm sure there are lots of other fun
> irrational numbers to use, like the Euler-Mascheroni constant
> (0.577...), 1/pi, etc. Does the golden ratio have some properties that
> these other numbers don't?
There is something special about the golden ratio. It may relate to the
fact that 1/phi = 1+phi. I don't know how to express it mathematically
though.
Years ago we were doing a video game. We had many objects moving across
the screen, each with an x coordinate and a dx velocity per "tick".
The velocity was fractional but we only had room to store the coordinate
as an integer.
To solve this, we needed to increment the position on a probabilistic
basis depending on the velocity. With a velocity of 0.75 we'd increment
the position 3/4 of the time, etc.
The best way we found to do this was to use successive multiples of the
golden ratio. Take the fractional part and compare with the velocity.
Increment the position if the phi multiple was < velocity.
We tried several different constants but the multiples of phi produced the
smoothest, most uniform motion. No other value worked as well; they all
produced patterns where the object would move and pause, move and pause.
It seems that the fractional part of successive multiples of phi has
a certain kind of uniformity and smoothness in terms of how it changes.
This may make it attractive in certain contexts for ciphers as well.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Wed, 14 Jun 2000 06:02:28 GMT
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> Greg wrote:
>
> > But the tyrant with a gun can stop you from using your PC.
>
> "tyrant with a gun" is redundant.
No, he is just an armed tyrant, that's all...
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: quantum cryptography at nytimes.com
Date: Wed, 14 Jun 2000 06:15:29 GMT
Tim Tyler wrote:
> ... I must say I find it hard to imagine QC replacing
> very much conventional encryption anytime soon.
Due to the expense, the initial applications of quantum
cryptography are likely to be those for which guaranteed
secrecy is crucial.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
Date: Wed, 14 Jun 2000 06:12:56 GMT
"Trevor L. Jackson, III" wrote:
> "Douglas A. Gwyn" wrote:
> > Tim Tyler wrote:
> > > If the size of the program is constrained, a halting determination program
> > > could be written which enumerates all programs of that size or shorter and
> > > lists whether they halt or not.
> > It "lists" them how?
> Turing programs can be written as input to a UTM. Such inputs are a sequence of
> ones and zeros, so they are an integer. The list is ordered by the respective
> integer values.
You missed the point -- *how* does it determine whether they halt?
> ... Is there any reason to believe that the growth in our
> understanding of the universe will stop in the near future?
No, but that is not a counterargument. All knowledge is contextual,
and if some physical knowledge has been properly validated, it holds
in the context for which it was established, even if more is
discovered later. For our most fundamental physical principles,
that is already a wide context indeed.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Why the golden ratio?
Date: Wed, 14 Jun 2000 06:17:39 GMT
lcs Mixmaster Remailer wrote:
> The best way we found to do this was to use successive multiples of
> the golden ratio.
Essentially a Fibonacci scheme.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Multiple encryptions
Date: Wed, 14 Jun 2000 06:18:15 GMT
Mok-Kong Shen wrote:
>
> Bryan Olson wrote:
> > If the keys are independant, then against ciphertext-only or
> > known plaintext, the composition must be at least as strong
> > as the first cipher applied[...]
> > Against chosen plaintext, (again assuming independent keys)
> > the composition must be at least as strong as the stronger
> > of the two.
> Does the requirement 'the keys are independent' somehow
> implicitly also involve the additional requirement 'the ciphers are
> independent in design' (which is presumably difficult to ascertain
> in the absolute sense)?
No. We do make the usual cryptographic assumption
that everything but the keys is known to the attacker.
> For otherwise I am afraid that counter-
> example could be constructed such that a combination of two
> ciphers is weaker than a single one.
Go for it.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: EE Detractor <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.firewalls,alt.privacy.anon-server,alt.privacy
Subject: Re: Evidence Eliminator Dis-Information Center
Date: Wed, 14 Jun 2000 00:47:14 -0500
On Tue, 13 Jun 2000 01:37:00 GMT, "donoli" <[EMAIL PROTECTED]>
wrote:
>IMO the EEsupport guy is a rookie. As I said before he's trying to put out
>the fire w/ gasoline. Every time he posts he looses another potential
>customer.
Rather than merely disrupting the newsgroup, his goal is apparently to
increase sales by snagging the constant influx of newcomers. He's not
your typical troll but a spammer who trolls to advertise his product
and make money. Keeping quiet, as we would with a normal troll, only
works in his favor by letting him pitch his product without challenge.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: pentium timings
Date: 14 Jun 2000 07:01:36 GMT
Haven't looked at the code
but the simplest way is to
boot to dos. Or if you prefer
linux shutdown to single user
mode. The only thing still
running should be the timer.
The overhead of loops and
such can easily be calculated
by running just the loop.
The timer interrupt overhead is
a bit more difficult. Or if you use
CPU clock counter you can
even disable the timer interrupt
for a short period of time.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
Date: Wed, 14 Jun 2000 04:02:17 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Random sboxes... real info
=====BEGIN PGP SIGNED MESSAGE=====
tomstd wrote:
> In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]>
> wrote:
> >So, following the advice of looking at a block cypher and thinking
> >of it as a large s-box (in the hope of this helping you design
> >smaller tables) apparently leads to the idea that smaller s-boxes
> >should be constructed as random permutations...
>
> No you failed to see my point.
>
> Let's take RC5 with a 128 bit key. There are about 2^128
> possible permutations right?
>
> Well those 2^128 permutations out of the entire (2^64)!
> permutations are strong with respect to diff and linear
> analysis.
I think you may be labouring under a misapprehension - the 2^128
permutations selected by the key are not stronger than a permutation
selected at random from the entire space of (2^64)! possibilities.
In fact, a method for selecting a permutation uniformly at random
from that space would be as secure as a keyed permutation (a.k.a.
block cipher) of that size can possibly be.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOUb1qjkCAxeYt5gVAQFUEAgAoNW64cQmWq8Xt7xpwEHlm/K9YpVpKMGp
h54Rs4CZCGZKX2REEaQ+dkFd7vQg3S4BIw82qJcVgXh7onow5pAH9vXbLunc9KJf
ktZ2YSCAksATPHtycKIBxpdNFJE1CEs69gLp6hE+58FexAjWmrbJirhF1f2qaggZ
Jl/wdBZSZV+D8VFOAmgqm7HdIy4zwgySnNnVniXvl5X0I/xCnjMdAHvxMXmDprj/
GcHK86+1WF5dGYPI4meTXTCp4O6I0dqgrvzVbu0/oVlXzli0JRspKKyyD6rO2W5H
iFf/t+MZ+3szGGED6WXLepIRY3hTReK9hsqdVUra94WwWavmMp1L7A==
=7Xzj
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Reasonably secure OTP passing
Date: 14 Jun 2000 07:37:26 GMT
Summary of what has gone before
without attribution to those
who said it
1) the idea
a) encrypt a OTP (the real thing
not a stream cipher) with a
PK/conventional cipher
b) send it
c) decrypt the OTP
d) encrypt using the OTP
f) send the real message
2) problems
a) cracking the PK
b) is the symetric cipher secure?
c) double bandwidth
d) source of true random bits
e) loss/theft of the OTP
3) the real questions
a) is it worth it?
b) is it more secure?
4) my opinion
a) It may be worth it, the added
complexity of attacking this system
is pretty heavy. This might be useful
if 'the fate of the free world' depends
on it. The overhead is pretty sever
for letters to my aunt Mary.
b) Everyone says it a chain is only
as strong as its weakest link.
In this case it would probably be the
storage of the OTP (presumably
encrypted) and the PK transfer.
The symetric cipher seems pretty
safe from attack unless the OTP
is stolen.
5) My verdict
c) encrypt the returning OTP
enchiphered text with a symetric
cipher.
b) generate the OTP immediately
before transmission and store
in an encrypted format with
a password known only to our
OTP reciever/user.
a) Just how paranoid are you?
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Bohdan Tashchuk <[EMAIL PROTECTED]>
Subject: Re: Question about recommended keysizes (768 bit RSA)
Date: Wed, 14 Jun 2000 00:48:54 -0700
Jerry Coffin wrote:
>
> The Pentium has a 64-bit, 133 MHz bus to memory and has on-board
> cache large enough to hold sieving code in its entirety, so that
> nearly that entire bandwidth can be used for data operations. IOW,
> bandwidth to memory in single-user, desktop machines has improved by
> a factor of at least 2,000:1 instead of the roughly 10:1 that your
> comparison claimed. Due to improvements elsewhere, the real
> improvement is considerably greater still, somewhere around 5,000 or
> 6,000:1 instead.
No, you are completely wrong.
Just because the bus can transfer at 133 MHz, that doesn't mean the SDRAM
memory can keep up. The PIII bus and memory are optimized for block
operations.
Your 133 MHz, 8-byte-wide bus can do scattered 1-byte writes to DRAM (let's
say for sieving) at a rate of about 10 or 20 million transfers (10 or 20
Megabytes) per second. This is because you're only writing 1-byte each
transfer, and because you are usually writing to a new DRAM "page" each
time.
And you had better not be using ECC memory. Because now your fancy bus got
even slower. Assuming your data isn't in cache (and sieving data probably
won't be), then you must:
read 8-bytes from ECC SDRAM memory
change 1-byte, recompute ECC
write 8-bytes back to ECC SDRAM memory
You're well under 10 Megabytes per second for that.
By comparison, the VAX 11/780 used a 10 MHz, 4-byte wide bus that could
accept byte writes at about 3 to 5 Megabytes per second (assuming several
independent memory cards and no ECC R-M-W cycles).
So, for byte writes to memory, your fancy new PIII system is less than 10:1
faster than a VAX 11/780.
The fundamental problem is that DRAM just hasn't kept up. This doesn't
matter is most benchmarks, but it kills you in something like sieving,
where you are doing nothing but scattered 1-byte writes.
In summary, you are nothing more than a blithering idiot. But there's no
shortage of your kind on Usenet.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Thoughts on an encryption protocol?
Date: Wed, 14 Jun 2000 07:51:05 +0000
David P Jablon wrote:
> Whoa, SPEKE is about as simple as it gets, and only requires three
> communications for full mutual explicit authentication, which is the
> absolute minimum.
Sorry, I was typing from the memory of an older paper which I probably
didn't fully understand at the time.
Just checked. One can obviously combine Bobs two messages in the
1996 paper page 16.
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: Baruch Even <[EMAIL PROTECTED]>
Subject: Re: Card Shuffling Protocol
Date: Tue, 13 Jun 2000 22:14:08 +0200
The algorithm seems to be ok except that you seem to have ommited many
details off it that should be in the description.
The current shuffler should encrypt everything with his PUBLIC key, and
send them to everyone encrypted, when the decided shuffling was selected
he should decrypt them all and send it to everyone, they can verify them
being correct by encrypting with his public key, if they get the same things
he sent before than all is ok, otherwise he lied.
Notice though that the protocol carries a large overhead of computation
and network transfers. If you denote the number of machines participating
by N, the number of extra shuffles chosen by S you get N(N-1)S messages
on the network and you need create NS extra shuffles and do N times the
fair coin flipping (a coin flipping alone will not do unless you do it many times
to choose one of the shuffles).
There is a hole that I thought about now, since everyone knows the ordering
it really carries no weight that everyone will shuffle, just choose a "server" in
any fair way and execute the card shuffling once. Any more will not add to
security since the others can just start from scratch, and your algorithm will
not detect it.
Doing it all only once improves performance considerably.
In article <8i38j1$etj$[EMAIL PROTECTED]>, zapzing <[EMAIL PROTECTED]>
wrote:
> I believe I have come up with a card shuffling protocol which may be
> interesting. I had to come up with it as a part of my cryptographic
> voting protocol. But since it could be useful on its own I decided to
> post it separately.
>
> Here's how it works: The players are arranged in some order P0 ...
> Pnp-1. It does not matter which player is first or last. Each player has
> a PGP-like public and private key. I will call these "permanent" keys
> even though they should probably be created only for one deck shuffling
> and then destroyed after that.
>
> The cards are C0 ... Cnc-1. the cards are just strings of bits, all of
> equal length.
>
> P0 creates a large number of "decks". to create a deck he Takes all the
> cards, appends a sufficiently large random string to each card
> (different for each card) and encrypts them using his permanent private
> key. He then shuffles the cards in a random order, that makes one deck.
>
> A fair coin flipping protocol is used to decide on which of P0's decks
> to use. P0 must then decrypt all the other decks. This "cut and choose"
> procedure insures that P0 has correctly followed the protocol.
>
> P0 then passes the deck that is to be used to P1. P1 "reshuffles" this
> deck by creating a large number of reshuffled decks. A reshuffled deck
> is used by taking the deck passed to P1 by P0, rearranging it in a
> random order, appending a random string to each card, and encrytping
> each card again in P1's permanent private key.
>
> Again, a fair coin flipping protocol is used to decide which of these
> reshuffled decks to used, and P1 must decrypt all the other decks.
>
> this continues until all players have reshuffled the deck.
>
> The cards are dealt out according to whatever the rules may be. If a
> player wants to know what the value of his card is, he sends it to the
> other players in reverse order to be blind-decrypted.
>
> I believe this protocol will ensure that pllayers all get the correct
> number of randomly selected cards and no two cards will appear in any
> one deck.
>
> Also a player can keep his card secret. When a player chooses to reveal
> a card, everyone will know that it was legitimately drawn by that
> player.
>
> --
> 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.
------------------------------
** 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
******************************
