Cryptography-Digest Digest #549, Volume #10      Fri, 12 Nov 99 00:13:03 EST

  Re: Proposal: Inexpensive Method of "True Random Data" Generation (Mike McCarty)
  Re: Encode It 1.03 CRACKED 1 month after released (JPeschel)
  Re: real random number generator idea -- any criticisms? ("Gary")
  Re: Build your own one-on-one compressor (Mok-Kong Shen)
  Re: E-CRYPT cracked too ! ("Ken Lee")
  Re: Signals From Intelligent Space Aliens?  Forget About It. (Mike McCarty)
  Re: OT: dates and sigs[Re: PGP Cracked ?]
  Re: Ultimate Crypto Protection? ("Trevor Jackson, III")
  Re: real random number generator idea -- any criticisms? (John Myre)
  Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
  Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
  Re: real random number generator idea -- any criticisms? (JD)
  Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column 
  Postpages for Handbook of Applied Cryptography (Alfred John Menezes)


From: [EMAIL PROTECTED] (Mike McCarty)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 11 Nov 1999 22:34:30 GMT

In article <[EMAIL PROTECTED]>, Coen Visser  <[EMAIL PROTECTED]> wrote:
)Mike McCarty wrote:
)> No individual string can be random. A string is or is not compressible,
)It is a definition: call a string random when it is incompressible.

I was disputing your definition.


)> You seem to be trying to decompose a single event, i.e. the generation
)> of a string, into multiple events, i.e. the generation of each string
)> element (or equivalently, generation of strings of length one element
)> each), and then use the randomness or non-randomness of the latter
)> events considered as a stochastic process as a means for determining
)> the randomness of the single event of generation of the entire string.
)Ah, that was not what I meant. I was trying to make a point (badly)
)about the inevitable occurence of regular patterns in random strings.

If that's true, then we are talking about different subjects. I thought
you were discussing randomness, and a putative definition in terms of

To reiterate: the compressibility or non-compressibility of any given
string depends on the universe from which it is drawn. A given string
has a "pattern" in it which leads it to be compressible (in the sense
that the compressed string is actually shorter than the uncompressed
version) only if one knows something about the universe from which it
is drawn. It is not a property of an individual string.

In order to further the exchange of information rather than talking at
cross purposes, would you please supply putative definitions for:

        random variable
        random process
        stochastic process
        random number
        random string

char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel      <- They make me say that.


From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Encode It 1.03 CRACKED 1 month after released
Date: 11 Nov 1999 22:55:03 GMT

"Alexander PUKALL" [EMAIL PROTECTED] wrote so much that
I decided to snip it:

>The soft can be found here :

>The soft use a stream cipher with no salt key. With a same key, the output
>of the stream cipher
>will be the same :

>A simple XOR with the same output stream for all files crypted with the same
>password !!
>But with the new SCC 524,288 Bit encryption method !! Yes my Lord !
>Oh snake oil My Love !!

Encode-It is Province's replacement program for Turbo Encryptor, which
was cracked by Casimir, Randall Williams,and myself. 

The SCC encryption method, I think you'll find, is, like Turbo Encrypto's,
home-grown.  Instead of just discovering that no salt is used, I think
you may be able to really crack Encode-It using ciphertext only, or by changing
a few snippets of code.



Joe Peschel 
D.O.E. SysWorks                        


From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: real random number generator idea -- any criticisms?
Date: Thu, 11 Nov 1999 22:57:38 -0000

It's easier to read the timestamp counter (rdtsc in assembler) every window
message event and append it the current random number then hash it giving
the new current random number.


From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Thu, 11 Nov 1999 23:40:20 +0100

Mike McCarty wrote:
> Basic English (as proposed in the early 60s) has an 800 word vocabulary.
> It is not a pidgin.

It's fine to know that. Since really top secrets are likely to be
'mundane' texts and any special words not in the dictionary could 
in most cases be expressed in round-about ways (besides being
translatable verbatim) -- because the communication partners in
such cases share some common (secret) contexts -- this means we 
can map each word to 10 bits, i.e. using a very small dictionary. 
Hence the amount of bits transmitted and available to the analyst
is greatly reduced and the software doing the translation will 
need only a fairly small database and thus be very efficient.

M. K. Shen 


From: "Ken Lee" <[EMAIL PROTECTED]>
Subject: Re: E-CRYPT cracked too !
Date: Thu, 11 Nov 1999 17:15:17 -0600
Reply-To: "Ken Lee" <[EMAIL PROTECTED]>

Can you explain to us the procedures, methods, and hints you used to crack
e-crypt, so that we can learn a thing or two...

Alexander PUKALL <[EMAIL PROTECTED]> wrote in message
news:80ehn1$3b4$[EMAIL PROTECTED]...
> E-Crypt, the revolutionary software package that allows for the secure
> exchange of email.
> E-Crypt is guaranteed to be the product that allows everyone, from the
> individual user to the administrator
> of a worldwide network,
> to spend more time being productive and less time worrying about
> The soft can be found at :
> I crypted a mail with e-crypt ( with header encrypted option )
> Plaintext :
> Message :
> The key was : 'AA'
> the ciphertext :
> subject : 82828282828282828282828282828282828282828282
> message :
> ***** Delete this Line and above then Decode MSG ******
> 7973797379737973
> I suppose that 8282 is the key 'AA' encrypted, to verify if the password
> correct or not.
> And a second message :
> Subject : BBBBBBBBBB
> message :
> With the key : 'BB'
> ciphertext :
> Subject : 848484848484848484848484
> ***** Delete this Line and above then Decode MSG ******
> 84847A767A767A767A767A767A767A767A767A767A767A767A76
> I suppose that 8484 is the key 'AA' encrypted, to verify if the password
> correct or not.
> I suppose i have not to continue to say the E-CRYPT soft is cracked, the
> algo used is some polyalphabetic substitution, with XOR.
> Alexander PUKALL
> November 11, 1999


From: [EMAIL PROTECTED] (Mike McCarty)
Subject: Re: Signals From Intelligent Space Aliens?  Forget About It.
Date: 11 Nov 1999 22:52:46 GMT

In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa  <[EMAIL PROTECTED]> wrote:
)"SCOTT19U.ZIP_GUY" wrote:
)> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
)> >"Douglas A. Gwyn" wrote:


)> >This mass expansion seemed to me to be dangerous and I believe I
)> >communicated this concern to the professor.  I believe he understood
)> >what I was concerned about and I believe his reply was meant to
)> >answer my question with regard to my concern.
)> >
)>    The mass that you think  would be dangerous is not.
)> If you where in a rocket without windows feeling an accleration of 1.1 G's you
)> would never even be able to tell if your going 1% the speed of light or 99.99%
)> the speed of light. Your concerns of the problem are false.


)If you did not know it, as mass approaches the speed of light, 
)the mass increases.

You seem to think that if I were travelling at a relativistic velocity
relative to you, then my mass would increase, and my own gravity would
crush me. This is not the case. In fact, as Scott stated, there would
be no way I could determine that I were accelerating or in a stationary
gravitational field. I would notice no "mass increase" whatsoever. If I
could, then I could detect absolute motion.



char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel      <- They make me say that.


Subject: Re: OT: dates and sigs[Re: PGP Cracked ?]
Date: 11 Nov 99 23:02:05 GMT

Jim Gillogly ([EMAIL PROTECTED]) wrote:
: How confident are you that it's <not> 1999 in the current Age, whatever
: that may be?

A good point, especially considering that Frodo's achievement was intended
as a type of the Crucifixion.

John Savard


Date: Thu, 11 Nov 1999 18:24:38 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Ultimate Crypto Protection?

Sundial Services wrote:

> Adam Durana wrote:
> > > I have a friend who tells me that the Russian military used double
> > enciphered
> > > OTP all through the cold war and that NSA, with all it's expertise and
> > computer
> > > hardware never had much success breaking it.
> > >
> > > Is double encipherment really all that effective?
> >
> > No one has ever broken an OTP.  Double OTP just seems like an overkill.  A
> > single OTP provides perfect security.
> Not if one of their spies is at the bottom of the Danube and the enemy
> stole a copy of his pad before shooting him.  A system involving two OTP
> streams would be resistant to either one of them being stolen, and would
> further introduce the question of how the streams were combined; the
> random nature of OTP streams offering no clues.
> Spy organizations think like that.

Hardly.  The spy at the bottom of the river had to have both pads.  A system
involving two pads has security equal to that of a single pad, but is four times
as hard to use.


From: John Myre <[EMAIL PROTECTED]>
Subject: Re: real random number generator idea -- any criticisms?
Date: Thu, 11 Nov 1999 16:36:23 -0700


> ...  ::GetTickCount() ... ::QueryPerformanceCounter() ...

Wouldn't it be interesting to check the results of these two
bit streams separately, as well?  If one is "random" than it
will mask patterns in the other.  Knowing their general
characteristics separately might come in handy someday.

John M.


From: Coen Visser <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Fri, 12 Nov 1999 00:58:38 +0000

"Trevor Jackson, III" wrote:

> Nope.  You are vaccilating on the use of the term compression.  previously you 
> that you could compress any single string irrespective of the population from which 
> was drawn.  Now you are looking at the population statistics.

That is a misunderstanding between us. I do not believe that one
can compress any single string irrespective of the population
from which it was drawn and never believed so. In fact I believe
that most strings from the set of all finite strings are difficult
to compress.

> My example was based on the your example os a single string being compressible.  In 
> I have a TRNG that dumps data onto floppies.  I have a ten megabit random string in 
> shirt pocket.  I've compressed ten megabits of randomness into "the string in
> randseed.bin on the floppy in my shirt pocket", which is certainly a high compression
> factor for lossless compression algorithms.
> Note that the actual value of the string is irrelevant to this compression technique.
> ANY string of ten millions bits can be encoded in a simlar way.  Thus all strings are
> compressible, and thus non-random, when your definition of compression is applied.

I am not following you here due to the above mentioned misunderstanding.

> > The connection between incompressibility of strings and randomness can
> > be used *directly* to prove all kinds of mathematical properties. So I
> > would say it is useful and meaningful. What can one do with "your"
> > definition of (random) number generators?

> Avoid mistakes.

That sounds very useful. How would you use the definition and underlying
theory to show that a RNG is not a TRNG?


        Coen Visser


From: "james d. hunter" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Thu, 11 Nov 1999 20:06:21 -0500

Coen Visser wrote:
> Mike McCarty wrote:
> > If that's true, then we are talking about different subjects. I thought
> > you were discussing randomness, and a putative definition in terms of
> > compressibility.
> I am discussing randomness and random strings as defined by
> incompressibility of a string. But this discussion has gotten so
> many side-tracks that it is hard for me to keep up with all
> the arguments and counter-arguments. So I may have stated
> something in the wrong context. My apologies if that is the case.

  I think you better define random first, before you discuss it.
  "Random" only makes sense in terms of a random process.
  Strings are usually interpreted as -fixed- outputs of a
  random process. "Incompressibility" has to do with the information
  content of the -fixed- string. There is nothing really "random" about
  You can have one random process -spawn- more random processes,
  but you have to define the probability distributions at each
  step in order for it to make sense.


Subject: Re: real random number generator idea -- any criticisms?
Date: Fri, 12 Nov 1999 02:36:18 GMT

In article <[EMAIL PROTECTED]>,
> On Thu, 11 Nov 1999 20:21:27 GMT, [EMAIL PROTECTED] wrote:

> >Make an initial call to ::GetTickCount(). Keep calling the function
> >repeatedly until the value changes, incrementing a counter each time.
> >Take the LSB of the counter and use that as a bit of randomness.  The
> >resolution of the win32 function ::GetTickCount is about  10ms for
> >55ms for 95.
> >
> >Thus, the method grabs randomness from the process scheduler.
> >
> The process scheduler is complicated, perhaps even cryptographically
> so (though I doubt it) but it is still deterministic.

Maybe, but remember that there may be lots of asynchronous interrupts
occurring during this time that cause context switches to occur,
running low-level device driver code, making the least significant bits
of the counter cryptographically unpredictable.  Events such as mouse
movements; keypresses; disk, network and modem activity, etc.

Look up Matt Blaze's truerand routine for an example of a good
implementation of this method.


Sent via
Before you buy.


Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 12 Nov 1999 02:48:38 GMT

Terry Ritter wrote:
> >Terry Ritter wrote:
> >> Well, in cryptography, there are various kinds of authentication:
> >
> >Glad you're seeing that.
> In the rest of the paragraph -- which you did not see fit to include
> here -- I described various types of "authentication."

I deleted the tangent.  There are several neat ways to
do it, and they don't necessarily fall into one
of the types from a list.

> "Session keys" (more properly called "message keys," in most cases)
> are in fact very close to the negotiation which I have been promoting
> all along.  In my proposal, one end sends a list; the other selects
> from that list, repeatedly, perhaps with every message, much like a
> message key.

O.K. There's our description of the protocol.  I'm
talking about attacks in which the adversary
substitutes his list of cipher for the list one side
sent (More below).

> In my proposals, it is has been, and still is, unnecessary to
> authenticate the cipher choice.  No authentication mistake is possible
> with respect to cipher choice.  The ciphers themselves must be
> authentic, but that is not a cipher-change protocol issue.

I'm not sure what you mean.  The adversary may modify the
messages that influence the choice of cipher.  It is the
authenticity of these messages that is at issue, and the
handling of these messages constitutes the cipher selection
protocol.  I'll show below why authentication is necessary.

> >Over and over you've stated that the negotiation is
> >secret, protected by a cipher.  When did you note
> >the need for authentication or name a MAC or
> >signature? Now you say it's just like other cipher
> >systems, such as public key ciphers.  Ciphers provide
> >poor authentication, and public key ciphers don't
> >really provide any authentication at all.  It is
> >not the case that your claim of secrecy, protected
> >by a cipher implies authentication.  In fact it
> >implies that you missed the attack.
> I have always said that the cipher-change negotiation must occur under
> cipher.  I am guilty of expecting that cipher system to be effective.
> But I missed no attack, because there was and is no attack on the
> cipher-change protocol itself, which is all I have been describing.

So you've described the protocol: "In my proposal, one
end sends a list; the other selects from that list".
You've been clear that when a side sends the list,
such communication is and under a cipher.  Now I'll
describe the attack on a system entirely consistent
with your description.

Suppose all parties are given an authentic certificate
for Bob's public key.  Alice sends her list of ciphers
to Bob, encrypted under Bob's public key.  Fred blocks
the message from Alice and substitutes his own list
consisting of one cipher he knows to be on Bob's list.
Bob, as the description specifies, selects a cipher
from the list.

So just as you described, the negotiation is protected
by a cipher.  Just as you wrote "In my proposal, one
end sends a list; the other selects from that list".
Thus Fred has achieved the chosen cipher attack, within
the protocol you described.  As you noted, we have to
assume the initial cipher is effective; ciphers provide
privacy and the example above grants that the cipher
is effective.

> You seem to have several big problems here, the first being the
> possibility that I missed something, and so deserve your castigation.

More like: you missed something and so should recognize
it now and fix it.

> Well, I did *not* miss what you think I did, but even if I had, who
> elected you God?  If you had found a factual problem, you could
> present that.  Instead, you cop an attitude and distort reality, both
> of which are way out of line.

I introduced the issue simply as a matter of fact.
Over and over you refused to see it, and acted like
I and others didn't know what we were talking about.

> >> Whatever
> >> cipher system has been established will authenticate
> >> received messages
> >> in some way (often with a hash of the plaintext),
> >> and thus will detect
> >> "any" attempt by an attacker to "modify the messages."
> >
> >Now you're starting to get it.  This authentication
> >was completely missing from your suggestion before
> >others pointed out the problem.
> There was and is no problem, and what was pointed out was wrong.  If
> the public-key certification or message authentication is bad, the
> original security is bad, and there is no protection for the raw
> plaintext that we are trying to protect, so cipher-change negotiation
> is the least of the problems.

As I asked before - if you had message authentication on
the negotiation, please just cite it.  You keep saying
it's protected by a cipher.  Got the privacy; where's
the authentication?

> Your peculiar concentration on "authentication" obscures the real
> problem, and that problem is that the original cipher must be secure
> in many ways, including algorithm, key, and implementation.

But the problem at issue is that the protocol you
described grants the adversary's choice even when we
assume these components are sound, as shown.

> Where did
> *you* ever say that *those* were required?  But they *are* required,
> and you missed those "attacks."  Tsk, tsk.

Yes, the protocol could fail because of one of these
components.  The issue here is protocol failure.

> >Yes, it can be fixed,
> >but the actual protocol design is not the simple
> >exercise you had thought.
> The protocol is *just* as simple as I first proposed.  There is
> essentially no protocol there at all:  We just select at random from a
> list.

And now we've seen that this doesn't work well without
the authentication mechanism.

> The design part of this is the construction of a hidden command
> channel behind the plaintext, the various messages and retained state
> required to perform a clean transition, and I believe, the ability to
> withstand message loss without problem.  This does require some
> design, and failure here means we will not change ciphers, or may do
> so in regular ways.

As shown, failure can grant the adversary his choice of
the ciphers, though as I noted in a previous post, the
cipher does have to be from Bob's approved list.

> In other words, the *worst* that can happen from a bad cipher-change
> protocol is that we end up using one cipher repeatedly, which is the
> *normal* situation now.  Failure in the protocol is thus only a
> failure to take advantage of new cipher-change strength, and not an
> introduction of weakness.

Shown false.

> It was clear enough for almost everyone else who read my proposals.
> Stop pretending that you have contributed something important.  You
> have not.  Stop pretending that I have ignored or dissembled about a
> real problem.  I have not.

It certainly wasn't clear to you.  Even after people
suggested the possibility of the attacker influencing the
cipher, you insisted that the secret negotiation under
a cipher ruled this out.  But look at the example - the
messages are secret under a cipher and the attacker still
gets his choice.  As I wrote the first time I brought
this up:

    Ciphers by themselves offer poor authentication, and
    the authentication of the selection channel is far
    more important than its privacy.  If I can find a way
    to forge, I can get you to use _my_ choice of your

> As far as I know, the only real problem which came up was the need for
> additional protection for the command channel, beyond that used for
> the plaintext.  That was pointed out by "others," not me.  But that is
> not your "authentication," and it is easily fixed.

And the problem I noted is easily fixed.  Your
persistence in stating that the channel is protected
a cipher and never noting an authentication mechanism
baffles me.

> >The cipher agility of your actual systems is far behind
> >the state of the art.
> "Cipher agility" would seem to mean the ability to change ciphers
> quickly.  Any system which can do this is *beyond* the current state
> of the art.  My proposals thus *are* the state of the art in
> non-government cryptography.

But you cited your commercial systems, which have no
cipher agility at all.

> >Your commercial
> >ciphers contradict such claims.
> I'm a little confused here:  Are you saying that I have produced
> ciphers of such complexity that they obviously were not easy to
> design?  Guilty.

No, I'm saying the commercial ciphers you cited are
far behind the state of art in cipher agility.  If you
believe so strongly that protocols should allow many
ciphers, and also that the design is not so hard, why
are they so monolithic?

> Actually, my ciphers are fairly simple, as serious systems go.  But
> the design and actual implementation of real cipher systems is not
> easy.  Perhaps you should try it, so we can see how well *you* do.

That's most of what I do for a living.

> Frankly, since your years-ago claim to have a break for my Fenced DES
> Cipher broke down in your own failure, you have been hard to live
> with.

When you first wrote that I claimed to "break" Fenced
DES, I immediately corrected you. I called my analysis
successful because it showed your security analysis was
wrong.  I was entirely clear on what my attack did -
and you know it.

> The reality is that I produced a design which, in the end,
> withstood your attacks; I built a cipher which you thought you could
> break, but could not.  I'm sure it was very embarrassing for you.

You produced a defective design, as I showed. How
many times have you written that a block cipher
should simulate a large random permutation?  Now we
know Fenced DES does not do what a block cipher
should. You tried to make my analysis look like
failure by making things up and saying I said them;
you even had quotation marks around claims you
fabricated.  Do you think that by now I've
forgotten that you wrote them and I didn't?

> But
> everyone makes mistakes, and those of us who speak out are especially
> exposed; most of us accept reality and move on.  Get over it.

Me get over it?  I don't think I've brought up
your pathetic dishonesty in years.  You keep
inserting Fenced DES into completely unrelated
discussions so you can once again lie about what
I wrote.


Sent via
Before you buy.


From: [EMAIL PROTECTED] (Alfred John Menezes)
Subject: Postpages for Handbook of Applied Cryptography
Date: 12 Nov 1999 02:38:13 GMT

In the past few months, we have made available all 15 chapters
from our "Handbook of Applied Cryptography" for free download 
from our web site:

Our publisher, CRC Press, has generously given us permission 
to place the postpages on the site. We have just uploaded:
  Appendix - Bibliography of Papers from Selected Cryptographic Forums
With these additions, the entire Handbook is now available for
free download.

We hope that the electronic version of the Handbook will be of use 
to people in their cryptographic work and study. We hope that by 
making the chapters available for free download, the book will be 
accessible to those who cannot afford to buy it, and to those who 
may only have a cursory interest in the material presented in the book. 

- Alfred

| Alfred Menezes        | Email: [EMAIL PROTECTED]                   |
| Department of C&O     | Phone: (519) 888-4567 x6934                    |
| University of Waterloo| Web page: |
| Waterloo, Ontario     | Web page for Handbook of Applied Cryptography: |
| Canada N2L 3G1        |        |
| Centre for Applied Cryptographic Research:  |



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