Cryptography-Digest Digest #431, Volume #11 Mon, 27 Mar 00 19:13:01 EST
Contents:
Blowfish (Thomas Luzat)
Re: DES question (Paul Koning)
Re: DES question (Paul Koning)
The lighter side of cryptology ([EMAIL PROTECTED])
Re: root mod a prime? ("Tom St Denis")
Re: Mixing N bits into N bits (Bill Unruh)
Re: OAP-L3: Answer me these? ("Trevor L. Jackson, III")
Re: Cipher Contest ([EMAIL PROTECTED])
Re: Gray Code like (Tim Tyler)
Re: OAP-L3: Answer me these? (Jerry Coffin)
HPC as an all or nothing transform?? ("Joseph Ashwood")
Re: The lighter side of cryptology (csybrandy)
Re: Examining random() functions (Arthur Dardia)
Re: The lighter side of cryptology (DJohn37050)
Re: Card shuffling (DMc)
Re: Examining random() functions ("Trevor L. Jackson, III")
Scramdisk ver3 release date? (Curious George)
----------------------------------------------------------------------------
From: Thomas Luzat <[EMAIL PROTECTED]>
Subject: Blowfish
Date: Mon, 27 Mar 2000 21:13:45 +0200
Reply-To: [EMAIL PROTECTED]
Hi,
I'm currently writing a Blowfish implementation and I am now wondering
which key sizes are allowed or given by "the Blowfish standard". I
only know that the key can be up to 448 bits in size... Do the key
sizes have to be multiples of 32 bits, 64 bits or something like that?
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: DES question
Date: Mon, 27 Mar 2000 14:23:23 -0500
doc wrote:
>
> I would appreciate any help/input in considering this
> question.
>
> Given a specific randomly generated ciphertext, does there
> exist a key, plaintext combination that can encrypt to it?
>
> Perhaps a more general way of asking this question is to
> inquire about the domain of the ciphertext.
DES is a permutation, so the domain of plaintext and ciphertext
are the same, i.e., the set of all 2^64 possible 64-bit binary
data blocks.
The answer depends on whether you
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: DES question
Date: Mon, 27 Mar 2000 14:34:57 -0500
Paul Koning wrote:
>
> doc wrote:
> >
> > I would appreciate any help/input in considering this
> > question.
> >
> > Given a specific randomly generated ciphertext, does there
> > exist a key, plaintext combination that can encrypt to it?
> >
> > Perhaps a more general way of asking this question is to
> > inquire about the domain of the ciphertext.
>
> DES is a permutation, so the domain of plaintext and ciphertext
> are the same, i.e., the set of all 2^64 possible 64-bit binary
> data blocks.
>
As for the first question, the answer must be "yes". Pick any key,
and decrypt. That's the matching plaintext.
If you meant to say "given a randomly chosen ciphertext AND a randomly
chosen plaintext, is there a key that maps one to the other" -- not
necessarily, given that there are 2^64 possible plaintext values
and only 2^56 possible keys. So the probability that a particular
chosen P/C pair can be produced by a DES key should be about 2^-8.
paul
------------------------------
From: [EMAIL PROTECTED]
Subject: The lighter side of cryptology
Date: Mon, 27 Mar 2000 20:02:42 GMT
I propose this message as the start of a
new thread devoted to the lighter side of
cryptology. If you have or find any silly
material related to crypto (including true
anecdotes) would you please post it to this
thread. I just saw this limerick which isn't
extremely funny but at least it's a start:
In Arctic and Tropical Climes,
The Integers, addition, and times,
Taken (mod p) will yield,
A full finite field,
As p ranges over the primes.
- Peter Olse
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: root mod a prime?
Date: Mon, 27 Mar 2000 20:31:34 GMT
Thanks for the direction. I will try to find/read those sources as my time
permits. And thanks for the people in the group answering my questions. I
know some of the math is over my head, but it's good just to see it first.
Tom
Mika R S Kojo <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> writes:
> >
> > The problem is that I am adding this to my crypto library, and want to
be
> > able to make new curves as the user sees fit.
> >
> > Tom
>
> Hi Tom,
>
> The problem with SEA (Schoof-Elkies-Atkin) algorithm is that you might
> need about hundred random tries before finding a suitable curve. Even
> though best implementations seem to find the order of one curve in
> about minute or two this clearly is not real time.
>
> So using Mike Scott's program is not too bad an option. What I understand
> it is very fast and freely available.
>
> Nevertheless, I would like to encourage you to take upon the task of
> implementing the Schoof's original algorithm with suitable Shanks
> bs-gs (or Pollard lambda) continuation. It is not trivial to
> implement, nor to understand, but very good practice at least if you
> are interested in the basic algebraic aspects of elliptic curves. In
> my opinion it is easier to implement than complex multiplication based
> counting.
>
> You probably should read the original paper by Rene Schoof, and the
> book by Alfred Menezes. Also you could look for the paper by Buchmann
> and Mueller for some insight. Be warned that the original paper by
> Schoof contains few typos in the equations (if I recall correctly),
> but those are easy to derive by oneself.
>
> If you have a few months time you could then expand the code to SEA,
> which is slightly more complicated to understand, and to
> implement. There is a good book by Ian Blake, Gadiel Seroussi and
> Nigel Smart which you probably should read even if you are not
> interested in the implementation of SEA algorithm. It gives a good
> overview of all aspects of elliptic curve cryptography.
>
>
> -- Mika
>
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Mixing N bits into N bits
Date: 27 Mar 2000 20:39:57 GMT
In <[EMAIL PROTECTED]> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
]Consider the full DES. If the input runs from 0 to 2^64-1, it is
]not apparent to me why each bit of the output should be very random.
It is because that is what one wants a crypto to do. One should be able
to deduce nothing from the output as to what the input is. Ie, the
output should look like a simple random permutation of the possible
inputs. Of course it is not really-- there is an easy inversion given by
the key, but that should not be easy to find.
]For suppose we run this presumably very random output backwards
]thru DES, then we do get back the original input which is not random
]at all. Thus the avalanche property etc. don't seem to be sufficient
]to study the issue at hand. What's the fault with my argument?
]Thanks.
]M. K. Shen
------------------------------
Date: Mon, 27 Mar 2000 16:03:50 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Jerry Coffin wrote:
> Sure -- that's more or less beside the original point. The claim was
> made that a one-time-pad, all by itself, was "perfect." It's true
> that when properly used and implemented, it's 100% immune to a
> plainttext-only attack, but that's more or less beside the point.
Now, there's a point to ponder! A cipher resistant to plaintext-only attack must be
designed for those "burn before reading" documents. ;-)
You did mean a ciphertext-only attack, right?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cipher Contest
Date: Mon, 27 Mar 2000 20:55:39 GMT
Adam,
What is the status of the contest? Has it started yet? If not, when
does it start.
Anyone interested in this contest should check out the latest papers on
AES at the NIST site. The cryptanalysis papers are all suprisingly easy
to understand.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Gray Code like
Reply-To: [EMAIL PROTECTED]
Date: Mon, 27 Mar 2000 21:06:38 GMT
David A. Wagner <[EMAIL PROTECTED]> wrote:
: Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
:> I think you're assuming that *any* maximal-length sequence can be
:> generated by a suitably-tapped LFSR. Is that actually a theorem?
: I'm not sure what the statement of the claim would be, but let's
: try a few:
: 1. Can all sequences of period 2^n - 1 can be generated by a n-bit LFSR?
: Answer: NO (except for very small n). There are close to 2^{2^n - 1}
: such sequences (certainly more than 2^{2^{n-1}}), whereas there are
: less than 2^{2n} LFSRs (at most 2^n choices of taps times 2^n choices
: of initial fill).
: 2. Can all sequences of period n be generated by a n-bit LFSR?
: Answer: YES. Consider the LFSR with polynomial x^n + 1, whose initial
: fill is first n bits of the sequence.
: Was that what you were asking?
What I *thought* he was aksing was whether *a* sequence of period 2^n - 1
exists in an LFSR, for all n.
This is a question which I /assume/ has an affirmative answer - but I
don't know of a proof. "Shift Register Sequences" probably has one -
but seems to be out-of-print in my country ;-|
--
__________
|im |yler The Mandala Centre http://mandala.co.uk/ [EMAIL PROTECTED]
7.194436287 - inverse hyperbolic Cosine of the Beast.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Mon, 27 Mar 2000 14:16:03 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> Now, there's a point to ponder! A cipher resistant to plaintext-only
> attack must be designed for those "burn before reading" documents. ;-)
No, this is the electronic age, so it's for the stuff you store in
write-only memory.
> You did mean a ciphertext-only attack, right?
Well, yes. This is what I get for trying to do anything requiring
intelligence before noon.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: HPC as an all or nothing transform??
Date: Mon, 27 Mar 2000 13:36:25 -0000
I know Hasty Pudding Cipher is not considered strong for
encryption (see AES for details if needed) . However, since
it has a completely dynamic block size, has there been any
consideration to using it as an all or nothing transform? It
seems to me that the mixing properties of something like HPC
could be useful for this, but I haven't analyzed it yet, so
I was wondering if someone else had. If HPC is useful for
such an operation it may have remaining usefulness in it.
Joe
------------------------------
From: csybrandy <[EMAIL PROTECTED]>
Subject: Re: The lighter side of cryptology
Date: Mon, 27 Mar 2000 16:55:54 -0500
Reply-To: [EMAIL PROTECTED]
"Mary had a crypto key, she kept it in escrow,
and everything that Mary said, the Feds were sure to know."
-- Sam Simpson, July 9, 1998
Pulled it off the scramdisk homepage. Hope they don't mind.
csybrandy
[EMAIL PROTECTED] wrote:
>
> I propose this message as the start of a
> new thread devoted to the lighter side of
> cryptology. If you have or find any silly
> material related to crypto (including true
> anecdotes) would you please post it to this
> thread. I just saw this limerick which isn't
> extremely funny but at least it's a start:
>
> In Arctic and Tropical Climes,
> The Integers, addition, and times,
> Taken (mod p) will yield,
> A full finite field,
> As p ranges over the primes.
>
> - Peter Olse
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: Examining random() functions
Date: Mon, 27 Mar 2000 17:11:18 -0500
_Andy_ wrote:
> I've been playing around with random integer generators and
> was wondering about different methods of examining the output.
>
> Currently, I take my results and plot a 3-dimensional graph
> and examine it by eye. i.e. I take three consecutive results and treat
> them as the (x,y,z) coordinates of a point and plot it on the graph. I
> repeat this until a visual pattern emerges. (As described in "Jungles
> of Randomness")
>
> If a pattern emerges, I tend to apply fiddle factors until the
> pattern becomes so complex that it seems to disappear.
>
> So, can anyone recommend another way?
>
> For example...
>
> The following function will generate a random integer where:
>
> 0 <= n < nMax.
>
> --begin random.c--
> static int nRandomSeed = 0;
>
> int SetSeed(int nSeed)
> {
> nRandomSeed = nSeed;
> return( nRandomSeed );
> }
>
> int Random(int nMax)
> {
> static int nOldRandom = 0;
> static int nIteration = 0;
> int n1;
>
> n1 = nRandomSeed;
> n1 *= nOldRandom + (nRandomSeed % 7);
> n1 += 797 + (nOldRandom >> 3);
> if( n1 & 0xc0 ) n1 -= nRandomSeed;
> nRandomSeed = nRandomSeed + n1 % 0xdfdf + nIteration;
>
> nOldRandom = n1;
> n1 = n1 % nMax;
> if( n1 < 0 ) n1 = -n1;
>
> nIteration++;
>
> return( n1 );
> }
> --end random.c--
>
> The distribution seems fair (for small nMax - I haven't
> checked large yet) now that the various fiddle factors have been
> introduced. It would be nice to have a more formalised proof, and
> better development process... rather than the trial-and-error that
> I've been using.
>
> Your thoughts appreciated,
>
> Andy
>
To check how random a generator was, I did this:
I wrote a for loop to roll a dice with a given number of sides, I used 6.
Knowing this, the true average should be 3.5. I then ran the loop for a
long time, billions and billions of roles and calculated the error
percentage for a given number of roles. You can perform a "Ho-Ha" test if
you know statistics to determine if there's a signifcant error or not.
While this method probably sucks horribly, you can use it to compare
against other platforms and implementations of random() functions.
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: The lighter side of cryptology
Date: 27 Mar 2000 23:13:51 GMT
Check out the Journal of Craptology.
Don Johnson
------------------------------
From: DMc <[EMAIL PROTECTED]>
Subject: Re: Card shuffling
Date: Mon, 27 Mar 2000 23:55:27 GMT
On Mon, 27 Mar 2000 18:08:45 GMT, [EMAIL PROTECTED] (Scott Nelson)
wrote:
>
>I see two issues here.
>
>1.) Can we really know if the Kd is to the Left of the Ad
>with better than chance accuracy after one riffle and cut?
>
>2.) Is there any advantage to be gained in knowing it?
>
>I claim the answer to both is yes.
>
>The first can be experimentally demonstrated.
>I have actually done this.
>The Ad Kd were removed and placed on top of each
>other in position 13 and 14, (1/4 the way down.)
>The deck was shuffled once, then examined.
>In 9 out of 15 trials, the Ad remained
>exactly on top of the Kd. In the 6 remaining
>trials, there were 1-3 cards between them.
>(3 times there was 1 card. twice there were 2,
>and once there were 3.)
>
I duplicated this experiment. I moved the K to the A in order to let
the pair move about in the deck. I get the same results you do. I then
riffled twice before cutting. Somewhat better, but still too many zero
in-between results.
Finally I riffled thrice before cutting. A difference of night and
day. More differences than seems logical. Very much like the
difference I found between a single riffle, and a riffle and a cut.
My original approach was macro and equaprobable randomness focused. I
cheerfully incorporate knowing something of the previous deal and 13
cards out of 52 in the current deal. So I revise my minimum shuffling
to three riffles and a simple cut for the game of contract bridge.
[EMAIL PROTECTED]
------------------------------
Date: Mon, 27 Mar 2000 19:04:55 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Examining random() functions
Arthur Dardia wrote:
> _Andy_ wrote:
>
> > I've been playing around with random integer generators and
> > was wondering about different methods of examining the output.
> >
> > Currently, I take my results and plot a 3-dimensional graph
> > and examine it by eye. i.e. I take three consecutive results and treat
> > them as the (x,y,z) coordinates of a point and plot it on the graph. I
> > repeat this until a visual pattern emerges. (As described in "Jungles
> > of Randomness")
> >
> > If a pattern emerges, I tend to apply fiddle factors until the
> > pattern becomes so complex that it seems to disappear.
> >
> > So, can anyone recommend another way?
> >
> > For example...
> >
> > The following function will generate a random integer where:
> >
> > 0 <= n < nMax.
> >
> > --begin random.c--
> > static int nRandomSeed = 0;
> >
> > int SetSeed(int nSeed)
> > {
> > nRandomSeed = nSeed;
> > return( nRandomSeed );
> > }
> >
> > int Random(int nMax)
> > {
> > static int nOldRandom = 0;
> > static int nIteration = 0;
> > int n1;
> >
> > n1 = nRandomSeed;
> > n1 *= nOldRandom + (nRandomSeed % 7);
> > n1 += 797 + (nOldRandom >> 3);
> > if( n1 & 0xc0 ) n1 -= nRandomSeed;
> > nRandomSeed = nRandomSeed + n1 % 0xdfdf + nIteration;
> >
> > nOldRandom = n1;
> > n1 = n1 % nMax;
> > if( n1 < 0 ) n1 = -n1;
> >
> > nIteration++;
> >
> > return( n1 );
> > }
> > --end random.c--
> >
> > The distribution seems fair (for small nMax - I haven't
> > checked large yet) now that the various fiddle factors have been
> > introduced. It would be nice to have a more formalised proof, and
> > better development process... rather than the trial-and-error that
> > I've been using.
> >
> > Your thoughts appreciated,
> >
> > Andy
> >
>
> To check how random a generator was, I did this:
> I wrote a for loop to roll a dice with a given number of sides, I used 6.
> Knowing this, the true average should be 3.5. I then ran the loop for a
> long time, billions and billions of roles and calculated the error
> percentage for a given number of roles. You can perform a "Ho-Ha" test if
> you know statistics to determine if there's a signifcant error or not.
>
> While this method probably sucks horribly, you can use it to compare
> against other platforms and implementations of random() functions.
This kind of testing gives only a rough estimate of the distribution of the
numbers, and tells little about the "quality" of the generator. As an
example, consider a generator that is just a counter. If your routine for
rolling dice is rand() % 6 + 1, then the counter-generator will give a
_perfect_ distribution, and the average will be exactly 3.5.
------------------------------
From: [EMAIL PROTECTED] (Curious George)
Subject: Scramdisk ver3 release date?
Date: Tue, 28 Mar 2000 00:01:15 GMT
Are there any rough estimates for a release date
of Scramdisk version 3?
I just need an order of magnitide. Weeks? Months? Years?
If it may be a long time, are Beta versions available now, or
in the near future?
------------------------------
** 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
******************************
