Cryptography-Digest Digest #969, Volume #13      Thu, 22 Mar 01 11:13:01 EST

Contents:
  Re: DEA standard S-tables beginner question. (Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?=)
  Re: Potential of machine translation techniques? (Richard Herring)
  Re: BBS ("Dobs")
  Re: Most secure way to add passphrase verification to "CipherSaber" (Mike DeTuri)
  Re: BBS ("Tom St Denis")
  Re: DEA standard S-tables beginner question. ("Tom St Denis")
  Speed of factoring (Soeren Gammelmark)
  Re: ECC rather than PGP ? ("Tom St Denis")
  Re: What happens when RSA keys don't use primes? ("Tom St Denis")
  Re: What the Hell...Here's what my system can do at it's best... (Keill Randor)
  Re: Multiple encryption, more secure ciphers (SCOTT19U.ZIP_GUY)
  Re: Most secure way to add passphrase verification to "CipherSaber" ("John L. Allen")
  New PGP2.6.3(i)n (Lutz Donnerhacke)
  New PGP2.6.3(i)n (Lutz Donnerhacke)
  Re: RC4 test vectors after gigabyte output?. ("ajd")
  Re: What the Hell...Here's what my system can do at it's best... (SCOTT19U.ZIP_GUY)
  Self Enforcing Protocol (Slightly OT and Long!) (Jim Farrand)
  Re: What the Hell...Here's what my system can do at it's best... (Eric Lee Green)

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

From: Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?= <[EMAIL PROTECTED]>
Subject: Re: DEA standard S-tables beginner question.
Date: Thu, 22 Mar 2001 15:15:51 +0200

Yaniv Sapir wrote:

> Is DEA a "bitsliced DES"?

DEA (Data Encryption Algorithm) is just another name for DES (Data Encryption
Standard). I believe DEA is used by ANSI and DES by NIST.

-- Panu H�m�l�inen

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

From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: Potential of machine translation techniques?
Date: 22 Mar 2001 13:30:11 GMT
Reply-To: [EMAIL PROTECTED]

In article <98tros$rnm$[EMAIL PROTECTED]>, Henrick Hellstr�m 
([EMAIL PROTECTED]) wrote:
> "Richard Herring" <[EMAIL PROTECTED]> skrev i meddelandet
> news:98qruc$a96$[EMAIL PROTECTED]...
> > EU languages form a very restricted subset of all natural
> > languages. Apart from Finnish they are all either Germanic or
> > Romance.

> The Gaelic languages, spoken on Ireland (were Irish is an official
> language), 

One of two. Does Ireland actually use Irish for any official EU business?

> Isle of Man and in Scotland, are Celtic languages. 

Don't forget Welsh.

And substantial minorities of EU populations speak Arabic, Bengali, 
Chinese, Urdu, ... 

That doesn't make them official EU languages, any more than are 
Welsh, Scottish Gaelic, Manx or Cornish. 

> Greek forms
> it's own subfamily of Indo European languages. 

OK, I forgot Greek.

> So there are at least three
> non Germanic, non Romance official langagues in the present 15 EU countries.

But only two (Finnish and Greek) among the 11 EU official languages.

> As far as I know all documents are also translated to the languages of the
> two remaining EES countries (Norway and Iceland, Germanic languages), as
> well as to the languages of the candidate countries, e.g. Estonia (related
> to Finnish), Poland, the Czeck Republic, Slovenia (Slavic languages),
> Hungary (remotely related to Finnish) and Cyprus (Greek and Turkish, the
> latter yet another non Indo European languange).

And are all these languages included in the machine-translation project?

-- 
Richard Herring       |  <[EMAIL PROTECTED]>

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

From: "Dobs" <[EMAIL PROTECTED]>
Subject: Re: BBS
Date: Thu, 22 Mar 2001 14:43:08 +0100

I know that p and q must be secret, but what does it mean form the
programming point of few. How should I make them secret. Thanx :)) ( I am
beginner sorry)
> I suggest you read HAC or some number theory text that talks about the
SQRT
> problem.
>
> Yes p and q must be secret, BBS is secure only if factoring is hard...If
you
> give out p and q factoring is not hard...
>
> Now if all you need is a good non-secure PRNG BBS is the totally wrong way
> to go.
>
> Tom
>
>



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

From: [EMAIL PROTECTED] (Mike DeTuri)
Subject: Re: Most secure way to add passphrase verification to "CipherSaber"
Date: Thu, 22 Mar 2001 13:43:22 GMT

I'm not sure if this is the best way to do it or not but it solves the
problem of a hash function not being available.  

After generating and tossing out the 256 bytes needed to make arcfour
secure, generate a few more throw-away bytes.  Then attach these
throw-away bytes to the ciphertext right after the 10 bytes of
initialization vector.  After the throw-away bytes start attaching the
ciphertext.  Using your examples below it would look like this:

IV, throw-away bytes, E(msg)

On decryption pull out the IV, generate the 256 bytes of keystream,
and generate the desired number of throw-away bytes.  Then compare the
generated throw-away bytes with the throw-away bytes in the
ciphertext, if they match start decrypting.  If not, display an error
message and ask for a different passphrase. 

Mike DeTuri


On Wed, 21 Mar 2001 16:27:13 GMT, "John L. Allen"
<[EMAIL PROTECTED]> wrote:

>I was thinking about adding some rudimentary passphrase (Key)
>verification check capability to the CipherSaber protocol (see
>http://ciphersaber.gurus.com/).  So, among the following choices, Which
>of these message streams is most secure as a means of providing a way
>for the decryptor to verify the correctness of the decryption Key
>without giving an attacker useful info:
>
>        0. IV, E(msg)                      # This is the current
>CipherSaber protocol
>        1. IV, E(IV), E(msg)               # bad: "known plaintext"
>        2. IV, E(E(IV)), E(msg)
>        3. IV, E(E(msg{1..10})), E(msg)    # bad: "known plaintext"
>        4. IV, E(E(E(msg{1..10}))), E(msg)
>        5. IV, H(msg{1..64}), E(msg)
>        6. IV, E(H(msg{1..64})), E(msg)
>        7. IV, E(Key), E(msg)
>        8. IV, H(Key), E(msg)
>        9. IV, E(H(Key)), E(msg)
>
>Where,  IV  is a random initialization vector.
>        E() is an encryption algorithm using key Key.
>        H() is a hash function.
>        msg is the message
>        msg{1..N} is the first N bytes of the message.
>
>Also, if a hash function is not available, what is the best way then?
>
>I lean toward #9 if a hash is available, otherwise, maybe #2 or #4.
>Encrypting the key and sending that as in #7 doesn't _look_ too good at
>first, but is it really that bad?
>
>John.
>



====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
=======  Over 80,000 Newsgroups = 16 Different Servers! ======

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

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: BBS
Date: Thu, 22 Mar 2001 13:58:12 GMT


"Dobs" <[EMAIL PROTECTED]> wrote in message news:99cvd1$1k9$[EMAIL PROTECTED]...
> I know that p and q must be secret, but what does it mean form the
> programming point of few. How should I make them secret. Thanx :)) ( I am
> beginner sorry)

Hmm no you're misunderstanding.  You keep them secret from others, not
yourself.

Tom

> > I suggest you read HAC or some number theory text that talks about the
> SQRT
> > problem.
> >
> > Yes p and q must be secret, BBS is secure only if factoring is hard...If
> you
> > give out p and q factoring is not hard...
> >
> > Now if all you need is a good non-secure PRNG BBS is the totally wrong
way
> > to go.
> >
> > Tom
> >
> >
>
>



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

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: DEA standard S-tables beginner question.
Date: Thu, 22 Mar 2001 13:59:40 GMT


"Yaniv Sapir" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom, Douglas, thanx.
>
> Douglas, I can imagine that LUTs are the easiest and maybe the fastest
> method. But, I need a function for that. My implementation will be based
on
> hardware (at least partly), it will be programmed in assembly, and for
this
> purpose, LUT are too expensive for me (believe me in that).
>
> Tom, I tried looking for "boolean decomposition", but came with nothing
> worthy. I also tried looking for "bitsliced DES" and came with nothing. Is
> DEA a "bitsliced DES"?

Hmm well it's not my subject of speciality.  Brian Gladman did boolean
decomposition of the Serpent sboxes maybe you can talk to him.  (you can
find his url in web search... that's how I found him)

Tom



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

From: Soeren Gammelmark <[EMAIL PROTECTED]>
Subject: Speed of factoring
Date: Thu, 22 Mar 2001 15:05:22 +0100

Hi

Yeasterday I read in Applied Cryptography, that the time-estimate of the
fastest variants of the quadratic sieve was
e^((1+0(1))ln(n)^(1/2)ln(ln(n))^(1/2))
What I don't understand is the 0(1)? Is it really zero multiplied with
one (which seems stupid to write) or is it a function indicating the
time it takes to factor som base number? I really do not understand how
to use the formula.

S=F8ren


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

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ECC rather than PGP ?
Date: Thu, 22 Mar 2001 14:06:04 GMT


"Anonymous" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I have just downloaded Greg Ofiesh's ECC public key encryption
> program (Hidden Point Conceal 3.1).
> I think that it is a viable alternative to PGP at this point, and the
> executable is only 120kb in size (BIG GRIN).
> Any Caveats ??.
>

How is it an alternative?  Are you sure his software is more secure or just
not exploited (yet).

See what you are doing is called stupid.  You jump to another software
without a clue about how the reality of the situation really works.

Tom



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

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: What happens when RSA keys don't use primes?
Date: Thu, 22 Mar 2001 14:07:41 GMT


"Paul Schlyter" <[EMAIL PROTECTED]> wrote in message
news:99cf7v$flt$[EMAIL PROTECTED]...
> In article <Wwcu6.100964$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > "Mxsmanic" <[EMAIL PROTECTED]> wrote in message
> > news:bv7u6.25457$[EMAIL PROTECTED]...
> >> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> >> news:3u6u6.98761$[EMAIL PROTECTED]...
> >>
> >>> No it means you should use a mathematically sound
> >>> probable prime generator such that the probability
> >>> of failure is astronomically small. (i.e Rabin-Miller)
> >>
> >> And if it fails, how will you know?
> >
> > You just will... who cares if the probability of failure
> > is 2^-107 will you ever see a failure?
>
> If you intend that RSA key to ever be used by anyone, why not test it
> before you deliver it?  Even if the probability of failure of the
> Rabin-Miller generator is as small as 2E-107, there are other
> possible failures with a much higher probability -- e.g. program bugs.
>
I am talking about math bugs.  You can't be 100% sure you have primes unless
you prove it and that can take a long time (you have to factor p-1 and q-1
and find gerenerators).  If the probability of arror is 2E-107 you don't
need to worry.

Tom



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

From: Keill Randor <[EMAIL PROTECTED]>
Subject: Re: What the Hell...Here's what my system can do at it's best...
Date: Thu, 22 Mar 2001 13:32:28 +0000

[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in article 
<[EMAIL PROTECTED]> : 

>   I am not sure you anwsered my questions. What part was what in your
>example. Does it work for all files or just text. Could you explain
>your example!!
>
>

O.k. to clarify a bit further.  My system I KNOW works for text, (pretty easily 
aswell).  As for computer data, it should work aswell, (though it might not be so 
easy).  To be honest, though, this system actually does more damage simply by being 
POSSIBLE, than it could by actually being used.  (If you had a peice of data, which 
you think isn't what it appears to be, then with my system it could literally be 
ANYTHING).  (I.e you could never trust any peice of data ever again...).  (Software 
would be worth virtually nothing if this program existed - it would kill the 
industry).  (Hardware shouldn't be hit quite so bad).

Anyway, as to my demonstration, ALL three parts are contained within the two 
paragraphs, i.e. the plaintext, key and ciphertext.  For example, in the above 
paragraph, the word computer could be the ciphertext, the word actually could be the 
plaintext, and the key could be any sequence in the paragraph 8 letters long....  
(Basically turning computer into actually).

Hope that explains things alittle better.  I cannot say any more without giving it 
away, which is something I do not wish to do until all other avenues have been 
explored.

To be honest, I would prefer to sell what I have.  Whoever controls this program will 
have so much power in the field of computing, communications etc, that they will 
effectively be one of the most powerful people in the world. (If they are ot already). 
(They would make Microsoft look like, well, crap....).

hope that helps,
[EMAIL PROTECTED]

_______________________________________________
Submitted via WebNewsReader of http://www.interbulletin.com


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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Multiple encryption, more secure ciphers
Date: 22 Mar 2001 14:13:10 GMT

[EMAIL PROTECTED] (Joe H. Acker) wrote in
<[EMAIL PROTECTED]>: 

>
>Thanks for your reply. But actually, I was asking how to make one
>algorithm, namely Rijndael, more secure using one key. I know that
>different algorithms and different keys would be the recommended way,
>but I don't have enough entropy for independent subkeys, and I can't use
>different algorithms in this case.
>

   I really think if your encrypting a file you should try Matts Bicom
if speed is not problem. The Bijectice PPM compressor as a front stage
would make it more secure than  most implimentation of Rijndael.
You could even follow it by a series of bijective opertians such
as running my reverse that rewrites files from the backend. And then
run Matts BICOM a second time.

>My assumption is that the subkey derivation is the most important factor
>in such a single-cipher multiple encryption, so I'm looking for a better
>way to derive subkeys than just hashing them. Any ideas? 
>
>How about k2 = hash(xor(k1, ct_i)) where ct_i is the last ciphertext
>block of the previous round...?
>

  Not exactly sure what your saying or doing here remember you also
have to decrypt it.


David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
        http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
        http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
        http://radiusnet.net/crypto/  then look for
  sub directory scott after pressing CRYPTO
Scott famous Compression Page
        http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:

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

From: "John L. Allen" <[EMAIL PROTECTED]>
Subject: Re: Most secure way to add passphrase verification to "CipherSaber"
Date: Thu, 22 Mar 2001 14:31:45 GMT

Paul Rubin wrote:

> "John L. Allen" <[EMAIL PROTECTED]> writes:
> > I was thinking about adding some rudimentary passphrase (Key)
> > verification check capability to the CipherSaber protocol (see
> > http://ciphersaber.gurus.com/).  So, among the following choices,
>
> All of them complicate ciphersaber so much that they defeat its
> purpose.  Ciphersaber is not intended as an ftp replacement.  It's
> supposed to be a bare minimum needed to provide confidentiality.  You
> can tell if your password is correct because if you use the wrong
> password to decrypt, you get garbage out.

I know CS is supposed to be as simple as possible, but I thought that
with only a little more complexity it could provide a convenient
and useful password verification method.

John.



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

From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Crossposted-To: z-netz.alt.pgp.allgemein,de.comp.security.misc,de.org.ccc
Subject: New PGP2.6.3(i)n
Date: 22 Mar 2001 14:40:07 GMT

ftp://ftp.iks-jena.de/mitarb/lutz/crypt/software/pgp/pgp263in/

20010322:
  - Protect against the Czech attack of modified secret key files. (Cool!)
  - Protect against MPI computing errors. (more programm errors than Bellcore)


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

From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Crossposted-To: z-netz.alt.pgp.allgemein,de.comp.security.misc,de.org.ccc
Subject: New PGP2.6.3(i)n
Date: 22 Mar 2001 14:40:39 GMT

ftp://ftp.iks-jena.de/mitarb/lutz/crypt/software/pgp/pgp263in/

20010322:
  - Protect against the Czech attack of modified secret key files. (Cool!)
  - Protect against MPI computing errors. (more programm errors than Bellcore)


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

From: "ajd" <[EMAIL PROTECTED]>
Subject: Re: RC4 test vectors after gigabyte output?.
Date: Thu, 22 Mar 2001 14:53:20 -0000

What are the input bytes that go with this? All zeroes?
ajd

"Gregory G Rose" <[EMAIL PROTECTED]> wrote in message
news:99c2pg$[EMAIL PROTECTED]...
> In article <u5C3OpCcF7b2VNiAEyPmh3csFGJy@wingate>,
> Luis Yanes  <[EMAIL PROTECTED]> wrote:
> >There is any RC4 test vectors after gigabyte output?.
>
> Well, not a gigabyte.
>
> Initialise RC4 (or equivalent) with the 8 byte key
> "test key". Then the first 44 output bytes are:
>
> unsigned char expected[] = {
>     0xbd, 0xe9, 0x5c, 0xb5, 0x2b, 0x8d, 0xf8, 0xfb,
>     0xf2, 0xb7, 0x51, 0xf6, 0x5b, 0xe1, 0xdf, 0x3e,
>     0xd7, 0x4b, 0x45, 0x7a, 0xe9, 0x76, 0x4d, 0x26,
>     0x2f, 0x43, 0xa4, 0x70, 0x9a, 0x2a, 0xc9, 0x4e,
>     0x11, 0x23, 0x89, 0x7b, 0x02, 0x2a, 0x4f, 0x07,
>     0x80, 0x98, 0xa1, 0xa0,
> };
>
> With the same initialisation, throw away 1MB (that
> is, 1048576 bytes) and the next 44 are:
>
> unsigned char meg_expected[] = {
>     0x6b, 0x10, 0xd6, 0x79, 0xc8, 0x87, 0xa1, 0x26,
>     0xee, 0x2d, 0x7b, 0xd6, 0xbe, 0x04, 0xbe, 0x0c,
>     0x8f, 0x7a, 0xb3, 0xf0, 0xe0, 0xb8, 0xbd, 0xb5,
>     0x0f, 0x0c, 0x52, 0x33, 0xae, 0x62, 0xdd, 0x9e,
>     0x38, 0x4d, 0x03, 0xdd, 0xaf, 0x56, 0xcd, 0x07,
>     0xb1, 0x89, 0x0c, 0x13,
> };
>
>
> As someone else pointed out, this is indeed a
> meaningful test. An even better test (but I don't
> have a test vector for it) is to generate some
> output, and use that output to rekey the cipher,
> and iterate this process a large number of times
> (say 1000000).
>
> Greg.
> --
> Greg Rose                                       INTERNET: [EMAIL PROTECTED]
> Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
> Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/
> Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C



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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What the Hell...Here's what my system can do at it's best...
Date: 22 Mar 2001 15:01:14 GMT

[EMAIL PROTECTED] (Keill Randor) wrote in
<[EMAIL PROTECTED]>: 

>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in article 
><[EMAIL PROTECTED]> : 
>
>>   I am not sure you anwsered my questions. What part was what in your
>>example. Does it work for all files or just text. Could you explain
>>your example!!
>>
>>
>
>O.k. to clarify a bit further.  My system I KNOW works for text, (pretty
>easily aswell).  As for computer data, it should work aswell, (though it
>might not be so easy).  To be honest, though, this system actually does
>more damage simply by being POSSIBLE, than it could by actually being
>used.  (If you had a peice of data, which you think isn't what it
>appears to be, then with my system it could literally be ANYTHING). 
>(I.e you could never trust any peice of data ever again...).  (Software
>would be worth virtually nothing if this program existed - it would kill
>the industry).  (Hardware shouldn't be hit quite so bad). 
>
>Anyway, as to my demonstration, ALL three parts are contained within the
>two paragraphs, i.e. the plaintext, key and ciphertext.  For example, in
>the above paragraph, the word computer could be the ciphertext, the word
>actually could be the plaintext, and the key could be any sequence in
>the paragraph 8 letters long....  (Basically turning computer into
>actually). 
>
>Hope that explains things alittle better.  I cannot say any more without
>giving it away, which is something I do not wish to do until all other
>avenues have been explored. 
>

  Acatually it explains nothing. If you fear saying anything about
then wait till "all other avenues have been explored"
But people in here want detail. Not titilation and its obvious
you will say nothing of use for a long time. Especailly if your
not even willing to explain a simple example of your on choosing.

>To be honest, I would prefer to sell what I have.  Whoever controls this
>program will have so much power in the field of computing,
>communications etc, that they will effectively be one of the most
>powerful people in the world. (If they are ot already). (They would make
>Microsoft look like, well, crap....). 
>

  Actually Microsoft already looks like crap to most Limux users
so you may have been to late. Some one else may have done what you
want to do. If you stuff is half as good as you say watch out for
the NSA they could steal it and then you wont get any money for it
and if you can't even show a simple example here no one will belive
you were even the inventor.

Take Care
You Need It

David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
        http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
        http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
        http://radiusnet.net/crypto/  then look for
  sub directory scott after pressing CRYPTO
Scott famous Compression Page
        http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:

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

From: Jim Farrand <[EMAIL PROTECTED]>
Subject: Self Enforcing Protocol (Slightly OT and Long!)
Date: Thu, 22 Mar 2001 15:01:56 GMT


This post may be a bit off-topic - it's about self-enforcing
protocols rather than actual encryption.  I'm posting here because
SEPs and crpytography seem to be closely connected (e.g. they are
always discussed in the same books.)

It's also quite long. I thought it best to tell people what I've done
so far rather than just ask for help.

You have been warned!

Here is the situation.  I want to build a software version of a
certain Collectible Card Game.  For this, I want to create a
self-enforcing protocol so that games can be played peer-peer (over a
network) without the risk of a player cheating by using a hacked client.

(TBH this is more of a thought exercise in self-enforcing protocols than
an actual project.  :) )

Okay, I'll now describe what the protocol needs to do, then my attempt 
at the protocol, then the problem with my attempt.  :)

Game
~~~~

Each player starts with a deck of cards.  He can choose what cards go
into his deck.  (But his opponent does not know.)

Cards have a TypeID which represents the card type.  It is fixed for
the duration of the game.  There may be several cards with the same
TypeID in the game.

Cards can be located in a players library, in his hand or in play.

Cards in play are face up on the table.  Therefore the TypeID of cards
in play are known to both players.  In certain situations, cards
(selected by the rules and actions of a player) move from play to the
players hand or to the library.

The TypeID of cards in a players hand are known to that player only.
In certain situations, cards (selected by the rules and actions of
players)
move from a players hand to play or to the library.

The Library operates slightly differently.  A Player will always know
the TypeID of cards in his library because he knows:

1. What cards he started with.
2. What cards are in his hand.
3. What cards are in play.

(1-(2+3)) is the cards in his library.

Cards can move from a players library to his hand, but these cards are 
selected randomly.  (In real life the library is a face down pile of
shuffled cards.  The player picks cards from the top of this pile.)

Problem:  Create a system in which:

1. Neither player can influence the order in which cards go from a
   players library to his hand. 
2. A player does not need to reveal the contents of his library to the 
   other player.

My Solution
~~~~~~~~~~~

Setup:

1. Each card already has a TypeID.  A different random constant Rand is
associated with each card.

2. Each player computes Hash=H(TypeID ++ Rand) for each card.
   (H is a secure Hash function, ++ is a concatenation operator.)

3. Each value of Hash is revealed to players opponent.

When Player A draws a card from his library:

1. Player B randomly selects the hash of a card in the
Player A's library.
2. That card is moved to the Player A's hand.

Player B cannot cheat because: He doesn't know the TypeID associated
with the hash he is choosing.

Player A cannot cheat because: He cannot change the TypeID associated
with the Hash.  He cannot influence the random Hash chosen by Player
B.

Actually A can cheat - he could put any card into his hand.  BUT,
(due to the way the game works) cards in a players hand have no
influence over the game until they go into play.  Such cheating is
therefore either pointless, or detected when the card is played.

Player A plays a card (from his hand into play):

1. He tells Player B the Hash, TypeID and Rand for the card.
2. Player B verifies that a card with that hash was indeed in Player
A's hand.  (He knows this because he selected all the cards which have 
gone into Player A's hand.)
3. Player B verifies the Hash==H(TypeID ++ Rand)

Player A cannot cheat because: Trying to play a card not in his hand
will be noticed in (2) or (3).

Problem
~~~~~~~

Say Player A has a card in play which is returned to Player A's
library.  Player A now draws a card at random from his library.  Now
Player B can cheat - he knows the Hash and TypeID for that card to he
can select or not select that card (whichever is more favorable to
him).

Question
~~~~~~~~

Can any suggest either a way to fix this problem or a better protocol
which doesn't have this problem?

The only solution I can think of is:

When a card is returned to a players library, new Rand and Hash values 
are calculated for all cards in the library.  This solved the problem
of Player B cheating when cards are drawn, it means that the clients
will have to do a lot more work tracking cards to prevent cheating,
and also means that a lot more Hashes have to be created/exchanged.

Thanks for reading so far!

Jim

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

From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: What the Hell...Here's what my system can do at it's best...
Reply-To: [EMAIL PROTECTED]
Date: 22 Mar 2001 09:07:44 -0600

On 22 Mar 2001 06:58:01 GMT, SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
 wrote:
>   Every new engineer use to write password grabbers. But now adays
>its considered bad form. I remmember some of the major weakness that

It's always been considered bad form :-). I never actually deployed
the thing, mind you. I had no need to do so, and didn't consider the
risks to be acceptable. It was just a little hack I wrote while I was
learning PL/1. (I wasn't supposed to be learning PL/1, for that matter --
according to the computer center's "Policies and Procedures", I was supposed
to use the account solely for class-related purposes, and the class used
Pascal -- but it seemed a shame to waste a whole account on an electrical
engineering class that required maybe 5 hours of programming total for the
entire course).  

Anyhow, I think there's an important point: the most critical
vulnerability in any system is the human element. While bribing a
sysop with a beer may not be doable in a DoD secure environment, it's
often possible to bribe a sysop with a briefcase full of cash. Gosh,
what was that guy's name again, who recently got arrested? No matter
how secure the codes are that we use, there is no such thing as an
"unbreakable" system. Heck, even OpenPGP is not "unbreakable". I bet
you that if I got you into a room with a hot poker, a bullwhip, and
two burly attendants with a bad attitude, you would "voluntarily" give
me the password to your PGP keyring within minutes.

-- 
Eric Lee Green [EMAIL PROTECTED] http://www.badtux.org
 AVOID EVIDENCE ELIMINATOR -- for details, see
   http://badtux.org/eric/editorial/scumbags.html 


====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
=======  Over 80,000 Newsgroups = 16 Different Servers! ======

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


** 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 by posting to sci.crypt.

End of Cryptography-Digest Digest
******************************

Reply via email to