Cryptography-Digest Digest #999, Volume #9 Fri, 6 Aug 99 16:13:04 EDT
Contents:
Re: Questions regarding elliptic curve cryptography. (Medical Electronics Lab)
Re: frequency of prime numbers? (John Savard)
Re: Is breaking RSA NP-Complete ? ([EMAIL PROTECTED])
Re: Americans abroad/Encryption rules? (Serge Paccalin)
Re: Questions regarding elliptic curve cryptography. (DJohn37050)
: I AM CAVING IN TO JA... (SCOTT19U.ZIP_GUY)
Re: frequency of prime numbers? (Bob Silverman)
Re: About Online Banking Security (KidMo84)
Re: About Online Banking Security (KidMo84)
Re: What is "the best" file cryptography program out there? (KidMo84)
Re: challenges / competitions??? (wtshaw)
Re: Microsoft Word 97 ([EMAIL PROTECTED])
Re: AES finalists to be announced (John Savard)
Re: AES finalists to be announced ([EMAIL PROTECTED])
Re: Error-Correcting Codes Added to Web Site (John Savard)
Re: AES finalists to be announced ([EMAIL PROTECTED])
Re: What is "the best" file cryptography program out there? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Questions regarding elliptic curve cryptography.
Date: Fri, 06 Aug 1999 12:32:40 -0500
Teh Yong Wei wrote:
>
> Me again. Sorry for posting so many "simple" questions to all of U. But,
> I myself am new in this field, so there is a lot of things that I am
> quite uncertain and don't understand. Here are some questions regarding
> ECC:
Nothing wrong with asking questions, in a while you'll be
asking questions which don't have answers :-)
> 1) How to determine a curve is a good curve?
A good curve for cryptography is one which has order #E such
that #E = k*r where k is small (<100) and r is a large prime.
> 2) How to choose a and b in the ECC equation?
At random is best, but if you use Koblitz curves it's given.
> 3) Do we need to know all the points on a curve?
:-) No. If you have a good curve the number of points is too
large to enumerate. Good crypto starts with field sizes larger
than 160, so there's something like 2^160 points on the curve
(or 2^154, but still really, really big).
> 4) Who will generate the curve? The sender or the receiver?
Arbitrary. For most applications the curve is chosen by the
programmer and burned into the code. For example, if you're
doing something for the US government you'd pick one of the
NIST specified curves and be done. For some applications, the
sender is the client and they want to control the level of
security, for others the sender is the server and they want
control. Do what works best for your application.
> 5) Why we need to "convert" the message to a pair of integer?
It's not always integers. ECC can be done over any field, but
GF(p) and GF(2^m) are the simplest to implement on modern
processors and FPGA's. For some algorithms the messages is
embedded into a point, then the point is "hidden" on the curve.
The operation of embedding the data onto the curve requires
attaching some "garbage" bits which can be flipped until the
message data has an "x" value that satisfies the equation of
the curve. The solution to the equation gives a point (x,y)
which is on the curve. the value of x is related to the
message m since x = "garbage"||m. (|| means concatenate).
> 6) How to make public key as short as possible?
The public key has to contain all the bits of x and 1 bit for
the y value. By choosing a shorter field size, you can reduce
the key space, but you want to be large enough that an attacker
can't brute force a solution in "reasonable" time. What's
reasonable depends on the application. If you only have to
keep the data secret for an hour, you can use pretty short keys
(80 bits for example), but if you need to keep something secret
for 10 years, you'd better use 180 or more bits.
>
> That's all for the moment. I am very much appreciate for all your helps.
> Thank you.
You're welcome. Keep asking questions!
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: frequency of prime numbers?
Date: Fri, 06 Aug 1999 18:09:30 GMT
Bob Silverman <[EMAIL PROTECTED]> wrote, in part:
>No. The "correction" mis-defines the term "prime number"
>by (in effect) saying: A prime number is defined to be a member
>of some pre-specified finite set, rather than defining it by its
>divisibility properties and then assuming they form a finite set.
While I won't agree with you that all forms of the _reductio ad
absurdum_ proof that lead to the conclusion that the primorial or
factorial plus 1 "is a prime number" (given the initial assumptions,
one of which is false, after all) are incorrect
although I won't comment on any specific example
I _do_ agree that since that number isn't a prime number in the real
world, that type of proof is needlessly confusing. Isn't that
criticism enough?
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is breaking RSA NP-Complete ?
Date: Fri, 06 Aug 1999 18:04:24 GMT
I wrote:
> NP-Hard is neither a subset nor superset of PSPACE.
Ooops, another mistake. The question of whether
NP-Hard contains PSPACE is still open. NP-Hard
is a superset of PSPACE if and only if P=NP.
Utterly trivial of course.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Serge Paccalin)
Subject: Re: Americans abroad/Encryption rules?
Date: Fri, 6 Aug 1999 20:05:42 +0200
Reply-To: [EMAIL PROTECTED]
On/le Thu, 05 Aug 1999 15:43:00 -0600,
wtshaw <[EMAIL PROTECTED]> wrote/a �crit...
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (JPeschel) wrote:
> >
> > WT, someone wrote that ROT-13 didn't have a key, but it does,
> > 13, Caesar's key was three.
If you want, but since the "key" appears in the algorithm, it can't be
considered encryption.
> > The security of a system should be within the key: K.'s principle.
> >
> > A lot of these classical ciphers have a huge keyspace, even a Caesar
> > cipher. The size of the keyspace, though, of course is meaningless
> > for a Caesar cipher's security. So I think the US government
> > would not bother to prosecute anyone for, say, making classical ciphers
> > available from a US web site. (Doesn't the ACA do that?) I think
> > a regulation that tried to specifically spell out what was exempt
> > would run into trouble mainly because people would try to find loopholes.
>
> Obviously strength is more than keyspace, and it is a tough question to
> quantify. How to quantify it is one worth pursuing, but some sort of
> scaling, as I have before suggested, to evaluate different algorithms is
> probably indicated.
>
> A regulation that specifically spelled out which ciphers were weaker or
> stronger would simply direct people to use the better ciphers, sort of
> counterproductive to the whole idea of wanting people to ignorantly use
> bad ciphers.
> >
> > I suppose you could call UUencoding a form of encryption in a broad
> > sense. Still, if you were teaching a class on encryption, it might
> > be better not to consider UUencoding and the like as a subset of
> > encryption. Too confusing, I think.
> >
> That is my point, that there can be no clear line, if any at all, between
> what is encryption and what is not.
Maybe I'm biased because I'm French and can refer to laws of my
country, but the French law draws that line on whether you need a
secret info to decode or not:
- You don't need to learn a secret to "UUdecode" so UUEncode is not
encryption.
- You don't need to learn a secret to decode ROT-13, so ROT-13 is not
encryption, either.
- You DO need to learn a secret to decode ROT-N (namely, the value of
N), so ROT-N is encryption. The algorithm is weak (frequencies...) and
the key is laughably short (< 5 bits), but that's another matter...
--
___________
_/ _ \_`_`_`_) Serge PACCALIN
\ \_L_) [EMAIL PROTECTED]
-'(__) L'hypoth�se la plus �labor�e ne saurait remplacer
_/___(_) la r�alit� la plus bancale. -- San Antonio
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Questions regarding elliptic curve cryptography.
Date: 06 Aug 1999 17:27:31 GMT
Don Johnson's comments prefixed with *.
>> 1) How to determine a curve is a good curve?
>
>This is a matter of some debate. Some people, for example, believe
>it is OK to use Koblitz curves provided that they have the right
>properties (which I don't enumerate here). I believe that "good"
>curves have as little inherent structure as can be managed, i.e. that
>special curves, such as Koblitz curves, should be considered "suspect".
>But this is an *opinion* and there is no proven mathematics behind it.
>It is just the general belief that the more algebraic structure a
>curve has, the more likely it is that some attack (even if currently
>undiscovered) can exploit the structure.
>
>However, that said, the only fundamental property that a good curve
>should have is that for the field over which it is defined it have
>prime or nearly-prime order. (To avoid Pohlig-Hellman attacks)
>
* ANSI X9.62 ECDSA specifies at least a 160-bit prime order subgroup and
exlusion of the MOV and anomalous conditions.
* NIST recently announced curves for use with Federal Gov't: These are in 3
classes:
1. Random curves over Fp
2. Random curves over F2**p
3. Koblitz curves over F2**p
Sometimes there are very constrained scenarios where only a Koblitz curve is
practical. In this scenario, it is use Koblitz or nothing, as nothing else
fits. Use of a Koblitz curve with a random backup curve is one way to address
concerns with structure of Koblitz curves. This is one aspect of "future
resiliency" that ECC systems possess. That is, one can use Koblitz curves
today for the performance advantages and IF they are found to be weak some time
in the future, then one can switch over to a non-weak curve.
>
>> 2) How to choose a and b in the ECC equation?
>
>Generally speaking, randomly is best, unless using a special curve
>such as a Koblitz curve. It is a matter of some debate as to whether
>curves having complex multiplication qualify as special. I mention
>this because for such curves the choice of (a,b) is constrained.
>
>> 3) Do we need to know all the points on a curve?
>
>No. In fact, for the curve to be secure, it should be impossible
>to know all the points because there should be too many of them.
>
>> 4) Who will generate the curve? The sender or the receiver?
>
>Either. Or they can jointly agree. Or use a standardized (e.g. NIST)
>curve.
* For example, ANSI X9.62 ECDSA has many example curves. And of course, one
can use NIST curves reasoning that what is good enough for the US federal
government is good enough for me.
>
>> 5) Why we need to "convert" the message to a pair of integer?
>
>Because we need to encode the message in such a way that becomes
>a point on the curve. Points are pairs of integers.
* Any formatting is normally done "under the covers" so a user does not see any
of this.
>
>> 6) How to make public key as short as possible?
>
>This depends on the level of security you require. It's really a
>question only you can answer. Make it big enough to just suit your
>needs.
>
* A EC point is normally represented as a point (x,y) where x and y are
elements in the underlying field (say 160 bits each). Certicom has a
technology called point compression where the y-coordinate is reduced to a
single bit. This saves about half the bits in transmitting the value of a
point.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: : I AM CAVING IN TO JA...
Date: Thu, 05 Aug 1999 22:03:09 GMT
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.
Also if you stuck with microshaft browser the page will not appear the same
as witha good Netscape version. Sorry but Netscape is better in my humble
opinion.
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: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: frequency of prime numbers?
Date: Fri, 06 Aug 1999 17:27:45 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John McDonald,
Jr.) wrote:
> On 4 Aug 99 15:15:17 MDT, sl3nf.cc@usu@edu (Sniggerfardimungus) wrote:
>
> >I ask this question here not because it necessarily relates to
cryptography,
> >but to an interest of cryptographers, prime numbers; is there any
reason to
> >believe that there are either a finite or an infinite number of
primes? Even
> >better, is there any proof either way?
>
> I believe, (and I could be mistaken) that this is addressed in a
> rather lengthy proof by Goedel. He purports that mathematics is an
> incomplete and infinite system.
No. What Goedel showed was that any sufficiently rich axiomatic
system is incomplete in the sense that there are true statements
which can not be proved. [as well as other stuff I won't discuss].
Peano arithmetic is "sufficiently rich", BTW.
But why bring this subject up? The question was about whether there are
infinitely many primes. 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]
>
> 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.
The fact that the density of primes decreases comes from some elementary
results in number theory. The fact that pi(n) ~ n/log(n) comes from the
Prime Number Theorem, not Goedel's theorem.
> BTW: Another implication that I believe arose from his proof was that
> not only are there an infinite number of primes, but there are also an
> infinite number of twin primes.
More grossly incorrect nonsense. The question about twin primes
is still open and has nothing to do with Goedel's theorem.
> Hope this helps.
Hope what helps? Nothing you said was correct.
--
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: [EMAIL PROTECTED] (KidMo84)
Subject: Re: About Online Banking Security
Date: 06 Aug 1999 18:57:57 GMT
I am not trying to compare it to atm's, i am just asking, does it have
resonable security for reviewing checking information and that type of stuff.
I know atm's are more security, though like anythin there is an easy bypass,
steeling the pin and card. Just like somebody mentioned with the computer
cookies. And the hardest thing is somebody reproducing the site with a storage
on the username and id.
I know there are backdoors to alot of stuff. I just want to know if it is
reasonable secure.
------------------------------
From: [EMAIL PROTECTED] (KidMo84)
Subject: Re: About Online Banking Security
Date: 06 Aug 1999 18:51:37 GMT
My browser has 128bit encryption.
------------------------------
From: [EMAIL PROTECTED] (KidMo84)
Subject: Re: What is "the best" file cryptography program out there?
Date: 06 Aug 1999 18:49:17 GMT
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.
Signed,
KidMo
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: challenges / competitions???
Date: Thu, 05 Aug 1999 16:07:35 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Gabe Simon) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
> I was just wondering if anyone knew about a website that had
> cryptanalysis challenges for people to try to solve. I was hoping
> for something with multiple levels of difficulty for us newbies out
> there... If such a site does not exist... would anyone be interested
> in making one? I know I would... it wouldn't be too hard to
> organize...
>
> Gabe Simon
>
The level of algorithms makes lots of difference, as some ciphertexts are
meant to be solvable by even simple means, hense, recreational, while some
ciphers are supposedly so difficult that even with automated means they
are perhaps not attackable for an individual, with all levels inbetween
these two extremes. Just what did you have in mind?
Obviouly, some ciphers are well known, others known but capabilities for
dealing with them almost non-existant. Just finished Mafra, number 21 of a
series of ciphers. Below is an encrypted form of the preceeding
paragraph...your mission, if you choose to accept it, is to solve for the
keys:
tcunr zpxfa mpesz ecfec akmou whjjk hqdeo bexoe fsejp ecfer wjcuh cgmxs
ecyex bqjxu voerw xterl vxctn baeoo wxvnb iexdn towuu mditm xskgn dipxl
bcqsw lnpim denmi pajpd suqfq ruecx jsixx ogbnd pgtbl rierv yadwp nvfxg
abksz qmxmx eswvn mjdwi ofmqp mwarc nddeg qnubj yteav naiee gnrkn awnry
njfeo evkoe ocnmi pajnd iuola bkmjq nahny tsxyf lticf dpera dxyzn dlthx
izndp epbxn kotvy gpzpb vldpu vgjmp esnld ywuoj kkqqv powhb sxukf laadw
fcqxu kdbqg pfcot jzkkh zadcz okjxg zjzal xidaf ogtnu gysnj apnvx
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Microsoft Word 97
Date: Fri, 06 Aug 1999 18:53:33 GMT
Hello,
They offer a shareware Word password recovery program.
www.soft4you.com/mso2000/
--ALI--
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 18:02:49 GMT
[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...
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AES finalists to be announced
Date: Fri, 06 Aug 1999 18:49:55 GMT
In article <7of4hl$fc5$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <7of2og$dv6$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > 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.
>
> Do I care?
>
Yes. Because even though you talk a lot you couldnt crack an egg let
alone a very simple cipher message.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Error-Correcting Codes Added to Web Site
Date: Fri, 06 Aug 1999 19:22:16 GMT
[EMAIL PROTECTED] wrote, in part:
>It would be good to add links to some better error correcting
>codes at the end, like Turbo codes
> http://www331.jpl.nasa.gov/public/JPLtcodes.html
>and Gallager codes
> http://wol.ra.phy.cam.ac.uk/mackay/codes/
I looked up the links; having finally figured out what a Turbo Code is
(the sites you gave didn't give explicit examples, but since Turbo
Codes are a general concept, that's understandable) and have added a
description of them to the page.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AES finalists to be announced
Date: Fri, 06 Aug 1999 19:11:41 GMT
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.
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 19:36:52 GMT
In article <7of4bo$fac$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> It's not always about key lengths! Doesn't anyone understand that? A
> keylength 'suggests' (at best) an upper bound on security. It doesn't
> mean you have to try half of the 128-bit keys to break 128-bit
> ciphers. If a cipher is vulnerable to iterative attacks with a modest
> amount of knowledge it could be weaker (note: FEAL at four rounds).
If
> your key generation is weak ...
>
> The brute force ability depends on the algorithm. Blowfish for
example
> is much harder to brute force then DES simply because of the key
> schedule. Assuming every is equal though...
>
> it takes 7 hours max against DES, the same machine would break a
64-bit
> key in 74 days. A 80-bit key in 13406 years, and a 128-bit key in
> 3,773,580,522,841,040,695 years. This assumes you use the DES cracker
> model. Some algorithms with newer technology might be faster.
>
> Assuming you can find a DES key in 1 minute, finding a 64-bit key
would
> take 4.2 hours. Finding a 80-bit key would take 485 years, finding a
> 128-bit key would take 8,984,715,530,573,906 years. This is testing
> rate of 1,200,959,900,632,132 (2^50.09) keys a second which is
> uncomprehendable for 99% of all people (meaning their computers can't
> even come close). Against the RC5 challenge my machine did 500,000
> keys a second (2^18.93).
>
> Clearly 64-bit keys are on the lower bound. I would still think they
> are secure against 99% of all adversaries (note: the NSA is not always
> against you). 80-bit keys are still secure for any seeable future,
and
> 128-bit keys will most likely never become too short in our lifetime.
>
The NSA is not always against you and if it is Tom Stdenis a 2 bit key
is secure.
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
******************************
