Cryptography-Digest Digest #922, Volume #9       Wed, 21 Jul 99 22:13:03 EDT

Contents:
  yet more about fibo generators ([EMAIL PROTECTED])
  Re: Open questions about Dave Scotts Method ([EMAIL PROTECTED])
  Good Book on Linear Algebra ([EMAIL PROTECTED])
  Re: [Q] Finding K from P and C ("Doug Gwyn (ISTD/CNS) " <[EMAIL PROTECTED]>)
  Re: Open questions about Dave Scotts Method (JPeschel)
  Re: Algorithm or Protocol? (Patrick Juola)
  Your opinion upon this crypto-algorithm! ([EMAIL PROTECTED])
  Re: Compression for encryption (John Savard)
  Re: another news article on Kryptos ("Doug Gwyn (ISTD/CNS) " <[EMAIL PROTECTED]>)
  Re: randomness of powerball, was something about one time pads ("Doug Gwyn 
(ISTD/CNS) " <[EMAIL PROTECTED]>)
  Re: Public Key =>? Trapdoor Functions? ("Doug Gwyn (ISTD/CNS) " <[EMAIL PROTECTED]>)
  Re: Benfords law for factoring primes? ("Doug Gwyn (ISTD/CNS) " <[EMAIL PROTECTED]>)
  Re: randomness of powerball, was something about one time pads (Jim Gillogly)
  Re: Length of public key in PGP? ([EMAIL PROTECTED])
  Re: How Big is a Byte? (was: New Encryption Product!) (Gergo Barany)
  Re: Length of public key in PGP? (fungus)
  Re: Xor Redundancies ("Harvey Rook")
  Re: randomness of powerball, was something about one time pads (Dennis Ritchie)
  Re: yet more about fibo generators (Terry Ritter)

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

From: [EMAIL PROTECTED]
Subject: yet more about fibo generators
Date: Wed, 21 Jul 1999 21:37:28 GMT

Getting loads of information about the generators ( :( ) I decided to
look into it myself.  I found some interesting information though...

The period of Additive Generators is the same as LFSR generators.  My
reasoning behind this is that the LSB of both are the same.  If one bit
has a smaller period the period of the output is limited.  Each
additional bit has smaller harmonic periods (the previous bit except
for the first bit).  Since all harmonics are divisors the period of the
entire word is of the highest bit.  Since the msb has the longest
period we associated that with the period of the generator.

Cryptographically this means certain bits hard shorter periods which is
not good if enough keystream can be gathered... Generally the
generators are long enough (MUSH for example) to avoid this problem,
but the difference in periods does not give me a warm fuzzy feeling.

Which leads me to this question, are dense LFSR generators (in parallel
for software) worse then a sparse Additive Generators (FISH/PIKE or
MUSH)?  In parallel-LFSRs no bit is 'more' random then the others, or
am I missing something?

Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

From: [EMAIL PROTECTED]
Subject: Re: Open questions about Dave Scotts Method
Date: Wed, 21 Jul 1999 21:09:19 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (JPeschel) wrote:
> I doubt that David is going to answer your questions, especially since
> he has a $1,000 riding on scott16u. (On the other hand, since I just
> said what I did, he may answer your questions. :-) )
>
> If you believe you are on the trail of a potential attack, go for it,
> and good luck! There may be in a grand in it for you.

I don't care to break it because I admit I probably can't.  However one
could possibly find iterative attacks etc..

My question on size/rounds ratio (well message size/word size/rounds
ratio) is good to find out how many rounds are required for SAC.  He
guessed at 25 he doesn't know.  Also what other word sizes are secure
(and what are their respective key spaces).  If he analyzed it more he
would appear more knowledgeable.  Many people still think of him as a
snake oil peddler.

Etc... He just chooses to belittle me since I am a newbie.  So what.  I
am 17 years old and still in high school.  There are bound to be 100
people in this group who know more then me.  But I have some valid
questions he is hiding from for obvious reasons.

Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

From: [EMAIL PROTECTED]
Subject: Good Book on Linear Algebra
Date: Wed, 21 Jul 1999 21:40:47 GMT

I was visiting Windsor this week and I stopped by a bookstore.  They
happen to have this book so I picked it up.  It's

Linear Algebra, 2nd Edition, Stephen H. Friedberg, Arnold J. Insel and
Lawrence E. Spence.

It's a first year intro book into Linear Algebra which I find quite
informative.  If anyone wants to learn about this they should try to
find this book.

ISBN 0-13-537102-3

Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

From: "Doug Gwyn (ISTD/CNS) <gwyn>" <[EMAIL PROTECTED]>
Subject: Re: [Q] Finding K from P and C
Date: Wed, 21 Jul 1999 14:36:46 GMT

Sungmin Chun wrote:
> I have little knowledge of neccessary math(I majoring in elec. engg.)
> so that I can't understand how the 'known plaintext attack' can be done.

Little math is required to understand known-plaintext attack,
and considerable math ought to be required to be an EE major..

> Why some E(P,K) can be weak to the 'known plaintext attack' and
> others cannot?

What else would you expect?  Systems have different structures, so
they should have different characteristics.

Instead of reading Applied Cryptography and the Handbook, you
would be better served by reading Kahn's "The Codebreakers",
which will show you how these things are done for simpler
systems.  When you see what weaknesses can be exploited, then
it becomes clearer what needs to be avoided when designing a
more secure system.

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

From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Open questions about Dave Scotts Method
Date: 21 Jul 1999 22:29:10 GMT

>[EMAIL PROTECTED] writes:

>I don't care to break it because I admit I probably can't.  However one
>could possibly find iterative attacks etc..
>
>My question on size/rounds ratio (well message size/word size/rounds
>ratio) is good to find out how many rounds are required for SAC.  He
>guessed at 25 he doesn't know.  Also what other word sizes are secure
>(and what are their respective key spaces).  If he analyzed it more he
>would appear more knowledgeable.  Many people still think of him as a
>snake oil peddler.
>
>Etc... He just chooses to belittle me since I am a newbie.  So what.  I
>am 17 years old and still in high school.  There are bound to be 100
>people in this group who know more then me.  But I have some valid
>questions he is hiding from for obvious reasons.
>

Tom, 
I was trying to sound encouraging.

If you want to play around with the scott ciphers, you might want to
try, as I suggested a while ago, implementing the "Onion's attack" on
an earlier version of scott16.

Dave knows I am not enamoured by his utility, but we still get along
pretty well.

Joe 


__________________________________________

Joe Peschel 
D.O.E. SysWorks                                 
http://members.aol.com/jpeschel/index.htm
__________________________________________


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

From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Algorithm or Protocol?
Date: 21 Jul 1999 19:16:34 -0400

In article <7n5b2k$7gq$[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>  John Myre <[EMAIL PROTECTED]> wrote:
>> Different people use the terms "algorithm" and "protocol" in different
>> ways, so there can be arguments about their definitions.  They are
>> similar in that both refer to a well-defined sequence of steps.  From
>> what I've seen, the big difference is that a "protocol" explicitly
>> involves more than one party.  For example, there are communications
>> protocols like IP and TCP.  Diplomatic protocols describe how people
>> should interact, such as how an "ambassador" should speak to a "king".
>
>I don't see 'Algorithm' and 'Protocol' as interchangeable.
>
>M^e mod N is a algorithm (or expression), whereas give g^x mod p, take
>g^y mod p, compute g^xy mod p is a protocol (each step is an
>expression).

But algorithms aren't expressions; the general definition of
algorithms that I've seen are something like "a defininite and
finite sequence of steps"; what's the "expression" for a 
mergesort or beam-search algorithm?

        -kitten

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

From: [EMAIL PROTECTED]
Subject: Your opinion upon this crypto-algorithm!
Date: Wed, 21 Jul 1999 22:40:04 GMT

I'd be interested in your opinions upon this crypto-algorithm
It's similar to DES/GOST. I uses a "Feistel-network" too.
Please don't flame me if it's bullshit!

I have a full specification written in TeX (with some flowcharts)
and a implementation in C++ which can use Electronic Code Bock (ECB) or
Cipher Block Chaining (CBC) mode.

Here's a short description of one en/decryption-round:

1. The 64 bit plainblock is split into two 32 bit blocks.
   The one will be called "L" the other "R".
2. R is expanded by an expansion-matrix, which doubles 16
   of the former 32 bits up to 48 bit.
3. The expanded R is XORed with the actual 48 bit round-key
   from the key-repository.
4. The expanded and XORed R is split up into four 12 bit blocks.
5. Each of this four blocks is now used as an index into
   four substitution-tables (S-Boxes)
   Each S-Box contains 4096 32 bit values. The 32 bit values
   are unique over all S-Boxes.
6. The XORed results of S-BOX1 and S-BOX3 is added to
   the XORed results of S-BOX2 and S-BOX4
   short:
   (result(SBOX1) XOR result(SBOX3))+(result(SBOX2) XOR result(SBOX4))
   the whole result is therefore a 32 bit block.
7. The 32 bit result of step 6. is XORed with L
8. The result of step 7. is the new R and the old R is the new L

The expansion-matrix (E-Box) is designed so that doubled bits act in
different S-Boxes.

The keyrepository contains a 48 bit roundkey for each round.

The number of rounds is variable in steps of 2 (beginning with 2).
Therefore the keylength is variable (keylength = rounds*48bit)

Further info's are available by email

sincerely yours,
Jochen Schmidt
[EMAIL PROTECTED]


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Compression for encryption
Date: Wed, 21 Jul 1999 22:57:56 GMT

[EMAIL PROTECTED] wrote, in part:

>To me putting compression and encryption in the same field is
>irresponsible.  They go hand in hand for communications in that you
>first compress then encrypt but compression methods rarely hide
>information well.

Compression methods certainly don't hide information of themselves.
But randomizing the equivalents in compression, like bisecting
messages to conceal stereotyped beginnings, is a precautionary measure
that is not harmful.

And it does make sense to optimize a compression method for
cryptographic purposes: i.e. to ensure that it leaves behind very
little redundancy, even if that takes computer time not justified by
bandwith savings alone; to ensure that the redundancy left behind is
in a form less likely to be useful to a cryptanalyst; to integrate
compression capabilities into an encryption program so that headers
indicating compression are not present - all these things are
sensible, not irresponsible.

John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm

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

From: "Doug Gwyn (ISTD/CNS) <gwyn>" <[EMAIL PROTECTED]>
Subject: Re: another news article on Kryptos
Date: Wed, 21 Jul 1999 14:30:41 GMT

Mok-Kong Shen wrote:
> Could the present instance be interpreted to mean ...

Certainly, the more complex you make the encryption system,
*usually* more work (and input data) is needed to crack it.

But "switching algorithms" under control of a key is itself
a fixed algorithm, just more complex than its components.

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

From: "Doug Gwyn (ISTD/CNS) <gwyn>" <[EMAIL PROTECTED]>
Subject: Re: randomness of powerball, was something about one time pads
Date: Wed, 21 Jul 1999 15:06:11 GMT

[EMAIL PROTECTED] wrote:
> Mok Kong Shen wrote:
> > Maybe I misunderstood. But doesn't the issue call into memory
> > the case where an ideal RNG can generate a sequence of 0's of
> > arbitrary length? There is a non-zero chance that the time point
> > of (huge) win is at infinity.

Actually the probability of that is zero.

> There is no huge win anywhere.  The rules stated that bet doubling
> follows a loss.  Following a win the bet reverts to one unit.

But, every time you win a play, you have a net gain of $1 since the
last time you won (or began play).  The wins may not be huge, but
if you accumulate enough of them you should become very wealthy.

So far, I haven't seen anyone in sci.crypt come close to identifying
the flaw in this strategy.

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

From: "Doug Gwyn (ISTD/CNS) <gwyn>" <[EMAIL PROTECTED]>
Subject: Re: Public Key =>? Trapdoor Functions?
Date: Wed, 21 Jul 1999 14:45:10 GMT

Coms 1003 wrote:
> Does semantically secure, probabilistic public-key encryption
> necessarily imply the existence of trapdoor one-way functions?

Yes, in fact tomatoes imply ditto.

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

From: "Doug Gwyn (ISTD/CNS) <gwyn>" <[EMAIL PROTECTED]>
Subject: Re: Benfords law for factoring primes?
Date: Wed, 21 Jul 1999 14:51:18 GMT

"Peter L. Montgomery" wrote:
> ... Maple V Release 5 (WMI Campus Wide License) ...

And one can do something similar in Mathematica, which I have licensed
on my home PC.  However, I did mean that I can factor a *prime* in the
context in which it *is* a prime, not in some different context.

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

From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: randomness of powerball, was something about one time pads
Date: Wed, 21 Jul 1999 17:25:34 -0700

Doug Gwyn (ISTD/CNS) wrote:
> But, every time you win a play, you have a net gain of $1 since the
> last time you won (or began play).  The wins may not be huge, but
> if you accumulate enough of them you should become very wealthy.
> 
> So far, I haven't seen anyone in sci.crypt come close to identifying
> the flaw in this strategy.

The house has more money than the player.  Every now and then the player
will experience 20 or 30 losses in a row, and won't be able to double
up the last time.  In addition, many houses have a bet limit, again
preventing the Martingale player from doubling the bet at some point.

-- 
        Jim Gillogly
        29 Afterlithe S.R. 1999, 00:21
        12.19.6.6.17, 2 Caban 5 Xul, Second Lord of Night

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

From: [EMAIL PROTECTED]
Subject: Re: Length of public key in PGP?
Date: Wed, 21 Jul 1999 23:28:19 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (Wim Lewis) wrote:
> specifically refers to PGP... it's worth noting that in PGP the RSA
> plaintext is a session key not longer than 168 bits or so, so this

Not longer than 168 bits? Why? People are talking about 1024 bit primes
for PGP.

Weedlet


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

From: [EMAIL PROTECTED] (Gergo Barany)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 22 Jul 1999 00:02:39 GMT

In article <7n58s3$q0s$[EMAIL PROTECTED]>, Finder Keeper wrote:
>But zero isn't the first number. It's the zero-th number.

It's the zeroth number, but because zero is the number with which we
start counting, the zeroth number is the first number of counting, which
makes zero the first number.

Gergo

-- 
I found Rome a city of bricks and left it a city of marble.
                -- Augustus Caesar

GU d- s:+ a--- C++>$ UL+++ P>++ L+++ E>++ W+ N++ o? K- w--- !O !M !V
PS+ PE+ Y+ PGP+ t* 5+ X- R>+ tv++ b+>+++ DI+ D+ G>++ e* h! !r !y+

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

From: fungus <[EMAIL PROTECTED]>
Subject: Re: Length of public key in PGP?
Date: Thu, 22 Jul 1999 02:57:49 +0200



[EMAIL PROTECTED] wrote:
> 
> In article <[EMAIL PROTECTED]>,
>   [EMAIL PROTECTED] (Wim Lewis) wrote:
> > specifically refers to PGP... it's worth noting that in PGP the RSA
> > plaintext is a session key not longer than 168 bits or so, so this
> 
> Not longer than 168 bits? Why? People are talking about 1024 bit primes
> for PGP.
> 

He said "session key"...


-- 
<\___/>
/ O O \
\_____/  FTB.

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

From: "Harvey Rook" <[EMAIL PROTECTED]>
Subject: Re: Xor Redundancies
Date: Wed, 21 Jul 1999 17:28:04 -0700

The big problem with adding security to everyday utilities, is that most
people don't really want strong security.  They want their security to be
like a locked file-cabinet. If they loose the key, they can use a crow-bar
to break in. They bitch and complain when they can't recover their data
after they've lost their password.

Every one knows some one who's forgotten their password after they came back
from vacation. How much data does that person deserve to loose because of
frail memory?

Harv
[EMAIL PROTECTED]
Spam Guard, it's the mail isn't cold, it's hot.


JPeschel <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> It's also true, as you say, that vendors tack on "security" as an
> extra in some programs: MS Word, PKZIP, etc.  The utilities I
> was thinking about are "encryption" utlilities: Turbo Encryto, UBE98,
> FileLocker, Crypt-o-Text, and others.
>




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

From: Dennis Ritchie <[EMAIL PROTECTED]>
Subject: Re: randomness of powerball, was something about one time pads
Date: Thu, 22 Jul 1999 02:06:33 +0100
Reply-To: [EMAIL PROTECTED]

Jim Gillogly wrote:
> 
> Doug Gwyn (ISTD/CNS) wrote:
 ...
> > So far, I haven't seen anyone in sci.crypt come close to identifying
> > the flaw in this [Martingale] strategy.
> 
> The house has more money than the player.  Every now and then the player
> will experience 20 or 30 losses in a row, and won't be able to double
> up the last time.  In addition, many houses have a bet limit, again
> preventing the Martingale player from doubling the bet at some point.

Yes, and the "you don't have unlimited resources" and "bet limit"
issues become especially important when the game is real, whether in the
casino or in crypto, in ways that can make the math of random-walk
analysis flee from your mind even if you knew it already.

        Dennis

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

From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: yet more about fibo generators
Date: Thu, 22 Jul 1999 01:59:56 GMT


On Wed, 21 Jul 1999 21:37:28 GMT, in <7n5eim$919$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] wrote:

>Getting loads of information about the generators ( :( ) I decided to
>look into it myself.  I found some interesting information though...
>
>The period of Additive Generators is the same as LFSR generators.  

False.  See, for example:

   http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect7.2.4

where I report actual experiments on many tiny generators, testing
*every* primitive polynomial for each short degree.  Since this is on
the web, you cannot argue that you have had no access to it.  

Additive RNG periods actually have been known for well over a decade:

114. Marsaglia, G. and L. Tsay. 1985. Matrices and the Structure of
Random Number Sequences. Linear Algebra and its Applications. 67:
147-156. 

If you cannot find this information in your favorite crypto books,
perhaps you should complain to the authors.  


>My
>reasoning behind this is that the LSB of both are the same.  If one bit
>has a smaller period the period of the output is limited.  Each
>additional bit has smaller harmonic periods (the previous bit except
>for the first bit).  Since all harmonics are divisors the period of the
>entire word is of the highest bit.  Since the msb has the longest
>period we associated that with the period of the generator.
>
>Cryptographically this means certain bits hard shorter periods which is
>not good if enough keystream can be gathered... Generally the
>generators are long enough (MUSH for example) to avoid this problem,
>but the difference in periods does not give me a warm fuzzy feeling.
>
>Which leads me to this question, are dense LFSR generators (in parallel
>for software) worse then a sparse Additive Generators (FISH/PIKE or
>MUSH)?  In parallel-LFSRs no bit is 'more' random then the others, or
>am I missing something?

For one thing, you are missing an explicit definition of what you
imagine "dense LFSR generators" to be.

If you mean "LFSR's having many feedback taps," they are no stronger
than LFSR's with few taps.  Both are linear mechanisms and if we know
the taps, their unknown state can be computed when we have that same
amount of known plaintext (or, of course, more).  

I have long advocated and used a nonlinear filtering system after the
RNG proper.  The particular design I use I call a "jitterizer."  One
description is available in:

   http://www.io.com/~ritter/KEYSHUF.HTM 

---
Terry Ritter   [EMAIL PROTECTED]   http://www.io.com/~ritter/
Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM


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


** 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
******************************

Reply via email to