Cryptography-Digest Digest #1, Volume #10 Fri, 6 Aug 99 18:13:04 EDT
Contents:
Re: new PGP key and test ([EMAIL PROTECTED])
Re: Prime numbers wanted (Roger Carbol)
Re: OTP export controlled? (Bo D�mstedt)
Re: Microsoft Word 97 ([EMAIL PROTECTED])
Re: AES finalists to be announced (John Savard)
Broken Link On QuickBooks99 Crack ("John E. Kuslich")
Re: What is "the best" file cryptography program out there? (John Savard)
Re: frequency of prime numbers? (John McDonald, Jr.)
Re: new PGP key and test ([EMAIL PROTECTED])
key lengths ([EMAIL PROTECTED])
Re: What is "the best" file cryptography program out there? ([EMAIL PROTECTED])
Re: AES finalists to be announced (John Savard)
Re: AES finalists to be announced (Paul Crowley)
Re: rsa prime collision (Bob Silverman)
Re: OTP export controlled? (Jim Felling)
Re: Ways to steal cookies in HTTP and HTTPS ([EMAIL PROTECTED])
Re: key lengths ([EMAIL PROTECTED])
Re: Academic vs Industrial (Jim Felling)
Re: frequency of prime numbers? (Andy Finkenstadt)
rsa prime collision ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: new PGP key and test
Date: Fri, 06 Aug 1999 19:22:54 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> and there's always Usenet newsgroups:
> �alt.security
> �alt.hacking
> �alt.2600
> �alt.cyberpunk
> �comp.security.misc
I will check out the first two groups.
Thanks,
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.
------------------------------
Subject: Re: Prime numbers wanted
From: Roger Carbol <[EMAIL PROTECTED]>
Date: Tue, 03 Aug 1999 19:32:22 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>> Or is this another "making a list of all primes up to the 200
>> digit level would require turning every molecule in the universe
>> into a computer and letting it run 15 billion years" issue?
>And that's one reason why.
Ah. I suspected as much, but I also know that:
1) My knowledge of the speed of prime-generating/checking is
pretty slim.
2) I don't have even an approximate idea of the density of
primes up around the 200 digit level.
Thanks to everyone who (even involutarily) tolerates my ongoing
disillusionment...
.. Roger Carbol .. [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Bo D�mstedt)
Crossposted-To: talk.politics.crypto
Subject: Re: OTP export controlled?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 06 Aug 1999 20:25:16 GMT
[EMAIL PROTECTED] (Patrick Juola) wrote:
[...]
>How have you managed to make the pad theft-proof?
>
> -kitten
You don't have to! If you use OTP there is no secret to steal.
The perfect thing to use in an hostile environment.
Bo D�mstedt
Protego Information AB
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Microsoft Word 97
Date: Fri, 06 Aug 1999 19:31:31 GMT
Hi,
Check out this URL: www.passwordservice.com/crack.html
They offer a service that can help you
_ _ _ _ _ _
Hans Wiek
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I lost the password for a Microsoft Word 97 document.
> Help me !!!
> Thank's
> NPW
>
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES finalists to be announced
Date: Fri, 06 Aug 1999 20:37:39 GMT
[EMAIL PROTECTED] wrote, in part:
> I cares. Read the charter on why.
Oh, and by the way: where does it say in the charter that you can post
*binaries* to this newsgroup?
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Broken Link On QuickBooks99 Crack
Date: Fri, 06 Aug 1999 12:47:27 -0700
Sorry for the broken link on our web site at http://www.crak.com
Thanks to all of you who sent us messages to complain.
A demo of our new QuickBooks99 cracker is now available on our web site
at:
http://www.crak.com/programs/qb99demo.zip
The underlying mechanism for this program's operation should be of
interest in anyone writing cryptographic code. It shows that the
Windows operation system is so insecure that only a few lines of code
will crack what otherwise would be a relatively strong software locking
algorithm.
One can easily write code that will open a process and gain access
rights to that process. The newly opend process memory is then at your
disposal, including instruction memory. One can then alter the code of
the process started in this way and cause the child process to do his
bidding.
Again, I will state my opinion that there is no security in the PC and
there will be none until the PC architecture offers hardware encryption.
JK
--
CRAK Software (Password Recovery Software)
Http://www.crak.com
[EMAIL PROTECTED]
602 863 9274 or 1 800 505 2725 In the USA
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: What is "the best" file cryptography program out there?
Date: Fri, 06 Aug 1999 20:42:12 GMT
[EMAIL PROTECTED] wrote, in part:
>That form of implicit trust scares me. What makes a 1024 bit key less
>secure then a 4096 bit key? (And if you say ease of solving you have
>no clue about the crypto world).
Well, a 1024 bit RSA modulus or D-H public key may not be crackable today. But
compare a Pentium III with a 6502. Computers are getting faster! And factoring
and other such attack algorithms are improving too.
(However, baldly claiming that 2048 is insecure, and changing to 4096 is
_necessary_, *does* remind me of David A. Scott. One might suggest doing so to
be on the safe side, but a simple assertion that 2048 is insecure _is_ kind of
far-out.)
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John McDonald, Jr.)
Subject: Re: frequency of prime numbers?
Date: Fri, 06 Aug 1999 20:42:10 GMT
On Fri, 06 Aug 1999 17:27:45 GMT, Bob Silverman <[EMAIL PROTECTED]> wrote:
>But why bring this subject up? The question was about whether there are
>infinitely many primes. [sic] Tells us how/why you think Goedel's [first]
>incompleteness theorem has anything to do with this.
>
>[actually, it does, but in an indirect way -- I will be a bit loose
>here as I don't want to get into a discussion of formal grammars:
>
>Goedel encoding represents formal theorems (which are strings of the
> axiomatic system) using the fact that the integers form a UFD. Since
>there are infinitely many possible strings, there must be infinitely
>many integers to do the encodings. But the infinitude of primes comes
>FIRST and not as a result of Goedel's thm.
>But this is a separate issue]
I believe that my confusion came from the order of the
implications... I will have to reverse myself on the therom to fully
answer this, so expect an actual response tomorrow.
>> One implication of his theorom suggests that even though the
>> concentration of primes becomes smaller the further fown the
>> numberline you go, that there are still infinitely many primes.
>
>No. Goedel's Thm. says nothing of the kind.
I didn't mean to imply that Goedel's theorom _stated_ that
there were infinitely many primes, but simply that it had subtle
implications one of which was infinite primes. Apologies for the
confusion.
[-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
John K. McDonald, Jr. Alcatel, USA
[EMAIL PROTECTED]
please remove -delete- for responses.
--
"I speak for me and not this company"
TO SPAMMERS:
Please view the definitions for
"telephone facsimile machine,"
"unsolicted advertisement," and the
prohibition and penalty for sending
unsolicited faxes before sending Un-
solicited Commercial E-mail to the
above address. Violators WILL BE
PROSECUTED. These can be found
in:
The Telephone Consumer Protection Act
of 1991, Title 47, Chapter 5,
Subchapter II, Section 227.
[=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: new PGP key and test
Date: Fri, 06 Aug 1999 19:56:28 GMT
In article <7ofcm2$lnd$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > and there's always Usenet newsgroups:
> > �alt.security
> > �alt.hacking
> > �alt.2600
> > �alt.cyberpunk
> > �comp.security.misc
>
> I will check out the first two groups.
>
Go a head but you wont understand them either.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: key lengths
Date: Fri, 06 Aug 1999 19:59:23 GMT
People like quoting big key lengths. Here are some numbers to look at
A 64-bit key at 2^20 keys a second, can be searched in 2^44 seconds.
That is 557,844 years (278,922 years average). Throw 2^20 machines at
it and you are down to 194 days (97 days average).
A 80-bit key at 2^20 keys a second, can be searched in 2^60 seconds.
That is 36,558,901,084 (18,279,450,542 average). Throw 2^20 machines
at it and you get 34,865 years (17,432 years avg.).
A 128-bit key at 2^20 keys a second can be searched in 2^108 seconds.
That is 10,290,415,831,380,857,647,867,707 years ... enough?
Basically 64-bit keys provide personal level privacy where simple
letters are intended as private but not life threatening. 80-bit keys
are long enough to thwart any real dedicated attack (like
distributed.net). Maybe with 2^30 machines you can find 80 bit keys
but that's not likely (still would take 2^50 seconds). 128-bit keys
are not really searchable in this universe. It would take to long even
with every single cpu on earth working on it. With 2^40 (1 trillion)
computers running at 2^30 keys a second (billion) searching a 128-bit
key still takes 2^58 seconds or 9,139,725,271 years (4,569,862,635
years avg).
Now that this has been said. Can we stop assuming the strength is in
the key length? Please?
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: Fri, 06 Aug 1999 20:16:09 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (KidMo84) wrote:
> I feel that with new advances in technowledgy, there will be
processors out
> there that will be be able to run at 5000mhz+ in the next 20-30
years. So
> though with the processing speed now it might take 485 years to crack
an 80bit
> key, in the future with faster processors, and maby special computers
just made
> to crack these high bit algorithms brute force, it will greatly
reduce time.
>
There are limitations though. Running any current chip at 5ghz would
a) take too much power to run, and b) generate way too much heat.
I don't think processors are going to leap much in speed (unless some
new fabrication process becomes invented). It's like saying how fast
can you make a rocket car before it blows up and kills the driver.
Still the only way to attack 64/80 bit keys in the forseeable future
would be massive dedicated attacks. 64 bit keys could fall if say 2^23
computers running 2^20 keys/sec each. A key could be found in 12 days
average. That's a lot to ask even for today. The same attack against
an 80-bit key would take 2,179 years average to complete.
You have to remember that 'special' chip designs don't work against
algorithms like Blowfish which require alot of key material. In
blowfish any n-bit key is really like a n+9 bit key because of the key
schedule. So a 64-bit user key is really 73-bits of work factor ...
In general... yes you have to count for technological improvements but
don't expect much. If computers really do jump that much (every 2
years) then you can expect 60 bit keys to be weak this year, 61 bit
keys to be weak in 2001, 80 bit keys to be weak in 2039, 128 bit keys
to be weak in 2135 ... This assumes in the year 2135 that we can find
128 bit keys in 3.5 hours (same as DES 5 years ago). This is a speed
of 2^114.37 keys/sec though which is not really likely.
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] (John Savard)
Subject: Re: AES finalists to be announced
Date: Fri, 06 Aug 1999 20:36:14 GMT
[EMAIL PROTECTED] wrote, in part:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (John Savard) wrote:
>> [EMAIL PROTECTED] wrote, in part:
>> > You dont know much that file is not currupted it is simple to crack
>but
>> >beyond you. Its now in seperate thread just for you oh little one.
>> Who cares? Read the FAQ on why that sort of thing is a waste of
>> time...
> I cares. Read the charter on why.
The sci.crypt charter is as follows:
>sci.crypt Different methods of data en/decryption.
>sci.crypt.research Cryptography, cryptanalysis, and related issues.
>talk.politics.crypto The relation between cryptography and government.
>The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
>every three weeks. You should read it before posting to either group.
>A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
>It is not. It is reserved for discussion of the _science_ of cryptology,
>including cryptography, cryptanalysis, and related topics such as
>one-way hash functions.
>Use talk.politics.crypto for the _politics_ of cryptography, including
>Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
>export controls.
>What if you want to post an article which is neither pure science nor
>pure politics? Go for talk.politics.crypto. Political discussions are
>naturally free-ranging, and can easily include scientific articles. But
>sci.crypt is much more limited: it has no room for politics.
>It's appropriate to post (or at least cross-post) Clipper discussions to
>alt.privacy.clipper, which should become talk.politics.crypto.clipper at
>some point.
>There are now several PGP newsgroups. Try comp.security.pgp.resources if
>you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
>and c.s.pgp.discuss for other PGP-related questions.
>Questions about microfilm and smuggling and other non-cryptographic
>``spy stuff'' don't belong in sci.crypt. Try alt.security.
>Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
>comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
>comp.compression, comp.security.misc.
>Here's the sci.crypt.research charter: ``The discussion of cryptography,
>cryptanalysis, and related issues, in a more civilised environment than
>is currently provided by sci.crypt.'' If you want to submit something to
>the moderators, try [EMAIL PROTECTED]
I don't see what in there is supportive of your challenge.
As it is quite easy - even without using an encryption method that is genuinely
secure - to encrypt a message in such a way that decrypting it would take an
inordinate amount of work, the fact that I could cook up a message that you
couldn't break wouldn't prove that I was smarter than you.
That sort of tactic is, quite appropriately, undeserving of a response and of
whatever time and effort might be required to solve the challenge message
involved.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: AES finalists to be announced
Date: 6 Aug 1999 20:40:52 +0100
[EMAIL PROTECTED] writes:
> I have been informed by NIST that the five or so AES finalists will be
> announced next Monday at 10 am. My Frog algorithm, as expected, will
> not be one of them.
Condolences. OK, ladies and gentlemen, place your bets now. Here are
my guesses, for amusement's sake only.
Candidates: CAST-256, CRYPTON, DEAL, DFC, E2, FROG, Hasty Pudding,
LOKI97, MARS, MAGENTA, RC6, Rijndael, SAFER+, SERPENT, Twofish.
These ciphers have real cryptanalytic results against them and can't
be considered: Frog, MAGENTA, Loki97, DEAL.
These ciphers have some disadvantage that makes it unlikely they'll
get further: SAFER+ (too slow), Hasty Pudding (too weird), CRYPTON
(too similar to Rijndael and some cryptanalytic results), DFC (too
slow on 32-bit processors).
These two ciphers are just certs for the shortlist, since they're
great all-rounders: Rijndael, Twofish. They aren't the front runners
by every measurement, but they're never far behind the front runner.
That leaves five candidates for three places:
E2, RC6, MARS, Serpent, CAST-256.
My guess is that MARS won't make it because it has no big wins over
RC6, and it's more complex and not based on a fielded design, and E2
won't make it because it doesn't have any big wins over any of them.
That leaves these three:
RC6: incredible simplicity, blinding performance, impressive mixing
CAST-256: based on well-understood and widely respected design
Serpent: conservative design and very attractive security analysis.
There's my guess: Twofish, Rijndael, RC6, CAST-256, Serpent. Any
other guesses?
Note that I'm not going on about smartcard memory issues here since
I've been told that the figures I used last time aren't always a good
guide...
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: rsa prime collision
Date: Fri, 06 Aug 1999 21:00:51 GMT
In article <7ofh7i$pdf$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In a 768-bit modulus (768 bit RSA key) each prime is about 384 bits.
> There are 2^384 / ln(2^384) primes which are below 2^384. This is
> 2^375.94 primes.
>
> Would it be correct to assume the chance of two 768-bit rsa keys
> sharing a factor is 2^-187.97?
No. Assume N1 = p1 q1 and N2 = p2 q2 are randomly generated
768 bit keys. The probability that p1 = p2 or q2 or q1 = p2 or q2
is roughly 4/pi(2^384) ~ 4/2^376
However, this is based on some unstated assumptions about the
random generation process, i.e. was there sufficient entropy for the
SEEDS for the prng,
> What is the impact on security (say in
> smaller keys) when two public keys are the result of a shared factor
> (but not both)?
Clearly *if* there are two public keys N1, N2 and GCD(N1, N2) > 1
then you have recovered both private keys. Ask what needs to take place
for this to happen. Suppose there are a large number of public keys
available. You need to gather them all and compute GCD's in pairs
to find a non-trivial GCD. The number of pairs to search is roughly
one-half the SQUARE of the number of keys. That's a lot of data
and a lot of computing.
--
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/
Share what you know. Learn what you don't.
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: OTP export controlled?
Date: Fri, 06 Aug 1999 15:51:42 -0500
How do you keep the OTP secret then?
"Bo D�mstedt" wrote:
> [EMAIL PROTECTED] (Patrick Juola) wrote:
> [...]
> >How have you managed to make the pad theft-proof?
> >
> > -kitten
>
> You don't have to! If you use OTP there is no secret to steal.
> The perfect thing to use in an hostile environment.
>
> Bo D�mstedt
> Protego Information AB
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.infosystems.www.misc,comp.security.misc
Subject: Re: Ways to steal cookies in HTTP and HTTPS
Date: Fri, 06 Aug 1999 21:21:06 GMT
In article <[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
> If you don't accept them, how will the browser divulge them?
> It's best to not accept them in the 1st place, which
> Communicator lets you do.
If you configure Communicator not to accept 3rd party cookies, it
will still divulge 1st party cookies (i.e., cookies you got from
sites whose URL's you actually typed in) when an unauthorized 3rd
party puts IMG tags into HTML source ... as described in the
original post. But don't take my word for it :-), try it:
Edit => Preferences => Advanced => "Accept only cookies that
get sent back to the originating server"
then read a file with <img src="amazon.com/foo.jpg"> and snoop on
the http traffic...
The point is that you may wish the accept the cookie of amazon.com
*when* you explicitly connect to them, but you probably never want
a connection to microsoft.com to lead to a divulgence of your
amazon.com cookie. It would be nice if browser's were
configurable to disallow *all* 3rd party cookie activity.
> The only charges you can make with just a cookie at that site
> are for merchandise orders to the address that they have shipped
> your previous orders to. If you want to send merchandise to a
> different address, you have to log in to the secure server with
> your email address and password.
"That site" (by which I think we mean Amazon) doesn't use secure
cookies for 1-click purchases. I am not comfortable with any
charges to my credit card happening as a result of someone
stealing my cookie, whether through active or passive means.
What if someone wanted to force a publisher to reprint a book that
has been out of print for a while? They steal my cookie and 100
others and order the same book. They don't care that they have to
pay $39.99 for it themselves; they just don't want to wait years
for it to come into print again.
I don't think it's a good idea to have a non-HTTPS cookie used as
an authentication token of any kind.
> If you can mount an active attack, you get all the user's
> session content, not just cookies. It's not that likely that
> any single cookie will be more valuable than the session content
> over some period.
Not if the user accepted a secure cookie during a 128-bit SSLv3
session. IMHO, that kind of cookie *would* be an acceptable
authentication token (I think some banks use secure cookies in for
single sign-on purposes in this way). No active attack that I
know of will succeed to get extra session information (like your
credit card #).
As mentioned in the original post, if the user *ever* enables
40-bit SSLv2, the otherwise secure cookie is vulnerable to an
active attack when the owner least expects it -- due to this 3rd
party cookie divulgence mechanism.
> The damage from getting the cookies stolen is almost entirely
> eliminated by encrypting the cookies at the server side.
Why? If a mere presentation of the cookie can be used to buy
things, then its contents (whether encrypted data or not) are
mostly irrelevant. It seems to me that server-side encryption
buys you very little beyond user privacy. Server-side encryption
by no means forces proof of ownership by the client. Therefore
stealing such a cookie really can cause damage in an SSL
connection where the server is strongly authenticated but the user
is effectively anonymous.
John Pliam
[EMAIL PROTECTED]
http://ima.umn.edu/~pliam
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: Fri, 06 Aug 1999 20:54:58 GMT
In article <7ofeqk$ngg$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> People like quoting big key lengths. Here are some numbers to look at
>
> A 64-bit key at 2^20 keys a second, can be searched in 2^44 seconds.
> That is 557,844 years (278,922 years average). Throw 2^20 machines at
> it and you are down to 194 days (97 days average).
>
> A 80-bit key at 2^20 keys a second, can be searched in 2^60 seconds.
> That is 36,558,901,084 (18,279,450,542 average). Throw 2^20 machines
> at it and you get 34,865 years (17,432 years avg.).
>
> A 128-bit key at 2^20 keys a second can be searched in 2^108 seconds.
> That is 10,290,415,831,380,857,647,867,707 years ... enough?
>
> Basically 64-bit keys provide personal level privacy where simple
> letters are intended as private but not life threatening. 80-bit keys
> are long enough to thwart any real dedicated attack (like
> distributed.net). Maybe with 2^30 machines you can find 80 bit keys
> but that's not likely (still would take 2^50 seconds). 128-bit keys
> are not really searchable in this universe. It would take to long
even
> with every single cpu on earth working on it. With 2^40 (1 trillion)
> computers running at 2^30 keys a second (billion) searching a 128-bit
> key still takes 2^58 seconds or 9,139,725,271 years (4,569,862,635
> years avg).
>
> Now that this has been said. Can we stop assuming the strength is in
> the key length? Please?
>
Just you assumed that. Let us see you crack that message.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Academic vs Industrial
Date: Fri, 06 Aug 1999 16:15:57 -0500
"Bo D�mstedt" wrote:
> "Markku J. Saarelainen" wrote:
> > There seems to be building up a consensus that many academic algorithms
> > and standardization results are quite ineffective for any serious data
> > protection purposes
> [cut]
> >Surely, these standards should not be used for
> > any industrial data security applications.
> and then Paul Koning wrote:
> >Where did you get that idea?
> >My impression is exactly the opposite. Academic work has been
> >creating problems for spooky control of crypto since the early
> >days of RSA. Later work (IDEA, CAST, Blowfish, all the AES
> >proposals) continue this trend.
> >Or are you trying to say that none of these are any good because
> >they are all controlled by the NSA? Are you a David Scott clone?
> >
> > paul
>
> Assuming that Markku J. Saarelainen is not a David Scott clone,
> we can still not exclude that his argument could be correct in the
> respect that beforementioned cipher algorithms could be weak.
>
> Bo D�mstedt
> Chief Cryptographer
> Protego Information AB
> Malmoe,Sweden
> http://www.protego.se
Or those algorithims could be strong. All crypto has the potential to have
undiscovered weaknesses, but all of the mentioned algorithms have been the
subjects of intense public scrutiny as to their quality, and no significant
flaws have been found as of yet -- some have known weaknesses(i.e. weak keys,
protocol issues-- such as RSA's (multiple keys, same N) ), but they all have
had rigorous and in-depth analysis. They are as strong as any presently out
there and the evidence for their strength is strong.
------------------------------
From: [EMAIL PROTECTED] (Andy Finkenstadt)
Subject: Re: frequency of prime numbers?
Date: 6 Aug 1999 17:53:42 -0400
Reply-To: [EMAIL PROTECTED]
In <7of5u2$giq$[EMAIL PROTECTED]> Bob Silverman <[EMAIL PROTECTED]> writes:
>But why bring this subject up? The question was about whether there are
>infinitely many primes. ...
Maybe I'm just dense, but isn't there a really easy and simple to understand
proof of this?
First, define a prime number as any number where you can only divide
the number by itself and 1 in order to have an integer result.
If you assume there is a maximum prime number, such that there are
exactly N primes, you can find a higher prime number by multiplying
all of those prime numbers together (don't forget the prime number
2) and adding 1.
Lather, Rinse, Repeat.
No?
Andy
--
Andrew Finkenstadt (http://www.finkenstadt.com/andy/)
"I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone."
- Bjarne Stronstrup
------------------------------
From: [EMAIL PROTECTED]
Subject: rsa prime collision
Date: Fri, 06 Aug 1999 20:40:21 GMT
In a 768-bit modulus (768 bit RSA key) each prime is about 384 bits.
There are 2^384 / ln(2^384) primes which are below 2^384. This is
2^375.94 primes.
Would it be correct to assume the chance of two 768-bit rsa keys
sharing a factor is 2^-187.97? What is the impact on security (say in
smaller keys) when two public keys are the result of a shared factor
(but not both)?
Thanks,
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
******************************
