Cryptography-Digest Digest #912, Volume #12 Fri, 13 Oct 00 15:13:00 EDT
Contents:
Re: Problem with SHA256 implementation (Tom St Denis)
Re: My SHA code and Endianess (Tom St Denis)
Re: What is meant by non-Linear... (Tom St Denis)
Re: Is it trivial for NSA to crack these ciphers? ("Stephen M. Gardner")
Re: What is meant by non-Linear... (Terry Ritter)
Re: What is meant by non-Linear... ("Stephen M. Gardner")
Re: algo to generate permutations ("bubba")
Re: SHA-256 security [was : SHA-256 implementation in pure C (free)] (Tom St Denis)
Re: CPU's aimed at cryptography (Mike Rosing)
Re: algo to generate permutations (Mok-Kong Shen)
Re: FTL Computation (ca314159)
Re: What is meant by non-Linear... (Mok-Kong Shen)
Re: Why wasn't MARS chosen as AES? (Dave Hazelwood)
A journal about crypto history (Mok-Kong Shen)
Re: Rijndael implementations (SCOTT19U.ZIP_GUY)
Re: CPU's aimed at cryptography (Michael Torla)
Re: What is meant by non-Linear... (Bryan Olson)
ANNOUNCE: SandMark -- A Software Watermarking Tool for Java (Christian S. Collberg)
Re: FTL Computation ("Paul Lutus")
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Problem with SHA256 implementation
Date: Fri, 13 Oct 2000 16:59:56 GMT
In article <Pine.GSO.4.21.0010130938140.1335-
[EMAIL PROTECTED]>,
Daniel Leonard <[EMAIL PROTECTED]> wrote:
> On Thu, 12 Oct 2000, Tom St Denis wrote:
>
> > At http://www.geocities.com/tomstdenis/files/sha256.c is
my "portable"
> > implementation of SHA-256. I have triple checked the code (found
> > numerous typos) but it still doesn't produce the correct output... I
> > would seriously appreciate some help!!!
> >=20
> > Tom
>
> 'abc' works, as well as 1000000 x 'a' on a Sun Ultra 5. Anybody
tested my
> Java code ?
Did you test my code on the Sun, Is the Sun a high endian? Where is
your java code?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: My SHA code and Endianess
Date: Fri, 13 Oct 2000 17:01:51 GMT
In article <[EMAIL PROTECTED]>,
Jim Gillogly <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > I have a strange feeling my code is not as "endian neutral" as I
> > wanted. Can someone on a big endian please test it out? This is
> > driving me mad...
> >
> > http://www.geocities.com/tomstdenis/files/sha256.c
>
> The "abc" test works fine with your code on at least one
> big-endian machine, an HP 9000/785. Your clrscr() function
> isn't portable, by the way.
The 'clrscr()'wasa reminant from my debugging. If you redownload the
source you can get the finished code.
Thanks for testing it.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is meant by non-Linear...
Date: Fri, 13 Oct 2000 17:03:16 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : "Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
> :> Rob Marston <[EMAIL PROTECTED]> wrote:
>
> :> > Is that it?
> :> No. A function y = f(x) is linear if, as Mr Savard stated, it can
be
> :> expressed y = a*x + b [1], for some reasonable definition of *
and +
> :> [2].
>
> : That is wrong, normally it's a boolean dot product of several
vectors
> : [...]
>
> Actually, it was correct. A function y = f(x) *is* linear if it can
be
> expressed y = a*x + b, for some reasonable definition of * and +.
>
> ...give or take some fluff about affine functions that Scott
relegated to
> helpful footnotes.
>
> FWIW, I've never liked the idea of categorising y = a*x + 1 as *not* a
> linear function. IMO, linear should mean something like "pertaining
to a
> straight line", not "affine functions which happens to go through the
> origin".
Yeah but in sboxes for example from DES we are using the parity of the
input bits vs the parity of the ouput bits and the parity of some key
bits. That is hardly a line, it's more like y0 = x0 + k0 + b...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Stephen M. Gardner" <[EMAIL PROTECTED]>
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Fri, 13 Oct 2000 11:55:45 -0500
Andre van Straaten wrote:
> I keep my home and my car locked, knowing that the FBI or other
> specialists might break in within 30 seconds or less.
But a good cryptographic algorithm is not a car. For some reason people seem
to attribute wizard-like powers to these agencies. Modern algorithms are subjected to
public scrutiny in an
environment where the secret agencies have no advantage (public disclosure of
algorithms and attacks). With modern cryptography the NSA is no better off than anyone
else. Where the opponents fall
down are in the more prosaic aspects of security: key distribution and human factors.
I think it can be said that despite the paranoia of some, the algorithms of modern
crypto themselves are safe
from NSA (or any other alphabet soup agency) attack. Securing the channel itself is
not the problem. Securing the endpoints and the key distribution path as well as
guaranteeing the loyalty of the
participants is what usually is the biggest problem for those who come into conflict
with the alphabet soup agencies. Of course, the truly paranoid might say that
worrying about the algorithm is what
the NSA wants you to do. The old "Look here not there" is the oldest trick in the
spy's arsenal. Most of the really brilliant spying is covered up with misdirection,
just like the magicians do.
There is no such thing as wizardry, only misdirected attention.
--
Take a walk on the wild side: http://www.metronet.com/~gardner/
There is a road, no simple highway, between the dawn and the
dark of night. And if you go no one may follow. That path is
for your steps alone.
The Grateful Dead ("Ripple")
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: What is meant by non-Linear...
Date: Fri, 13 Oct 2000 17:15:58 GMT
On Thu, 12 Oct 2000 06:00:40 -0700, in
<8s4dud$2q6$[EMAIL PROTECTED]>, in sci.crypt "Scott Fluhrer"
<[EMAIL PROTECTED]> wrote:
>Rob Marston <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> So to put it in a nutshell, if I had two S-Box's {the first is an Xor
>> and the Second is an And} then...
>>
>> SBox Out Out
>> In Xor And
>> 00 0 0
>> 01 1 0
>> 10 1 0
>> 11 0 1
>>
>> I could reverse the Xor S-Box by knowing the output bit and
>> either input bit, but I could not reverse the And operation?
>>
>> Is that it?
>No. A function y = f(x) is linear if, as Mr Savard stated, it can be
>expressed y = a*x + b [1], for some reasonable definition of * and + [2].
I would consider both XOR and AND to be linear operations mod 2. In
particular, XOR and AND form a field mod 2.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Stephen M. Gardner" <[EMAIL PROTECTED]>
Subject: Re: What is meant by non-Linear...
Date: Fri, 13 Oct 2000 12:27:28 -0500
Tim Tyler wrote:
> FWIW, I've never liked the idea of categorising y = a*x + 1 as *not* a
> linear function. IMO, linear should mean something like "pertaining to a
> straight line", not "affine functions which happens to go through the
> origin".
The problem with your 'straight line' definition is that I don't think it
maps very intuitively to finite fields. Consider these questions: What does
a linear equation "look like" when the equation is defined over GF(p)? Do
the points lie in the pattern of a line when graphed in a Cartesian plane?
As an example of what I am getting at, try plotting this simple linear
function: y = 2x over GF(3). Does it lie on a line in discrete Cartesian
plane?
A better definition might be a transformation T is linear if T(x+y) = T(x) +
T(y) and T(ax) = aT(x). The equation y = 2x over GF(3) satisfies this
criterion but doesn't lie on a line in a Cartesian coordinate system.
--
Take a walk on the wild side: http://www.metronet.com/~gardner/
There is a road, no simple highway, between the dawn and the
dark of night. And if you go no one may follow. That path is
for your steps alone.
The Grateful Dead ("Ripple")
------------------------------
From: "bubba" <[EMAIL PROTECTED]>
Subject: Re: algo to generate permutations
Date: Fri, 13 Oct 2000 12:33:25 -0500
This is the best I could do during lunch break. It
seems like I have come up with something simpler
in the past. It is a handy program to run to work those
jumble puzzles in the newspaper.
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void permute (char *fixed, char *text)
{
int index, length = strlen (text);
if (length == 1)
{
printf ("%s%s\n", fixed, text);
return;
}
for (index = 0; index < length; index++)
{
char *temp = strdup (text);
int fixedlength = strlen (fixed);
char *newfixed = malloc (fixedlength + 2);
strcpy (newfixed, fixed);
newfixed [fixedlength] = text [index];
newfixed [fixedlength + 1] = '\0';
strcpy (temp + index, temp + index + 1);
permute (newfixed, temp);
free (temp);
free (newfixed);
}
}
int main (int argc, char *argv [])
{
permute ("", argv [1]);
}
"stephane longchamp" <[EMAIL PROTECTED]> wrote in message
news:8s6sio$aga$[EMAIL PROTECTED]...
> Do someone know an algo to generate all permutations of a string of
letters
> ?
>
> example :
>
> ABCD
> ABDC
> ACBD
> ACDB
> .....
>
>
>
>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SHA-256 security [was : SHA-256 implementation in pure C (free)]
Date: Fri, 13 Oct 2000 17:33:38 GMT
In article <Pine.GSO.4.21.0010130942180.1335-
[EMAIL PROTECTED]>,
Daniel Leonard <[EMAIL PROTECTED]> wrote:
> On Thu, 12 Oct 2000, Tom St Denis wrote:
>
> > I hope SHA-256 is in fact secure though... heheheh
> >=20
> > Tom
>
> There is a thing I found in the code that puzzles me. At any given
time
> during the calculation of T1 and T2, there is one of the register
variable
> that is not used. Does that affects anything ?
Most likely, but given the number of rounds...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: CPU's aimed at cryptography
Date: Fri, 13 Oct 2000 12:35:44 -0500
Greggy wrote:
>
> RSA moduli range from 80 to 2k
> ECC field range from 50 to 500
>
> Clearly you are correct. And it is the silicon space that has made
> that decision for them, no doubt.
>
> BUT if you look at the way they word their brochure, you don't know
> what field size they are referring to. One might assume a comparable
> field size to the 1k RSA test case, but they don't say that.
>
> And they don't mention the field type, the curve parameters, etc.
>
> Should we expect excrutiating details or not?
Unfortunatly probably not. Sales isn't interested in details.
Certainly not any they don't understand :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: algo to generate permutations
Date: Fri, 13 Oct 2000 20:06:27 +0200
stephane longchamp wrote:
>
> Do someone know an algo to generate all permutations of a string of letters
> ?
>
> example :
>
> ABCD
> ABDC
> ACBD
> ACDB
> .....
This is called generation of permutations in lexicographical
order. If you look at some of the permutations at the
beginning of the list, you'll easily see how the algorithm
should be. If you do need an algorithm written by others
ready for copying, I suggest that you look at the collection
of algorithms maintained by ACM, which contains many many
very useful and good algorithms for numerical computations.
That collection is certainly accessible via any university
computing centre. (You may have to do translations from one
programming language to another.)
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: ca314159 <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Date: Fri, 13 Oct 2000 18:02:12 GMT
In article <UPFF5.42706$[EMAIL PROTECTED]>,
"Paul Lutus" <[EMAIL PROTECTED]> wrote:
> and the spot does not move at FTL.
If _it_ doesn't, then what does _it_ do ?
Does _it_ exist at all ?
The spot, is a symbol.
It, moves FTL.
It, has size, position, shape, brightness, can be seen, ...
It, exists just like this asterisk: "*".
You may claim the asterisk doesn't exist
because there are no specific electrons/photons
making it up and it's:
> The abstract notion of a point of contact between different
> light packets
but then, the asterick itself becomes sort of a fuzzy,
half-real, illusion of a quantum-like entity.
Here's someone who's exploited FTL shutters to holograph
the actual motion of light. He's basically done what Einstein
asked: what's it like to ride on a beam of light ?
http://www.matpr.kth.se/personal/nilsa/
If _it_ was an illusion, Nils Abramson would not have been
able to exploit _it_, now would he ?
Somebody should give Nils a Nobel prize.
--
If you had to prove the relation:
log(a*b) = log(a) + log(b)
each time you used it analytically, that would slow your
theoretical work to a crawl.
No, you only need to prove this relation in numerical
computation, not in analytical/analog computation.
In numerical computation it is proven each time you calculate
using it. The empirical measurement, is of the physical
numerical calculation using that symbolic algorithm.
But in analogical computation, the key elements are correlations;
not dependancies, as are used in logical computers.
Analogs/correlations are acausual. They don't have to obey
causual laws like the speed of light.
--
SIRDS are correlated pixels; usually horizontally polarized.
They give you a virtual 3-d image. An actual image of a low
dimensional quasi-Hilbert space.
http://search.yahoo.com/bin/search?p=sirds
If you concentrate too hard on any individual pixel/s,
measure them, the part of or the whole 3-d image effect
collapses like a collapsing wavefunction.
It is not an "illusion", it is an effect, and an exploited
one at that. An illusion is calling the water refraction in
desert air a lake. The fact, that the water in the desert
air can look like the water in a lake is based on a physical
'effect'.
> Your bringing up quantum computers ...
(I can context crop also)
I don't think one can talk about this topic in depth without
bringing in Special Relitivity, General Relativity,
and Quantum Mechanics.
For instance web links can also act like qubits.
They are and aren't relevant, simultaneosly.
You only find out which if you actually look at the link content.
Make a measurement.
Until you do, the links on a page
are in a state of superposition in
regards to any assertions/annotations
regarding their unseen contents.
They are merely correlated until they are instantiated.
Symbolic algebra is different from numerical computation.
These two different forms of computation have different
physical properties.
Symbolic computation can take place
acausually (correlations are themselves acausual)
and therefore break the speed of light limit
which is a physical (causual) law.
This is the reverse of the high-jump cheat,
it can only be exploited to a certain
extent, but it does allow you to leap
over the bar. In this case the speed of light
is the bar.
Same thing in FTL computation except that what
is bending is light and what doesn't, is space.
A light spot's virtual (symbolic) projection can
move FTL in non-inertial reference frames like
that of a rotating lighthouse lamp.
Ideas (correlations) can be communicated
instantaneously, deterministic (new) information
must be communicated less than the speed of light.
The limitations of flat spaces are not the same
as those for curved spaces Special Relativity
theory is not the same as General Relativity theory.
There would be any need for a general theory if
the specific theory was the whole picture.
Many definitions are rigid,
but no definitions are unbendable.
When one bends definitions,
one can also bend the laws based on them.
> Quantum computing relies on a kind of massive parallelism
"a kind of" ?
You mean it's not reeeaally "massive parallelism" ?
What,
is,
it ?
--
"So, so you think you can tell
Heaven from Hell,
blue skies from pain.
Can you tell a green field
from a cold steel rail?
A smile from a veil?
Do you think you can tell?
Did they get you to trade
your heroes for ghosts?
...
"
- Pink Floyd
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What is meant by non-Linear...
Date: Fri, 13 Oct 2000 20:24:21 +0200
"Stephen M. Gardner" wrote:
>
> A better definition might be a transformation T is linear if T(x+y) = T(x) +
> T(y) and T(ax) = aT(x). The equation y = 2x over GF(3) satisfies this
> criterion but doesn't lie on a line in a Cartesian coordinate system.
I understand this to mean that linearity is with respect
to the ring. Now it follows that 'linearity' without
qualification is fuzzy and hence 'non-linearity' without
qualification is also (perhaps more) fuzzy. Or do I miss
something?
M. K. Shen
------------------------------
From: Dave Hazelwood <[EMAIL PROTECTED]>
Subject: Re: Why wasn't MARS chosen as AES?
Date: Mon, 09 Oct 2000 08:47:51 +0800
On 07 Oct 2000 03:41:54 GMT, [EMAIL PROTECTED] (UBCHI2) wrote:
>Why wasn't MARS chosen as AES?
Because MARS is in outer space ?
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: A journal about crypto history
Date: Fri, 13 Oct 2000 20:39:46 +0200
I just saw in the library one issue of a journal that was
new to me but that is already in its vol.15. From the content
of that issue, I deduce that the journal could be of value
to those interested in crypto history:
Intelligence and National Security.
URL of its producer is www.frankass.com
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Rijndael implementations
Date: 13 Oct 2000 18:23:00 GMT
[EMAIL PROTECTED] (Douglas A. Gwyn) wrote in
<[EMAIL PROTECTED]>:
>Tom St Denis wrote:
>> *Plus* 99.9999% of the computer users (literate and illeterate alike)
>> think a byte is an extended ASCII char of eight bits.
>
>You have even less credibility than Al Gore -- what poll
>produced those statistics?
>
>I am willing to grant that 100% of *ignorant* computer users
>believe that a byte has 8 bits, but that is not much more
>than an implication of the consequences of being ignorant.
>
I worked with field data characters 6 bits and 9 bit ascii
on machines that had 36 bit words. But I would say 8 bits is what
is normally meant by a BYTE in todays world.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Michael Torla <[EMAIL PROTECTED]>
Subject: Re: CPU's aimed at cryptography
Date: Fri, 13 Oct 2000 11:04:38 -0700
==============4DD25D38DDE030C955311320
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Greggy wrote:
> RSA moduli range from 80 to 2k
> ECC field range from 50 to 500
>
> Clearly you are correct. And it is the silicon space that has made
> that decision for them, no doubt.
>
> BUT if you look at the way they word their brochure, you don't know
> what field size they are referring to. One might assume a comparable
> field size to the 1k RSA test case, but they don't say that.
I believe it's 1k RSA.
> And they don't mention the field type, the curve parameters, etc.
MPC180e performs Elliptic Curve Point Multiplication in either Fp or F2m
polynomial basis.
for F2m, curve parameters a and c (c=b^2^(m-2)) are entirely programmable.
(curve y^2 + xy = x^3 + ax^2 + b)
for Fp, curve parameters a and b are entirely programmable. (curve y^2 =
x^3 + ax + b)
>
>
> Should we expect excrutiating details or not?
>
> > JCA wrote:
> > >
> > > If we are talking 1024-bit RSA moduli, 32 ms for the signature
> > > time is very unimpressive. Similar or better speeds are already
> > > achieved in software on a medium range PA-RISC box, and much
> > > faster performance on a 500 MHz IA64 box.
> >
> > But check out the M180e:
> >
> > Public Key Execution Unit
> > - RSA signature time of 32ms supporting 13 IKE handshakes per
> second.
> > - Elliptic Curve cryptography signature time of 11ms
> supporting 45.5 IKE
> > hand- shakes per second.
> >
> > RSA isn't the target market.
> >
> > Patience, persistence, truth,
> > Dr. mike
> >
--
========================================================================
| Michael J. Torla [EMAIL PROTECTED] |
| Motorola SPS Security Technology Center |
| Tempe, AZ 85282 |
========================================================================
*DigitalDNA(tm) from Motorola: It's who we are. It's what we do.
==============4DD25D38DDE030C955311320
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Greggy wrote:
<blockquote TYPE=CITE>RSA moduli range from 80 to 2k
<br>ECC field range from 50 to 500
<p>Clearly you are correct. And it is the silicon space that has
made
<br>that decision for them, no doubt.
<p>BUT if you look at the way they word their brochure, you don't know
<br>what field size they are referring to. One might assume a comparable
<br>field size to the 1k RSA test case, but they don't say that.</blockquote>
I believe it's 1k RSA.
<blockquote TYPE=CITE>And they don't mention the field type, the curve
parameters, etc.</blockquote>
MPC180e performs Elliptic Curve Point Multiplication in either Fp or F2m
polynomial basis.
<p>for F2m, curve parameters a and c (c=b^2^(m-2)) are entirely programmable.
(curve y^2 + xy = x^3 + ax^2 + b)
<p>for Fp, curve parameters a and b are entirely programmable. (curve y^2
= x^3 + ax + b)
<blockquote TYPE=CITE>
<p>Should we expect excrutiating details or not?
<p>> JCA wrote:
<br>> >
<br>> > If we are talking 1024-bit RSA moduli,
32 ms for the signature
<br>> > time is very unimpressive. Similar or better speeds are already
<br>> > achieved in software on a medium range PA-RISC box, and much
<br>> > faster performance on a 500 MHz IA64 box.
<br>>
<br>> But check out the M180e:
<br>>
<br>> Public Key Execution Unit
<br>> - RSA signature time
of 32ms supporting 13 IKE handshakes per
<br>second.
<br>> - Elliptic Curve
cryptography signature time of 11ms
<br>supporting 45.5 IKE
<br>>
hand-
shakes per second.
<br>>
<br>> RSA isn't the target market.
<br>>
<br>> Patience, persistence, truth,
<br>> Dr. mike
<br>></blockquote>
<pre>--
========================================================================
| Michael J.
|Torla
| [EMAIL PROTECTED] |
| Motorola
|SPS
| Security Technology Center
||
| Tempe, AZ 85282 |
========================================================================
*DigitalDNA(tm) from Motorola: It's who we are. It's what we
do.</pre>
</html>
==============4DD25D38DDE030C955311320==
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: What is meant by non-Linear...
Date: Fri, 13 Oct 2000 18:19:47 GMT
Stephen M. Gardner wrote:
[...]
> A better definition might be a transformation T is linear if
> T(x+y) = T(x) + T(y) and T(ax) = aT(x). The equation y = 2x over
GF(3)
> satisfies this criterion but doesn't lie on a line in a Cartesian
> coordinate system.
We should note that the variable "a" in the rule for multiplication
T(ax) = aT(x)
is restricted to some scaler (constant), unlike the "y" in the rule
for addition. We do not, for example, require that T(x*x) = x*T(x).
This gives us a more general idea of linear. As an example,
"derivative" is a linear transformation.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Christian S. Collberg)
Crossposted-To: comp.security.misc,comp.lang.java.security,comp.lang.java.programmer
Subject: ANNOUNCE: SandMark -- A Software Watermarking Tool for Java
Date: 13 Oct 2000 11:03:45 -0700
SandMark: Software Watermarking for Java
----------------------------------------
The first version of SandMark, a software watermarking
tool for Java, is now available for download:
http://www.cs.arizona.edu/sandmark/
SandMark is a system for embedding a watermark in a Java program.
It modifies the application source code to make it build a
heap-based structure at execution time that encodes a watermark.
The watermark is recognized by dumping and analyzing the Java heap.
SandMark embodies the research described in
Software Watermarking: Models and Dynamic Embeddings,
by Christian Collberg and Clark Thomborson, published in
ACM Symposium on Principles of Programming Languages (POPL99)
http://www.cs.auckland.ac.nz/~collberg/Research/Publications/CollbergThomborson99a
SandMark was implemented by Gregg Townsend and Christian Collberg
at the University of Arizona, under NSF grant CCR-0073483.
Christian Collberg
Department of Computer Science
The University fo Arizona
------------------------------
From: "Paul Lutus" <[EMAIL PROTECTED]>
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: FTL Computation
Date: Fri, 13 Oct 2000 18:55:02 GMT
ca314159 <[EMAIL PROTECTED]> wrote in message
news:8s7in0$er$[EMAIL PROTECTED]...
> In article <UPFF5.42706$[EMAIL PROTECTED]>,
> "Paul Lutus" <[EMAIL PROTECTED]> wrote:
>
> > and the spot does not move at FTL.
>
> If _it_ doesn't, then what does _it_ do ?
>
> Does _it_ exist at all ?
>
> The spot, is a symbol.
It is not a physical entity, which was your first mistake. It cannot carry
information, which was your second.
> It, moves FTL.
>
> It, has size, position, shape, brightness, can be seen, ...
All false. The things that have brightness are individual wave packets, not
the "spot."
So it goes though your entire rambling, new-age-physics post. You say
everything *except* contradict the prohibition against FTL. Not true in
relativistic physics, not true in quantum or quantum computing, not true
anywhere.
--
Paul Lutus
www.arachnoid.com
------------------------------
** 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
******************************
