Cryptography-Digest Digest #112, Volume #11 Sun, 13 Feb 00 09:13:01 EST
Contents:
Re: CHEATING AT PARADISE POKER (Linda Sherman)
Re: CHEATING AT PARADISE POKER (Tony L. Svanstrom)
Crypto-related algorithms in Perl. (Tony L. Svanstrom)
Re: Has some already created a DATA DIODE? (Matthias Bruestle)
Re: Basic Crypto Question 2 (John Savard)
Re: How to Annoy the NSA (MCKAY john)
Apple file security question (RC2 and ASC) ([EMAIL PROTECTED])
Re: RFC: Reconstruction of XORd data ("Rick Braddam")
Re: Crypto-related algorithms in Perl. (Jeff Zucker)
New encryption algorithm ABC. ("Bogdan Tomaszewski")
Re: SHA-1 sources needed! (Tom St Denis)
Re: Has some already created a DATA DIODE? (Tom St Denis)
Re: SHA1 and longer keys? (Tom St Denis)
Re: Has some already created a DATA DIODE? (Tom St Denis)
----------------------------------------------------------------------------
From: Linda Sherman <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: CHEATING AT PARADISE POKER
Date: Sun, 13 Feb 2000 09:01:47 GMT
Joseph Ashwood wrote:
>
> Their statements are almost all fluff.
>
> The facts they do give:
> Their choice of using modular division in their so-called
> random number generation leads to a bias towards the low
> order cards, this results in a tendancy for the cards that
> started at the top of the deck to end at the top.
>
> Their choice of using the C/C++ rand() function allows for a
> good cryptographer to begin computing the future values
> without too much difficulty.
I must have read different pages than you did.
The way I read it, they don't use rand(). They are showing why they
DON'T use rand(). They admittedly confuse the issue by saying they use a
"32-bit rand() function" but on the random number generator page they
say they use a modified version of prng that takes a 2016-bit seed. prng
is most definitely not rand().
> They state where they get their random seeds from, it's
> almost a joke it's so poor. The low order bits of the
> counter on a computer are only random when sampled at
> suitably random, fairly distant intervals, if their doing it
> to get the stated 17 bits per second it's no longer random.
Again, I think we must have read different pages. The page I read says
take seed bits from a variety of sources and sample them in different
parts of the code. This includes unpredictable external sources, such as
the clocks on
I'm satisfied that, if they are doing what they say they are doing,
there is no way anyone can predict the next card on any deal without
actually having access to the server.
Lin
--
Linda K Sherman <[EMAIL PROTECTED]>
[EMAIL PROTECTED] www.cti-pro.com www.dalati.com
------------------------------
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Crossposted-To: rec.gambling.poker
Subject: Re: CHEATING AT PARADISE POKER
Date: Sun, 13 Feb 2000 10:13:20 +0100
Linda Sherman <[EMAIL PROTECTED]> wrote:
> Joseph Ashwood wrote:
> >
> > Their statements are almost all fluff.
> >
> > The facts they do give:
> > Their choice of using modular division in their so-called
> > random number generation leads to a bias towards the low
> > order cards, this results in a tendancy for the cards that
> > started at the top of the deck to end at the top.
> >
> > Their choice of using the C/C++ rand() function allows for a
> > good cryptographer to begin computing the future values
> > without too much difficulty.
>
> I must have read different pages than you did.
>
> The way I read it, they don't use rand(). They are showing why they
> DON'T use rand(). They admittedly confuse the issue by saying they use a
> "32-bit rand() function" but on the random number generator page they
> say they use a modified version of prng that takes a 2016-bit seed. prng
> is most definitely not rand().
>From <URL:http://www.paradisepoker.com/shuffling.html>:
Fortunately most rand() functions have more than 6 bits of
result, however even at 15 bits of result (the most common
with C compilers), there is a definite bias towards the
first 8 cards in the deck.
At Paradise Poker, we chose to use a 31 bit rand()
function (coming from a 2016 bit seed that has entropy
constantly added to it - see random number generator for
more details), thereby decreasing the bias even further
(by a factor of 65536), as well as shuffling the deck more
than once. We found that shuffling twice removes 99% of
the bias, and shuffling 3 times makes it pretty much
immeasurable, then we decided to triple it for good
measure and bump it up to 10 times to keep the marketing
people happy. These two changes result in a shuffled deck
with no detectable bias.
> > They state where they get their random seeds from, it's
> > almost a joke it's so poor. The low order bits of the
> > counter on a computer are only random when sampled at
> > suitably random, fairly distant intervals, if their doing it
> > to get the stated 17 bits per second it's no longer random.
>
> Again, I think we must have read different pages. The page I read says
> take seed bits from a variety of sources and sample them in different
> parts of the code. This includes unpredictable external sources, such as
> the clocks on
>From <URL:http://www.paradisepoker.com/rng.html >:
We have chosen to use a 2016 bit seed for Paradise Poker.
Some might call this overkill or paranoid, we think it was
worth the effort. Using this method, combined with our
shuffling algorithm, allows us to shuffle a deck so that
ALL possible shuffles are indeed possible.
So what good is a 2016 bit seed if it doesn't contain
random data? If we were to assume for the purposes of this
discussion that each hand takes approximately 120 seconds
(some take more, some take less) and that we wanted to
have at least 2000 new bits modifying our seed for each
hand (overkill), we would need approximately 17 completely
random (non-predictable) new bits per second to add to the
entropy of our seed. This is easily achieved by looking at
the low order bits of the CPU's time stamp counter
(366MHz) at irregular parts of the program and when data
is received from client connections, and using it to add
to the entropy in our large seed. We also have the client
programs send the lower 32-bits of their CPU time stamp
counters with every action they make, and we add in a few
other non-predictable bits as well, giving us a minimum of
at least 20 completely new random bits added to our seed
per second. It is important to note that these new bits do
not replace existing seed bits, they merely modify the
existing seed (XOR), therefore making it less predictable.
Even if an attacker was able to feed non-random (probably
fixed) data in place of the TSC we expect, there is still
plenty of new random information to ensure that we are
dealing truly randomly shuffled decks.
The updated seed is used for dealing cards during each
card dealing round, and since a hand almost always lasts
longer than it takes to inject 2000 bits of new random
data, all subsequent cards will be dealt using a seed
which is completely random and which is completely
unrelated to the seed used to deal the previous hands of
cards.
You can't ask for better seeding than that.
The random number generator itself is based on the
Berkeley prng using a state table size of 64 longs. We
modified it to allow changing the seed state without a
save/restore operation, but other than that, it is the
same algorithm that has been scrutinized by data security
professionals for years.
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
---���---���-----------------------------------------------���---���---
\O/ \O/ �1999 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Crossposted-To: comp.lang.perl.misc,comp.lang.perl.modules
Subject: Crypto-related algorithms in Perl.
Date: Sun, 13 Feb 2000 10:21:13 +0100
Does anyone know of a good non-CPAN source for crypto-related algorithms
in Perl (modules would be nice, but not a must).
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
---���---���-----------------------------------------------���---���---
\O/ \O/ �1999 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: Has some already created a DATA DIODE?
Date: Sun, 13 Feb 2000 09:12:48 GMT
Mahlzeit
No Spam ([EMAIL PROTECTED]) wrote:
> comments on. Is there an (easy, quick, simple) way to create
> what I call a DATA DIODE. A piece of code that is a one way
> check valve, allowing the data to flow from a PRNG but does not
> allow the attacker to back up the data path?
You mean a hash function like SHA1?
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
Life is hard, but it's harder if you have too many scruples.
--
insanity inside
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Basic Crypto Question 2
Date: Sun, 13 Feb 2000 09:55:32 GMT
On Sat, 12 Feb 2000 16:50:42 GMT, [EMAIL PROTECTED] wrote, in part:
>4. What about using PRNG's based on thermodynamics and random motion of
>molecules...or a theoretical model of some other natural random
>phenomena ....
The problem with that is that with a true physical RNG, the initial
conditions are 'random', whereas with a computer program, one still
needs some random source for the starting value, no matter how good
the generator itself is.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (MCKAY john)
Subject: Re: How to Annoy the NSA
Date: 13 Feb 2000 10:36:54 GMT
In article <[EMAIL PROTECTED]> "Trevor Jackson, III"
<[EMAIL PROTECTED]> writes:
>"Douglas A. Gwyn" wrote:
>
>> "Trevor Jackson, III" wrote:
>> > Prime P is easy to factor no matter how large.
>> > The factors are P and one.
>>
>> We don't usually include 1 among the factors,
>> because then the UFT doesn't work.
>
>I know that UFT requires that one be left out because its exponent is
>indeterminate, but other mathematical perspectives, such as perfect
>numbers, requires that one be included. Without one 28 isn't perfect.
>
1 is a unit in Z (it is invertible) and this is why it is omitted when
quoting UFT. It most certainly IS a factor - but not a prime factor.
J
>In the elementary case where "the factors of" means "the (integral)
>divisors of" one must be included in the set.
>
>
--
But leave the wise to wrangle, and with me
the quarrel of the universe let be;
and, in some corner of the hubbub couched,
make game of that which makes as much of thee.
------------------------------
From: [EMAIL PROTECTED]
Subject: Apple file security question (RC2 and ASC)
Date: Sun, 13 Feb 2000 11:20:34 GMT
I've just wondered about the security features of Mac OS 9. Here is a
passage from an article about Apple's file encryption:
"The ASC algorithm provides security that is comparable to algorithms
such as Luby-Rackoff [...]. While it's not the strongest possible
encryption or compression (it's a tradeoff between the two) it is very
fast, providing encryption and compression simultaneously, rather than in
two separate operations. "
According to the article, it uses a 56 bit key and Apple admits that it
doesn't provide security against professional attacks.
Does anybody know about attacks against this encryption? Does anybody
know the ACS encryption? Is ACS secure enough to protect against pre-
fabricated cracking tools running on a PC?
The other encryption Mac OS 9 uses is RC2 which doesn't seem to have been
published so far. Beside the fact that it hasn't been peer-reviewed
extensively, have there been any known attacks on it yet? Apple uses it
to encrypt the keychain which contains all user passwords... Is it
reasonable to assume that RC2 cannot be cracked by individuals?
I'm not an expert, just curious.
John Stone
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: RFC: Reconstruction of XORd data
Date: Sun, 13 Feb 2000 05:52:31 -0600
"Samuel Paik" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> David A Molnar wrote:
> > C doesn't have a nice way to express carry bits.
> Sort of true. However:
>
> unsigned x, y, z, c;
>
> z = x + y;
>
> c = (z < x) ? 1 : 0; // c = 1 if carry out from addition
>
> This is essentially how MIPS and Alpha compute carry out.
This appears to me to only work when shifting left, using signed values.
Also, the add operation can affect higher-order bits without affecting
the sign of the result, which is an unwanted effect. You'd have to
multiply by 2 for a left shift and divide by 2 for a right shift
instead of add. Don't forget to check the sign before you multiply or
you'll lose the high-order bit.
If I were doing it in C I'd mask bits off with AND or XOR then use << or
>> to shift. It would be a lot longer than my pseudoAssembler and
probably even harder to understand what the results would be.
The carry bit in asm ends up with the shifted-out bit regardless of
which direction you shift. Also, the carry is shifted into the other end
before it is set/cleared to the value of the shifted out bit. That's how
shifting right out of src1 then shifting left into dest1 moves the LSB
of src1 to the LSB of dest1. Then the next step shifts the MSB of src2
into the LSB of dest1, moving the previously shifted in bit one position
to the left. In the result (dest1 and dest2) you end up with the four
high order bits of each character interleaved with the four low order
bits of a different character.
If you just iterated over "shift src1 right one then shift dest1 left
one" you would end up with src1 in dest1 *with the bit order reversed*.
I'm really disappointed that my choice of programming language hindered
consideration of the effect I was trying to describe.
Rick
------------------------------
From: Jeff Zucker <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.perl.misc,comp.lang.perl.modules
Subject: Re: Crypto-related algorithms in Perl.
Date: Sun, 13 Feb 2000 04:09:36 -0800
"Tony L. Svanstrom" wrote:
>
> Does anyone know of a good non-CPAN source for crypto-related algorithms
> in Perl (modules would be nice, but not a must).
Yeah, just read Neal Stephenson's newest book. :-)
--
Jeff
------------------------------
From: "Bogdan Tomaszewski" <[EMAIL PROTECTED]>
Subject: New encryption algorithm ABC.
Date: Sun, 13 Feb 2000 13:14:27 GMT
I discovered new encryption algorithm. I called him ABC - Alternative Binary
Code.
Permits on usage of key about unrestricted lengths from this
neself( dependent only from lengths of key) with level of safety.
You know some programme testing entropia or breaking keys?
I can somewhere check whether message after coding realizes conditionses of
good agorithm?
Best regards
Bogdan Tomaszewski
Poland
[EMAIL PROTECTED]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SHA-1 sources needed!
Date: Sun, 13 Feb 2000 13:25:50 GMT
In article <885ie5$ecm$[EMAIL PROTECTED]>,
"Nikolaus" <[EMAIL PROTECTED]> wrote:
> Could anybody send me the source code (or URL) of SHA-1 hash algorithm
> written on C/C++ ??
>
> thanx,
> Nikolaus
>
I know Mike Rosing [regular in this forum, pretty cool guy] has a copy
of Jim Golligy [is that right?] SHA-1/SHA-0 source code. Hopefully he
will respond, if not I will dig it up for ya.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Has some already created a DATA DIODE?
Date: Sun, 13 Feb 2000 13:35:54 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I thinking about the problems of using a PRNG for encryption, the
> following seems clear.. to attack PRNG encryption you have you
> have two options (assuming some of the plain data is known or
> knowable (ie. it's english!).
>
> First a brute force attack can be applied to the encryption key
> (the seed) or secondly, knowing the plain data, the attacker can
> work back to learn the state of the PRNG.
>
> It is this second method of attack I would like the group's
> comments on. Is there an (easy, quick, simple) way to create
> what I call a DATA DIODE. A piece of code that is a one way
> check valve, allowing the data to flow from a PRNG but does not
> allow the attacker to back up the data path?
>
AlgM is a good place to start, just don't use LCG's as the underlying
PRNG. AlgM with two 'long' Fibonacii generators is secure.
> The following illustrates what I an talking about..
> ============================================================
> +----+ +------------------+ +------------------+
> |PRNG|--->| 15 bit integer A |-- + --| 16 bit integer B |
> +----+ +-----------------=+ +------------------+
>
> Then
>
> +----------------------+ +---------------------+
> | high 8 bit byte of B |-- + --| low 8 bit byte of B |
> +----------------------+ +---------------------+
>
> +-----+
> Equals the 8 bit output encryption PAD byte | PAD |
> +-----+
This is still a highly linear system if the underlying RNG is linear.
It will not make it much more secure. An extension to this idea is
Xn = (Yn - Zn) mod m
[Knuth vol2]. Where Y and Z are two RNG's at step 'n'.
> written in C:
>
> #include <stdlib.h>
> #include <stdio.h>
> #include <conio.h>
>
> int main(void)
> {
> unsigned char PAD[1];
Not to be picky, but if the array has one element, just store it as so.
unsigned char PAD;
> int i,rand_num;
> union diode {
> unsigned int INT_B;
> unsigned char byte[2];
> } out;
Not to be picky, but who says int is 16 bits? At best you should
use 'short' [but that's no gurantee either].
> out.INT_B = 1731;
Magic constant?
> printf("\nThe pad byte generation:\
> \nINT A,\t\tINT B,\t\tINT B(HEX),\tPAD (HEX) ");
> for(i = 0; i < 4; i++) {
> rand_num = rand();
> out.INT_B += rand_num ;
> printf("\n %d,\t\t%d,\t\t%X, ", rand_num, out.INT_B, out.INT_B);
> PAD[0] = (out.byte[0] + out.byte[1]);
> printf("\t\t%2.X", PAD[0]);
> }
>
> return 0;
> }
Another point is that the seed for 'rand()' is often 32 or 16 bits.
This is way to short for even a remotely secure program.
> As an example, I use the first 4 integers output from the PRNG in
> Borland's C, seeded with the number 1, which are:
>
> 346, 130, 10982, 1090..
>
> we will set the starting state of integer B is 1731. So:
>
> INT A + INT B0 int B1 <HEX> then INT B HI byte + LO byte = PAD
> 346 1731 2077 081D 08 1D 25
> 130 2077 2207 089F 08 9F A7
> 10982 2769 13189 3385 33 85 B8
> 1090 3807 14279 37C7 37 C7 FE
>
> This system has two unknowns, the seed state of th PRNG and the
> initial value of INT A.
The problem is that the 'rand()' function has detectable patterns. So
while this method seems interesting, I doubt it would withstand a
serious attack. Also your LCG has to be enormous to avoid brute force
keysearches.
> My question how does the attacker proceed to learn the state of
> the PRNG so as to determine the next PAD byte.
My guess would be to 'guestimate' what the lower byte of 'rand()' and
proceed from there. Since the lower byte of 'rand()' is what drives
the rng essentially. I dunno, I am not much for attacking things [too
much else going on now].
My suggestion is to add...
PAD = (Byte[0] + Byte[1]) mod m
Where m is prime. Or you can turn it into a shrinking generator like
so.
1. A = (B1 + B2) mod 521
2. if (A > 255) goto 1
3. Output A.
[Where B1 and B2 are two 8-bit values].
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SHA1 and longer keys?
Date: Sun, 13 Feb 2000 13:39:46 GMT
In article <883p9m$2n7$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi there!
>
> I'm a newbie to encryption and was wondering if the following method
in
> VisualBasic to get larger keys using a HMAC_SHA1 class from another
> devloper is secure �� assuming that HMAC_SHA1 does what it is
supposed to
> do and that the sessionkey array [1..8] each contain 20 bytes of high
> entropy random data:
>
> For i = 2 to 8
> result = HMAC_SHA1(password, sessionkeys(i)+HMAC_SHA1(password,
result+
> sessionKeys(i-1)))+result
> Next
>
> returns 160 bytes I use as key. password is the literal password
string.
> Is this secure at all? If not, what's the best way to get a larger key
> than the result of SHA1?
>
> Thanks,
>
> John Stein
You would never need keys this big comming from a user supplied
passwd. But lets suppose you want a 320 bit key... [using sha] Just
do this.
K1 = SHA(PASSWD + SALT)
K2 = SHA(K1 + PASSWD)
K = K1 || K2
It's basically a CBC style chaining mode. 'Salt' should be some >64
bit value [which is publicly known, but unique to each session key]
appended to the password in the first hash.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Has some already created a DATA DIODE?
Date: Sun, 13 Feb 2000 13:43:57 GMT
In article <886bvq$ods$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> 1. A = (B1 + B2) mod 521
> 2. if (A > 255) goto 1
> 3. Output A.
>
> [Where B1 and B2 are two 8-bit values].
Oops [silly me], B1/B2 have to be larger then 8 bits for this to work.
Preferably 32-bits or so.
Given a 32 bit sum (B1+B2) there are 'about' 2^23 ways to get any value
[mod 521].
Tom
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
******************************
