Cryptography-Digest Digest #15, Volume #10        Sun, 8 Aug 99 11:13:03 EDT

Contents:
  Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . . (Guenther Brunthaler)
  Re: What is "the best" file cryptography program out there? (Guenther Brunthaler)
  Re: CIA KRYPTOS ENIGMA ("Douglas A. Gwyn")
  Re: Scott Ciphers ([EMAIL PROTECTED])
  Re: What is "the best" file cryptography program out there? ([EMAIL PROTECTED])
  Re: What is "the best" file cryptography program out there? ([EMAIL PROTECTED])
  Re: Scott Ciphers (SCOTT19U.ZIP_GUY)
  Re: What is "the best" file cryptography program out there? (SCOTT19U.ZIP_GUY)
  Re: : I AM CAVING IN TO JA... (SCOTT19U.ZIP_GUY)
  Re: challenge/competition revisited ([EMAIL PROTECTED])
  Re: challenges / competitions??? ([EMAIL PROTECTED])
  Re: Download virtually unbreakable encryption programme (Wincrypt IDEA) 
([EMAIL PROTECTED])
  Re: key lengths ([EMAIL PROTECTED])

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

From: [EMAIL PROTECTED] (Guenther Brunthaler)
Crossposted-To: comp.lang.c++
Subject: Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . .
Date: Sun, 08 Aug 1999 09:55:57 GMT

On 7 Aug 1999 18:41:27 GMT, [EMAIL PROTECTED] () wrote:

>     Why does Microsoft ABSOLUTELY REQUIRE me to install and use their
>Internet Explorer (IE) before I can even install their Visual C++ compiler?  

Haven't you have heard of all those rumours about the various built-in
backdoors of IE?

If those rumours were true, then the reason for such a requirement is
straightforward: In order for MS to be able to steal your sources and
personal data anytime they would like to, your have to install IE in
order to enable them to do so.

I do however not say that those rumours may be true - they are just
that: rumours.

However, it certainly would not be hard for MS to include such
backdoors into IE, especially with regard to the current MS vs. the
government lawsuit: MS could enable certain secret services to access
the built-in IE backdoors, if the government agrees not to sentence MS
in turn (or at least not in an extent that was too painful for MS).

But those are also just rumours, of course.

Although all of them could easily be true from a technical viewpoint.

But the basic question is: How much do YOU trust MS?


Greetings,

Guenther
--
Note: the 'From'-address shown in the header is an Anti-Spam
fake-address. Please remove 'nospam.' from the address in order
to get my real email address.

In order to get my public RSA PGP-key, send mail with blank body
to: [EMAIL PROTECTED]
Subject: get 0x2D2F0683

Key ID: 2D2F0683, 1024 bit, created 1993/02/05
Fingerprint:  11 71 47 2F AF 2F CD F4  E6 78 D5 E5 3E DD 07 B5 

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

From: [EMAIL PROTECTED] (Guenther Brunthaler)
Subject: Re: What is "the best" file cryptography program out there?
Date: Sun, 08 Aug 1999 09:55:57 GMT

On Thu, 05 Aug 1999 00:52:07 GMT, Bob Silverman <[EMAIL PROTECTED]> wrote:

>Anyone who thinks that even 2048 bits are needed is clearly
>clueless about the subject.

Due to my knowlege it has been stated that an RSA key with 3100 may
require approximately the same effort to be broken by brute force as a
128 bit IDEA session key.

That means, in case IDEA session keys are used, 3100 bit RSA keys
would provide the optimum key length in PGP.

Longer RSA keys cannot increase the security for a single message,
because otherwise cracking the session key would be easier (which is
enough to decode the message).

In practice, however, longer RSA keys are advantageous, because
breaking a session key only helps one decode a single message, while
breaking the RSA key will enable the attacker to decode ALL messages
that have been encrypted by that key.


Greetings,

Guenther
--
Note: the 'From'-address shown in the header is an Anti-Spam
fake-address. Please remove 'nospam.' from the address in order
to get my real email address.

In order to get my public RSA PGP-key, send mail with blank body
to: [EMAIL PROTECTED]
Subject: get 0x2D2F0683

Key ID: 2D2F0683, 1024 bit, created 1993/02/05
Fingerprint:  11 71 47 2F AF 2F CD F4  E6 78 D5 E5 3E DD 07 B5 

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: CIA KRYPTOS ENIGMA
Date: Sun, 08 Aug 1999 03:50:03 GMT

collomb wrote:
> The CIA has been informed directly and indirectly at each step of
> that discovery and, curiously,  kept mute.

Out of charity to the clueless, no doubt.

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

From: [EMAIL PROTECTED]
Subject: Re: Scott Ciphers
Date: Sun, 08 Aug 1999 12:20:19 GMT

In article <7oj2lo$19li$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <7oitqi$vo3$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> >After finding a description of David Scott's scottNu ciphers, I
decided
> >to take a look.  Here's the exact link for anyone that want's to look
> >and see what I'm referring to.
> >
> >http://members.xoom.com/_XOOM/ecil/page2.htm
> >
> >Here are my observations of the algorithm, though I have made no
formal
> >analysis.
> >1. The algorithm works on the entire file at once.  Hope your not
> >encrypting large files.  This is potentially very memory intensive,
> >though the structure seems very well suited for smaller files.
> >
> >2. Encryption is based on a simple equation:
> >      C[n] = S[(C[n-1] XOR P[n]) + P[n-1]] // encryption
> >      P[n] = C[n-1] XOR (SI[c[n]] - P[n+1]) // decryption
> >   where C[i] is the ciphertext, P[i] is the plaintext, and S[i] and
> >SI[i] are the s-box's that is generated.  SI[i] is the inverse of
S[i].
> > Personally, I think this is very nice.  The problem is creating
> >inverses of S-boxes.
>
>   Actually there is no problem calulating the inverse S box.
>
> >
> >3. During the S-box generation, a table consisting of the values 0,
1,
> >....FFFF is created.  Now, I quote "Each of these values will be
selected
> >only once by the algorithm."  If David Scott's "assistant" is talking
> >about the key generation algorithm, then he is very wrong.  Later on
in
> >the descrption, values in this array are being replaced, but never
> >referenced.
> >
> >4. Despite the claims, it appears that values in the S-box can very
well
> >be repeated.
>
>   Obviously you have not looked at the code. Ritter has and a few
others
> but when the reverse (inverse) S box is being built I also do a check
to
> test for a single cycle so no entries are repeated
>
I took a quick look and found your source code to be quite confusing.
Anyway, I guess this means that your "assistant" needs to fix his
description.  There was no mention of any tests in that section.
> >
> >5. Another thing I noticed is that is appears that values can be
> >overwritten.
> >
>
>   A german found a mode that I did not exercise where it is possible
> that an over write could occur especially if one goes to another
machine
> and tries it. I have found a way to get this to occur but it does not
occur
> in the normal mode. There is a easy fix in C that I post a while back
> and will be in the next release of soure code it was a very small fix.
> I tested the main contest solution before and after the fix and it
made no
> difference.
>
I noticed I forgot to mention that the overwriting can occur in the
table setup.  That's what you were talking about, correct?

> >6. As for the S-box, it is not stated how it is initialized before
being
> >changed.  If it is not initialized, then S-box[j-1] will be defferent
> >every time it's run.  If it's initialized with all 0's, then S-Box[0]
> >and List[0] are constantly overwritten.
>
>    Well you can run the program and see this does not happen.
>
> >
> >What do I think?  I think the concept is excellent.  If the generated
> >S-box is strong enough, it's a great algorithm!  However, unless this
> >algorithm description is very screwed up, the s-box generation
algorithm
> >needs to be changed.
>
>   The S box can be any single cycle. And the single cycle property
> is checked for when it is built.
>
> >
> >Anyway, that's what I came up with.  Enjoy!
> >
> >Casey
> >
> >
> >Sent via Deja.com http://www.deja.com/
> >Share what you know. Learn what you don't.
>
> 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
>


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

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

From: [EMAIL PROTECTED]
Subject: Re: What is "the best" file cryptography program out there?
Date: Sun, 08 Aug 1999 13:02:38 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (Jerry Coffin) wrote:
> The extremely expensive machines in the single digit GHz range that
> won't make it to the public happened years ago.  As it happens, I
live
> in Colorado Springs, the home of Cray Computer, Inc., before Seymour
> got killed.  I was lucky enough to get to go see one of the (three)
> Cray 3's that got built, 7 or 8 years ago.  Even at that time, they
> ran at 1 GHz.  If Seymour was still alive, and there was a market to
> support it, I'm confident he'd be building machines that ran at
around
> 10 GHz or so by now.
>
> In machines closer to the consumer level, Samsung has been building
> Alpha 21264 chips since the end of last year.  By the end of this
> year, they plan to ship 1 GHz chips.  When they get their
fabrication
> tuned well, it should be able to run at around 2 GHz or so.
>
> It's also worth nothing that Alphas tend to be substantially faster
> than Intel chips at the same clock speed -- it depends somewhat on
the
> sorts of things you're doing, but figure around double the speed at
> integer work and around quadruple at floating point work.
>
> IOW, by the end of this year, anybody with a few thousand dollars to
> spare will be able to buy a machine that's equivalent to
approximately
> a 2 GHz Intel chip.  In another year or so after that, they'll be
able
> to buy the equivalent of a 4 GHz Intel chip.
>
> To make a long story short, the kind of speed you're talking about is
> a LOT less than 10 years off; three years would be a LOT closer to
> reality.
>
> > If we linearly scale a 200mhz machine (2^20 keys/sec) to a 5000mhz
> > machine (2^24.64 keys/sec) it will still take 2^55.35 seconds to
search
> > an 80-bit key.  That is 731,178,021 years avg per key. Throw a
million
> > at it and you are at 731.17 years.
>
> Things rarely scale linearly, or anywhere close to it.  Consider that
> a 16-bit multiplication on a 486 takes 13 to 26 clock cycles.
>
> The Pentium III using the streaming SIMD instructions can do four
> multiplications with a single instruction, and can execute one of
> these every cycle (and execute a couple of other instructions at the
> same time as well).
>
> IOW, with carefully optimized code, a Pentium III could be around 100
> times as fast as a 486, even at exactly the same clock speed.
>
> > But you are limited by such fundemental things.  The fastest chip I
> > have seen was 1.6Ghz even then it was liquid cooled and cost
millions.
> > I don't expect them to be publicly avail anytime soon for say 200
> > dollars (same price for a decent intel chip).
>
> I don't think a 1.6 GHz chip should cost millions at the present
time.
> In fact, it wouldn't surprise me if a current Alpha would run that
> fast with liquid cooling, and they can be gotten for a few thousand
> dollars.  For that matter, if you didn't mind sorting through a few
> chips, it wouldn't surprise me if you could find a few Intel (or
> PowerPC) chips that would run at over a GHz -- keep in mind that to
> maximize yields, Intel is VERY conservative in their chip ratings.
> They've done demos for years of (carefully chosen) chips running at
> two and three times the maximum currently available clock speeds.
>

Thanks for the info.  I am not in the 'game' that much.  Well I still
don't believe that massive multi ghz machines will be used in key
searches any time soon.  What I would like to know is how fast can you
get CMOS (or whatever they use in CPUs) to run before it loses
consistency (electrons become covalent and jump wires ...)?

Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2  Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp


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

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

From: [EMAIL PROTECTED]
Subject: Re: What is "the best" file cryptography program out there?
Date: Sun, 08 Aug 1999 12:58:23 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (KidMo84) wrote:
> Well since 1990 weve jumped from an 80mhz processor to around
1000ghz, which a
> pentium3 can be overclocked to, even though it really does get too
hot, but
> that will be perfected before long, i am guessing at least a 1000ghz
improvment
> of processors every 10  years. Especially in the last 3 years there
has been
> increased productivity in the speed of processors.

You are missing two crucial points.  Even at 5000mhz (5ghz) with a
million computers it would take 697 years average to find an 80-bit key
(assuming a rate of 25*2^20).  Second:  With current design methods
chips can only go so fast before blowing up.  I would follow photon
based computers (NanoTech) since they require less current and generate
far less heat.

Saying you can get a x86 like cpu running at 5ghz is very very
optimistic.  Basically you can do experiments if you want.  Clock an
8086 to 60mhz.  What happens?  It blows up.  Clock a PII 300 to 500
mhz, what happens?  It blows up.

One last point is that the computers that run at >1ghz (IBM is
designing one and NORTEL has some) cost millions and are not publicly
available.

Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2  Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp


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

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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Scott Ciphers
Date: Sun, 08 Aug 1999 14:11:39 GMT

In article <7ojsm0$j1k$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:

..

>I noticed I forgot to mention that the overwriting can occur in the
>table setup.  That's what you were talking about, correct?
>
   Sort of. Just add the fixs I but in. If you have a keyenc.key file
and a secret password. It should work no matter what with the
stuff that is there

..



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: What is "the best" file cryptography program out there?
Date: Sun, 08 Aug 1999 14:25:07 GMT

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
(Guenther Brunthaler) wrote:
>On Thu, 05 Aug 1999 00:52:07 GMT, Bob Silverman <[EMAIL PROTECTED]> wrote:
>
>>Anyone who thinks that even 2048 bits are needed is clearly
>>clueless about the subject.
>
>Due to my knowlege it has been stated that an RSA key with 3100 may
>require approximately the same effort to be broken by brute force as a
>128 bit IDEA session key.
>
>That means, in case IDEA session keys are used, 3100 bit RSA keys
>would provide the optimum key length in PGP.
>
>Longer RSA keys cannot increase the security for a single message,
>because otherwise cracking the session key would be easier (which is
>enough to decode the message).
>
>In practice, however, longer RSA keys are advantageous, because
>breaking a session key only helps one decode a single message, while
>breaking the RSA key will enable the attacker to decode ALL messages
>that have been encrypted by that key.
>
>

  In practice one should use the longest RSA key that one can spend time
on his machine waiting for the session key to be encoded. The main reason
for this is not just that machines are getting faster but faster and faster
mathematical ways of factoring have been developed and no reason to think
that there will not be better mathematical short cuts in the futures. Assuming
the NSA can not aready easily factor it and assuming that IDEA in the
weak chainning mode that PGP choose to use is also safe.





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: : I AM CAVING IN TO JA...
Date: Sun, 08 Aug 1999 14:16:26 GMT

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Dave Salovesh) wrote:
>In article <7ocu6e$q1o$[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) opined:
>
>> I see more and more sites that say you Need JavaScript or some application
>>to use the site. I can't see why webpage designers seem to always try to
>>force the user to get newer crap when the regular HTML works. But they
>>seem to make things more complicated.
>>  So I give up. I have added some useful SCRIPT to my main webpage so
>>that those that have a Browser that is JavaScript capable can get some
>>useful info from my site. Sorry but if you Browser is not JavaScript capable
>>you may not get to see this specail advice it is for JavaSrcipt enabled 
>>viewers only. 
>
>Wait a sec - you can't see why HTML authors push for newer crap, and
>then -you- join them?  You say regular HTML works, and then you put
>useful information on your site that people can only see using JS?
>
>I don't get it.  Why not push yourself to use HTML better - why cave?
>

   Well it is not exactly cave. By the way a friend of mine says the JS
or mircoshaft is very weak and that it errors out using his browser so I may
have to find a common subset of the language both so both browsers 
under the impression everything is working correctly.




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]
Subject: Re: challenge/competition revisited
Date: Sun, 08 Aug 1999 13:20:53 GMT

<snip>

I have about 10 papers on cryptanalysis on my hd (I didn't write the
papers but...) Anyways if you want them I could zip them up and email
them in private to you.

They include analysis of

DES, RC5, Blowfish, ICE, LOKI89, LOKI91, REDOC, Lucifer

and probably a couple others.

Tom


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

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

From: [EMAIL PROTECTED]
Subject: Re: challenges / competitions???
Date: Sun, 08 Aug 1999 13:15:15 GMT

In article <7oj1pd$1lj0$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>   I have lots of reason. I am more honest than most people
> you have ever met. But I think the only way to prove it. Is to
> solve it and see.

Again why solve it?  nobody uses your method.  See RC5/RSA/DES are
popular well known methods.  Attacking them is like attacking seat
belts in cars.  They actually have an impact on your life.  Scottu
means zero to 99.99% of the world.  (Of course DES/RSA/RC5 means zero
to 97% of the world but who's counting?)

>  Tim the contest is pretty black and white. Not like the BS contests
> where you may get a prise if you come up with what Mr BS
> considers a worthy attack. Take a look.

Again ciphertext only is not the only method of attack.  You should
encourage cryptanalysis based on your previous crypanalsys.  Maybe
someone can find something you did not?

Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2  Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp


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

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

From: [EMAIL PROTECTED]
Subject: Re: Download virtually unbreakable encryption programme (Wincrypt IDEA)
Date: Sun, 08 Aug 1999 13:29:20 GMT

In article <7ohott$98k$[EMAIL PROTECTED]>,
  "Terry  Mechan" <[EMAIL PROTECTED]> wrote:
> Download virtually unbreakable encryption programme (Wincrypt IDEA)
>
> http://www.tmechan.freeserve.co.uk/WINCRYPT95.EXE
>
> More details on
>
> http://www.tmechan.freeserve.co.uk

SPAMMER!

No algorithm is unbreakable.  Even the OTP is breakable if you steal
the key tape.  And you are using IDEA?  Wow that must be some quite
feat.  Maybe I will just pickup a copy of PGP?

Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2  Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp


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

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

From: [EMAIL PROTECTED]
Subject: Re: key lengths
Date: Sun, 08 Aug 1999 13:27:50 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (Jerry Coffin) wrote:
> > > It's also worth noting that many of the better attacks typically
> > > reduce the difficulty of an attack by a more or less fixed factor
> > > compared to a brute-force attack on the same cipher.
> > >
> > Then the cipher has been broken.
>
> Of course -- but how many ciphers have been in use for, say, 20 or 30
> years and NOT been broken to at least some degree?  The number is
> vanishingly small.  We can design algorithms to be resistant to known
> breaks, and we can use some general principles we believe will make
> them hard to break in general, but if we design an algorithm with the
> expectation of using it for an extended period of time, we should
plan
> on the fact that eventually somebody's likely to break it to some
> degree or other.

Yeah but algorithms like DES have not really been broken.  Can you use
the known iterative attacks against it?  Not really.  I would expect
AES to have the same qualities.

> Presumably here you're talking about things like differential and
> linear cryptanalysis.  Differential cryptanalysis is often practical
> against designs that weren't designed to resist it -- just for
> example, it was quite a practical attack on Lucifer.  Obviously
> anybody who knows what they're doing now is going to design their
> algorithm to resist known attacks, but it's almost inevitable that
> somebody's going to invent new attacks in the future.

I agree.

> So would anybody.  Unfortunately, without knowing all the attacks
> people are going to invent over the operational life of the cipher,
> there's no way to know what attacks will be feasible.

That doesn't make 1024-bit keys a must have though, which is what the
argument really is about.

> > But key length generally doesn't say much about the actual strength
of
> > a cipher unless it's perfect.
>
> Quite the contrary -- it tells you something about the degree to
which
> the cipher can be imperfect before an attack becomes practical.
>

But a 1024-bit vingere cipher is not really strong is it?  56-bit keys
in DES would be much stronger.  Key lengths just give upper bounds.
Meaning it can be AT MOST this secure.  However many ciphers relied on
that fact and missed real scrutiny.

I agree that 'secure' ciphers are broken all the time.  But I know that
people can do well (look at DES 22 years later).

Tom
--
PGP 6.0.2i Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2  Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp


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

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


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