Cryptography-Digest Digest #795, Volume #9       Mon, 28 Jun 99 21:13:04 EDT

Contents:
  Re: one time pad (William Tanksley)
  Re: The One-Time Pad Paradox ("Douglas A. Gwyn")
  Re: one time pad (William Tanksley)
  Quasigroup engryption ([EMAIL PROTECTED])
  Re: one time pad (Greg Ofiesh)
  Quasigroup encryption ([EMAIL PROTECTED])
  Re: trapdoor one way functions (Nicol So)
  Can Anyone Help Me Crack A Simple Code? (mercury)
  Re: The One-Time Pad Paradox (Onke M. Airly)
  PIII Random Number Generator? ("Dale Clapperton")
  Re: one time pad (Mickey McInnis)
  Re: one time pad (Greg Ofiesh)
  Re: Can Anyone Help Me Crack A Simple Code? (William Tanksley)

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

From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: one time pad
Reply-To: [EMAIL PROTECTED]
Date: Mon, 28 Jun 1999 22:46:51 GMT

On Mon, 28 Jun 1999 03:38:51 -0400, [EMAIL PROTECTED] wrote:
>William Tanksley wrote:

>> On Sun, 27 Jun 1999 01:54:55 -0400, [EMAIL PROTECTED] wrote:
>> >William Tanksley wrote:

>> >> There is NO single stream of data coming out of an alleged RNG which would
>> >> prove to me that it wasn't an RNG.

>> >Well I have this special RNG that meets these criteria.  It's quite
>> >cheap.  It is also sold under the name "zero ohm resistor", but for
>> >today only, I'll make a special offer of $10.00 each.

>> Did I mention that there's no single stream which can prove (or even
>> suggest) to me that an alleged RNG is in fact a true RNG?

>> Now, give me control and let me generate what I consider to be multiple
>> streams (under my control), and let me see the generator's details, and
>> let people who specialize in the details see them, and after a while I'll
>> consider it suggested that the thing is an RNG.

>The interesting issue isn't that you would decide, but how you would
>decide.  Do you use Karnak's Criteria (hold envelop to forehead)?  Is
>there anything in your decision process that does not fit into a DTM? 
>If it all fits in a DTM it can be completely automated.

My primary point is negative, not positive -- a single stream tells me
nothing.  It doesn't tell an automaton anything, either.

>If it can be automated it can run in real time.  If it runs on the
>output of your generator, how will you react if/when it complains?

As I mentioned, the automaton can't run in real time with respect to the
generator -- the automaton has to have control over the generator,
including the ability to restart it in any and all ways possible (power
cycle, etc).

If the automaton says the generator produces suspicious streams, I'll
throw the generator away.  If it doesn't complain, then I'll consider the
possibilty that the stream might be acceptable as a random sequence
generator.

I might actually use it as such if I cannot see patterns in it, and if
other people (including those more skilled than I) produce similar
results.

There are some true RNGs out there which fit these requirements, although
it's not certain that I'd want to use any of them for OTPs.

-- 
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
   :-: May faulty logic undermine your entire philosophy!

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: The One-Time Pad Paradox
Date: Mon, 28 Jun 1999 21:58:32 GMT

John Savard wrote:
> During World War II, the OSS devised a handgun with such a good
> silencer that almost no sound - and no flash of light - came from
> the gun when it was fired. That, too, is _still_ too dangerous to
> have floating around...

First, it's easy enough to construct such a suppressor, especially
if it doesn't have to stand up under repeated firing (the key is
that the bullet must be subsonic); second, it is no more dangerous
than matches, gasoline, knives, or many other objects that almost
everybody has ready access to.  Less so, actually, when not attached
to a firearm.

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

From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: one time pad
Reply-To: [EMAIL PROTECTED]
Date: Mon, 28 Jun 1999 23:04:28 GMT

On Mon, 28 Jun 1999 19:13:02 GMT, Greg Ofiesh wrote:

>>...Personally, I doubt it, but you never know...

>I agree so much with your statement on predicting radio active decay
>that I would even bet my life on the proposition that we will never be
>able to predict decay.  And that is the first and (at this time) the
>only thing I would be willing to bet my life on.

That's one of the last things I would bet on.  The hypothesis that quantum
fluxuations are random is one of the weakest in science today; it's not
backed by any theory with any predictive value.

>> Even if we start with the assumption that we can implement
>> an OTP in a way that really matches the spec, so it's truly
>> unbreakable, we're left with the more fundamental problem
>> that it's not useful in most common situations anyway -- it
>> still has a key that's just as large as the text being encrypted,
>> rendering it worthless in the average situation.

>I must tell you, I keep hearing people say several things over and over
>again and yet I have NO IDEA what they are talking about (not that I
>think they are wrong, but I wonder if some of them know themselves).

>For example, what is the definition of "most common situation" that
>would make OTPs useless?

Well, think about it.  With computers responsible for communication, you
usually don't have any more or less secure channels; you're stuck with
electronic networks and human memory for passwords.

A human can't remember an OTP, so you're out of luck there.  Networks are
supposed to be insecure (why else use crypto?).  So you have only two
choices: use symmetric crypto based on a user-memorized password, or use
public key crypto to negotiate a symmetric key.

But these aren't the most common or most general uses, simply the most
prevalent among computer users.

>And why has anyone even come to believe that my (unstated) plans for
>OTP use are common or average?

Because you haven't said otherwise, and you asked our advice.

>Don't get me wrong, I am not upset.  I am just curious what people mean
>by these over generalized statements and what they think my intentions
>are based on what little I have stated.

We can only make general statements -- you haven't said anything specific.

>The US Military, I was told, uses OTPs for their most sensitive
>communications (what ever those are).

Could be.  They don't tell me things like that.  I do find it believable
that the Red Phone uses OTP.

>> We have quite a few symmetric ciphers that as far as we
>> know at the present time aren't breakable.  Even if we
>> assume that they're entirely secure, they're still not
>> useful if what you really need is a public-key style cryptography.

>I never mentioned public key and I don't believe it is nearly as useful
>as it is being touted.  Look at the whole concept of Certifying
>Authorities.  The question that comes into my mind is, "Who are they?
>Can they become corrupt?  Would I trust them with my data?"  So you can
>see that in my mind, PKey is almost useless just on that grounds alone.

Key exchange is also useful, and that uses public key techniques.

CAs are a consideration with any type of key.

>> In the end, trying to talk about whether it's better to use public-
>> key, symmetric or OTP cryptography is mostly a pointless gesture.
>> Each does different sorts of things.  Believing that an algorithm
>> provides a high level of security is pointless if it simply won't do
>> the sorts of things you want or need to get done.

>The discussion, as I see it, has to do with provable security.  In the
>end, I would use encryption ABC if that was absolutely the only one
>that could be proved uncrackable.  My application is specialized and I
>can for the most part work with the requirements and restrictions of
>almost any cipher.  Remember, I am the one seeking information to
>validate my decision to deploy OTPs, and I have already considered the
>extreme logistics of its deployment.

Generally speaking, security flaws come as part of the system, not the
algorithm.  If you use one of the standard, documented, and tested ciphers
you'll be clear up to the brute-force difficulty of your keys -- and
endangered by every weakness in your system.

>Sent via Deja.com http://www.deja.com/

-- 
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
   :-: May faulty logic undermine your entire philosophy!

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

From: [EMAIL PROTECTED]
Subject: Quasigroup engryption
Date: Mon, 28 Jun 1999 22:23:31 GMT

Hello

 Please read this paper, have anyone idea is it this secure? Where I
can find more papers about using quasigroups for encrytpion?

http://www.pmf.ukim.edu.mk/~danilo/quasigroup.html

Thank you.


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

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

From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Mon, 28 Jun 1999 23:28:01 GMT


> > ...in theory are crackable given enough and
> >proper resources (which WILL come in time).
>
> I see.  And how much time do you anticipate until a brute-force
> search of a 256-bit keyspace is practical.
>
> There are several other provably secure cyphers that are no
> less impractical than a true OTP.  As in, they're all next
> door to useless in Real Life.

Again, in theory.  Now if you want to take this to the practicle, let
me ask you, are you 100% certain (ready to bet your life on it) that
the NSA does not yet have a working quantum computer or other highly
advanced device that would make even a 1k bit keyspace very reasonable?


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

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

From: [EMAIL PROTECTED]
Subject: Quasigroup encryption
Date: Mon, 28 Jun 1999 23:22:41 GMT

Hello

Please read this paper. Has anyone idea how secure is this method?
Where I can find more papers about using quasigroups for encryption?

http://www.pmf.ukim.edu.mk/~danilo/quasigroup.html

Thank you.


PS: Excuse me for the errors in previous posting.


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

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

From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: trapdoor one way functions
Date: Mon, 28 Jun 1999 19:45:27 -0400

[EMAIL PROTECTED] wrote:
> 
> I was wondering if there are any other trapdoor one way functions in
> academia that don't use either the discrete logarithm problem or the
> integer factoring problem.

Are you sure exponentiation (defined over a suitable finite group) is
trapdoor one-way, instead of just one-way?  What kind of trapdoor
information would allow you to compute discrete log fast?

Nicol

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

From: mercury <[EMAIL PROTECTED]>
Subject: Can Anyone Help Me Crack A Simple Code?
Date: Mon, 28 Jun 1999 19:34:13 -0400
Reply-To: [EMAIL PROTECTED]

Here is a Challenge for Anyone Interested in Breaking Codes.
I am Looking for the Algorithm that Does the Following:

Here Is a List of 6 Inputs for the UnKnown Algorithm:

582 285 8183
753 980 4828
653 429 9888
883 285 8883
528 853 8849
628 382 2858

Any One of These will Produce the Same OutPut.  (Which is UnKnown)
There are Other Ten Digit Codes that will Work Also.

I Believe the Algorithm is a very Simple Routine.

Does Anyone have any InSight on a Good Way to Go About Solving this
Riddle?

-mercury  <[EMAIL PROTECTED]>




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

From: [EMAIL PROTECTED] (Onke M. Airly)
Subject: Re: The One-Time Pad Paradox
Date: Mon, 28 Jun 1999 23:41:12 GMT

[EMAIL PROTECTED] () wrote:

>One must use a key that is truly and genuinely random.

>Now, there is a small, but finite, probability that the random key will
>happen to be 000000...

>If one uses such a key, one is sending one's message in plaintext.

One must therefore add the additional constraint that the message to be
sent must be a "recipriversexclusion", which is defined as "a number whose
existence can only be defined as being anything other than itself." This is
all part of bistromathics, as described by Douglas Adams in Life, the
Universe, and Everything.
-- 
"Onke M. Airly"     better known as [EMAIL PROTECTED]
 0123 4  56789      <- Use this key to decode my email address.
                    Fun & Free - http://www.5X5poker.com/

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

From: "Dale Clapperton" <[EMAIL PROTECTED]>
Subject: PIII Random Number Generator?
Date: Tue, 29 Jun 1999 09:37:57 +1000

Hi

Does anyone know of any studies done on whether the Random Number Generator
on the Pentium III chips is truly random or not?

Thanks

Dale



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

From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: one time pad
Date: 28 Jun 1999 23:50:21 GMT
Reply-To: [EMAIL PROTECTED]

In article <7l8jeg$e7n$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Patrick Juola) 
writes:
|> In article <7l8hfi$poi$[EMAIL PROTECTED]>,
|> Greg Ofiesh  <[EMAIL PROTECTED]> wrote:
|> >> Even if we start with the assumption that we can implement
|> >> an OTP in a way that really matches the spec, so it's truly
|> >> unbreakable, we're left with the more fundamental problem
|> >> that it's not useful in most common situations anyway -- it
|> >> still has a key that's just as large as the text being encrypted,
|> >> rendering it worthless in the average situation.
|> >
|> >I must tell you, I keep hearing people say several things over and over
|> >again and yet I have NO IDEA what they are talking about (not that I
|> >think they are wrong, but I wonder if some of them know themselves).
|> >
|> >For example, what is the definition of "most common situation" that
|> >would make OTPs useless?
|> >
|> >What is the definition of the "average" situation that makes OTP
|> >worthless?
|>
|> The major weakness of the OTP is that it requires that the key
|> be as long as the message and sent securely over a channel.
|> If you have a secure channel of sufficient capacity to take the
|> key, it will also (by definition) take the message -- so why
|> are you bothering with using an OTP?
|>
|> The most common application in cryptogrphy is where a secure
|> channel is available, but of *MUCH* lower capacity than the
|> insecure channel to which cryptogrphy is applied.  If no secure
|> channel is available, symmetric crypto is completely inappropriate;
|> if the secure channel is equally available and has equal or
|> greater capacity, cryptography in general is inappropriate.
|>

For very important applications, it's common for there to be a secure
channel available that is of sufficiently high capacity, but not
real-time.  One example would be secure physical delivery of CD-R disks
with OTP data.  One CD-R with 600 MB of pad on it would cover many
crypto applications for months or years, and it would be almost as
easy to ship dozens or hundreds of CD-R's at a time.

It doesn't cover all situations, true, but it's definitely practical
for many cases.  For instance, it should cover point-to-point
correspondence for any two people who aren't mailing each other
pictures or wav files all the time.

e.g. Someone typing 60 words per minute, 8 hours a day would generate
172KB of data a day.  This would take 9 years to reach 600 MB on a
CD-R.


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

From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Mon, 28 Jun 1999 23:57:08 GMT


> The major weakness of the OTP is that it requires that the key
> be as long as the message and sent securely over a channel.
> If you have a secure channel of sufficient capacity to take the
> key, it will also (by definition) take the message -- so why
> are you bothering with using an OTP?

Get "sending the pad over a secured channel" out of your mind.  Think
in terms of "sending the pad over a channel WHEN it is secured so that
it can secure the same or other channel at later times."

> Because, again by definition, most uses are common/average, and
> unless you state otherwise, people will -- and should -- assume
> that your uses are otherwise typical.

I see your point.  I should have clarified the extremes of my need and
willingness to fulfill them.


> So don't use a certifying authority.  Other models exist, including
> web-of-trust or individual certifiers.

I was just pointing out one obvious problem with present day deployment
of PKey.  The math is another obvious problem.  It can be cracked
tomorrow by a math discovery and there is no reason we should ever
expect to hear of it.  If I made such a discovery, I would sale it to
the NSA for millions and you would never know of it.


> >The discussion, as I see it, has to do with provable security.  In
the
> >end, I would use encryption ABC if that was absolutely the only one
> >that could be proved uncrackable.  My application is specialized and
I
> >can for the most part work with the requirements and restrictions of
> >almost any cipher.  Remember, I am the one seeking information to
> >validate my decision to deploy OTPs, and I have already considered
the
> >extreme logistics of its deployment.
>
> In other words, don't confuse you with facts as your mind is already
> made up.  Have fun.




I said I am the one seeking information to validate my decision to
deploy OTPs.  I did not say I made up my mind to do so.  but before I
waste people's time to help me validate my decision, I need to know
that I am also prepared to deploy at any expense.  And I am
"prepared".  That is all I said.

I am tempted to think you meant to slight me, but I refuse to think ill
of you.



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

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

From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: Can Anyone Help Me Crack A Simple Code?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 29 Jun 1999 00:27:41 GMT

On Mon, 28 Jun 1999 19:34:13 -0400, mercury wrote:
>Here is a Challenge for Anyone Interested in Breaking Codes.
>I am Looking for the Algorithm that Does the Following:

>Here Is a List of 6 Inputs for the UnKnown Algorithm:

>582 285 8183
>753 980 4828
>653 429 9888
>883 285 8883
>528 853 8849
>628 382 2858

>Any One of These will Produce the Same OutPut.  (Which is UnKnown)
>There are Other Ten Digit Codes that will Work Also.

>I Believe the Algorithm is a very Simple Routine.

It is.  The algorithm which most efficiently solves this problem does so
by leaving the computer off, thus producing no output.  Every one of the
mentioned inputs will produce the same output (nothing whatsoever).

>Does Anyone have any InSight on a Good Way to Go About Solving this
>Riddle?

This solution also has the enormous advantage of postponing the eventual
heat-death of the universe compared to any other solution.

In other words, give more information.

Oh, and I never thought I'd say this and don't take it too much to heart,
but lay off the shift key, if you can do so without abandoning it entirely.

>-mercury  <[EMAIL PROTECTED]>

-- 
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
   :-: May faulty logic undermine your entire philosophy!

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


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