Cryptography-Digest Digest #915, Volume #10 Sun, 16 Jan 00 20:13:01 EST
Contents:
Re: Password example encrypt/dycrypt! ([EMAIL PROTECTED])
NTRU Cryptosystems Inc. ([EMAIL PROTECTED])
Re: NTRU Cryptosystems Inc. (David Wagner)
Re: NTRU Cryptosystems Inc. (Mok-Kong Shen)
Cracking an ADFGVX cipher ([EMAIL PROTECTED])
Re: NTRU Cryptosystems Inc. ("Michael Scott")
Re: My Encryption system (Jeff Lockwood)
Re: NTRU Cryptosystems Inc. (lordcow77)
Re: Ciphers for Parallel Computers ("Douglas A. Gwyn")
Re: Cracking DES ("Douglas A. Gwyn")
ECHELON and Monitoring (Tom St Denis)
Re: Forward secrecy for public key encryption (David Hopwood)
Re: ECHELON and Monitoring (Tom McCune)
Re: is signing a signature with RSA risky? (David Hopwood)
Re: Quantum Computers and Weather Forecasting (Matt Kennel)
Re: NTRU Cryptosystems Inc. (David A Molnar)
Re: Stage 8: Singh's Cipher Challenge (JPeschel)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Password example encrypt/dycrypt!
Date: 16 Jan 2000 21:50:33 GMT
> You can find the MDx, SHA-1 and others at
> ftp://ftp.funet.fi/pub/crypt/hash/
You've missed one - the Message Authenticator Algorithm is, as far as I'm
aware, the first Cryptographic Hash Function or Message Digest to gain
widespread acceptance. It has become a part of ISO standard 8731-2:
Approved Algorithms for Message Authentication. Even Applied Cryptography
fails to acknowledge its historical importance.
As it seems to be unavailable in electronic form, I've put HTML and PDF
versions on my web site.
Keith
http://www.cix.co.uk/~klockstone
------------------------
'Unwise a grave for Arthur'
-- The Black Book of Carmarthen
------------------------------
From: [EMAIL PROTECTED]
Subject: NTRU Cryptosystems Inc.
Date: Sun, 16 Jan 2000 21:55:01 GMT
World's Fastest Public Key Cryptography System
NTRU Cryptosystems Inc., delivers the world's fastest secure public key
cryptography system, operating more than 100 times faster than any
competitor!
Secure communications involving devices such as mobile telephones,
digital televisions, smart cards, and digital music and video players
are becoming an integral part of the new Internet economy. And
virtually every enterprise application is moving to the Internet. This
creates a need for public key security on a scale dramatically higher
than ever before. Only one public key cryptosystem meets the needs of
these advanced applications.
Wireless communication devices are joining VCRs and cable television as
pervasive mass market consumer products. NTRU provides key enabling
technology to ensure secure communications. Only NTRU operates quickly
and securely in low power devices such as mobile telephones and
portable web browsers.
Although currently in its infancy, the use of data services will
proliferate over the next five years. Users are demanding anytime,
anywhere access to Internet services and online merchants. Today, there
is relatively little concern over data security by consumers of
wireless data services. But just as happened with PC-based Internet e-
commerce, consumers will demand sufficient security before entrusting
their critical personal information, such as credit card numbers and
stock trading records, to wireless service channels.
Until NTRU, wireless security was a hit or miss affair. Wireless device
manufacturers had two choices: try to force fit inherently unsuitable
public key systems (like Certicom's ECC) into small, low power devices,
or accept secret key systems which are vulnerable to security attacks
and difficult to manage.
NTRU is ideally suited to wireless applications. On the device side, it
fits easily into mobile telephones and other portable devices. It
operates at high speeds (more than 100 times faster than ECC or RSA)
and high security levels, even on low power 8-bit processors. NTRU can
be implemented in very little memory, and, when incorporated into
silicon, with small gate counts. So users don't have to settle for
second-best security when using wireless devices
For more information, go to www.ntru.com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NTRU Cryptosystems Inc.
Date: 16 Jan 2000 14:25:47 -0800
In article <85teng$1sb$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> NTRU Cryptosystems Inc., delivers the world's fastest secure public key
> cryptography system, operating more than 100 times faster than any
> competitor!
Is there any basis in fact for this `100 times faster than any
competitor!' claim, or is this pure marketing fluff? It sure looks
like unsubstantiated marketing froth to me.
First, NTRU's own speed measurements appear to disprove this claim.
In fact, the NTRU web site repeats this `100x faster' claim *on the very
same web page* with the speed measurements that refute it: namely, their
measurements show NTRU-n263 encryption is only 12x faster than RSA-1024
(3676 blocks/sec vs. 309 blocks/sec, @ 300 MHz).
Second of all (as if that weren't enough) those measurements appear biased
and technically flawed. Those measurements are for RSA with exponent
2^16 + 1, a footnote reveals; but what the footnote doesn't tell you
is that, in practice, the fastest RSA implementations use exponent 3,
which is much faster than exponent 2^16 + 1. What a bogus methodology!
This is a lovely example of the `strawman' fallacy. Is this supposed
to inspire trust in the other claims on that website?
I just did my own set of measurements, and SSLeay's RSA-1024 encryption
with exponent 3 goes at about 1750 blocks/sec on my 450 MHz machine.
Presumably, that correspond to about 1167 blocks/sec on a 300 MHz machine,
which corresponds to a speed gap of just 3x or so -- a far cry from the
claimed 100x.
Maybe there's some reasonable justification for these `100x faster' claims.
But if so, I couldn't find them on the NTRU web page.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NTRU Cryptosystems Inc.
Date: Sun, 16 Jan 2000 23:40:20 +0100
[EMAIL PROTECTED] wrote:
>
> World's Fastest Public Key Cryptography System
>
> NTRU Cryptosystems Inc., delivers the world's fastest secure public key
> cryptography system, operating more than 100 times faster than any
> competitor!
100 times faster, but how about its strength?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Cracking an ADFGVX cipher
Date: Sun, 16 Jan 2000 22:30:13 GMT
how do you crack an ADFGVX cipher that has over 36 character (64) and
possibly homophones?
Thanx a bunch
Jack
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: NTRU Cryptosystems Inc.
Date: Sun, 16 Jan 2000 23:00:22 -0000
Behind the advertising hype at www.ntru.com, there does appear to be a PK
method worth considering. See the paper at
http://grouper.ieee.org/groups/1363/addendum.html#HPS
Some considerable mathematical talents seem to be involved. Isn't Joseph H.
Silverman the man who "wrote the book" on elliptic curves?
Mike Scott
=====================
Fastest is best.
MIRACL multiprecision C/C++ library for big number cryptography
http://indigo.ie/~mscott
------------------------------
From: Jeff Lockwood <[EMAIL PROTECTED]>
Subject: Re: My Encryption system
Date: Mon, 17 Jan 2000 09:49:24 +1100
Jeff Lockwood <[EMAIL PROTECTED]>
PGP public key:
homepages.ihug.com.au/~satan/pgpkey.asc
On Sun, 16 Jan 2000, D10n... [o] wrote:
> <snip all>
> R.A.T. encryption is quite good. It's inovative. When I saw that the base
> functions were XOR's I felt sure it would be easy to crack but I was mistaken.
> There is not enough information to reverse engineer the ciphertext. Also,
> identical letters are not encrypted the same 99.9% of the time. Those few times
> when an individual letter is encrypted that same as a previous occurance makes
> things just that little bit harder.
>
> The encryption and decryption routines are small and fast and there is a nice
> sized key. As previously stated, this system may be open to brute force attacks.
> Given the size of the key this would involve some great time with a normal home
> computer but perhaps tens of hours with a super computer.
>
> After analasys I must say that I still like this encryption routine very much.
> However, and here comes the bad news, I was able to create a streamlined
> 'educated' brute force attack which could provide a crack one my 'slow' pentium
> 100.
>
> The key array was mapped using key pointers A and B using your terminology. If you
> look at the results of any encrypted text, the ascii values for each character
> trace the route where B will access the 256 byte key table. (now to be known as
> array D[n])
>
It seems , that exposing a value that is used as one of the indexes in the
next iteration was not a good idea at all.
The Fix:
create another array of 256 bytes; where each location containes an
index into the key array. call it K-index;
eg:
k-index[0] contains the location of 0 in the key,
k-index[1] contains the location of 1 in the key;
Now , instead of outputting B , I'll output k-index[B] .
in the decode routine, X will now become key[X].
That ought to do it.
Jeff Lockwood
------------------------------
From: lordcow77 <[EMAIL PROTECTED]>
Subject: Re: NTRU Cryptosystems Inc.
Date: Sun, 16 Jan 2000 15:24:49 -0800
RSA with low exponents may not be equivalent to factoring. I really
don't think it's neccesarily prudent to use an encryption exponent of
3. That notwithstanding, I believe the 100x figure refers to generation
of public/private key pairs. It's really very easy in the NTRU
cryptosystem, as you don't have to worry about implementing/optimizing
large number arithmetic, just manipulating polynomials over the ring of
truncate polynomials. It can be programmed from scratch in perhaps 3 or
4 hours, depending on how rusty one is at programming the algorithm for
finding the inverse of a polynomial.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Ciphers for Parallel Computers
Date: Sun, 16 Jan 2000 23:34:04 GMT
Mok-Kong Shen wrote:
> If one can arrange that brute-force is the only practically viable
> approach of attack, ...
Almost never the case.
> In an admittedly very imprecise sense I suppose that the analyst is
> generally forced to brute-force if the algorithm design is such that
> the whole scheme cannot be formulated in terms of a small set of
> mathematical equations of fairly simple nature with the key as
> the variable.
Also almost never the case. However, just because one has a set of
equations doesn't mean that they are easy to solve. For example,
known PT and CT might yield (upon plugging in all those constants):
K0(1+K2)K3 + (1+K0)K1K2K3 + K1K2(1+K3) = 0
K0K2 + (1+K0)(1+K1)K3 + K1K2K3 = 0
(1+K1)(1+K3) + K0K1(1+K3) + K0K3 = 0
K0(1+K1)(1+K3) + K1(1+K2)(1+K3) + K0K1K2K3 = 0
which is a set of 4 simple equations in GF(2)^4, but so far as I
know there is no general methodology for solving such systems that
takes appreciably less work than a brute-force search over the domain
(for larger systems, anyway). If it were a set of *linear* equations
it would be easy to solve, but no cryptographer who knows his business
would design a system whose encryption equations were linear in the
key variables.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cracking DES
Date: Sun, 16 Jan 2000 23:39:37 GMT
Paul Schlyter wrote:
> OK, but then you must have some other way to determine whether
> you've obtained the correct cleartext or not.
That's pretty easy, unless the PT has no characteristics that
distinguish it from a uniformly random set of bits.
ZFUDAFYLAVBQPOCBKPAGUSRRGNCPQEGFN
vs.
NOWISTHETIMEFORALLGOODMENTOCOMETO
There are several simple statistical tests that can distinguish
between such putative PTs, and for a large sample they are
highly reliable.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: ECHELON and Monitoring
Date: Sun, 16 Jan 2000 23:55:15 GMT
Just by a previous thread titles I can see ignorance around. What does
it mean that <insert group name here> watches this group? Didly. I
read this group too, am I a threat?
Seriously people...
tom
--
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 17 Jan 2000 00:11:44 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Forward secrecy for public key encryption
=====BEGIN PGP SIGNED MESSAGE=====
David Wagner wrote:
>
> In article <[EMAIL PROTECTED]>,
> lcs Mixmaster Remailer <[EMAIL PROTECTED]> wrote:
> > The latter idea was proposed by Adam Back on the Cypherpunks list on
> > May 31, 1998:
http://www.inet-one.com/cypherpunks/dir.1998.05.25-1998.05.31/msg00171.html
> >
> > The ensuing discussion did not seem very promising, though. It was
> > hard to find a scheme where the key holder had a significant edge.
> >
> > He needs to be able to compute discrete logs efficiently while making
> > sure that an attacker who may have vastly greater resources could not
> > factor the modulus or compute discrete logs.
>
> Here is an idea for an improvement which I didn't see on cypherpunks.
[...]
> But what if we choose n as the product of, say, four primes, n=pqrs?
It was there, and also in Maurer's paper.
I see that Adam Back saw the exact same quote in Handbook of
Applied Cryptography that I did :-) :
# Maurer and Yacobi [824] (modifying their earlier proposal [823])
# propose an identity-based one-pass key pre-distribution scheme
# using composite-modulus Diffie-Hellman, featuring implicitly-
# certified public key-agreement keys essentially consisting of
# a user's identity (or email address); the corresponding private
# key is the discrete logarithm of this, computed by a trusted
# authority which, knowing the factorization of an appropriately
# chosen modulus n, can thereby compute logarithms.
A 1996 update of [824] is on Ueli Maurer's web page:
http://www.inf.ethz.ch/personal/maurer/publications.html
ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/dcc.ps
(Isn't the web wonderful?)
Looking at this paper, and at <http://www.inet-one.com/cypherpunks/
dir.1998.06.01-1998.06.07/msg00041.html>, it seems we are all
thinking of basically the same approach:
# Maurer suggests as appropriate parameters a modulus n which is a
# product of three or four prime values each of 60-70 digits
# (200-230 bits). Each prime p should be such that (p-1)/2 is also
# prime. This will provide a modulus of up to about 920 bits.
#
# According to the paper's analysis, the best algorithm for attacking
# a number of this form is elliptic curve factoring, which is suitable
# for finding relatively small factors. As of 1991, the largest factor
# found using this method had 38 digits. Finding a 70 digit factor would
# take 270 times longer.
#
# Creating keys will require solving the discrete log problem modulo
# each of the primes. Maurer states that for primes of 65-70 digits
# the algorithm is feasible on a small to medium size computer, again
# as of 1991.
John Savard:
> I *think* that known factoring algorithms aren't any better at
> factoring product-of-four-prime composites than they are at factoring
> RSA-composites of the same size.
The problem is that ECM can now factor numbers where the smallest factor
is about 54 decimal digits (~180 bits), and is very close to being able
to find factors of 60 digits (~200 bits).
According to a post by Paul Zimmerman, with title "New ECM record: up
to 60 digits", in sci.crypt on 5th January:
# On December 26, 1999, Nik Lygeros and Michel Mizony, two math researchers
# from Lyon (France), found a prime factor of 54 digits of a 127-digit
# composite number with GMP-ECM, a free implementation of the Elliptic
# Curve Method (ECM). According to the table maintained by Richard Brent [1]
# this is the largest prime factor ever found by ECM. The previous record was
# hold by Conrad Curry with a 53-digit prime found in September 1998.
# [...]
# In a recent paper [8], Richard Brent extrapolates the ECM record to be
# of D digits at year about 9.3*sqrt(D)+1932.3. This would give a record
# of D=60 digits at year Y=2004. We strongly believe 60 digits will be
# reached before, perhaps already in 2002 or even this year!
#
# [1] ftp://ftp.comlab.ox.ac.uk/pub/Documents/techpapers/Richard.Brent/
champs.txt
# [...]
# [8] Some Parallel Algorithms for Integer Factorisation, Euro-Par 99, cf
# ftp://ftp.comlab.ox.ac.uk/pub/Documents/techpapers/Richard.Brent/
rpb193.dvi.gz
I reckon that something like 6.9*sqrt(D)+1948 is a more realistic fit
(for public distributed attacks, not taking into account dedicated
hardware). That gives 77 digits (~256 bits) in about 2008. Given that
the whole purpose of forward secrecy is to prevent "old" messages from
being read, this means that 256 bits is not really long enough.
If you make the primes much longer than 256 bits, it's too difficult
to do the discrete log. Note that unlike the original identity-based
scheme, the forward-secret scheme requires *each user* to be able to do
the discrete log computation, so precomputation doesn't help as much.
(Does anyone have any estimates of how long it takes to compute a
discrete log modulo a 256-bit prime, using index calculus, on a current
single-processor PC?)
The Pohlig-Hellman variant also seems to be impractical at the moment,
because to get a work factor of 2^80 for the attacker, the user needs
to do 2^40 operations to create a key pair. This might be reasonable
if it only needed to be done once on scheme setup, but is not reasonable
for a typical user's single machine.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOIJeFTkCAxeYt5gVAQFy9gf/V041Dwkg/ahLxWdxUQ2VByaddtfHo/Kw
uc13PCJaXEBHmChmcf+xmVsyBBpvM+HRTCa7A94Q6mjE+B8jHpFui7h12JxHbkkL
M5NyQXLvs5WXMwx3SI2vIDGK5B/m9EQmgAsgIM0fovLR+WfRsZWIpXfY1+sTldIK
YOxfspPoDfLrixJToFxj4wC2mpKynueC5QHUGSv/qzxmmk8WAK3+KWSoPv3ZZnv3
nLTcEJAfRqEXNoqKI/r6svF1ue0BWDqP45+Ojbg+bsZ8k3a3YuHuBJ3KLlZcuftI
GhY2rY2d7wjMI24hY349G4yDUaywHv47o9RyEfYtMs0vGDCwePzUwQ==
=qCyA
=====END PGP SIGNATURE=====
------------------------------
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: ECHELON and Monitoring
Date: Mon, 17 Jan 2000 00:19:36 GMT
In article <85tlov$6q2$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>Just by a previous thread titles I can see ignorance around. What does
>it mean that <insert group name here> watches this group? Didly. I
>read this group too, am I a threat?
Gosh Tom, you seem pretty scary to me! :-)
------------------------------
Date: Mon, 17 Jan 2000 00:25:41 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: is signing a signature with RSA risky?
=====BEGIN PGP SIGNED MESSAGE=====
Tim Tyler wrote:
>
> Anton Stiglic <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
[...]
> :> If the message's signature verification fails, you /know/ you are not
> :> using the correct key to decrypt (assuming the message is not corrupt).
>
> : O.k., I see. But then again, there are plenty of ways
> : for you to found out if you are decrypting with the
> : write key or not, simply by observing the message you
> : get when you decrypt, depending on the system, you will
> : probably be looking for something specific.
>
> Perhaps your file will be compressed? If so - if the compression is
> good enough - all your decrypts may resemble plausible messages - or
> they may resemble them closely enough that rejecting them
> *automatically* is a little bit tricky.
No, this is a myth. Compressed text (and most other compressed structured
data) is usually not significantly more difficult to detect than
uncompressed text or structured data.
> : One example would be a specific header like "From: ".
>
> Normally, such a text is in a header, and isn't encrypted in the first
> place.
Often headers *are* encrypted, and for good reason. It may be just as
important to keep secret the title of a message, say, or the exact list
of final recipients, as it is to keep secret the message body.
Failing to encrypt headers when they should be encrypted, is a much
more common cause of security problems than the reverse.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOIJhOTkCAxeYt5gVAQGQKAf/Umw/5Z8YJ+YgmRYxYSK5pUrKKrw5EleX
EjYPcNyL8Q5ZzxTGNsPzVkMR0gxSwJnGz5jHCX7AAS4SSygUzCH5MkOgXG0RAQj6
qOUvcG7knXvhX3xtfHOs8+wjgOYy3C/vNrLaClRtg8izWr6prsn0xbjyIR5jhLJ7
iD/YrNLHToW2DbSKeSsKLWIQL/huvUi8aWIvP7rUNiLOz5OsPBUWLrUY0tumxzfT
f6BmChcGOnTvLelDU2hW7/XiDh+g/v6M35ZSe2KdH4c+vpR9sOqKTbcMp1V8F8lk
xm/k/9kvrZKoRxCtPWvg7JC7r/FfyLdS/wfZcf+AxgHVsGNktC185Q==
=jKEd
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Matt Kennel)
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
Date: 17 Jan 2000 00:59:28 GMT
Reply-To: mbkennel@<REMOVE THE BAD DOMAIN>yahoo.spam-B-gone.com
On Thu, 02 Dec 1999 23:13:36 GMT, John Savard <[EMAIL PROTECTED]> wrote:
:Joseph Bartlo <[EMAIL PROTECTED]> wrote, in part:
:
:>My initial comment is that although an interesting concept, I think the
:>entire system must be considered, as do any intelligent modifications
:>on it. What does your concept say about a person dropping dry ice in
:>a cloud & causing rain ? Or dare I say with the risk of extreme criticism
:>of people in the group who evidently feel this is completely impossible,
:>that possibly from another being with far greater capabilities ?
:
:>If you are talking about a *perfect* forecast, even if a butterfly flapping
:>its wings disturbed the weather 2 weeks later a *known way*, you'd still
:>have to know when & where it'd flap its wings :)
:
:No; my post specifically states that while the *butterfly effect* sets
:an _irreducible_ limit to forecasting, at present the number of sites
:measuring the wind/air pressure/temperature leaves holes big enough
:for things to slip through that _don't_ exist to create random
:perturbations in the weather.
Right now, better weather forecasting (in say traditional measures
like "mean squared error of 500 mb heights") would be most improved by
better and denser observations.
This means money: probes and physical sensors and operational networks.
However, there is another issue which involves redefining "better"
forecasting, i.e. being able to estimate probability distributions of
potential events, giving forecasts and confidence levels like any
normal statistician would.
For this, increased computer power would be quite useful, but still
there are theoretical issues involved in choosing your axes to make
perturbations on--- you have enough computer power for maybe 16 when
there are a few 10^6 degrees of freedom counting naively.
Quantum computers aren't going to do anything that useful soon enough
to worry about it.
:http://www.ecn.ab.ca/~jsavard/crypto.htm
--
* Matthew B. Kennel/Institute for Nonlinear Science, UCSD
*
* "To chill, or to pop a cap in my dome, whoomp! there it is."
* Hamlet, Fresh Prince of Denmark.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: NTRU Cryptosystems Inc.
Date: 17 Jan 2000 00:54:45 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
> In article <85teng$1sb$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>> NTRU Cryptosystems Inc., delivers the world's fastest secure public key
>> cryptography system, operating more than 100 times faster than any
>> competitor!
> Is there any basis in fact for this `100 times faster than any
> competitor!' claim, or is this pure marketing fluff? It sure looks
> like unsubstantiated marketing froth to me.
The marketing at ntru.com has never been very good. For a while the page
claimed that "No one has ever tried to parallelize the LLL algorithm."
That is false and has been since at least 1991. The good news is that
this particular claim has been removed from the site. An e-mail inquiry
revealed that the authors of the system are aware of parallel LLL, and in fact
have tried to take it into account in recommending key sizes. I do not see where
this is stated on the NTRU site. :-(
It's probably better just to ignore all the text and go straight to the
conference papers. Including the ones with the footnote about
"Academic papers generally try to make strong claims (to avoid
the research appearing as a failure),"
(although I can't find either of them online ?)
A while back on the P1363 mailing list, there was a call for comments about
NTRU. I don't know if it's finished yet. The results will be very interesting to
read.
Personally, I think it is a system which I should know much more about than I
currently do. In particular, I need to figure out why and how it is different
than other polynomial schemes which have been proposed and broken horribly over
the years.
Thansk,
-David
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Stage 8: Singh's Cipher Challenge
Date: 17 Jan 2000 01:08:07 GMT
Mark VandeWettering [EMAIL PROTECTED] writes:
>It was about this time that I discovered the following webpage:
>
>http://www.fortunecity.com/skyscraper/coding/379/gillog1.htm
>
>which seemed to verify the basic idea behind the approach I was
>considering. I considered this considerable morale boost (since I don't
>_really_ know what I am doing :-)
Good article, isn't it! I got Jim's permission a couple
months ago to upload it. I believe my site is the only place
on the web where the article exists.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
** 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
******************************
