Cryptography-Digest Digest #862, Volume #11 Fri, 26 May 00 04:13:01 EDT
Contents:
Re: Is OTP unbreakable? (Greg)
Re: pentium timings and RC5 code (Greg)
Q: appropriate number of key-uses before replacement?
([EMAIL PROTECTED])
Re: Is OTP unbreakable? ("Douglas A. Gwyn")
Re: list of prime numbers ("Douglas A. Gwyn")
Re: Help on factoring large numbers (100+ digits) (Scott Contini)
Re: NTRU Anyone? (Scott Contini)
Re: list of prime numbers (John Savard)
Re: bamburismus (John Savard)
Re: Schnorr patent and DSA (James Moore)
Re: appropriate number of key-uses before replacement? ("Lyalc")
Re: Another sci.crypt Cipher ([EMAIL PROTECTED])
quantum computation (Koji Katakura)
Re: Q: appropriate number of key-uses before replacement? (S. T. L.)
interval arithmetic (was: Re: More on Pi and randomness) (Jonathan Thornburg)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out point? ("donoli")
Re: Matrix key distribution? (Erich Schnoor)
Re: Matrix key distribution? (Erich Schnoor)
Re: Base Encryption: Revolutionary Cypher (wtshaw)
Re: Retail distributors of DES chips? (David Hopwood)
Re: Short Secure Serial Numbers (David Hopwood)
Re: A Family of Algorithms, Base78Ct (Mok-Kong Shen)
Re: quantum computation (Mok-Kong Shen)
Re: bamburismus (Mok-Kong Shen)
Re: NTRU Anyone? ("Antoine Joux")
OAP-L3: Version 5.x Revealed (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Thu, 25 May 2000 23:33:05 GMT
> ...is finite, the same number of possible keys." Of
> course, "it is shown" refers to arguments later in his paper.
And of course you really don't need any math to state the obvious,
now do you? The statement you quoted stands on its own merits.
--
There is only one gun law on the books- the second amendment.
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: pentium timings and RC5 code
Date: Thu, 25 May 2000 23:41:05 GMT
> No they are saying it's possible to time it, just that my code
> sucks. Well Guys go ahead.
Well I disagree and as someone who has done this in the past I think
I know what I am talking about. The Pent is extremely subject to
its environment and thus the environment prevents you from timing
anything ran on a Pent. The only way to do it is to manufacture
a mother board that cranks the maximum through put of a Pent, then
write your own OS that will NEVER interrupt your code flow, and will
never allow a peripheral to access the bus and mess up the bus timings,
ect. But then this is unrealistic.
You can write your code to run say 100 bytes per microsecond under
such an unrealistic OS. Then run it in windows
and get it to run 80 bytes per microsecond.
You can then tune it to produce 90 bytes per second under the
unrealistic OS and 110 bytes under Windows.
So what have you gained by measuring anything in the first place?
--
There is only one gun law on the books- the second amendment.
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Q: appropriate number of key-uses before replacement?
Date: Fri, 26 May 2000 00:05:30 GMT
Hello all. The literature suggests rotating keys
regularly, but I have yet to see suggestions on
how often is often enough?
For a 160-bit MAC, with a 2048-bit RSA, how many
encryptions are too many? Changing keys often
means the keys are more susceptable to tampering
in-transit...
There must be a happy medium, but I don't know
where to start. :)
Suggestions? Followups to [EMAIL PROTECTED]
would be most convenient for me, though replies to
the group will work. :)
Thanks! :)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Fri, 26 May 2000 00:24:52 GMT
Greg wrote:
> And of course you really don't need any math to state the obvious,
> now do you?
History has shown that "the obvious" is *especially* in need of
carefully reasoned proof. Your informal "proof" of OTP security
is so sloppily phrased that similar "reasoning" could be applied
to some systems which definitely can be cracked; i.e., it is not
a valid proof.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: list of prime numbers
Date: Fri, 26 May 2000 00:27:53 GMT
Lyalc wrote:
> One simple explanation may be:
> With enough primes, the chances of being able to factor any 'n' used in
> someones Public key increase.
Not really. Dividing by known primes one at a time is not an effective
method of factoring integers of that size.
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: Help on factoring large numbers (100+ digits)
Date: 26 May 2000 01:19:13 GMT
In article <[EMAIL PROTECTED]>,
Daniel <[EMAIL PROTECTED]> wrote:
>1) Is there a general method which allows calculating (large) prime
>numbers (except Erastothenes'Sieve which is rather slow)
>
>2) Is there a general method for factoring large numbers which contain
>over 100 digits?
>
>All help greatly appreciated. Thanks
You should visit the FactorWorld web site that I'm building for
answers to factoring questions:
http://www.maths.usyd.edu.au:8000/u/contini/factoring/FactorWorld.html
Scott
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: NTRU Anyone?
Date: 26 May 2000 01:32:28 GMT
In article <8gkb8c$1as$[EMAIL PROTECTED]>, Greg <[EMAIL PROTECTED]> wrote:
>Anyone know anything about NTRU public key encryption? Is it
>strong? Is it useful? Is it much faster than RSA or ECC?
>
It is a lattice based cryptosystem which seems to be strong so far,
but keep in mind that many of these lattice based cryptosystems
have been crushed using LLL. I recently downloaded a nice survey
on lattices in cryptology by Nguyen and Stern, which I definitely
recommend reading. You can get it from Nguyen's web site:
http://www.di.ens.fr/~pnguyen/
It comments about NTRU's resistance to lattice attacks (so far).
However, like RSA, proper padding is necessary for NTRU - otherwise
the encryption leaks information about the message, and there are
attacks which are effective if proper padding is not used.
Scott
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: list of prime numbers
Date: Fri, 26 May 2000 01:40:35 GMT
On Thu, 25 May 2000 16:46:17 GMT, [EMAIL PROTECTED] (Daniel)
wrote, in part:
>I don't know if this is public domain or not, but can we get a list
>with the (recent) prime numbers (up to 150 digits)?
>All help greatly appreciated
A 150-digit prime number is not a major mathematical discovery. There
is a page of "prime number records" on the Internet, but it deals with
primes that are tens of thousands of digits in length.
Programs like PGP generate prime numbers of 150 digits at random,
taking several minutes to do so. (And, as others have noted, there are
too many such primes to list: otherwise, RSA would have no security.)
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: bamburismus
Date: Fri, 26 May 2000 01:42:23 GMT
On Thu, 25 May 2000 06:03:52 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>The
>last I heard, 3DES was one of the systems that *no*body was
>reading with any method substantially better than a brute-force
>key search, but (a) it's not the only system being used and (b)
>it's among the family of systems I suspect *can* be cracked
>along the lines of my now-defunct research project of a couple
>of years ago.
Although that is not terribly definite, in my simplicity I would tend
to consider such a thing an injudicious revelation even so.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: James Moore <[EMAIL PROTECTED]>
Subject: Re: Schnorr patent and DSA
Date: Thu, 25 May 2000 22:15:24 -0500
Reply-To: [EMAIL PROTECTED]
On Wed, 24 May 2000, Roger Schlafly <[EMAIL PROTECTED]> wrote:
>> Was the question of DSA being covered by the Schnorr patent ever
>> resolved?
>Yes, it was established that the Schnorr patent does not cover DSA.
>Schnorr turned over the patent rights to Public Key Partners,
>and later to RSA Data Security. The subject was litigated,
>and they renounced any patent coverage in court.
Do you know where a published record of this might be found?
Thanks,
James Moore
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: appropriate number of key-uses before replacement?
Date: Fri, 26 May 2000 13:25:20 +1000
A lower bound is 1 key, one message - for symmetric AND public key methods
Lyal
[EMAIL PROTECTED] wrote in message
<8gkf4b$65f$[EMAIL PROTECTED]>...
>Hello all. The literature suggests rotating keys
>regularly, but I have yet to see suggestions on
>how often is often enough?
>
>For a 160-bit MAC, with a 2048-bit RSA, how many
>encryptions are too many? Changing keys often
>means the keys are more susceptable to tampering
>in-transit...
>
>There must be a happy medium, but I don't know
>where to start. :)
>
>Suggestions? Followups to [EMAIL PROTECTED]
>would be most convenient for me, though replies to
>the group will work. :)
>
>Thanks! :)
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Another sci.crypt Cipher
Date: Fri, 26 May 2000 03:15:21 GMT
In article <[EMAIL PROTECTED]>,
tomstd <[EMAIL PROTECTED]> wrote:
> The cipher I was talking about earlier was not broken by my
> attack because I used an invalid model (counting sboxes). So I
> updated my paper, cleaned up the source code and voila.
>
> The rerefence source is at
>
> http://www.tomstdenis.com/tc1ref.c
>
> And the paper in word97 format (sorry I can't get to the TOM
> site to make it into .ps or .pdf format) here
>
> http://www.tomstdenis.com/tc1.doc
>
> I made some observations but I have yet to break the cipher.
>
> Tom
Tom,
Just a quick look. There is a class of 2^32 weak keys. When all four
input bytes are the same, the slide attack will be useful or so it
appears. GOST also has this property.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Koji Katakura <[EMAIL PROTECTED]>
Subject: quantum computation
Date: Thu, 25 May 2000 22:27:52 -0500
Does anyone tell me news groups for quantum computing?
Thanks in advance.
Koji
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: Q: appropriate number of key-uses before replacement?
Date: 26 May 2000 05:03:25 GMT
<<For a 160-bit MAC, with a 2048-bit RSA, how many
encryptions are too many? Changing keys often
means the keys are more susceptable to tampering
in-transit...>>
I don't know, but I'm almost certain it'll be something godawful like 10^81
messages. I.E., don't worry about it, unless you're using a sucky algorithm,
in which case you should first worry about the algorithm.
-*---*-------
S.T. "andard Mode" L. ***137***
STL's Wickedly Nifty Quotation Collection: http://quote.cjb.net
Join the Minions of Orthodoxy today!
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Crossposted-To: sci.math.num-analysis
Subject: interval arithmetic (was: Re: More on Pi and randomness)
Date: 26 May 2000 07:14:38 +0200
[[I've added a cross-post to sci.math.num-analysis, and redirected
followups there, because interval arithmetic really belongs there, not
in sci.crypt.]]
[[I _think_ I've correctly unwrapped the nested quoting here, but if
I've mistakenly attributed anyone's words to someone else, my apologies.]]
In article <8gijl9$cp5$[EMAIL PROTECTED]>, I wrote
> Such "probabilistic [[error analysis]]" is *very* dangerous,
> because it almost invariably
> neglects correlations between the errors in different variables.
In article <[EMAIL PROTECTED]> "Douglas A. Gwyn" wrote:
>> True; one should use such methods only when the quantities being
>> combined have independent errors, or when one can explicitly
>> treat any correlation that may exist.
>>
>> Interval arithmetic has a similar problem in the opposite direction.
In article <[EMAIL PROTECTED]>,
Tony T. Warnock <[EMAIL PROTECTED]> then responded
>Actually interval arithmetic does not have this problem. This is because
>intervals are the most pessimestic way of viewing things. Enclosure is the
>primary virtue of interval arithmetic. If no divisions or intersections (or
====================================
>some other operations) are done, the intervals expand proportionally to the
======================
>number of operations. The statistical errors expand proportional to the
>square root of the number of operations.
That qualification is a rather important one, and rules out a lot
of algorithms. In general, a naieve replacement of all floating-point
numbers by intervals results on very pessimistic error bounds, i.e.
quite often the final output intervals are just (-infinity, +infinity).
While certainly _correct_, this is usually less than satisfying to
the user/customer.
To get good results from interval arithmetic generally requires using
special interval-friendly algorithms. These exist for some problem areas.
Alas, I don't know of any interval-friendly algorithms for (to name a
problem area I'm particularly interested in) numerically integrating
nonlinear systems of PDEs. Moreover, interval arithmetic only really
deals with (the easier) part of the errors in numerically solving such
a problem: We really make *two* types of approximations/errors:
(1) We discretize the problem, lowering it from an infinite-dimensional
continuum problem to a finite-dimensional algebraic one.
(2) We approximately solve the discrete problem using finite-precision
arithmetic.
Interval arithmetic can be very useful in controlling and bounding (2)
errors, but so far as I can see it has nothing to say about the (1) errors.
What's worse, (1) errors normally dominate in (non-interval) PDE
computations.
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
"There isn't a security vulnerability in Outlook involved in this at all."
-- Scott Culp (Microsoft) providing "spin" on the "I Love You" mail virus
------------------------------
From: "donoli" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out point?
Date: Fri, 26 May 2000 05:30:30 GMT
EE Support wrote in message ...
>Hi,
>
>EE Tech Support here.
>
>Greetings to those genuine people who continue to support our
>wonderful Evidence Eliminator software.
>
>Isn't it amazing how many "Anonymous" or semi-anonymous "people",
>often they have big-sigs with PGP too, are spending all their time and
>effort broadcasting false reports about our wonderful software.
>
###########
snip
At this point in time I am neutral on this debate, as I was with the Aureate
debate. What I don't understand is, in both cases, the side in favor of the
software company, claims that posts from anonymous posters are less valid
than someone w/ a traceable e-mail address. To me, it makes no sense at all
even though I am not posting anonymously.
donoli.
###########
------------------------------
From: Erich Schnoor <[EMAIL PROTECTED]>
Subject: Re: Matrix key distribution?
Date: Fri, 26 May 2000 08:25:33 +0200
Michael Brown schrieb:
> Are there any other matrix encryption things around?
>
> Michael Brown.
Good morning,
there is a "multi-matrix" program at
http://www.telecyper.com/cypher2u.htm
Sorry, the explanations are in german language, but
the demo programs (can be downloaded) are in
English.
Best greetings
Erich Schnoor
------------------------------
From: Erich Schnoor <[EMAIL PROTECTED]>
Subject: Re: Matrix key distribution?
Date: Fri, 26 May 2000 08:35:28 +0200
Erich Schnoor schrieb:
>
> Good morning,
>
> there is a "multi-matrix" program at
>
> http://www.telecyper.com/cypher2u.htm
>
Sorry, the URL is:
http://www.telecypher.com/cypher2u.htm
Erich Schnoor
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Base Encryption: Revolutionary Cypher
Date: Fri, 26 May 2000 00:22:17 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> Tim Tyler wrote:
>
> > ...but you can't see a failure to get avalanche in *any* base and have
> > good overall diffusion properties. If your system exhibits good
> > avalanche properties, it should not be possible to transform it into
> > another base, and watch the avalanche disappear. If you can do this, the
> > system has undesirable cheracteristics in that base.
> >
> > This is the case Eric was describing. He wasn't seeing avalanche, and
> > erroneously concluding that therefore, the effect would happen in all
> > bases. He was seeing a /lack/ of avalanche - and concluding that the
> > system was broken.
>
> Pardon, I haven't yet fully understood you. The first paragraph seems
> to says that avalanche, if present in one base, should manifest in another.
> I guess that it logically follows that if avalanche is not observable at
all in
> one base, then it shouldn't manifest in another. But this seems to
> contradict the content of the second paragraph.
>
> M. K. Shen
Best to have as good a look at the data as possible. Some time ago there
was program that let you get a three dimensional view of data. After
feeding it with a prng series, the lack of randomness was most apparent
when walking around the data. So is the case with bases, just gives you
more prospective.
--
Secrets that are told or available are not secrets any more, surely
not trade secrets. Security of secrets is no dependant on someone
else's stupidy, only in your making them available in any form.
------------------------------
Date: Fri, 26 May 2000 08:07:15 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Retail distributors of DES chips?
=====BEGIN PGP SIGNED MESSAGE=====
Mark Wooding wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > That's not true. This cipher could simply be
> >
> > Ek(P) = P xor K
> >
> > unless you test it.
>
> Yes, but the point is that, in theory, DES is completely deterministic.
> If you have a DES chip, you can feed known keys and plaintexts in it,
> and verify that you get the right answers against some other known and
> trusted implementation. You can even give it `trick questions' every
> now and then while it's in production use, checking its results, to make
> sure it's not randomly deciding to emit leaked key material instead of
> giving the right answers every now and then. I'd hope that most serious
> users of black-box cryptography hardware or software did something like
> this.
Testing isn't sufficient. Consider:
DES'[K](P) = DES[K](P), if P != backdoor
= K, if P == backdoor
Then with a single chosen plaintext, the key is revealed. Assuming the
backdoor plaintext is chosen randomly, no amount of testing that takes
less than 2^63 expected work will find it.
> With DSA, if you don't trust the hardware, you're stuffed.
Indeed, but that's just as true for any other algorithm - it's just a
little bit more involved for someone to work out how to stuff you.
- - --
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
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOS4ieDkCAxeYt5gVAQHOUQf8DAJuAiDxIHLRNvbijTsAuzC8VIMALsvx
ZRD5YX9XhVSIERnaGcB5VTzsbJVfwXfjG5BqTHf6CamR6pCP3SWPdEHNU1sVBdVd
U7vjOqYHUd7aIP+t6MTHx1/oswc/IowMfJ53DUoqYwHhKnKX/oWpZBhucz8EpcVZ
sxaXdGLL0AKzwQhrKDAkvGrH87WJOqynF/UP06tCJGl2ydJ0SNK319IlK6UOZ0+t
bDfNxNPtA9lLgRbm/gJzrcF67z+TLUFjNnO7wz0J2VDgIllH5QDfg6cfHkcHMZFG
0JcyarBUxiqUsV9Aa9icM27HGTN5AqkQes6OuRQbPjGNthOyzZTwMQ==
=3cHu
=====END PGP SIGNATURE=====
------------------------------
Date: Fri, 26 May 2000 08:02:14 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Short Secure Serial Numbers
=====BEGIN PGP SIGNED MESSAGE=====
Rick Heylen wrote:
>
> I am trying to find a solution to the following problem.
> We have a serial number which the user types in (so it can't be too long).
> The serial number contains some information like a product ID, user number
> etc with a total information content of about 96 bits and 40 bits of
> "checksum" with the idea being that for all possible information contents,
> there is only one valid checksum and that in order to find a valid serial
> number, an attacker would have to test on average 2^39 possibilities.
> The code that verifies the serial number is public but we'd still like it
> to be time-consuming to generate different valid serial numbers.
> Normal public key cryptography would be suitable except that the message
> size for the system to be secure would be longer than what a user would be
> happy to type in.
I'm not sure that it would be all that long. A discrete-log (e.g. DSA)
signature would require a 2t + m bit serial number, where 2^t is the
security level, and m is the number of bits of information encoded.
For example, if you need a 2^56 security level and 96 bits of information,
that would make a 208-bit serial number, which is 41 characters in base 36
(i.e. 0-9a-z) encoding. (A 2^40 security level works out as 35 characters.)
If there is checkable redundancy in the product ID or user number, then it
would be possible to use a signature scheme with message recovery and get
the length requirement down further.
- --
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
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOS2tZjkCAxeYt5gVAQEYBAf/VUT9lKgEJL9NJU8e/GJA1mkvWvwYOW8b
SAdnbHKoQbFNdxhlaEhdLnKV4A8pxbJEj3qvAImMjazP+fedf5OGoJqAu9RMkw7W
kBZYejz1wFUhZz34t6qpl6x68CQJNRkT+yHTH2/qy8Jj5Mp7PQ1+leAHmpDErN/G
q0K0mgne3ggaGBDnFN48FHeu18E0aul1Q4+nW0Glck111YFFbM9SImyz5gz1WZ3k
YBHULKQfEnyLDxzM68f4+e5Y0AtdPEbrIHcwoupzTYfe2ja1F0t8/XAEqAtrnydw
OoLoxpTGm+KCgk4fmiaHVxZjr3BhNdKEhWO3U7wY9BgmOsVWZCtIBA==
=ZImS
=====END PGP SIGNATURE=====
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A Family of Algorithms, Base78Ct
Date: Fri, 26 May 2000 09:26:52 +0200
wtshaw wrote:
> The essence of the mathematical relationships, the inequalities in most
> cases, is at the heart of the concept. By studying the mathematical
> relationships involving an associated set of bases in a given algorithm,
> you should come to learn pretty much all that you need. If you have
> addition questions, ask.
I like to know whether the following correctly captures the essence
of your methods:
One has a string of digits in a base B1. Break this up into sets of
certain fixed size. The digits in each set represent an integer in base
B1. Obtain the representation of these integers in base B2. This results
in sets of digits in base B2. Do some permutation of the digits in
each set. Finally concatenate all to form a string of digits in base B2.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: quantum computation
Date: Fri, 26 May 2000 09:26:37 +0200
Koji Katakura wrote:
> Does anyone tell me news groups for quantum computing?
>
There is no such newsgroup, as far as I know. Perhaps you might have
to join sci.physics. This group has occassionally some postings about
that topic.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: bamburismus
Date: Fri, 26 May 2000 09:26:45 +0200
John Savard wrote:
> Although that is not terribly definite, in my simplicity I would tend
> to consider such a thing an injudicious revelation even so.
It depends. If it was an academic research project, there shouldn't
be any problem. In fact, it is a pity that sometimes academic research
projects die and afterwards the materials are archived somewhere
and later completely forgotten.
M. K. Shen
------------------------------
From: "Antoine Joux" <[EMAIL PROTECTED]>
Subject: Re: NTRU Anyone?
Date: Fri, 26 May 2000 09:26:01 +0200
Scott Contini a �crit dans le message
<8gkk7c$ng5$[EMAIL PROTECTED]>...
>Greg <[EMAIL PROTECTED]> wrote:
>>Anyone know anything about NTRU public key encryption?
>
>It is a lattice based cryptosystem which seems to be strong so far,
<snip>
>It comments about NTRU's resistance to lattice attacks (so far).
>
>However, like RSA, proper padding is necessary for NTRU - otherwise
>the encryption leaks information about the message, and there are
>attacks which are effective if proper padding is not used.
A couple of comments on this:
1) NTRU is not lattice based, in fact it works with modular polynomials
(with two differents modulus p and q which are typically 3 and 128/256).
However, some lattice based attacks have been successful against NTRU with
low security parameters. [see the reference to Phong Nguyen page in Scott's
message]
2) NTRU does indeed require a proper padding, however the padding currently
proposed in the technical papers of the NTRU team is not sufficient and it
allows chosen ciphertext attacks against the system see:
http://www-cse.ucsd.edu/users/mihir/crypto2k/accepts.html entry 18
Antoine Joux
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: OAP-L3: Version 5.x Revealed
Date: Fri, 26 May 2000 00:40:17 -0700
OAP-L3: Version 5.x Revealed
(Both OAP-L3 Version 4.x and OAP-L3 Version 5.x are patent pending
under two separate patent applications.)
For the serious amateurs and the professionals, OAP-L3 Version 5.x is
well on its way to becoming fully developed.
I am not going to discuss the implications of this new OAP-L3 Version
5.x here in this news group at this time.
But you can see it in table form with text explanations by going to
http://www.ciphile.com
Click on the What's Ahead web page from the Table of Contents.
At the bottom of the What's Ahead web page you will find two
hyperlinks: "Version 5.0 Tables" and "Version 5.0 Table Text".
The hyperlink "Version 5.0 Tables" will bring up a web page with four
example tables describing the preferred embodiment of Version 5.0, and
three alternative embodiment table examples.
The hyperlink "Version 5.0 Table Text" will provide a description of
the tables and their operation.
I will say this much: some of you have expressed concern that the
efficiency of OAP-L3 leaves something to be desired.
With OAP-L3 Version 5.x, only one person need the full
implementation with an executable file near 2MB. This person
would be responsible for creating the data files (the table data
files) used in the encryption / decryption process.
The other person only needs to be supplied with software that
only encrypts and decrypts messages using such a table. I guess
that this executable file need only be about 50KB or maybe less (for
a windows executable.)
So, using a table such as Table 4 with 120 rows, it would be 6942
bytes long (uncompressed), and this table could generate about 3E12
(maximum) random digits.
The software and the data file (a data table) could be kept on a
floppy disk. And when the software is run, it could be read
directly from this floppy disk and loaded directly into RAM along
with the data table.
Additionally, there would be a few associated pointer / counter
files that would at most take up another 1000 bytes.
That's it: software of about 50KB capable of generating about 3E12
random digits with data files of about 8KB all of which will run
entirely in RAM (being loaded directly from floppy diskette). Then
when the encryption or decryption is completed, the only new data
written to the diskette would be the updated pointer / counter
files.
I could incorporate a short routine in the encrypt / decrypt software
to overwrite RAM to provide about as good of computer hardware
security imaginable or possible. Nothing from the diskette goes to
your hard drive and the RAM is overwritten. Very clean.
Get an 800MHz or faster Pentium III or AMD Athlon CPU with full
speed on board cache and I think encryption / decryption could be
done quite quickly and efficiently.
------------------------------
** 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
******************************
