Cryptography-Digest Digest #345, Volume #14 Sat, 12 May 01 18:13:00 EDT
Contents:
Re: Key escrow based on BBS ("Jeffrey Walton")
Re: OAP-L3: "The absurd weakness." (Anthony Stephen Szopa)
Re: OAP-L3: "The absurd weakness." ("Trevor L. Jackson, III")
Re: Are low exponents a problem with RSA? (Paul Rubin)
Re: Best encrypting algoritme (wtshaw)
Re: ON-topic - UK crime statistics (was Re: Best, Strongest Algorithm) (wtshaw)
Re: Encryption in JavaSCRIPT (DES or Blowfish) (Paul Schlyter)
Memory (M) Theory and Elliptic Curves/Functions - Doctorow ("Osher Doctorow")
Re: Encryption in JavaSCRIPT (DES or Blowfish) ("Super-Simon")
----------------------------------------------------------------------------
Reply-To: "Jeffrey Walton" <[EMAIL PROTECTED]>
From: "Jeffrey Walton" <[EMAIL PROTECTED]>
Subject: Re: Key escrow based on BBS
Date: Sat, 12 May 2001 16:36:50 -0400
It looks a little like El Gama, and a little like Rabin. I've always kind
of viewed Rabin as a particular implementation of El Gamal, with exponent 2.
(Please forgive my ignorance)
I'm not sure what using the lower ln(ln(N)) bits would do.
Jeff
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:zraL6.73275$[EMAIL PROTECTED]...
I was wondering after all the Key Escrow debackle in the mid 90s has anyone
suggested this trivial solution?
1. Host makes a blum integer N and publishes it along with a large prime p,
and primitive element in Z*p called g.
2. Each user picks their own large integer x (which is secret) and
publishes y = g^x mod p
Now I want to send a message to a user I do
1. Make a random k and compute y' = g^k mod p. I send y' to the user
2. I use K = y^k mod p, as my BBS seed.
3. I encode the message using the lower lg lg N bits xor'ed against the
plaintext. i.e K = K^2 mod N and use the lower bits of K
4. I perform another squaring e.g. K = K^2 mod N and store K along with the
stream.
Presuming that both factoring and discrete logs are hard with only g^k mod p
an attacker will not know the seed and with only the last K value an
attacker cannot find the square root of K modulo N.
The legitimate reader knows 'x' and can compute K from y' as y'^x mod p.
Thus they can read the message. The host however knows the factors of N and
can easily work it backwards and obviously read the message too. Voila
instant key escrow.
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: OAP-L3: "The absurd weakness."
Date: Sat, 12 May 2001 13:38:11 -0700
James Felling wrote:
>
> Tom St Denis wrote:
>
> > "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Tom St Denis wrote:
> > > >
> > > > "Antho
>
><snip>
>
>
>ver again you can and will eventually get good data, it
> requires more work to get to that point than it would with a conventional
> stream cypher.
OK. You have made a few points from within a cage behind bars. Now
if we take you out of the cage and out from behind the bars, can you
make good on your assertions?
"aplying that method N times will give exactly the same level of
security as applying it once."
Tell us the method and give us an example. This is true for one
process using a single permutation file and it is noted in the
instructions that you should only use this method once for this
very reason. If you shuffle this single permutation file with
another one or more permutation files then you can use the process
once again since you no longer have the same original single
permutation file.
"some of the methods will comute." Which ones and give us an example.
"Some of the methods have fixed points. Data that that method cannot
and will not alter." Which ones and give us an example.
"I do accept that using your medhods over and over again you can and
will eventually get good data, it requires more work to get to that
point than it would with a conventional stream cypher."
What is "good data?"
One security advantage IS that it takes a bit more work to arrive at
what I call the key space or point at which OTP files can be
generated with the desired user security level. But once you get
there, you only need to run a very few additional processes to move
further out into the key space to generate subsequent random numbers
with even greater security.
For instance, let's say you run 100 processes at random with random
user input to arrive at three permutation files from which you will
generate random number files which in turn will be processed further
to generate the OTP files.
To generate subsequent permutation files you do not need to start
from scratch and run another 100 processes at random with random user
input to generate different random number files that will be
processed further to generate another set of OTP files.
You need only run a few more random processes on each permutation
file to enter even further into the key space where you can generate
even more secure random number files from which you can generate
even more secure OTP files. So this extra work is most significant
the first time out and need not be nearly as difficult subsequently.
If a user wanted, they would not even have to generate new random
number files. They could simply reprocess the original random number
files using all the available methods offered with OAP-L3 but using
different random user input then generate completely different OTP
files from these original reshuffled random number files.
The idea is that once a user has achieved their desired security level
by running enough processes at random using random user input, they
will be far enough out into the key space where using any of the
above suggestions will continue to result in practicably unbreakable
encryption or the generation of crack-proof OTP files.
Also, because it does take extra work, because the nature of the
OAP-L3 OTP generation methods require that all the random methods be
processed with generally the exact random user input before the
process of even checking if the guess is correct, cracking OAP-L3
very quickly becomes practicably impossible.
For instance, with other encryption software, guessing a key and
plugging it in will tell you in the span of milliseconds whether or
not you have the right key. But with OAP-L3, any single guess will
require the cracker to run the processes described by the guess
completely to test the guess. And the guess must be tested further
to see if the guess was right but only the offset within the guessed
OTP files was correct. So this process could take seconds, minutes,
hours, days, etc.
Let's use a worst case scenario and say that each guess will only
take one second to verify. If there are 1E50 possible outcomes and
you only have to guess half of these before you discover the key
then it will take you 1E50 / 2 = 5E49 seconds to arrive at the
correct key which is about 1.5E42 years to get the right answer.
(assuming about 1E8 seconds / 3-years)
On top of all this a cracker has no idea when the OAP-L3 user decided to
stop or decided that a particular security level was sufficient.
Generally, all of this forces a cracker to try every single possible key
with each guess as each step is taken further out into the
possible ever expanding key space.
Lastly (for now,) other encryption software uses one or more
mathematical equations to generate their encryption output. OAP-L3
does not although the methods can be expressed mathematically. Just
like there were once mathematical expressions that were thought to be
insolvable but later made trivial, so might these other encryption
software methods' equations be made trivial to crack if they are not
already.
Such an eventuality is not possible with OAP-L3 since it does not use
any such susceptible mathematical equations in the generation process
of the OTP files.
You only have to ask yourself, "How much time, energy, and resources
do I have to spare in order to crack OAP-L3?"
Yes? "What is 'good data?'"
I'd say OAP-L3 generates good data: very good data.
I agree with you on this point.
It certainly can provide absolute privacy, even against quantum
computers.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: "The absurd weakness."
Date: Sat, 12 May 2001 20:40:04 GMT
Anthony Stephen Szopa wrote:
> David Hopwood wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > "Douglas A. Gwyn" wrote:
> > > James Felling wrote:
> > > > ... while I do accept that using your medhods over and over again
> > > > you can and will eventually get good data, it requires more work to
> > > > get to that point than it would with a conventional stream cypher.
> > >
> > > Well put.
> >
> > It should also be noted that it isn't just a little bit more work; it is
> > several orders of magnitude more work. The types of shuffling operations
> > that OAP-L3 uses are all special cases of the same method, and that method
> > is not very good at distributing entropy within the permutation table.
> > In particular, the probability that two initially adjacent elements will
> > remain adjacent, is far greater than it should be by chance. The result
> > is similar to trying to shuffle a stacked deck of cards using a small
> > number of shuffles - except that the table is much larger than 52 elements,
> > which makes the resulting bias much worse.
> >
> > There's little point in telling Szopa this, though; people have done that
> > before, but he tries to claim that the output stage will hide the non-
> > randomness in the permutation table. AFAICS (from an admittedly brief
> > analysis), there is no reason to believe that it does, and I would be
> > surprised if there were not a distinguisher using only a small amount
> > of output. (If anyone here is really bored, and inclined to spend a
> > hour or two deciphering a few pages of badly written cipher description
> > from someone with an anti-mathematical bent, they'd have a good chance
> > of breaking OAP-L3 with the recommended number of steps.)
> >
> > In any case, the cipher is ridiculously inefficient, and too reliant
> > on the quality of user-provided random input.
> >
> > - --
> > David Hopwood <[EMAIL PROTECTED]>
> >
> > Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
> > RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
> > Nothing in this message is intended to be legally binding. If I revoke a
> > public key but refuse to specify why, it is because the private key has been
> > seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: 2.6.3i
> > Charset: noconv
> >
> > iQEVAwUBOviLgTkCAxeYt5gVAQGlTQgAiWYVbHi0AkhGG8Ho9sqTz0Kq4ES47g/6
> > tGk6pcMEV1nChlpXw8n3Zg2Dh6hjOrV9TWHDWAiilyY8eIEWi9awwIkeA6K6nNyA
> > EvDVbSgywKYpg+0hlHnmcpzKnSfeMs8g65U8v+ZQcCrOItCiqkD2b068bmd4+aop
> > GDKR1bvaa7vLeVrRYcw4mdPr6MFa8VuRplWTOpuJg0l8N6MSHgYlaSTPCxOvNVjq
> > vpNewWBFCrHxqs9RnBlDPNPBIFet4stOwo5wMxzrJvPAKaSDq37f/Q4n8NrpUp9I
> > GUWEOlUNND716SaYrf7Gf0QjgHs+ra+/mJcKnXV9r0bHMPX+GAuTBg==
> > =9B+D
> > -----END PGP SIGNATURE-----
>
> I am sure there are many here in these news groups who are most
> anxious to see some proof supporting your unfounded assertions.
I doubt it. You clearly aren't because you studiously ignore, in a non-oxymoronic
fashion, every attempt to communicate the fundamental issues. There is noone else
who has any anxiety over the issue because it is obvious by inspection. All one
has to do is read the instructions and the help files.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Are low exponents a problem with RSA?
Date: 12 May 2001 13:46:42 -0700
[EMAIL PROTECTED] (David Wagner) writes:
> (There is also theoretical work which might be viewed as evidence that
> RSA could be less secure with e=3 than with general e, but personally
> I'm happy to stick with e=3 for the moment.)
I'd think you'd really want e=2 which is provably equivalent to factoring,
though then it's not RSA any more.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best encrypting algoritme
Date: Sat, 12 May 2001 14:42:28 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
> I agree. Block length is an essential parameter that
> could be profitably varied. I believe that most block
> algorithms can be modified to work well with variable
> block sizes without much difficulty. Of course, that's
> merely a belief of mine, no proof. The issue is somewhat
> analogous to that of employing fixed vs. random S-boxes,
> I suppose.
>
> M. K. Shen
Some algorithms cannot track different block sizes well. It is an asset
to be able to do so, and those that paint themselves into the proverbial
corner are deficient.
A desirable generic approach should allow many dimentions of variability.
Quickly we can return to the discussion of whether a scaled down algorithm
is useful, but a better variable block length cipher scales in only one
attribute during processing to match ciphertext, not anything else.
Functionality shows the benefits and careful analysis yields proof that
strength need not be compromised.
I consider s-boxes as more in the key area, fixed and random as different
ways to fill key space. Qualified and/or locked-in keys are just key
preferences.
--
Mother Nature always gets her revenge.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: ON-topic - UK crime statistics (was Re: Best, Strongest Algorithm)
Date: Sat, 12 May 2001 15:06:43 -0600
In article <[EMAIL PROTECTED]>, Jim D wrote:
> On 11 May 2001 17:37:34 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
> wrote:
> > Hell when I was a kid
> >I took a gun to school. My NRA safety class required you to bring
> >your own 22. Now adays people shit in there pants when a kid takes
> >a gun to school. The view is different because the liberals have
> >fucked it up and destroyed values.
>
> Isn't America a wonderful place? ! Rather you than me, pal!
>
In elementary school, we had 4-10's and 22's and caried them to class
occasioinally, shot them at recess, took bullets apart, ignited contents
and fired the caps with a rock. The powder sometimes went into bombs,
most that fizzled. We shot firewirks, including banned ones from
Oklahoma, made our own cannon that fired projectiles of sticks, grass, and
rocks as we played war games with old building materials. In high school,
we had our own rocket club and some of these thing went for miles. We had
not adult supervision, made our own membership cards, and met to try out
our latest projects.
Joe did get into trouble when a batch of solid fuld exploded on the
kitchen stove and blew out some windows. After that his experiments,
including electronic ones, were banned to an old chicken coop.
Otherwise, nobody cared, we were learning lot about physics, not trying to
bump each other off. Luckily, injuries were rare and slight. One would
say we were trying to get hurt and I almst did with a few blasts, and I
don't think I'll choose to mess with nitro again, making it or blowing up
outhouses.
It takes confined city slickers to turn such play into means to enforce
prejudice and feuds.
--
Mother Nature always gets her revenge.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: comp.lang.java.javascript,comp.lang.javascript
Subject: Re: Encryption in JavaSCRIPT (DES or Blowfish)
Date: 12 May 2001 22:17:18 +0200
In article <9dk19t$lv8$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
>
>Super-Simon <[EMAIL PROTECTED]> wrote in message
>news:9dc2on$geg$[EMAIL PROTECTED]...
>> Hi,
>>
>> Is it possible to encrypt and decrypt strings with DES or Blowfish in
>> JavaSCRIPT? If it is possible, where can I get more information????
>
>Its likely you wont want to use DES. It can be broken by exhaustive search
>of the keyspace in under 24 hours using super-computers.
Triple-DES solves that problem.....
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: "Osher Doctorow" <[EMAIL PROTECTED]@ix.netcom.com>
Subject: Memory (M) Theory and Elliptic Curves/Functions - Doctorow
Date: Sat, 12 May 2001 15:35:22 -0700
From: Osher Doctorow [EMAIL PROTECTED], Sat. May 12, 2001 2PM
Memory (M) Theory, which I have been working on for the past year, studies
events which depend on two or more previous times. Its main tools are
Volterra integral and integrodifferential equations, the convolution
product, Delay/Retarded functional differential equations, Spherical
Harmonics and other Special Functions including Elliptic Functions, the
proximity function which intuitively describes *nearness* instead of the
distance-function's/metric's *farness*, etc. (See sci.physics,
sci.physics.relativity, sci.optics, and so on for some of my recent
contributions.)
Here I want to concentrate on elliptic curves/functions, which were used by
Wiles to prove Fermat's Last Theorem and thereby relate to both number
theory and cryptography. The inverse of the elliptic integral of the first
kind is a Jacobi elliptic function. G. E. Andrews, R. Askey, and R. Roy's
Special Functions, Cambridge University Press: Cambridge 1999 gives the best
presentation of these integrals and functions that I have seen (plus
spherical harmonics, etc.). The elliptic integral of the first kind is the
integral from 0 to x of 1 divided by sqrt[(1 - t^2)(1 - k^2 t^2)] dt for x
in [-1, 1]. So t is also is [-1, 1], more specifically in [-1, x]. If we
multiply out the quantity inside the square root, we get 1 + k^2 t^4 - (k^2
+ 1)t^2. Now, the proximity function p1(x, y) = 1 + y - x for y < = x, and
usually 0 < = y < = x < = 1 (e.g., for Lukaciewicz fuzzy multivalued logical
implication, for Non-Bayesian Logic-Based Probability where y = P(AB) and x
= P(A) with AB being the intersection of set/events A and B and P( ) being
probability of). In LBP, or what I call the probability representastion of
M-Theory, the proximity function indicates the probable influence of A on B.
If we interpret this analogously here, then the quantity inside the square
root above has the form p1(x, y) = 1 + y - x for y = k^2 t^4 and x = t^2(k^2
+ 1). So this would hypothetically tell us the influence of t^2(k^2 + 1) on
k^2t^4. Notice that for t in [0, x], t^4 < = t^2, and k^2 < = k^2 + 1, so
y < = x is certainly satisfied, and on [0, 1] we also have 0 < = y < = x < =
1.
According to what I have said above, t^2 influences t^4 (I ignore k^2
because it is somewhat trivial that k^2 is influenced by or influences k^2 +
1, since they are constants). If this is true in general, then lower
powers of a variable influence their higher powers (since the first power
influences the second, etc) in [0, 1]. The reverse can be argued for [1,
infinity) since now the roles of x and y have to be interchanged since the
higher power of a quantity > 1 is greater than the lower power. But
Fermat's Last Theorem has all terms of nth degree or power for n > 2
(integer). The equation in question in that theorem is x^n + y^n = z^n.
Let us compare this with x^(n+1) + y^(n+1) = z^(n+1). Of course, we don't
expect the same x, y, and z in both equations, but what if t in t^4 were
replaced by another variable, say s, of the same type in some way (say, both
> = 1 integers). Would t^4 influence s^2, and t^n influence s^(n-1) in
general for n > = 2? If we let n --> infinity, does it make any sense to
say that there is a (non-real) upper bound with infinite influence?
Certainly we get a sequence of increasing powers of t with increasing
influence on lower powers as the power goes up. I think that it would be
interesting to see how far we could proceed with this argument in
discovering shortcuts or deeper properties of Fermat's Last Theorem and its
proof. Notice that I left probability behind in the above - the proximity
function generalizes to arbitrary functions, whether they involve
probability or not. However, it could well be studied whether changing
influence to probable influence has any applications to the problem
mentioned.
Osher Doctorow Ph.D.
Ventura College (until May 16), Doctorow Consultants
------------------------------
From: "Super-Simon" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.java.javascript,comp.lang.javascript
Subject: Re: Encryption in JavaSCRIPT (DES or Blowfish)
Date: Sun, 13 May 2001 00:05:44 +0200
> > Is it possible to encrypt and decrypt strings with DES or Blowfish in
> > JavaSCRIPT? If it is possible, where can I get more information????
>
> Its likely you wont want to use DES. It can be broken by exhaustive search
> of the keyspace in under 24 hours using super-computers.
Don't matter, I want to use DES with streaming encryption; I think it's save
enough for that....
------------------------------
** 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
******************************
