Cryptography-Digest Digest #923, Volume #9       Thu, 22 Jul 99 04:13:04 EDT

Contents:
  Re: Length of public key in PGP? ([EMAIL PROTECTED])
  Re: How Big is a Byte? (was: New Encryption Product!) (Tim Shoppa)
  Re: randomness of powerball, was something about one time pads (John Briggs)
  Re: NBE: Not crackable by brute force key search (David Hamilton)
  Re: another news article on Kryptos (Jim Gillogly)
  Re: another news article on Kryptos (Jim Gillogly)
  Re: How Big is a Byte? (was: New Encryption Product!) (wtshaw)
  Re: another news article on Kryptos (wtshaw)
  Re: Open questions about Dave Scotts Method (SCOTT19U.ZIP_GUY)
  Re: Compression for encryption (SCOTT19U.ZIP_GUY)
  Q: Does ElGamal require that (p-1)/2 is also prime like DH? (Hartmut Schroeder)
  RE: Crypto keys (Anonymous)
  RSA public key (vincent)

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

From: [EMAIL PROTECTED]
Subject: Re: Length of public key in PGP?
Date: Wed, 21 Jul 1999 21:49:57 -0400

To tell you the truth, I have never thought of that.  I have allways used
RSA to encrypt session keys that are too small to overflow the limit (the
session keys are then used to encrypt the message with a symmetric
algorithm, such as blowfish or idea).


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

From: Tim Shoppa <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Thu, 22 Jul 1999 01:39:50 GMT

Gergo Barany wrote:
> 
> 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.

These young C programmers and their delusions.  Fortran programmers,
of course, know that 1 is truly the first number.

Tim.

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

From: [EMAIL PROTECTED] (John Briggs)
Subject: Re: randomness of powerball, was something about one time pads
Date: 19 Jul 99 13:23:52 -0400

In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
> fungus wrote:
>> A simple proof that they aren't goes as follows:
>> This game is actually played in carnavals and casinos. ...
> 
> What's played there is Chuck-a-Luck as I described it,
> where the payoff is the same for 1, 2, or 3 shows of
> your chosen number, not the originally cited game where
> the payoff is proportional to the number of shows of
> your number.  The latter can be factored into orthogonal
> subproblems: each die's contribution is *independent* of
> what goes on with the other dice, so the per-die outcome
> can be scaled up simply by multiplying by the total
> number of dice (3 x 1/6).  The former (Chuck-a-Luck)
> has expected outcome 1/6 + 5/36 + 25/216 (where the
> terms can be found by the survivor rule), which is
> less than fair (1/2).

As I understand the game, you put 1 chip (or whatever) on the counter.
Then depending on the roll of the dice, either they take your
chip or you keep your chip and they hand you 1, 2 or 3.  Let's call
this "original rules".

Result:         -1 with probability 125/216     Expected gain:  -0.578
                +1 with probability  75/216     Expected gain:  +0.347
                +2 with probability  15/216     Expected gain:  +0.138
                +3 with probability   1/216     Expected gain:  +0.013
                                                ----------------------
                                                                -0.080

Or we could assume your version, you put one chip on the counter.
Then depending on the roll of the dice, either they take your
1 or you keep your 1 and they hand you 1.  Let's call this "cheapskate
rules".

Result:         -1 with probability 125/216     Expected gain: -0.578
                +1 with probability  91/216     Expected gain: +0.421
                                                ---------------------
                                                               -0.157

In neither case does the game decompose cleanly into a set of three
independent sub-games.  The results on the other two dice influence
the payoff matrix on the remaining die.  In particular, if you've already
got a six, your stake is no longer at risk.

If you can be seduced into believing that "original rules" is cleanly
decomposable into three independent sub-games then you are a mark.
The carny wants you to think this.

Three independent sub-games on the reward side yes.  But there's a
different and non-independent sub-game on the risk side.  This may be
what Doug Gwyn has in mind.  He's usually pretty sharp.


There is a cleanly decomposable variant:

You put your one chip on the counter.  The carny keeps it regardless.
Then he hands you 1, 2 or 3 depending on the throw of the dice.

Result          -1 with probability 125/216     Expected gain:  -0.578
                 0 with probability  75/216     Expected gain:   0
                +1 with probability  15/216     Expected gain:  +0.069
                +2 with probability   1/216     Expected gain:  +0.009
                                                ----------------------
                                                                -0.500

Nobody would play that game.  It's obviously unfair.  The payout is
1/6 per die for a total of 1/2.  The fair price is thus 1/2 chip.

        John Briggs                     [EMAIL PROTECTED]

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

From: [EMAIL PROTECTED] (David Hamilton)
Subject: Re: NBE: Not crackable by brute force key search
Date: Mon, 19 Jul 1999 17:34:29 GMT

=====BEGIN PGP SIGNED MESSAGE=====

[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:

(snip)

> If the Tom your refering to is the young kid then be aware he knows very 
>little about actual encryption. A long time a go I put him in my kill file 
>after I found it was impossible to carry on any resonable disscussion with 
>him.

When it comes to 'reasonable discussions', you obviously can't talk. In the
past, you have used the following:

   (a) Not only am i rude but also crude so fucking what that is the way I
am. I also don't spell worth a shit but big fucking deal everyone has
crosses to bear or are you perfect. I mean I think you kind of an ass
like me but I bet you see your self in a higher light.
   (b) I answer as I see them. And so do you. SO don't tell me how to fucking
write.
   (c) You really are a pompous ass aren't you.
   (d) Or maybe you don't strike me as much of an asshole as in other replys
   (e) As to your last stupid question did I design it. Yes and its
algoritms.
   (f) how the FUCK do you know. (I hope this makes up for lack or rudness
which you waved in my face from an earlier post).
   (g) Is that os FUCKING HARD or are you just all talk.
   (h) So fuck you and let the people try it.
   (i) Well asshole.

By the way, have you cracked IDEA yet? (You did say you would didn't you?) 


David Hamilton.  Only I give the right to read what I write and PGP allows me
                           to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179  Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with 2048 bit RSA key

iQEVAwUBN5Ng0co1RmX6QSF5AQHcfgf+MftcpUipBo5DZrnSmt0oWOS38NuJPRIt
LVeu9Aq5Hl0iprm6IaWp2sNO2nrokkRtYgL3KOxspYw18AM6mgS+QeYlTEG3Yjlc
TqHamoTGTWZvnQ+rN3X/wTxaUI5OdxRpZKp1fX6h67CSQqPtS539WSa/6wvFC8EB
iWbKOAsFRquxqWl/qIWva51MLFhiDTCFxeNNLtuA/c8EJbBYkrQqapkBSq2HYoge
mv5YtIsLTn2oHT8iMDrqdFPXduHqpGzWtVryBndFbTkYYMx0+BQ6ARywHuW11jU9
hQ9c2Q0seXGPoSY/HEZ7NZXRl+yWc4x1shj5k/g8TjAxYqAN39RKLQ==
=UCfR
=====END PGP SIGNATURE=====

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

From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: another news article on Kryptos
Date: Wed, 21 Jul 1999 19:43:32 -0700

Doug Gwyn (ISTD/CNS) wrote:
> 
> Jim Gillogly wrote:
> >  50 0.0800
> >  25 0.0533
> 
> An IC should be around 1.  There are 4 coincidences at a width of 50,
> and (47*1+3*0)/26 are expected for random, so IC(50) = 4*26/47 = 2.2.

Unfortunately there are a couple of definitions of IC, and I grew up
using the Sinkov one, which has the same range as kappa (Dorothy Denning
uses it this way also).  But yes, the bulge at 50 is suspicious.

> Another interesting characteristic is that there are 6 doubled
> (adjacent) letters, with 96/26 = 3.7 expected for random.

Yup.  Depending on the alphabet and plaintext, Wheatstone can lead
to more doubled letters than random (and more than in plain English,
which I think is a little less than random), but I don't see a
smoking gun here.

> > I'd been looking for Fibonacci-style generators with period 50,
> > and not finding any.
> 
> Not surprising, since they're unlikely to be used for alphabetic
> (non-binary) systems.

I was thinking in particular of Gromark (Gronsfeld with Mixed Alphabet
and Fib-style Running Key), but yes, they're not common.

> Have you tried running key, with KRYPTOSABC... (both forms of
> encipherment)?  This could be tested by crib dragging, looking
> for potential plaintext in the recovered key fragment.

Yes -- also with KRYPTOSABC... with mixing in a transposition block
using a few different widths.  Of course, I may not have dragged the
right cribs.  I seem to recall that one of Allen Sherman's students
did a running key program with pretty good results, so that ought
to be feasible.  Hurm...

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

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

From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: another news article on Kryptos
Date: Wed, 21 Jul 1999 20:32:49 -0700

Jim Gillogly wrote:
> 
> Doug Gwyn (ISTD/CNS) wrote:
> 
> > Have you tried running key, with KRYPTOSABC... (both forms of
> > encipherment)?  This could be tested by crib dragging, looking
> > for potential plaintext in the recovered key fragment.
> 
> Yes -- also with KRYPTOSABC... with mixing in a transposition block
> using a few different widths.  Of course, I may not have dragged the
> right cribs.  I seem to recall that one of Allen Sherman's students
> did a running key program with pretty good results, so that ought
> to be feasible.  Hurm...

I should add I've tried more than "both forms of encipherment": Vigenere,
Beaufort, Variant Beaufort and Porta, both enciphering and deciphering,
since the dragged crib could be in either key or plaintext.

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

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

From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Wed, 21 Jul 1999 22:25:53 -0600

In article <7n58s3$q0s$[EMAIL PROTECTED]>, REMOVE X AND Y
<[EMAIL PROTECTED]> wrote:

> But zero isn't the first number. It's the zero-th number.
> 
> Cheerio,
> Vega
> 
> Michael D. ([EMAIL PROTECTED]) wrote:
> : I think that a major problem that we all have is that our mothers, yes, mine
> : as well as yours, taught us  that the first number is one(1) rather than
> : zero(0). It was cute when we were three(3), but now, as a result of that
> : conditioning, we cannot do math in our heads.

Zero has no value in itself as it expresses the absence of a number in a
particular place.  

Consider a real problem in which the choice is between numbering beginning
with one and numbering beginning with zero.  You might number 1, 2, 3, 11,
12, 13, etc, or 00, 01, 02, 10, 11, 12, etc.  The use is, of course,
addressing, defining locations in memory or in something like a key.  It
does not matter which system you use as long as you and whoever you are
communicating with are on the same track.
-- 
When I talk about running the bases, it's not baseball.

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

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: another news article on Kryptos
Date: Wed, 21 Jul 1999 22:44:47 -0600

In article <[EMAIL PROTECTED]>, "Doug Gwyn (ISTD/CNS) <gwyn>"
<[EMAIL PROTECTED]> wrote:

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

This is not going to be always true.  Complication is one way to strength,
but it might involve doing things inefficiently.  The better goal is to
have as simple an encyption system as possible, with the strength being
entirely in the key(s).
> 
> But "switching algorithms" under control of a key is itself
> a fixed algorithm, just more complex than its components.

Consider a little ditty I did called Code Blue which in nothing more than
a takeoff on a tableau ciphers, with a deranged alphabet as the base for
the table, another deranged alphabet for the usual keystring, and another
alphabet of still the same size which determines which of three modes the
table can be used.  The base string is 27 characters, the keystring is 27
characters, and the mode determining key is 27 characters, most
importantly of three trits each.  The whole thing cycles in 81
encryptions, the keystring being used 3 times in the process.
-- 
When I talk about running the bases, it's not baseball.

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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Open questions about Dave Scotts Method
Date: Thu, 22 Jul 1999 05:21:00 GMT

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
(JPeschel) wrote:
>>[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 I don't belitlle him for being a little boy. I just got tired of reading 
his posts. We went in circles. Very time I tried to answer his questions
or make a point he goes to left field. He evne said he was tired of responding
to my posts and said he would quit. I guess he has not quit. If he want to 
write me with short questions I might anwser him. But as young as he is
he should look at the code himself if he really wants to learn but I think
he is all talk and no action.

 


David A. Scott
--
                    SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
                    http://www.jim.com/jamesd/Kong/scott19u.zip
                    http://members.xoom.com/ecil/index.htm
                    NOTE EMAIL address is for SPAMERS

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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Compression for encryption
Date: Thu, 22 Jul 1999 05:11:08 GMT

In article <[EMAIL PROTECTED]>, Paul Koning <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> 
>>  I presently have an adapative huffman compress that is suitable for
>> encryption. Will soon have a BWT type of compress that may be
>> better. 
>
>What does it mean for a compress [sic] to be "suitable for
>encryption"?  All compression algorithms make the plaintext smaller
>and less redundant, both of which are good things.  What properties
>would make one suitable, or not suitable, for encryption?
>
>        paul

  No as a matter of fact most compression routines do not make a
random file smaller. If any thing they in general make a random file
longer. There are many reasons for the longer length headers is just
one of them.
 However if one has data that is of very high entropy not only will
compression be a waste of time as a first step before encryption
but high entropy data can safely be encrypted with something as poor
as any of the AES candidates. Since a person intercepting the
data would not have a clue what the data was even if the correct
key along with several others was used to try to break the system.
 However if one is wanting to often send a low entropy message such
as this post it is best to use a compression routine designed to
make such files smaller so that the overall entropy of sent message
is reasied. The problem with most compression routines is that
even if the file is smaller there are tell tale signs that files are
compressed. So that if the enemy guess a key he may be able
to reject the file as a file that is not a valid compressed file. So it
is best to use a compression method that does not leave tracks.
 My version of adaptive huffman compression does just that.
A compression/decompression may be used with encryption
and will add nothing for the attacker to get a handle on if 
for all ffiles A compressed to B then B decompressed to A
and for all files C decompressed to D then D decompresses to C
Of course you would also hope to use a compress/decompression
method that on the average shortens the length of the files that
you are tending to use.


David A. Scott
--
                    SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
                    http://www.jim.com/jamesd/Kong/scott19u.zip
                    http://members.xoom.com/ecil/index.htm
                    NOTE EMAIL address is for SPAMERS

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

From: [EMAIL PROTECTED] (Hartmut Schroeder)
Subject: Q: Does ElGamal require that (p-1)/2 is also prime like DH?
Date: Thu, 22 Jul 1999 07:21:51 GMT

Hi,
while reading "Applied Cryptography" it is mentioned that 
ElGamal and Diffie-Hellman are based on the same mathematical Problem.
It is also said that prime p you choose for Diffie-Hellman 
has also to be a prime when you compute (p-1)/2.

It would take a while to find great Primes that meet this criteria. 

The Book seem nothing to say in the ElGamal Section that this
is also true for prime p when using ElGamal.

Could someone enlighten me?

Regards H.Schroeder


Hartmut Schroeder             MMS Communication AG
mailto:[EMAIL PROTECTED]           Eiffestrasse 598
http://www.mms.de/~hacko      20537 Hamburg, Germany
Phone: +49 40 211105-40       Fax: +49 40 210 32 210
UTM 32U0569835 5934083 WGS84

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

Date: Thu, 22 Jul 1999 08:55:37 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: RE: Crypto keys

>Hello!

>I have a need for creating a crypto key and I wonder is the value you
>get from MS guidgen.exe any good?
>
>cf13dd90-3f74-11d3-afd2-0060087534eb
>
>// Anders

So, you would be using that as a key? And with what algorithm?
And how would you decrypt the messages that you have encrypted?
What do you mean by a need for creating a crypto key?

If you want to use encryption, I suggest that you install 
PGP to your computer and use that. You can find it here:

http://www.pgpi.com/

It creates the keys, handles the encryption and is reliable.

I think I didnt quite get what you wanted to do, but hope this
helps.
===========================================================
Posted with AnonNews at http://anonymicer.home.pages.de/



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

From: vincent <[EMAIL PROTECTED]>
Subject: RSA public key
Date: Wed, 21 Jul 1999 18:24:16 +0100

Sorry to ask you what would be an easy question if I was good in Math.
If I always take the same very small exponent for the public key (for
example 3) and I compute the private key with p and q (the prime
numbers) big enough, do I limit the number of private key which will
result from this computation ?

Is it weak to do so, because obviously it would make the encryption
faster (as well as the key generation) ?

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


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