Cryptography-Digest Digest #853, Volume #11      Wed, 24 May 00 19:13:01 EDT

Contents:
  Re: how do you know your decyption worked? (Dan Day)
  Re: how do you know your decyption worked? (wtshaw)
  Re: ALIENS - RELIGION ("stephen pollard")
  Re: ideal safer style sboxes (lordcow77)
  Re: RSA/PK Question (DJohn37050)
  Re: ideal safer style sboxes (tomstd)
  Re: RSA/PK Question ([EMAIL PROTECTED])
  Re: RSA/PK Question ([EMAIL PROTECTED])
  Paper on Finite Automaton PKC ("Dr. Yongge Wang")
  Re: RSA/PK Question (tomstd)
  Re: RSA/PK Question (Mark Wooding)
  Re: safer style sboxes (Mark Wooding)
  Re: pentium timings ("Trevor L. Jackson, III")
  Re: Observation of Matsui's Sboxes (Mark Wooding)
  Re: HTML encryption (Arthur Dardia)

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

From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: how do you know your decyption worked?
Date: Wed, 24 May 2000 18:17:52 GMT

On Tue, 23 May 2000 09:16:58 +0200, Runu Knips <[EMAIL PROTECTED]>
wrote:
>A not much less secure way is to store a one way hash of the
>plaintext at the end or start of the plaintext.

All of the answers so far to "Carb Unit's" question assume
that he's asking how an encryption/decryption program can verify
that the user provided the correct key for decryption.

However, I don't think that's what he's actually asking.

Instead, I think he's asking how a cryptanalyst can tell when
he has correctly "broken" the encryption and recovered the
original plaintext, given that the "plaintext" may not be text,
or very "plain", and it may be difficult for the cryptanalyst to
distinguish the desired plaintext from the gibberish that
results from an improper decryption.


--
   "How strangely will the Tools of a Tyrant pervert the 
plain Meaning of Words!"
   --Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776

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

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: how do you know your decyption worked?
Date: Wed, 24 May 2000 12:09:07 -0600

In article <[EMAIL PROTECTED]>, Erich Schnoor
<[EMAIL PROTECTED]> wrote:

> Carb Unit schrieb:
> 
> > .............., and that there are thousands of such formats
> > in the world today, what do you do after you run your decryption
> > algorithm?  Test if it's a GIF?, no?, a ZIP?, no?, a WAV?, etc?
> >
> > Or is the assumption always that the material is plain text?
> >
> 
> In good programs the original file name is included into the encrypted
> Data. Then the decrypted file will get the same name ( .txt, .doc, .gif,
> 
> .exe, .pdf  etc.)
> 
> Best greetings
> Erich Schnoor

Good programs? Still better programs don't tip off the casual observer as
to any of the contents and the means by which they were encrypted. Such
things as the original file title are best encrypted as well, allowing for
an anonymous title for the encryotion, if you must keep it in a
file...which brings up another point, some ciphertext may be best handled
if not put in a file: <c><a>(v)[o]<l>  <m>(b)[n]<p><v>  (v)(t)<o><v>[l] 
[j]<h>[q](n)(n)  [a](v)(d)(j)[a]  (q)(v)[g]<x>(g)  <a>[y]<x>(g)<k>  <l>
-- 
Secrets that are told or available are not secrets any more, surely
not trade secrets.  Security of secrets is no dependant on someone 
else's stupidy, only in your making them available in any form.

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

From: "stephen pollard" <[EMAIL PROTECTED]>
Crossposted-To: alt.alien.research,alt.alien.visitors
Subject: Re: ALIENS - RELIGION
Date: Wed, 24 May 2000 20:51:11 +0100



--
=====================================================
Click here for Free Video!!
http://www.gohip.com/free_video/

Leo Sgouros <[EMAIL PROTECTED]> wrote in message
news:G%DV4.8850$[EMAIL PROTECTED]...
> You speak the truth about this Bible Code book.
> Can you tell him why?
> Its about how you can fudge codes out of alphabets with missing letters
when
> you make the right blocks out of them, and draw the right goofy lines.
>
> B:.B:.
>
>
> "it is finished"
>
>
> --
> "and the four had one likeness,and their
> appearance and their work was as it were
> a wheel in the middle of a wheel"
> www.mkshadows.net
> "E. L." <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> Jonny: You're referring to Ezekiel 2:12, 14-15.  No one knows what he
> claims he saw.  I would simply say that as in modern times, people are
> being picked up by tornadoes and being deposited a distance from where
> they were picked up.
>
> Regarding the book "The Bible Code," disabuse yourself from reading
> ANYTHING into it.  Do research here on the web and read all the prosaic
> explanations for why there is no such thing as a bible code or, as you
> say below, "...it gives you another perspective on the reasoning behind
> the existence of the book (the Bible)."  It doesn't do any of the sort.
> The only perspective you get is the author's.
> ------------------------------------------------------
> Group: alt.alien.research Date: Sat, May 20, 2000, 2:28am (EDT+5) From:
> [EMAIL PROTECTED] (Daryl Lloyd) Re: ALIENS - RELIGION
> Read Ezekiel again, and this time read it with an open mind, not with
> one enclosed by religious, mind-washing bullshit! Try telling me what he
> claims he saw, and his being carried of to somewhere (I can't remember
> right now, but believe me, I will find out again and tell you) were
> natural phenomena and not intervention by a more advanced intelligence,
> one with machines, not the ability to pick people up and carry them away
> with thought alone.
> And if you don't believe in extra-terrestrials, why do you feel the need
> to come here and start a load of shit about something completely
> irrelevant, i.e. MS versus Linux? What is the fucking point?
> One last thing, try and find a book entitled 'The Bible Code'. I'm not
> saying it's correct, all I'm saying is, it gives you another perspective
> on the reasoning behind the existence of the book (the Bible).
> If you want to start shit with me simply because I don't believe in your
> 'god', then go right ahead. But answer me two questions. Will you feel
> better because you have done? Will it actually improve your life at all?
> No matter what you do or say, I will not believe in any 'god' other than
> the universe as a whole.
> Boi-boi,
> Love,
> Jonny
> xxxxx
>
>
> At last there are people who do not believe in the religious clap trap
that
is appearing every day to try to explain natural occurrences
bye animal.
ps anybody who wants to can try to convince me that all "religions" are not
a fraud .



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

Subject: Re: ideal safer style sboxes
From: lordcow77 <[EMAIL PROTECTED]>
Date: Wed, 24 May 2000 12:54:11 -0700

Hello,

Replacing the s-boxes in SAFER will almost certainly make the
algorithm as a whole weaker, regardless of whether or not the
differential or linear properties of the new s-boxes are better
or not. The security of the algorithm depends crucially on the
fact that E(x)+E(y)=E(x+y). Refer to S. Vaudenay's _On the
security of SAFER and multipermutations_ for more information.

* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


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

From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: RSA/PK Question
Date: 24 May 2000 20:00:56 GMT

RSA public key with low exponent is a 2nd power function of key length,
doubling size means about 4 times as long.
RSA private key or public key with arbitrary exponent is a 3rd power function
of key length. Doubling size means about 8 times as long.
RSA key gen is a 4th power function of key length. Doubling size means about 16
times as long.
Don Johnson

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

Subject: Re: ideal safer style sboxes
From: tomstd <[EMAIL PROTECTED]>
Date: Wed, 24 May 2000 12:59:47 -0700

In article <[EMAIL PROTECTED]>,
lordcow77 <[EMAIL PROTECTED]> wrote:
>Hello,
>
>Replacing the s-boxes in SAFER will almost certainly make the
>algorithm as a whole weaker, regardless of whether or not the
>differential or linear properties of the new s-boxes are better
>or not. The security of the algorithm depends crucially on the
>fact that E(x)+E(y)=E(x+y). Refer to S. Vaudenay's _On the
>security of SAFER and multipermutations_ for more information.

Shame on me.  I have already read that paper too.

I stand corrected.

Tom


* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


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

From: [EMAIL PROTECTED]
Subject: Re: RSA/PK Question
Date: Wed, 24 May 2000 20:14:55 GMT

In article <8ggu8v$gjs$[EMAIL PROTECTED]>,
  Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <8gghmg$6ul$[EMAIL PROTECTED]>,
>   [EMAIL PROTECTED] wrote:
> > If Kp and Ks are the public and secret RSA Keys and if Ka is a
random
> > key of the same lenth:
> >
> > If Ka is XORed with Kp and Ks indpendently i.e.
> >
> > Kp`= Ka XOR Kp
> > Ks`= Ka XOR Ks
> >
> > Can one still encrypt with Kp`and decrept with Ks`using RSA ?
> >
> > My second question relates to long RSA keys...Is it reasonable to
> assume
> > that a 10000 bit RSA key will take 10 times as long to generate as a
> > 1000 bit RSA key.... Would appreciate some key generation
> timmings...for
> > long key pairs...
>
> Question 1:  Why on earth would you want a 10kbit RSA key? That's the
> first sign you don't know what you are doing.
>
Incorrect...have you ever heard of PGP CKT build....that uses RSA keys
>8k...I can assure you that it does not take 10**3 - 10**4 times more
then 1k PGP otherwise no one would use it...ok..I think I better ask the
author...Imad how long his key gen takes...
> Question 2:  Why would you assume it would take linearly more time?
> Cuz you don't know what you are talking about?

see above...

>
> I admit I am not the godsen of math here, but be realistic and just
ask
> how RSA keys are made.  Once you figure that out, you will see why
> 10kbit keys could take you a day or so to make (well it would take a
> long time to say the least).

Wrong...if ckt takes a day..no one will use it...
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: [EMAIL PROTECTED]
Subject: Re: RSA/PK Question
Date: Wed, 24 May 2000 20:18:20 GMT

In article <8gh4cr$lh7$[EMAIL PROTECTED]>,
  Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
>   [EMAIL PROTECTED] (Mark Wooding) wrote:
> > [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > > If Kp and Ks are the public and secret RSA Keys and if Ka is a
> random
> > > key of the same lenth:
> > >
> > > If Ka is XORed with Kp and Ks indpendently [...] Can one still
> encrypt
> > > with Kp`and decrept with Ks`using RSA ?
> >
> > No.  This will hardly ever work.
>
> Correct.
>
> > > My second question relates to long RSA keys...Is it reasonable to
> assume
> > > that a 10000 bit RSA key will take 10 times as long to generate as
a
> > > 1000 bit RSA key....
> >
> > No.  It'll take about 1000 times as long, I think.  Key generation
> times
> > increase with the cube of the key length.
>
> No.  The fourth power. Testing an individual candidate runs in time
> O( (log N)^3)  and one must test O(log N) candidates on average.
>

Bob..there is a CKT build of PGP which uses very long keys...>8k...and
it sure does not take 10**4 minutes...no one would use it...I will get
some timmings from the autor and get back to you..

P.S. Are you the Robert D. Silverman who published Parallel
implemntation of QS?

> --
> Bob Silverman
> "You can lead a horse's ass to knowledge, but you can't make him
think"
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: "Dr. Yongge Wang" <[EMAIL PROTECTED]>
Subject: Paper on Finite Automaton PKC
Date: 24 May 2000 21:10:30 GMT

OK, I found the reference, check the following paper 
for PKC based on finite automaton:

\bibitem{tao}
R.~Tao and  S.~Chen. On finite automaton public-key cryptosystem.
{\it Theoretical Computer Science}, (226)1-2:143--172, 1999.
                                                                


-- 

======================================================.
Yongge Wang                                           |
Some Crypto Company                                   | 
My employer takes no responsibility on                | 
any of my post here                                   |
Canada                                                |
http://cs.uwm.edu/~wang                               |
======================================================'


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

Subject: Re: RSA/PK Question
From: tomstd <[EMAIL PROTECTED]>
Date: Wed, 24 May 2000 14:30:11 -0700

In article <8ghd7g$sgs$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
>In article <8ggu8v$gjs$[EMAIL PROTECTED]>,
>  Tom St Denis <[EMAIL PROTECTED]> wrote:
>> In article <8gghmg$6ul$[EMAIL PROTECTED]>,
>>   [EMAIL PROTECTED] wrote:
>> > If Kp and Ks are the public and secret RSA Keys and if Ka
is a
>random
>> > key of the same lenth:
>> >
>> > If Ka is XORed with Kp and Ks indpendently i.e.
>> >
>> > Kp`= Ka XOR Kp
>> > Ks`= Ka XOR Ks
>> >
>> > Can one still encrypt with Kp`and decrept with Ks`using
RSA ?
>> >
>> > My second question relates to long RSA keys...Is it
reasonable to
>> assume
>> > that a 10000 bit RSA key will take 10 times as long to
generate as a
>> > 1000 bit RSA key.... Would appreciate some key generation
>> timmings...for
>> > long key pairs...
>>
>> Question 1:  Why on earth would you want a 10kbit RSA key?
That's the
>> first sign you don't know what you are doing.
>>
>Incorrect...have you ever heard of PGP CKT build....that uses
RSA keys
>>8k...I can assure you that it does not take 10**3 - 10**4
times more
>then 1k PGP otherwise no one would use it...ok..I think I
better ask the
>author...Imad how long his key gen takes...


No one who knows what they are doing will use 8kbit RSA keys
saying "they must be more secure then 2kbit keys".  If we
*can't* factor 2kbit keys, then it doesn't matter right?

>> Question 2:  Why would you assume it would take linearly more
time?
>> Cuz you don't know what you are talking about?
>
>see above...
>
>>
>> I admit I am not the godsen of math here, but be realistic
and just
>ask
>> how RSA keys are made.  Once you figure that out, you will
see why
>> 10kbit keys could take you a day or so to make (well it would
take a
>> long time to say the least).
>
>Wrong...if ckt takes a day..no one will use it...

Without a super-well tuned PK library 10kbit keys could be way
too slow.  Even with well tuned code 10kbit keys are too slow
anyways.

Tom


* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


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

From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: RSA/PK Question
Date: 24 May 2000 22:21:45 GMT

Bob Silverman <[EMAIL PROTECTED]> wrote:
> No.  The fourth power. Testing an individual candidate runs in time
> O( (log N)^3)  and one must test O(log N) candidates on average.

Ahh.  That explains why my empirical testing and memory were
contradicting each other. ;-)  I stand corrected.

-- [mdw]

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

From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: safer style sboxes
Date: 24 May 2000 22:25:06 GMT

Tom St Denis <[EMAIL PROTECTED]> wrote:

> How exactly do you calculate the DP given a probability 'p' and 'n'
> active sboxes?

If p_i is the probability of the characteristic you want through S-box
i, then the total probablity is
  _____
   | |
   | |  p_i
    i

assuming they're independent, which would be probably reasonable.

-- [mdw]

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

Date: Wed, 24 May 2000 18:56:51 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: pentium timings



Jerry Coffin wrote:

> In article <3ajW4.3929$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
> > I think the boys are being overly pedantic.  For most applications the
> > timing that is important is the timing you measure under real operating
> > system conditions.  What the heck difference does it make if you wind up
> > measuring some O/S overhead.  That overhead will be there in the real
> > application so you might as well take it into consideration.
>
> I'm NOT talking about measuring OS overhead.  I'm talking about the
> processor executing instructions out of order, and (in particular)
> executing the timing instructions out of order.  Assume you wanted to
> time the execution of a single NOP:
>
>         rdtsc
>         mov edi, edx
>         mov esi, eax
>         nop
>         rdtsc
>
> the second RDTSC could actually be executed _before_ the first, and
> it could end up indicating that that NOP (and the two mov's) took a
> _negative_ amount of time.  It could also execute the NOP before any
> of the other instructions in the sequence, so the code wouldn't time
> the execution of the NOP at all.  Other sequences are possible as
> well; the result is that there's NO relationship between the
> difference between the readings from the TSC and the actual amount of
> time taken by the instructions involved.

This appears to be a violation of the single constraint you mentioned earlier in
this thread.  If your description is true (and I have no reason to believe that
it is not), then the more recent implementations of RDTSC are flawed in that they
should have the moral equivalent of an implicit "sequence point".  Out-of-order
execution, which is usually accompanied by speculative execution, can give truly
ridiculous result such as both paths of a branch/merge producing the same timing
result.

Eliminating OS overhead is a _completely_ separate issue.  It's often

> desirable to do so, but it's NOT what I was talking about at all.
>
> > Taking averages of the results of GetTickCount() before and after execution
> > of a subroutine ought to be good enough for about 99.99999% of the
> > applications, provided you code takes longer to run than the ms resolution
> > of this function.
>
> Under normal circumstances its real resolution is ~55 ms (for
> Lose95/98) or 10 ms (for NT/2000).  That, of course, is a major
> problem: it's difficult to find ANY cipher that has (for example) a
> round function that takes anywhere close to that long.
>
> Of course, you can do a LOT better: if you have GetTickCount
> available, you probably also have QueryPerformanceCounter and
> QueryPerformanceFrequency available, and they're _much_ more precise
> (normally around 4 orders of magnitude more precise).
>
> Of course, there are lots of other issues here as well -- just for an
> obvious example, GetTickCount doesn't work AT ALL under Linux...
>
> In the end, it comes down to this: if you're going to go to the
> trouble of measuring things in clock ticks to start with, then it's
> FAR more sensible to do it so the results are meaningful in the same
> range.  As-is, Tom's code loses close to 2 orders of magnitude
> compared to what properly written code of the same general type can
> do.  IMO, that's a pretty lousy way of doing things.
>
> > If it does not, then just run it inline several times to
> > make it do so.
>
> Sure...and instead of results that might be a little wrong, typically
> produce results that are certain to be _way_ wrong!  Worse yet, put
> yourself through extra work to collect results that won't help you
> anyway.
>
> Don't get me wrong: collecting results on a larger piece of the
> system can be useful and meaningful, and when you're doing so,
> something higher-level than RDTSC can be useful.  GetTickCount is
> rarely the best alternative when it happens, but various other things
> can be useful anyway.  The question at the moment is whether the code
> Tom presented was useful in the basic range of things it attempted to
> cover -- a microscopic-level time attempting to collect data at the
> level of individual clock cycles.  IMO, the answer to that question
> is a resounding NO!  Likewise, if you're trying to optimize something
> like a round function, it's going to be a LOT more difficult to get
> useful results from something like GetTickCount than from a decent
> timer at the clock-cycle level.

How do you feel about the approach to timing suggested by Kernigan and Pike?
They advocated timing elementary functions with many (1e6+) iterations.


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

From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Observation of Matsui's Sboxes
Date: 24 May 2000 22:40:58 GMT

tomstd <[EMAIL PROTECTED]> wrote:

> If the A() function you sent is the sbox, then it's flawed, no
> matter what transform you do before/after.

No.  The S-box is S(x) = A(I(x)).  It's the composition of both
operations.

Was I really that unclear?

-- [mdw]

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

From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: HTML encryption
Date: Wed, 24 May 2000 18:50:36 -0400

DigiboyCiPHER wrote:

> Is there any easy way to encrypt HTML source but retain use amongst
> non-javascript browsers?
>
> --
> ------
> Marcus
> ------
> www.cybergoth.cjb.net
> Techno gothic cyberculture
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

That should be impossible.


--
Arthur Dardia      Wayne Hills High School      [EMAIL PROTECTED]
 PGP 6.5.1 Public Key    http://www.webspan.net/~ahdiii/ahdiii.asc



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


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