Cryptography-Digest Digest #470, Volume #14 Tue, 29 May 01 10:13:01 EDT
Contents:
Re: Good crypto or just good enough? (Mark Wooding)
Re: Medical data confidentiality on network comms (Larry Kilgallen)
Re: Turbo Small Public Key Cryptosystem (Tony L. Svanstrom)
Re: DES Crypto Myth?? (DJohn37050)
Re: Turbo Small Public Key Cryptosystem (Tom St Denis)
Re: Quantum Computers with relation to factoring and BBS (Bodo Moeller)
Re: Good crypto or just good enough? (Mok-Kong Shen)
NIST Rng Test Software (Brice)
Re: Euroean commision will recommend all citizens to use encryption in email next
week, because of echelon. ("John Niven")
Re: Euroean commision will recommend all citizens to use encryption in (Mok-Kong
Shen)
Re: NIST Rng Test Software (Mok-Kong Shen)
Re: Cool Cryptography Website! (SCOTT19U.ZIP_GUY)
Re: Discrete Log question (Lon Willett)
Re: A new technology for internet security? (Mok-Kong Shen)
Re: Cool Cryptography Website! (John Savard)
Re: Good crypto or just good enough? (Eric Lee Green)
Re: Good crypto or just good enough? (John Myre)
Certicom's ECCp-109 Challenge (call for users) (Chris Monico)
Re: A new technology for internet security? (Simon Josefsson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Good crypto or just good enough?
Date: 29 May 2001 09:18:57 GMT
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
> [1] Actually, that's obviously true of 3DES in EEE mode. It's almost
> certainly true of the more common EDE mode, although a proof of that eludes
> me at the moment.
Hmm. Interesting. Of course, it'd be true of EDE with independent
round keys (since the difference between encryption and decryption
operations is the key-schedule only).
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: 29 May 2001 05:51:48 -0500
In article <[EMAIL PROTECTED]>, Samuel Paik <[EMAIL PROTECTED]> writes:
> Larry Kilgallen wrote:
>> But some of them are susceptible to cryptographic controls.
>> Consider the issue of delegation. My doctor can see my
>> medical records. My doctor should be able to delegate
>> the ability to see those records to a specialist for a
>> limited amount of time, but without delegating unlimited
>> rights to further delegation.
>
> How? Isn't this yet another attempt at DRM or am I missing something?
I have no idea what you mean by the abbreviation "DRM", so let me
try guessing what you may have been trying to say.
Certainly anyone along the chain can photocopy a printout without
control. The control to which I am referring is over _computer_
access to the records. When I visited my doctor last month she
pulled up a graph of one of my medical statistics over time. She
has no direct access to the data -- that access is only from the
central computer when she logs in. She is not allowed in the
computer room. I would prefer she logged in with a digital signature
and released my records to a specialist only with a digital signature,
but we are not there yet. As I said, n-out-of-m key splitting can
be used for emergency room scenarios (with extensive alarming and
notification to the patient and primary care physician).
------------------------------
Subject: Re: Turbo Small Public Key Cryptosystem
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Tue, 29 May 2001 10:53:54 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> "Tony L. Svanstrom" wrote:
> >
> > Tom St Denis <[EMAIL PROTECTED]> wrote:
> >
> > > I wrote a really super small PK system for *NIX today (in about 1.5 hrs)
> > >
> > > It uses DH and RC4 to encode/decode messages. It doesn't do signatures
> > > (what's the point?). It's very compact... in linux it builds to about
> > > 32kb in size and is very fast.
> >
> > You call that "super small", wanna hear the size of the one I wrote in
> > perl...?! hehe
>
> Um yes but recall that most of the 32kb is in fact library and object
> file overhead. My actual code is very small.
I know, but real systems have perl installed, so... ;-)
> At anyrate I uploaded another copy that includes a readme :-)
/Tony
--
########################################################################
I'm sorry, I'm sorry; actually, what I said was:
HOW WOULD YOU LIKE TO SUCK MY BALLS?
- South Park -
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 29 May 2001 10:55:50 GMT
Subject: Re: DES Crypto Myth??
Actually, among the real crypies that I know, he is not thought that highly of
as a crypie. He is more of a collator and compiler. He does have access to
some good crypies.
Don Johnson
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Turbo Small Public Key Cryptosystem
Date: Tue, 29 May 2001 11:00:03 GMT
Jack Lindso wrote:
>
> This isn't a solution, PGP and the likes are cryptosystems for the common
> user who doesn't use magnetic cards, to him it's a bother as it is. Isn't
> there another way, besides, once you have a mag card you don't need to use
> passwords, just generate a prandom key and be done with it. How about
> Biometrics, is there a good enough implementation. I heard they had a
> problem with hashing the Bio data, since every time it was hashed you got a
> different result.
This is not relevant. How the password gets into PGP does matter.
If they started putting mag reader/writters in keyboards 10 years ago we
wouldn't have password problems today.
Tom
------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Quantum Computers with relation to factoring and BBS
Date: 29 May 2001 11:28:36 GMT
Scott Fluhrer <[EMAIL PROTECTED]>:
[...]
> - NP is the set of problems for which, if something has a "Yes" answer,
> there always exists a quickly verifiable proof of that "Yes" answer. For
> factoring, a "Yes" answer can be demonstrated by showing the factorization,
> which can be quickly verified.
Actually, it is not quite that easy -- you also need a proof that
primality testing is in NP: You have to make sure that you are
factoring into *primes*. Without this requirement, an algorithm that
simply returns its input would be a "factoring algorithm".
Primality testing, in fact, *is* in NP (and thus, so is factoring).
But proving this is rather involved.
--
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Tue, 29 May 2001 13:56:09 +0200
Scott Fluhrer wrote:
>
> David Wagner <[EMAIL PROTECTED]> wrote:
> > Sam Simpson wrote:
> > >Thanks for the response David. I was specifically enquiring RE Douglas's
> > >"it must be at least *slightly* more secure" statement. You show that
> they
> > >must be at least equivalent, but does your proof show that 3des must be
> any
> > >stronger than DES, rather than just equivalent?
> >
> > No, it doesn't. It seems to be very difficult to show that 3des is
> > even a little bit more secure than des. I don't know of any provable
> > justification for the "at least *slightly* more secure" statement (but
> > I'd be interested to hear if there is one!).
>
> It is well known that DES does not form a group. From that, we know that
> the set of permutations formed by 3DES is a strict superset of the
> permutations formed by DES [1].
>
> Of course, getting from "the set of permutations is larger" to "it's more
> secure in any meaningful way" is a bit tricky, but at least the first part
> is strictly provable.
>
> [1] Actually, that's obviously true of 3DES in EEE mode. It's almost
> certainly true of the more common EDE mode, although a proof of that eludes
> me at the moment.
Isn't it that in EDE mode 3DES reduces to DES when the keys
are equal? (It was the intention to provide that possibility,
if I don't err.) On the other hand, if that's the only case
for that to happen, then (assuming the chance of operator
error is negligible) do we need to condiser the possiblity
of 3DES reducing to DES (whether EEE or EDE) to be a fact
to deem 3DES to be not even a little bit better than DES?
(After all, we also don't consider a cipher to be weak
simply because there is always a non-zero chance of guessing
the right key and hence break it. Note also that, if we
can't rigorously prove a proposition A, we are normally yet
far from being able to reasonalbly speculate that 'not A'
is true.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Brice)
Crossposted-To: sci.crypt.random-numbers
Subject: NIST Rng Test Software
Date: 29 May 2001 05:06:12 -0700
Hi,
Has anyone managed/tried to compile the NIST Rng Test software on a Windows machine
(either 98 or NT) ? If so, could you help me out or send me an executable of the
compiled that i could run ?
And while i'm on the subject, what do people think of this test software compared
to DIEHARD ?
Thank you in advance for your help.
Brice.
------------------------------
From: "John Niven" <[EMAIL PROTECTED]>
Subject: Re: Euroean commision will recommend all citizens to use encryption in email
next week, because of echelon.
Date: Tue, 29 May 2001 13:28:39 +0100
> I cannot stand for the accuracty of this news report, especially as I
think
http://news.bbc.co.uk/hi/english/world/europe/newsid_1357000/1357264.stm
It's MEPs calling for encryption, not the Parliament or Commission, but it's
true nevertheless.
John
--
John Niven
(Reply through newsgroup)
"Jan Panteltje" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Sort of amazed me, this was leaked and I include the original message as
> it reached me from NOS TV in teletext, with translation.
>
> It seems Echelon is used by the US and GB for industrial espionage,
> I suppose they (the commision) thinks that by everyone encrypting their
> email Echelon will become rather useles.
>
> Here is the message:
...msg snipped...
>
> I cannot stand for the accuracty of this news report, especially as I
think
> encryption is not allowed in France, and GB is a member of the EEC.
> So it may be a hoax.
> We will have to wait and see....
> One could also ask: Does Wiersma have shares in companies making
encryption
> software... or anyone in that committee...
> or were they just testing if my keyword search program in teletext works?
> hehehe
> Regards
> Jan
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Euroean commision will recommend all citizens to use encryption in
Date: Tue, 29 May 2001 14:51:18 +0200
John Niven wrote:
>
> > I cannot stand for the accuracty of this news report, especially as I
> think
>
> http://news.bbc.co.uk/hi/english/world/europe/newsid_1357000/1357264.stm
>
> It's MEPs calling for encryption, not the Parliament or Commission, but it's
> true nevertheless.
I don't know the truth either, but I got the following stuff
forwarded by someone who received it.
M. K. Shen
==================================
==================================
===== Forwarded
From: "Armin Medosch" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Mon, 28 May 2001 12:32:06 +0200
Subject: <nettime> Echelon: new documents on economic espionage and
human rights
In a major report to be published this week, the Echelon committee
of the European Parliament has found that the conduct of
electronic surveillance activities by US intelligence breaches the
European Convention of Human Rights even when conducted,
allegedly, for law enforcement purposes. It concludes that if the
British and German governments fail to prevent the improper use of
surveillance stations sited on their territory to intercept private and
commercial communications, they may be in breach both of
community law and of human rights treaties.
In collaboration with the British journalist Duncan Campbell, the
online magazine Telepolis today launches a package of Echelon-
related material on the WWW.
Four new studies on "Interception Capabilities - Impact and
Exploitation" were commissioned by the Temporary Committee on
the Echelon Interception System of the European Parliament in
December 2000. They cover the use of communications
intelligence (COMINT) for economic purposes, legal and human
rights issues, and recent political and technological developments.
Among the key topics covered are the documentary and factual
evidence for the existence of the COMSAT (communications
satellite) intercept system known as "ECHELON".
These studies were presented to the Echelon Committee at its
Brussels meeting on 22 and 23 January 2001. The fourth study, on
new political and technical developments, was presented only in
the form of a slideshow. These studies are published with
permission from the secretariat of the Echelon Committee.
Introduction and summary in an article by Duncan Campbell:
Germany, UK breaching human rights with NSA spy link-up
Echelon system identified as "legislation-free zone"
Duncan Campbell
http://www.heise.de/tp/english/special/ech/7753/1.html
IC2001, paper 1: ECHELON and its role in COMINT
http://www.heise.de/tp/deutsch/special/ech/7747/1.html
This paper summarises the evidence for the existence of
ECHELON as a global interception system. It records official
admissions about the secret UKUSA agreement that links English-
speaking signals intelligence organisations. The paper also
provides detailed answers to questions put by the Committee. It
points out that very few media reports have provided original new
information about Echelon, and that many press reports have
enlarged on the nature of the interception systems and their
capabilities, without evidence.
IC2001, paper 2: COMINT impact on international trade
http://www.heise.de/tp/deutsch/special/ech/7752/1.html
Paper 2 sets out, with detailed sources, the case that from 1992 to
date Europe is likely to have sustained significant employment and
financial loss as a result of the U.S. government policy of "levelling
the playing field", introduced in 1991. It also refers to:
Annexe 2-1
Background papers about the U.S. Trade Promotion Co-ordinating
Committee (TPCC) and the Advocacy Center, including statements
of purpose
http://www.heise.de/tp/deutsch/special/ech/7743/1.html
Annexe 2-2
A questionaire for U.S. companies to answer in order to determine
whether or not they are deemed "American" and thus qualify for
official assistance.
http://www.heise.de/tp/deutsch/special/ech/7744/1.html
The questionnaire is also on the internet
http://www.ita.doc.gov/td/advocacy/question.htm
Annexe 2-3
Documents revealing the CIA's role in U.S. trade promotion,
obtained under the Freedom of Information Act.
http://www.heise.de/tp/deutsch/special/ech/7749/1.html
IC2001, paper 3: COMINT, privacy and human rights
http://www.heise.de/tp/deutsch/special/ech/7748/1.html
This paper reveals that Britain undertakes to protect the rights of
Americans, Canadians and Australians against interception that would
not comply with their own domestic law, while offering no protection of
any kind to other Europeans. This and other background papers
provided to the Echelon committee have prompted them to observe that
"possible threats to privacy and to businesses posed by a system of the
ECHELON type arise not only from the fact that is a particularly
powerful
monitoring system, but also that it operates in a largely
legislation-free
area."
# distributed via <nettime>: no commercial use without permission
# <nettime> is a moderated mailing list for net criticism,
# collaborative text filtering and cultural politics of the nets
# more info: [EMAIL PROTECTED] and "info nettime-l" in the msg
body
# archive: http://www.nettime.org contact: [EMAIL PROTECTED]
===== End forwarded message =====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: NIST Rng Test Software
Date: Tue, 29 May 2001 14:57:04 +0200
I like to request that he who successfully gets the NIST
package run on Windows makes the exe file publically
accessible on the net.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cool Cryptography Website!
Date: 29 May 2001 12:06:47 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On 29 May 2001 03:24:43 GMT, [EMAIL PROTECTED] (JPeschel)
>wrote, in part:
>
>>He doesn't seem to credit your site as an Internet resource.
>
I am curious Joe remember the site I pointed you to that was
a copy of your site. Did you get mad or what? I thought
you felt it was flattering. ALso its not clear to me John is
upset or not. are you john. Also if some one wants to make
a mirrir of my site feel free since nbci,com for its free pages
is seldom up.
ALso now that I am talking to you Joes what do the think
about AOL's price increase are you goinf to swatch to a real
ISP provider?
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: Lon Willett <[EMAIL PROTECTED]>
Subject: Re: Discrete Log question
Date: 29 May 2001 14:15:14 +0100
Tom St Denis <[EMAIL PROTECTED]> writes:
> I am writting a homebrew PK system (just for fun) and I was wondering
> something...
>
> I want to use the user password as the key so no private key must be
> stored on the disk (this also makes the private key portable) so I am
> using SHA256...
>
> I made a prime P such that P-1/2 is a big prime and P-1/2 is not 3
> (duh....).
>
> I take the hash of the passphrase H and convert it to a 256-bit number.
> I then use x=H^3 as the private DH exponent.
>
> Is this vulnerable to the DLP attacks which make use of limited range
> exponents?
>
> Tom
I don't believe that the key is particularly vulnerable, but neither
do I see that it is any better than just using H itself.
Consider the following: if the range of H was larger, (e.g. if H took
on values in the range 1 .. P-2), and you set x=H^3 mod P-1, then
clearly the system is equivalent to using H (H^3 mod P-1 is an easily
invertible permutation of the values 1 .. P-2). So the question is
whether or not using the restricted set of values {1, 2, 3 .. Hmax} is
better or worse than using the set of values {1, 2^3, 3^3 .. Hmax^3}.
I'm not aware of any significant difference.
A slightly better approach might be to generate all the bits of the
private key using the hash function. e.g.
x1 = hash(1 || password)
x2 = hash(2 || password)
...
x = x1 || x2 || ...
(or some other such scheme; basically seeding a reasonably strong
pseudo-RNG with the password).
I'm not aware of any _provable_ security improvements that this
provides, but it seems unlikely that SHA-256 is going to produce any
usable correlations between the different blocks, so it might be
somewhat less likely to have a vulnerability discovered.
Of course, the big problem (with the whole scheme) is that an attacker
just needs knowledge of the public key in order to try a dictionary
attack. But this is implicit in any system that derives a private key
from a password alone. Are you sure that you don't want to store at
least a salt value on the user's computer?
(And, BTW, you really should iterate the application of the hash
function, or otherwise do something that slows down dictionary
attacks).
Cheers,
/Lon
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A new technology for internet security?
Date: Tue, 29 May 2001 15:12:05 +0200
David Hopwood wrote:
>
> Mok-Kong Shen wrote:
> > A US firm claims to have developed a new technology for
> > internet security though varying the IP addresses:
> >
> > http://dailynews.yahoo.com/h/nm/20010521/wr/tech_security_dc_1.html
>
> I don't see how this would have the slightest effect against attacks on
> application-level protocols (exploiting insecure CGI scripts or e-mail
> clients that run executables, for example), which are the biggest
> practical threat anyway. Also, it introduces all the same protocol
> incompatibility problems as Network Address Translation.
It may be interesting to know how it is possible (at all)
to have a huge virtual space of IP addresses to switch
from. On the other hand, the two persons in that firm
have some special background (their peculier former
professional careers), so what is claimed might not be
simply totally unsupported marketing hype.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cool Cryptography Website!
Date: Tue, 29 May 2001 13:17:13 GMT
On 29 May 2001 12:06:47 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote, in part:
>ALso its not clear to me John is
>upset or not. are you john.
Well, I E-mailed the guy and didn't hear back. I am somewhat upset
simply because a site like this - not a mirror, just text taken from
my site and incorporated bodily, and rearranged, into an "original"
site - has the potential to place my authorship of my work into
question.
I'm hoping there's a good explanation, like this being just working
documents that weren't intended to be on the public Web - let alone
the search engines. If he were to clean up his act, though, and give
credit, then I'd be satisfied.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: Good crypto or just good enough?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 29 May 2001 13:28:51 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
On Tue, 29 May 2001 07:09:26 +0200, Stefan Lucks <[EMAIL PROTECTED]
uni-mannheim.de> wrote:
>On Mon, 28 May 2001, Eric Lee Green wrote:
>> A hash by itself simply verifies that the message came through. If you
>> then encrypt the hash [...] then you have a signed message.
>
>I don't think so. Encrypting a key-independent hash value does not
>necessarily provide a secure MAC. (Well, it depends on the choice of
>encryption, but note that I mentioned using triple DES in OFB mode above.)
Actually, it depends on the hash too. You'll note that this message, for
example, is signed via SHA1.
>
>Denote the original message by M, and assume both M and the hash value
>H(M) are encrypted using a block cipher in OFB mode (as above), or any
>binary additive block cipher. Instead of a MAC value, you have a value
> X = (M || H(M)) XOR S,
>where || denotes catenation and S is a key-dependent key stream, not
>depending on M.
Not exactly. You'd instead do
X=(M XOR S) || H(M) XOR T
in your particular situation, if you insisted upon using OFB mode. T
would be the same key, different salt value (i.e., different
stream). This, however, is a pretty bad idea with 3DES because the
block size is so small, as well as because of the expansion of the
MAC. Better would be to use ECB mode on the hash.
For that matter, with SHA1, it's arguable that
X=(M XOR S) || ( H(M || K) )
where K is some shared key value, is secure.
Or better yet, use public key encryption, and simply encrypt the hash
with your private key. This does not require a shared secret (just a
shared public key, exchanged somehow) and is thus a "better" guarantee
of authenticity for some degrees of "better".
>Assume the adversary somehow knows M. She can compute H(M) and thus
> S = (M || H(M)) XOR X.
>To provide a valid forgery for any message M', she computes
> X' = (M' || H(M')) XOR S.
>Voila!
This known-plaintext attack is a cousin of a replay attack. You'd
handle this the same way you handle replay attacks, e.g. with a MAC
outside of the encrypted data stream, which includes a
recipient-provided salt value and a sequence number. But you do have a
good point in that being able to decrypt the message does *NOT* insure
that the message was encrypted by the sender of M, and that additional
work must be done to provide the authentication function. (And incidentally,
you also provide the mathematical justification for the notion "don't
re-use salt values in OFB modes", since any other messages encrypted with
stream S are now toast).
=====BEGIN PGP SIGNATURE=====
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7E6Ld3DrrK1kMA04RAkqpAKCuz1QupiGQjlsIYVF3PUQ3c0FffACdFMO9
CM8G7ThXS7yuOzGuBKgB7tM=
=alrr
=====END PGP SIGNATURE=====
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Tue, 29 May 2001 07:24:57 -0600
Paul Pires wrote:
<snip>
> What is the true cost of labor at
> the expense of judgement?
<snip>
Many might find comp.risks interesting in that regard.
(It's moderated, basically a newsletter with collected
stories.)
JM
------------------------------
From: [EMAIL PROTECTED] (Chris Monico)
Crossposted-To: sci.math
Subject: Certicom's ECCp-109 Challenge (call for users)
Date: 29 May 2001 06:33:58 -0700
Hello all,
My apologies in advance if this get's posted twice. I sent it the other day,
but my news server seems to be down.
ECCp-109 Call For Users
=======================================================
We are coordinating an internet-distributed effort to
solve Certicom Inc.'s (http://www.certicom.com)
ECCp-109 challenge and are currently soliciting users
to help us with this.
* Homepage
The homepage for this project is at:
http://www.nd.edu/~cmonico/eccp109
* Format
The format is essentially the same as the one that Rob
Harley used to solve ECC2k-108 and other challenges.
The attack is collision based, meaning that the solution
will be found when two machines report some partially identical
results. Certicom is offering USD $10000 for the solution
of this challenge and each of the 2 users responsible for the
final solution will recieve $1000, with the remaining $8000
to be donated to the Free Software Foundation.
* Challenge Details
The specific challenge is to compute a discrete logarithm
of a point on an elliptic curve. The parameters are:
p = 564538252084441556247016902735257
a = 321094768129147601892514872825668
b = 430782315140218274262276694323197
Where the elliptic curve being considered is y^2 -x^3 -ax - b
over Z/(pZ). Our goal is to find an integer, N, such that
(44646769697405861057630861884284, 522968098895785888047540374779097)
= N*(97339010987059066523156133908935, 149670372846169285760682371978898)
where '*' is the natural action induced by the integers on the (abelian)
elliptic curve group of Z/(pZ)-rational points on this curve.
The algorithm being used to solve this challenge is, of course,
the distributed Pollard-Rho for discrete logartihms.
* The Software
The software and source code to help with this challenge are
available at the aforementioned web page. We currently have some
self-installing Windows ports and an x86 Linux port.
The x86 ports of the software are heavily optimized, with assembly
functions to do arithmetic modulo 'p'. While there is non-assembly
arithmetic included so that the code will compile on many 32-bit
machines with gcc, it is considerably slower without an assembly routine
for doing modular multiplication in Z/(pZ). There is currently no 64-bit
support at all.
------------------------------
From: Simon Josefsson <[EMAIL PROTECTED]>
Subject: Re: A new technology for internet security?
Date: 29 May 2001 15:38:47 +0200
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> David Hopwood wrote:
> >
> > Mok-Kong Shen wrote:
> > > A US firm claims to have developed a new technology for
> > > internet security though varying the IP addresses:
> > >
> > > http://dailynews.yahoo.com/h/nm/20010521/wr/tech_security_dc_1.html
> >
> > I don't see how this would have the slightest effect against attacks on
> > application-level protocols (exploiting insecure CGI scripts or e-mail
> > clients that run executables, for example), which are the biggest
> > practical threat anyway. Also, it introduces all the same protocol
> > incompatibility problems as Network Address Translation.
>
> It may be interesting to know how it is possible (at all)
> to have a huge virtual space of IP addresses to switch
> from.
Yes, especially considering:
The Invicta system uses special cards to link protected
computers to a central control unit. It lets clients decide
how often they wish to vary IP addresses and specify which
applications may be accessed on their network. The number of
IP addresses drawn on may be in the billions thanks to an
artificial increase in cyberspace, Sheymov said.
Billions of IP addresses? Perhaps they should give them to RIPE
instead to prevent the exhaustion of the IP address space...
It looks like it is some kind of NAT and/or tunneling device.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
