Cryptography-Digest Digest #797, Volume #9       Tue, 29 Jun 99 06:13:03 EDT

Contents:
  Re: Why mirrors invert left-to-right (was: Kryptos article) (Y. Alien Mork)
  Re: one time pad ("Douglas A. Gwyn")
  Re: one time pad ("Douglas A. Gwyn")
  Re: Why mirrors invert left-to-right (was: Kryptos article) ("Douglas A. Gwyn")
  Re: Why mirrors invert left-to-right (was: Kryptos article) (Ed Yang)
  Project "Infinity" - replace 1 (one) with infinity ("Markku 'Make' J. Saarelainen")
  Re: one time pad (David A Molnar)
  Re: Can Anyone Help Me Crack A Simple Code? (Jerry Coffin)
  Re: one time pad (Greg Ofiesh)
  Re: The One-Time Pad Paradox (wtshaw)
  Re: Quasigroup engryption (Boris Kazak)
  Re: Why mirrors invert left-to-right (was: Kryptos article) ("Douglas A. Gwyn")
  Re: Why mirrors invert left-to-right (was: Kryptos article) (Jim Gillogly)
  Re: Secure link over Inet if ISP is compromized. ("Jean Marc Dieu")
  Secure link over Inet if ISP is compromized. ("Gene Sokolov")
  Re: Secure link over Inet if ISP is compromized. ("Gene Sokolov")
  Re: Tough crypt question: how to break AT&T's monopoly??? (Bill Unruh)
  Re: Question on LIBDES ("Marc Hoeppner")
  How do you make RSA symmetrical? (Gilad Maayan)

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

From: [EMAIL PROTECTED] (Y. Alien Mork)
Subject: Re: Why mirrors invert left-to-right (was: Kryptos article)
Date: Tue, 29 Jun 1999 03:39:55 GMT

The guy that posts the sci.crypt FAQ is gonna kick your butt!

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Tue, 29 Jun 1999 03:28:16 GMT

[EMAIL PROTECTED] wrote:
> Douglas A. Gwyn wrote:
> > [EMAIL PROTECTED] wrote:
> > > So, given that it is and will remain impossible to prove a negative,
> > > that there are no weaknesses in a key generator, we can conclude that
> > > there cannot be perfect cipher systems.  LIke Godels proof of the
> > > incompleteness of mathematical logics, we can now take this lack of
> > > provability for granted.
> > No, you might however conclude that that one line of argumentation
> > is incapable of achieving a proof.
> Are you implying that some other approach might yeild a rigorous proof
> of key quality -- i.e., randomness?

I wasn't talking about "key quality" since that's not what the words
to which I was responding said.  However, we do know how to build
genuinely-random bit-sequence generators, and there are several
available commercially, usually as one component of a crypto chip.

You don't need a random key generator for provably secure encryption;
in fact, that is undesirable in most cases -- since random key cannot
be reliably generated synchronously at both origin and destination,
it would have to be transferred from one to the other (or from a
central key generation facility to both), thus you run into the
standard OTP key management problem.  For most purposes, it is much
better to use a moderate key size along with an encryption algorithm
against which every known attack methodology can be shown to fare not
appreciably better than exhaustive search of the key space.  (By
"known" I of course mean "known to the experts".)  That has been the
general procedure for official US cryptosystems for many decades, and
it has worked extremely well in practice.

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Tue, 29 Jun 1999 03:33:29 GMT

William Tanksley wrote:
> 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.

To the contrary, the quantum theory, with its inherent randomness,
is the best-established physical theory we have ever had.  The
Lamb shift provides an example of its excellent predictive value.

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Why mirrors invert left-to-right (was: Kryptos article)
Date: Tue, 29 Jun 1999 03:38:51 GMT

"S.T.L." wrote:
> Mirrors invert FRONT-TO-BACK. When we imagine ourselves standing side-by-side
> our mirror image, making our Fronts identical, then another direction MUST be
> reversed. We like to think that L-R is reversed because we are bilaterally
> symmetric. This is, because as someone else said, our left side resembles our
> right side much more than our head resembles our feet. If, however, we were
> simply C F Cl Br I atoms (if those exist), then we would have no problem - we
> would understand the concept of chirality and not be confused by the front-back
> switch.

The trick is that, to compare the object and its image, we map one
onto the other.  For almost everyone, that mapping consists of
treating the image as a real image (rather than virtual) and
rotating the object *about a vertical axis*, then translating it
onto the (real) image for comparison.  The left-to-right reversal
is a property of the specific mapping (rotation) we use.

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

From: Ed Yang <[EMAIL PROTECTED]>
Subject: Re: Why mirrors invert left-to-right (was: Kryptos article)
Date: Mon, 28 Jun 1999 20:51:38 -1000

Mirrors do not invert. What happens is a person turns around
a vertical axis to look at the real face, causing the person
to misinterpret the reflection. If you turn on a horizontal
axis, turning upside down, the mirror image would cause one
to misinterpret the mirror image as inverting up-to-down.


Nicol So wrote:
> 
> Lincoln Yeoh wrote:
> >
> > On Sat, 26 Jun 1999 03:49:50 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> > wrote:
> >
> > >Um, Jim, mirrors don't reverse in any particular direction.
> > >Martin Gardner had a discussion of this in one of his books:
> > >Why is your image in a flat mirror reversed left-to-right,
> > >not top-to-bottom?
> >
> > Maybe it because your right hand looks like your left hand and your head
> > doesn't look like your feet?
> >
> > They just mirror stuff, that's all, just like shadows in some ways.
> 
> It's deeper than that.  Without spoiling the fun, I can tell you that
> it's not an optics problem.  It's not even a physics problem--it's a
> philosophical one.
> 
> Consider this thought experiment: you stand in front of a mirror and
> take a portrait of yourself with a Polaroid camera.  The picture
> basically captures what you see in the mirror.  Then a friend of yours
> moves into the position where the mirror was, and takes another picture
> of you with another Polaroid camera.
> 
> Now compare the two pictures, they are (basically) inverted images of
> each other *along the vertical axis*.  Why does the inversion take place
> along one of infinitely many possible axes?  Einstein said there's no
> preferred frame of reference in nature. Why does the inversion
> "phenomenon" take place along a particular axis but not others?
> 
> Answering these questions is the real point of the puzzle.
> 
> Have fun.
> Nicol

-- 
Oxygen : Love It Or Leave It !

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

From: "Markku 'Make' J. Saarelainen" <[EMAIL PROTECTED]>
Subject: Project "Infinity" - replace 1 (one) with infinity
Date: Mon, 28 Jun 1999 23:08:11 +0000


Just wondering, if anybody is working on any project to replace 1 (one)
with infinity ....



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

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: 29 Jun 1999 04:14:37 GMT

Greg Ofiesh <[EMAIL PROTECTED]> wrote:


> 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 flip side of this is that tomorrow someone may prove a 
lower bound on factoring, or discrete log, or whatever. 
Then we would have another system with provable security,
although in a different sense than the OTP - it would
be secure in whatever setting where that lower bound 
is so large that no adversary can reasonably acheive it.

This is not to say that such a breakthrough will be public,
or even that it will happen soon. It's just a bit of
optimism. 

-David Molnar




> 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] (Jerry Coffin)
Subject: Re: Can Anyone Help Me Crack A Simple Code?
Date: Mon, 28 Jun 1999 23:22:00 -0600

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
says...
> 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.

With this information, we could specify LOTS of different things that 
meet the specification.  The most obvious would be to multiply the 
input by 0.  In this case, the output is 0 for all the inputs you 
provided, as well as for any other number.  Another possibility would 
be to multiply the number by its own inverse, which always produces 1 
as the output.

As you can quickly surmise, nearly the only limit here is your 
imagination.  If you could guarantee that these inputs produced a 
given output, and that all others produced some other output, it might 
be possible to start narrowing things down a little, but as-is, 
there's a (nearly?) infinite set of possibilities, and no particular 
reason to think one is better than another.

> I Believe the Algorithm is a very Simple Routine.

That would certainly include multiplication by 0.
 
> Does Anyone have any InSight on a Good Way to Go About Solving this
> Riddle?

yEs -- staRt by leArnIng whEn to (and WHeN noT to) uSe the shIft keY, 
anD tHen aSK thE RIddlEr TO spECiFy thE pRoBlem cOmPLEteLy enOugH For 
tHe QuEstiOn to MEan soMEThinG.

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

From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Tue, 29 Jun 1999 04:41:24 GMT


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


It is strange that anyone has to point this out.  But I would like to
add one thing that would drive home my point along this line and that
is there may only be one case - my case - for which OTP is suitable.
That does not invalidate my original post in the least.


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

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

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: The One-Time Pad Paradox
Date: Tue, 29 Jun 1999 00:28:01 -0600

In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:

> (1) The chance of an ideal OTP producing a string of all 0's of
> any meaningful size is extremely negligibly small. (2) The chance
> of one being able to create an ideal OTP in this real world is
> also extremely negligibly small. (I personally would consider both
> to be identically zero).
> 

There is a bigger chance that a bug in a program or OS might cause a
malfunction, or the operator messed up in an unpredictable way, causing
faulty encryption.  Sufficient design concepts are functionally good only
if implemented adequately, and the tendency is for rather poor mechanisms
for carrying out ideas in the real computer world.
-- 
It's always possible that a politician is acting out of principles.
--Michael Kinsley of Slate.com

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

From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: Quasigroup engryption
Date: Mon, 28 Jun 1999 22:50:14 -0400
Reply-To: [EMAIL PROTECTED]

[EMAIL PROTECTED] wrote:
> 
> 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.
===================
   This is essentially Vigenere cipher with autokeying. The n-th 
ciphertext letter determines which alphabet will be used for (n+1)-st
substitution. As the authors themselves admit, all the matrix of 
alphabets is easily reconstructable via a known-plaintext attack.
Double or triple superencryption with different matrices can help, 
but nobody knows by how much.
   The mathematical notation just serves to make the idea look 
presentable and serious. A very good stuff for a dissertation, 
but please look elsewhere for security.

    Best wishes                   BNK

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Why mirrors invert left-to-right (was: Kryptos article)
Date: Tue, 29 Jun 1999 05:58:34 GMT

Ed Yang wrote:
> Mirrors do not invert. What happens is a person turns around
> a vertical axis to look at the real face, causing the person
> to misinterpret the reflection. If you turn on a horizontal
> axis, turning upside down, the mirror image would cause one
> to misinterpret the mirror image as inverting up-to-down.

And if you change the mapping to rotation about a 45-degree
axis, mirrors appear to rotate objects by 90 degrees as well
as changing their "handedness".

Back to the original thing about reflecting the wrong side of
Kryptos in a pool:  Yes, it makes the letters appear normal.

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

From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Why mirrors invert left-to-right (was: Kryptos article)
Date: Mon, 28 Jun 1999 23:36:12 -0700

Douglas A. Gwyn wrote:
> Back to the original thing about reflecting the wrong side of
> Kryptos in a pool:  Yes, it makes the letters appear normal.

Not quite normal -- they'll appear upside down.  Note that on
the wrong side the rows start from the right, and they'll still
be on the right in the reflection.  If you freeze the pond and
stand it up behind you and turn around and look at it, the letters
will look normal.  Mirrors are trickier than they look.

However, I read some specs from Sanborn, and it turns out the
pool is supposed to be agitated, which would presumably make it
difficult to extract a coherent reflection from the sculpture.
Sounds symbolic of decryption, somehow...

-- 
        Jim Gillogly
        Highday, 6 Afterlithe S.R. 1999, 06:30
        12.19.6.5.14, 5 Ix 2 Tzec, Sixth Lord of Night

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

From: "Jean Marc Dieu" <[EMAIL PROTECTED]>
Subject: Re: Secure link over Inet if ISP is compromized.
Date: Tue, 29 Jun 1999 08:43:06 +0200

I guess this is the aim of public key cryptography, if we consider ISP-A and
ISP-B as "dangerous" as the internet. Anyway, ISP-A and B ARE PART of the
internet.

JM


Gene Sokolov a écrit dans le message <7l9p68$o09$[EMAIL PROTECTED]>...
>Let's assume that Alice and Bob both have dial-up Internet accounts. They
>want to establish a secure channel.
>
>Alice <--> ISP-A <--> Internet <--> ISP-B <--> Bob
>
>Do I understand this correctly, assuming that *all* their data is passed
>through ISP-A and ISP-B, there is absolutely no way to ensure secure
>communication between them if either of the ISP is controlled by the
>adversary? Alice and Bob would need another trusted channel to exchange
data
>before secure Internet link can be established.
>
>Gene Sokolov.
>
>



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

From: "Gene Sokolov" <[EMAIL PROTECTED]>
Subject: Secure link over Inet if ISP is compromized.
Date: Tue, 29 Jun 1999 10:26:43 +0400

Let's assume that Alice and Bob both have dial-up Internet accounts. They
want to establish a secure channel.

Alice <--> ISP-A <--> Internet <--> ISP-B <--> Bob

Do I understand this correctly, assuming that *all* their data is passed
through ISP-A and ISP-B, there is absolutely no way to ensure secure
communication between them if either of the ISP is controlled by the
adversary? Alice and Bob would need another trusted channel to exchange data
before secure Internet link can be established.

Gene Sokolov.



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

From: "Gene Sokolov" <[EMAIL PROTECTED]>
Subject: Re: Secure link over Inet if ISP is compromized.
Date: Tue, 29 Jun 1999 12:09:41 +0400


Jean Marc Dieu <[EMAIL PROTECTED]> wrote in message
news:7l9pq9$e54$[EMAIL PROTECTED]...
> I guess this is the aim of public key cryptography, if we consider ISP-A
and
> ISP-B as "dangerous" as the internet.

How can public key cryptography be a solution here? Please read the original
post again - *all* data is exchanged over what is assumed a compromized
channel. If Alice sends Bob her public key or starts DH key exchange
procedure, how does Bob know the data comes from Alice and not her
compromized ISP?





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

From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Tough crypt question: how to break AT&T's monopoly???
Date: 29 Jun 1999 08:10:52 GMT

In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (JPeschel) 
writes:

]>[EMAIL PROTECTED] (Bill Unruh) writes:


]>It would be trivial to write such a program. It would also, under the US
]>regualtions be illegal to send such an email outside the USA without a
]>license.

]Bill where in EAR is the tranmission of a message that can be decrypted
]restricted?  A one-way communication by a self-extracting encrypted file is not

The message is not restricted. The decryption program however is
restricted. Ie, as long as you did not send the self extracting program
along with the encrypted file, you would be OK. However that self
extracting program would probably get you into hot water.


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

From: "Marc Hoeppner" <*spam*[EMAIL PROTECTED]>
Subject: Re: Question on LIBDES
Date: Tue, 29 Jun 1999 11:00:06 +0200

ok, found it. I overlooked the reference in one of the macros...

Marc Hoeppner <*spam*[EMAIL PROTECTED]> wrote in message
news:7l8pk2$6v4$[EMAIL PROTECTED]...
> Hi,
>
> I am trying to understand the libdes version 4.01 of Eric Young, but there
> is something that I must have overlooked in the des_enc.c. The final inner
> function des_enc doesn't seem to use the key schedule at all which is
> abviously nonsense. Could someone please enlighten me?
>
> void des_encrypt(data, ks, encrypt)
> DES_LONG *data;
> des_key_schedule ks;
> int encrypt;
>  {
>  register DES_LONG l,r,t,u;
> #ifdef DES_PTR
>  register unsigned char *des_SP=(unsigned char *)des_SPtrans;
> #endif
> #ifndef DES_UNROLL
>  register int i;
> #endif
>  register DES_LONG *s;
>
>  r=data[0];
>  l=data[1];
>
>  IP(r,l);
>  /* Things have been modified so that the initial rotate is
>   * done outside the loop.  This required the
>   * des_SPtrans values in sp.h to be rotated 1 bit to the right.
>   * One perl script later and things have a 5% speed up on a sparc2.
>   * Thanks to Richard Outerbridge <[EMAIL PROTECTED]>
>   * for pointing this out. */
>  /* clear the top bits on machines with 8byte longs */
>  /* shift left by 2 */
>  r=ROTATE(r,29)&0xffffffffL;
>  l=ROTATE(l,29)&0xffffffffL;
>
>  s=(DES_LONG *)ks;
>  /* I don't know if it is worth the effort of loop unrolling the
>   * inner loop */
>  if (encrypt)
>   {
> #ifdef DES_UNROLL
>   D_ENCRYPT(l,r, 0); /*  1 */
>   D_ENCRYPT(r,l, 2); /*  2 */
>   D_ENCRYPT(l,r, 4); /*  3 */
>   D_ENCRYPT(r,l, 6); /*  4 */
>   D_ENCRYPT(l,r, 8); /*  5 */
>   D_ENCRYPT(r,l,10); /*  6 */
>   D_ENCRYPT(l,r,12); /*  7 */
>   D_ENCRYPT(r,l,14); /*  8 */
>   D_ENCRYPT(l,r,16); /*  9 */
>   D_ENCRYPT(r,l,18); /*  10 */
>   D_ENCRYPT(l,r,20); /*  11 */
>   D_ENCRYPT(r,l,22); /*  12 */
>   D_ENCRYPT(l,r,24); /*  13 */
>   D_ENCRYPT(r,l,26); /*  14 */
>   D_ENCRYPT(l,r,28); /*  15 */
>   D_ENCRYPT(r,l,30); /*  16 */
> #else
>   for (i=0; i<32; i+=8)
>    {
>    D_ENCRYPT(l,r,i+0); /*  1 */
>    D_ENCRYPT(r,l,i+2); /*  2 */
>    D_ENCRYPT(l,r,i+4); /*  3 */
>    D_ENCRYPT(r,l,i+6); /*  4 */
>    }
> #endif
>   }
>  else
>   {
> #ifdef DES_UNROLL
>   D_ENCRYPT(l,r,30); /* 16 */
>   D_ENCRYPT(r,l,28); /* 15 */
>   D_ENCRYPT(l,r,26); /* 14 */
>   D_ENCRYPT(r,l,24); /* 13 */
>   D_ENCRYPT(l,r,22); /* 12 */
>   D_ENCRYPT(r,l,20); /* 11 */
>   D_ENCRYPT(l,r,18); /* 10 */
>   D_ENCRYPT(r,l,16); /*  9 */
>   D_ENCRYPT(l,r,14); /*  8 */
>   D_ENCRYPT(r,l,12); /*  7 */
>   D_ENCRYPT(l,r,10); /*  6 */
>   D_ENCRYPT(r,l, 8); /*  5 */
>   D_ENCRYPT(l,r, 6); /*  4 */
>   D_ENCRYPT(r,l, 4); /*  3 */
>   D_ENCRYPT(l,r, 2); /*  2 */
>   D_ENCRYPT(r,l, 0); /*  1 */
> #else
>   for (i=30; i>0; i-=8)
>    {
>    D_ENCRYPT(l,r,i-0); /* 16 */
>    D_ENCRYPT(r,l,i-2); /* 15 */
>    D_ENCRYPT(l,r,i-4); /* 14 */
>    D_ENCRYPT(r,l,i-6); /* 13 */
>    }
> #endif
>   }
>
>  /* rotate and clear the top bits on machines with 8byte longs */
>  l=ROTATE(l,3)&0xffffffffL;
>  r=ROTATE(r,3)&0xffffffffL;
>
>  FP(r,l);
>  data[0]=l;
>  data[1]=r;
>  l=r=t=u=0;
>  }
>
>
> Marc
> [EMAIL PROTECTED]
>
>
>



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

From: [EMAIL PROTECTED] (Gilad Maayan)
Subject: How do you make RSA symmetrical?
Date: Tue, 29 Jun 1999 09:23:27 GMT

I'll probably be hammered for my stupidity, as in previous posts, but
I'm asking it anyway. Is there anyway to make RSA symmetrical? In
other words, to take, say, a 64-bit message, encrypt it with a
1024-bit key and get a 64-bit cyphertext, and then decrypt that, and
get back to your original 64 bits? I'm aware of the small keyspace
this would result in (you'd only have to check 2^64 possible
cyphertexts, etc.), but in my case, the ambiguity factor would make up
for this shortcoming.

I was thinking of something along the lines of this:

encryption:
M=C^d MOD (n+x)
where x is the relationship between plaintext size and modulus size
(in our case 16)

decryption:
C=(M^e * x) MOD (n+x)

Or something. As you can see I'm not particularly versed in
mathematics, but I think you get my drift. If anyone knows how to make
this work, I'd like to hear it.

Thanks,
Gilad Maayan

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


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