Cryptography-Digest Digest #43
Cryptography-Digest Digest #43, Volume #14 Fri, 30 Mar 01 11:13:00 EST
Contents:
Re: Support for 1536 bit RSA keys? ("Tom St Denis")
Re: Support for 1536 bit RSA keys? ("Tom St Denis")
Re: Support for 1536 bit RSA keys? (SCOTT19U.ZIP_GUY)
Re: Support for 1536 bit RSA keys? (SCOTT19U.ZIP_GUY)
Re: Support for 1536 bit RSA keys? ("Tom St Denis")
One of the great threats to Finland are those businessmen whom I have met and who
are trying to transfer production etc. to other nations ... such as Mexico
([EMAIL PROTECTED])
Re: diffie hellman ("Henrick Hellström")
Re: diffie hellman (SCOTT19U.ZIP_GUY)
Re: Support for 1536 bit RSA keys? ("Simon Hunt")
Re: Support for 1536 bit RSA keys? ("Simon Hunt")
Re: Support for 1536 bit RSA keys? ("Simon Hunt")
Re: Support for 1536 bit RSA keys? (Erwann ABALEA)
Re: Support for 1536 bit RSA keys? (SCOTT19U.ZIP_GUY)
From: "Tom St Denis" [EMAIL PROTECTED]
Subject: Re: Support for 1536 bit RSA keys?
Date: Fri, 30 Mar 2001 14:53:58 GMT
"Sam Simpson" [EMAIL PROTECTED] wrote in message
news:VA0x6.3006$[EMAIL PROTECTED]...
Tom St Denis [EMAIL PROTECTED] wrote in message
news:3s0x6.164060$[EMAIL PROTECTED]...
"Sam Simpson" [EMAIL PROTECTED] wrote in message
news:nk0x6.2980$[EMAIL PROTECTED]...
Tom St Denis [EMAIL PROTECTED] wrote in message
news:yg0x6.164037$[EMAIL PROTECTED]...
"Sam Simpson" [EMAIL PROTECTED] wrote in message
news:650x6.2958$[EMAIL PROTECTED]...
This is very misleading. My computer idles about 80% of the
day,
but
any
idle task gets 100% of a 1.2ghz computer. So saying "it was
done
in
idle
time" is misleading since most of the time the task gets the
entire
processor...
That's exactly the same as I said above: It's using your IDLE
time.
That's like saying "amazingly he travelled the distance and kept the
car
in
1st gear" when 1st gear can reach 200mph
So what? The statement is factually correctI don't understand what
your
argument is.
My problem is that it's misleading.
ok, I think this is where we disagree.
The task didn't work using a fraction
of the cpu time.
I assure you that it did. (My background is in computer science, crypto
is
a hobby...)
It used pretty much all of it!
The fraction 99/100 is still a fraction.
Saying "factoring done in
idle time" means "factoring done using a fraction of my cpu time" to
me...
what does it mean to you?
The original quote: "It is of interest to note that Rivest predicted that
a
129-bit factorization would take 40-quadrillion years whereas in reality
it
took just 8 months
using idle cycles on computers around the globe ."
It means that, when the CPU's weren't engaged in 'proper work' (e.g. word
processing, web serving, sending faxes, whatever), it is used to run a
process that works on the factoring problem.
You're still missing the point. Saying "idle time" makes it seem like it
wasn't alot. Like if I say wanna help me in your "spare time" at work you
will say "nope too busy". Similiar line of thinking. Idle time on 500+mhz
machines is actually quite a bit.
They really should have said "factoring done on machines using a significant
portion of their cpu time". It's generally more accurate and less
misleading.
Tom
--
From: "Tom St Denis" [EMAIL PROTECTED]
Subject: Re: Support for 1536 bit RSA keys?
Date: Fri, 30 Mar 2001 14:55:11 GMT
"Sam Simpson" [EMAIL PROTECTED] wrote in message
news:9D0x6.3011$[EMAIL PROTECTED]...
Tom St Denis [EMAIL PROTECTED] wrote in message
news:tu0x6.164064$[EMAIL PROTECTED]...
SNIP
If we can't factor 768-bit keys are 2048-bit ones better?
To quote Schneier again: "If 512-bit keys are insecure today, they were
just
as insecure last month. Anyone implementing RSA should have moved to
1028-bit keys years ago, and should be thinking about 2048-bit keys today.
It's tiring when people don't listen to cryptographers when they say that
something is insecure, waiting instead for someone to actually demonstrate
the insecurity."
Or, to paraphrase: Tom *listen* to cryptographers.
This line of thinking is inherantly flawed. 1024 bit keys will be insecure
10 years from now (just assume) so that means they are insecure now?
Tom
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Support for 1536 bit RSA keys?
Date: 30 Mar 2001 14:46:28 GMT
[EMAIL PROTECTED] wrote in Ne_w6.1530$[EMAIL PROTECTED]:
Thanks for reading this.
I am trying to assess cryptographic toolkit, certificate generation
software, certificate validation soft
Cryptography-Digest Digest #43
Cryptography-Digest Digest #43, Volume #13 Mon, 30 Oct 00 06:13:01 EST Contents: Re: CHAP security hole question (Vernon Schryver) Re: Psuedo-random number generator (Tim Tyler) Re: .java.policy (i figured it out) (Tim Tyler) Searching for a good PRNG (=?iso-8859-1?Q?Tom=E1s?= Perlines Hormann) Re: DATA PADDING FOR ENCRYPTION (Tim Tyler) From: [EMAIL PROTECTED] (Vernon Schryver) Subject: Re: CHAP security hole question Date: 30 Oct 2000 00:54:48 -0700 In article [EMAIL PROTECTED], David P Jablon [EMAIL PROTECTED] wrote: ... Here's how a malicious authenticatee learns the password in CHAP: He sends a random value R, and receives Hash(password, R). In one failed run of the protocol he can verify an unlimited number of guesses for the password off-line, by comparing the response to Hash(guess_1, R), Hash(guess_2, R), etc., until guess_i == password. Please read RFC 1994 or RFC 1334, and see that is wrong. CHAP works by - authenticator sends challenge - authenticatee responds with hash of the challenge and secret - authenticator says ok or not Forgive my misunderstanding of your term "authenticatee", but neither of those documents defines it. In RFC 1994, the challenger is the "authenticator" and the hasher is the "peer". It doesn't take a genius to see that replacing "authenticatee" with "authenticator" in the attack described above is the only interpretation that makes sense. ... Wrong. A bad guy can pose as the authenticator, obtain a hashed response, and then start guessing the password offline. Ok, I misunderstood the scenario. If the bad guy can pose as the authenticator, then it is possible do a dictionary attack. However, how does a bad guy pose as the CHAP authenticator? That generally requires that the bad guy get a good guy to originate the connection to the bad guy. That is far from impossible, such as with POTS glare, but it is a lot harder today with such as ISDN, DSL, and PPP/Ethernet (cable modems) than it once was. Given the most common situations in which CHAP is used, in which at least one of the authenticators is intentionally built to be unable to originate phone calls or any kind of PPP connection, it is generally literally impossible for the bad guy to pose as th authenticator that goes first. (Because of the "oracle" problem with CHAP, it is common to have the "server" PPP peer never go first.) Aaron Spangler had a web site up for quite a long time doing exactly that, grabbing NTLM hash responses of NT passwords from people browsing by. NTLM is not the same different protocol as CHAP. In other words, there are well known reasons why I keep distinguishing CHAP from MS-CHAP. For that matter, there are reasons why MS-CHAPv2 differs from MS-CHAPv1. ... But you seem to be backpedalling now. No, as I said from the almost the first, CHAP does have weaknesses. It's simply that contrary to the claims on the Integrity Sciences web pages, CHAP has not been made significantly or even noticeably obsolete by what Integrity Sciences is selling. That's partly because a PPP implementation that requires a human to participate in the authentication dance between the computers is lame. One reason for that lameness is that good PPP implementations occasionally re-authenticate, and you usually can't ask users to repeat their password in the middle of sessions (and for obvious reasons you'd probably rather not save the human's password for re-use). For another, good PPP implementations can do symmetric demand dialing in which the phone (or other serial) link is brought up only while there is traffic. Yes, of course, you don't always want symmetric demand dialing, sometime because the link is static (e.g. SONET) and sometimes because it is very transient (e.g. dial-up to consumer ISP account). More commonly, there are business reasons for ISP's to refuse (few consumers can handle configuring their systems to receive modem calls and fewer want them). Note also that an extremely large router vendor has said in private that it does not support originating phone calls in some products to counter weaknesses in CHAP that I've mentioned repeatedly and that are unrelated to weaknesses that Mr. Jablon claims to fix with his products. Yes, it is common for a constant poor password to be used for the CHAP secret, and so a third party can discover the password by watching a succssful session and doing a lot of computing, possibly vastly reduced with a dictioncary. However, given what CHAP (not MS-CHAP) is protecting in PPP, it would be silly to worry about such dangers. Really now? That philosophy seems at least socially irresponsible. All passwords should be considered highly sensitive data. No, the value of any password depends on the value
Cryptography-Digest Digest #43
Cryptography-Digest Digest #43, Volume #12 Fri, 16 Jun 00 10:13:00 EDT
Contents:
Re: primality tests (Andrew John Walker)
Re: obfuscating the RSA private key (Mark Wooding)
Re: Random sboxes... real info (Tim Tyler)
Re: Application specific SBoxes in Blowfish? ("Sam Simpson")
Re: Cipher design a fading field? (Alan Braggins)
Re: Cipher design a fading field? (Nicol So)
Encryption on missing hard-drives ([EMAIL PROTECTED])
Re: On using compression as proper means of encryption (SCOTT19U.ZIP_GUY)
Re: Encryption on missing hard-drives (Sébastien SAUVAGE)
Re: Random sboxes... real info (SCOTT19U.ZIP_GUY)
Re: Cipher design a fading field? (Mark Wooding)
Re: Cipher design a fading field? ("Trevor L. Jackson, III")
Re: Def of "nonlinear order" (=?iso-8859-1?Q?H=E5vard?= Raddum)
Re: Cipher design a fading field? ("Trevor L. Jackson, III")
Re: Encryption on missing hard-drives (SCOTT19U.ZIP_GUY)
Re: Cipher design a fading field? (Tim Tyler)
Re: Cipher design a fading field? (Alan Braggins)
Subject: Re: primality tests
From: [EMAIL PROTECTED] (Andrew John Walker)
Date: 16 Jun 2000 11:30:27 +1000
Bob Silverman [EMAIL PROTECTED] writes:
In article 8ianjq$r15$[EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
hello all,
when i implement probabilistic primality tests,
i know that
with Millrob for one base error possibility 0.25
False. The probability is bounded above by 1/4, but the actual
probability depends on the size of p.
An exact fromula is known which requires the factorisation, I posted the
reference just a few days ago in the
"An interesting page on the Rabin-Miller PP test" thread.
Andrew
--
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: obfuscating the RSA private key
Date: 16 Jun 2000 09:39:25 GMT
Mack [EMAIL PROTECTED] wrote:
The most common form of threshold scheme relies on N-spacial geometry.
Does it? I thought the most usual threshold scheme was Shamir's, which
uses polynomial interpolation in a finite field.
-- [mdw]
--
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: Random sboxes... real info
Reply-To: [EMAIL PROTECTED]
Date: Fri, 16 Jun 2000 09:59:15 GMT
David A. Wagner [EMAIL PROTECTED] wrote:
: Nope, I stand by my statement.
Yes. Drat ;-) It turns out it was me who was dreaming :-|
I should obviously have realised this myself the first time around.
I'll have to mentally mark this area as one where my intuition is
likely to lead me astray unless I am cautious.
My apologies for exposing everyone to what turns out to have been pretty
mindless blathering on the subject.
--
__ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
--
From: "Sam Simpson" [EMAIL PROTECTED]
Subject: Re: Application specific SBoxes in Blowfish?
Date: Fri, 16 Jun 2000 11:40:25 +0100
That precisely it Tim.
--
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption
Delphi Crypto Components. PGP Keys available at the same site.
Tim Tyler [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Andru Luvisi [EMAIL PROTECTED] wrote:
: "Sam Simpson" [EMAIL PROTECTED] writes:
: [snip]
: My aim is to have a new version of Blowfish totally incompatible
with
: existing implementations
: I wouldn't expect that there would be any problems, but why?
Possibility of existence of off-the-shelf Blowfish cracking
machine?
--
__ Lotus Artificial Life http://alife.co.uk/
[EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Goodbye
cool world.
--
From: Alan Braggins [EMAIL PROTECTED]
Subject: Re: Cipher design a fading field?
Date: 16 Jun 2000 13:04:46 +0100
"Douglas A. Gwyn" [EMAIL PROTECTED] writes:
for any given example program P there is a deterministic method M
that creates a program H = M(P) that will determine in finite time
whether or not P halts. Thus, M itself is a component of a fixed
procedure T that applied to *arbitary* P will determine in finite
time whether or not P halts.
Consider all possible 1 bit programs and "Halts" outputs, and
construct the tables
( ( ( 1 ), 1 ), ( ( 0 ), 1 ) )
( ( ( 1 ), 1 ), ( ( 0 ), 0 ) )
( ( ( 1 ), 0 ), ( ( 0 ), 1 ) )
( ( ( 1 ), 0 ), ( ( 0 ), 0 ) )
We lookup the program in the first element of a pair, and output the
second element. This is four programs. One of them will give the right
answer for both cases.
So we have deterministically created a suitable program (and 3 junk
ones). We don't know which is which, so we can't use this as a
building block to the general case, but the correct program _exists_).
Now consider all possible 2 bit programs, and co
Cryptography-Digest Digest #43
Cryptography-Digest Digest #43, Volume #11Thu, 3 Feb 00 06:13:01 EST
Contents:
Re: How to password protect files on distribution CD (Vernon Schryver)
Re: Court cases on DVD hacking is a problem for all of us (Highdesertman)
Re: Court cases on DVD hacking is a problem for all of us (Highdesertman)
Re: How to choose public-key e on RSA? ("Peter L. Montgomery")
From: [EMAIL PROTECTED] (Vernon Schryver)
Crossposted-To: alt.security.pgp,comp.security.unix
Subject: Re: How to password protect files on distribution CD
Date: 2 Feb 2000 11:54:56 -0700
(I'm combining two somewhat long replies to make it easier for non-participants
to ignore both of them.)
In article [EMAIL PROTECTED],
Alan J Rosenthal [EMAIL PROTECTED] wrote:
...
If you want that something close to that mode, then use the MAC address
of an Ethernet board, and treat the Ethernet board like an old fashioned
dongle.
I did mention MAC addresses later in my article, but if you're contemplating
the replacement of the entire computer, well, the ethernet hardware is part of
the computer. Not necessarily on a separate card at all, and besides you
might want to replace your ethernet card while replacing the rest of your
computer, or the ethernet card might break and you might replace it, ...
Use a $25 10BASE-T ISA card not even connected to a network.
Also, as I understand it, the ethernet standard specifies that the
MAC address is part of the computer, not specifically the ethernet hardware
and ideally not; and in fact most non-personal-computers have their MAC
address somewhere else on the motherboard; it doesn't change when you
exchange ethernet cards; it DOES change when you change motherboards and
use the old ethernet card.
In fact, most large non-PC's have some of their MAC addresses in separate
boards. The notion of a "motherboard" is limited to small systems and
now to systems the speed or price of PC. Big systems tend to have more
than one board containing CPUs.
You have the IEEE rule backwards. A MAC address is not allowed to be used
as the serial number of a computer, although more than one outfit does
exactly that, at least with the least significant bits of a MAC address.
In some situations I've seen, the MAC address along with the system serial
number and other stuff are not on what you might call the motherboard,
but in a write-once chip on the board carrying the connectors in which
the main CPU board(s) is(are) plugged. This is so that the main board(s)
containing CPU(s), some cache(s), and sometimes some main memory can be
replaced without changing the system serial number. I've seen this is
done for the convenience of system vendor's maintenance organization, but
it also helps third party, node-locked software and license managers.
(of course, I'm not talking about PC's)
The practice of a major UNIX vendor of using a single MAC address for more
than Ethernet interface on a single machine is technically wrong in the
sense that it has long caused serious problems on networks. If for some
reason two interfaces with the same MAC address are connected to the same
broadcast domain, Very Bad Things happen. Bridges get confused. ARP
doesn't work. IP addressing breaks down. Customers complain.
That a single host owns all of the interfaces with the MAC address
prevents none of those Very Bad Things.
...
I think most software vendors that are charging real money (i.e. not
shareware pricing) prefer to know when you buy a new computer and many
even prefer to force you to buy a new license. (I'm reporting not
commending the attitudes of some business and sales people
IMHO they oughtn't be able to do this. And I also think it's a privacy
violation for them to be able to find out stuff about your computer.
They should sell you N licences, period. And reselling them shouldn't
legally be able to be prohibited by the company except for specific reasons
(e.g. some software might be available only to doctors/cops/etc).
I mostly agree with that, but there are reasonable arguments to the
contrary. When you think you're buying fancy software, you're often buying
a service instead of software. For example, you might buy a service
consisting of 500 simulated hours of the operation of an integrated
circuit. It's easy for the vendor to sell you a 1-year license for a
system of X MIPS that can simulate 500 hours in a year of real time. If
you run that software on a system 10 times faster, you'd get more of that
simulating service than you paid for.
..
write, when that software is being used by legitimate, paying users.
There is no alternative to somehow collecting real money for some of my code.
Well, this is simply not true, but it's not really on topic for this
newsgroup. (Professional programmers existed prior to the commercialization
of software.)
Really? "Commercialized software" existed
Cryptography-Digest Digest #43
Cryptography-Digest Digest #43, Volume #10 Fri, 13 Aug 99 21:13:04 EDT
Contents:
The Shocking Truth About Akelarre! (John Savard)
Re: AES finalists to be announced (David A Molnar)
Re: Digital simulation ([EMAIL PROTECTED])
Re: Future Cryptology (David A Molnar)
Re: crypto survey (David A Molnar)
Re: IEEE Computer: Staying with the Herd (David A Molnar)
Re: The Most Secure Symmetric Algorithm (not counting the one-time pad) Ever!
(JPeschel)
Re: Depth of Two ("Douglas A. Gwyn")
Re: The Most Secure Symmetric Algorithm (not counting the one-time pad) Ever! (John
Savard)
Re: The Most Secure Symmetric Algorithm (not counting the one-time pad) Ever! (John
Savard)
Re: The Most Secure Symmetric Algorithm (not counting the one-time pad) Ever!
(JPeschel)
Re: Please help a HS student with an independent study in crypto
([EMAIL PROTECTED])
Re: NIST AES FInalists are ([EMAIL PROTECTED])
Re: About Algorithm M (John Savard)
I HOPE AM WRONG (SCOTT19U.ZIP_GUY)
Re: I HOPE AM WRONG ([EMAIL PROTECTED])
Re: Smart card generating RSA keys ([EMAIL PROTECTED])
Re: About Algorithm M ([EMAIL PROTECTED])
Re: Newbie Question - Do you need to have the message when you have a digest?
([EMAIL PROTECTED])
Re: Cipher-Feedback Mode ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (John Savard)
Subject: The Shocking Truth About Akelarre!
Date: Fri, 13 Aug 1999 22:12:31 GMT
Go to this page:
http://www.cogs.susx.ac.uk/users/larryt/basque.words.html
John Savard ( teneerf- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
--
From: David A Molnar [EMAIL PROTECTED]
Subject: Re: AES finalists to be announced
Date: 13 Aug 1999 22:16:09 GMT
Bruce Schneier [EMAIL PROTECTED] wrote:
First off, please realize that this is all very subjective.
[snip opinions]
That's why I asked for opinions. :-) Thank you for giving yours, since it
does much to explain the statement which started this whole sub-thread.
Thanks,
-David Molnar
--
From: [EMAIL PROTECTED]
Subject: Re: Digital simulation
Date: Fri, 13 Aug 1999 21:38:41 GMT
In article [EMAIL PROTECTED],
Christy Fulcher [EMAIL PROTECTED] wrote:
Im am looking for a way to simulate an encryption algorithm in
electronic workbench
(or similar), for a project in electronics. My knowledge so far
consists
of simple
circuits like and, not, xor etc. Could anyone help me in suggesting an
algorithm that can
be implemented using these tools.
Try a OTP hehehe...If you are serious I would try hardware oriented
ciphers such as DES first.
If you truly are into electronics you should note any cipher or program
can be done with XOR/AND gates ...
BTW, why did you post 4 times?
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: David A Molnar [EMAIL PROTECTED]
Subject: Re: Future Cryptology
Date: 13 Aug 1999 22:34:03 GMT
John [EMAIL PROTECTED] wrote:
I wonder, if one makes the algorithms public, it is only a
matter of time before they are cracked.
You are assuming that no "un-crackable" algorithm exists. This may be a
correct statement, but I know no way of proving or disproving it. If I
did, I'd apply for tenure.
This seems to be one of the reasons why cryptography correlates with
computational complexity, by the way. If we can't prove a system secure,
the next best thing is to show that breaking the system implies that P =
NP. Then if the system _is_ broken, well, no one will care because we'll
all be too busy exploring the applications of P = NP.
Note that it may not be enough to show that breaking the system for some
instance implies P = NP; we need it to be hard on the average (I think
Doug Gwyn pointed this out as a deficiency of standard complexity theory
in a separate thread) _AND_ not amenable to efficient approximation.
Even if no "un-crackable" algorithm exists, it takes time to analyse a new
algorithm. In this case, Terry Ritter's approach of using multiple ciphers
and multiple families of ciphers makes sense. You also need a way of
updating the cipher you use on the fly; one experiemental implementation
of this is Ben Adida's "Self-Describing Cryptography" at
http://ben.adida.net/thesis/
If they aren't public,
nobody will use them. What is the solution?
Secret algorithms are deployed every day.
Some by the NSA for use in classified systems, others by the vendors
mentioned in the Snake Oil FAQ. You don't need to look any farther than
GSM phones to see what has happened when a secret algorithm was discovered
and turned out to be weaker than expected.
My point is that I'm not sure your dichotomy holds.
-David Molnar
-
Cryptography-Digest Digest #43
Cryptography-Digest Digest #43, Volume #9 Sat, 6 Feb 99 06:13:03 EST
Contents:
Re: Rational points on a curve (Jayant Shukla)
Academia ([EMAIL PROTECTED])
Re: (probably old) ideas
Re: Threat Models: When You Can't Use a One-Time Pad
Re: Implementation of SHA1 (Robert G. Durnal)
Re: Rational points on a curve (Sammy)
Re: I hate to bring up PRNGs again... (Patrick Juola)
Re: Encoding for telephone over Internet (Patrick Juola)
Re: *** Where Does The Randomness Come From ?!? *** (Patrick Juola)
Request For Help - TIA NR (Somebody)
Re: Q: Differential analysis of Blowfish ("karl malbrain")
Re: Rational points on a curve (Logi Ragnarsson)
From: [EMAIL PROTECTED] (Jayant Shukla)
Subject: Re: Rational points on a curve
Date: 6 Feb 1999 02:39:37 GMT
Sammy [EMAIL PROTECTED] writes:
Jayant Shukla wrote:
Hi,
Is there an easy way to find integer points on
the curve y^2 = a x^2 + b x + c? i.e. both x and y
are integers. The constants a, b, and c are integers
as well.
regards,
Jayant
Yes. (x,y) = (1,1) is easy. So are (2,2) (3,3), etc.
when b=c=0 and a=1. There are many easy solutions to
the equation you gave.
But maybe you were interested in cryptographic uses of
elliptic curves over a finite field like:
y^2 = a x^3 + b x + c mod pEQUATION 1
I am really interested in the curve that I mentioned
and for the case when the constants a, b, and c are
all non zero integers. The solutions x any y are also
integers.
The elliptic curve that you have mentioned, I found
methods for finding rational points on that curve.
But I see no easy way to extend those method to
quadratic curves (a x^2 + b x + c).
In one book that I have, there is a mention of a
method by Hasse to solve this problem, but no references
were given.
regards,
Jayant
--
From: [EMAIL PROTECTED]
Subject: Academia
Date: Sun, 31 Jan 1999 09:50:32 GMT
The ability of a scholar to converse with ordinary Human beings is
inversely proportional to the number of letters that follow their
name.
--
From: [EMAIL PROTECTED] ()
Subject: Re: (probably old) ideas
Date: 6 Feb 99 04:17:58 GMT
Zerebubuth ([EMAIL PROTECTED]) wrote:
: 1) Huffman encode the plaintext, and using a BSP-like method, save the tree
: and one-time-pad encode it, since the tree is fixed-length for any file then
: you only need about 2K of one-time-pad bits to encrypt it. I have a feeling
: that this is insecure, but i cant see why?
Well, one could just create a fixed Huffman tree in advance from English
letter frequencies, and then assign equivalents secretly, and use the
coding as a key. Then you have a prefix-property monalphabetic
substitution: the problem for the cryptanalyst is that he can't see where
the letters begin or end.
It's harder to solve than a regular monalphabetic substitution. But it can
still be attacked, with more text, on the basis of frequency counts.
Huffman coding obscures frequency characteristics, but it doesn't
eliminate them.
John Savard
--
From: [EMAIL PROTECTED] ()
Subject: Re: Threat Models: When You Can't Use a One-Time Pad
Date: 6 Feb 99 04:27:54 GMT
Jim Dunnett ([EMAIL PROTECTED]) wrote:
: Sending it through the post is NOT a secure means of distributing
: a key.
It is IF my threat model doesn't include anyone with access to my
recipient's mailbox. (I can always send another key if the envelope is
opened...there is a range of required security levels.)
: No doubt they are as secure but hardly more convenient. Key
: distribution raises its ugly head again. Public-Key ciphers
: neatly avoid this problem.
Except I have to authenticate my correspondent. Less key to distribute
does improve things, and I do note that public-key systems have an
important advantage.
But sometimes you do have the opportunity to distribute keys, and taking
advantage of that, rather than trusting in the difficulty of factoring, is
*not* imprudent.
: Yes. If your OTP key is secure and not re-used. But this would
: require some other crypto program to store your key. You might
: as well use PGPDisc or ScramDisc for everything...much more
: convenient.
I thought that last sentence was precisely what I was saying about the use
of the OTP for file encryption! It's useless! Except, as one poster noted,
for deniability.
John Savard
--
From: [EMAIL PROTECTED] (Robert G. Durnal)
Subject: Re: Implementation of SHA1
Date: 6 Feb 1999 01:17:48 GMT
In [EMAIL PROTECTED], [EMAIL PROTECTED]
(DJohn37050) wrote:
: Look on NIST website as www.nist.gov for specs for SHA-1
: Don Johnson
I have coded a version from these specs, in assembly language; takes
476 bytes. See sha1.zip on my site.
==
My home page URL=http://members.tripod.com/~afn21533/ Robert G. Durnal
Hosting HIDE4PGP, HIDESEEK v5.0, PGE, TinyIdea (link
