Cryptography-Digest Digest #532
Cryptography-Digest Digest #532, Volume #14 Wed, 6 Jun 01 03:13:01 EDT
Contents:
Re: Medical data confidentiality on network comms (wtshaw)
Re: practical birthday paradox issues ("Dirk Bruere")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (JPeschel)
Bow before your new master (Brent K Kohler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Re: Medical data confidentiality on network comms (Richard D. Latham)
Re: practical birthday paradox issues (Richard D. Latham)
Re: And the FBI, too (Re: National Security Nightmare?) (Paul Crowley)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (JPeschel)
Re: PRP => PRF (TRUNCATE) (Gregory G Rose)
Re: Bow before your new master ("Mike S.")
Re: fast CTR like ciphers? ("Scott Fluhrer")
Re: Welcoming another Anti-Evidence Eliminator stooge to USENET (P. Dulles / AKA
Loki) (Eric Lee Green)
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: comp.security.misc
Subject: Re: Medical data confidentiality on network comms
Date: Tue, 05 Jun 2001 20:39:43 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
...
> An emergency doctor may need some data while the patient
> isn't in a position to give authorization and the like.
> Once he gets that, it's difficult to prevent him to
> secretly use it in illegal ways. It's basically a trust
> that the patients have on the doctors in general. Note
> also that there are other persons that help them, e.g.
> the nurses etc. It would be extremely costly to absolutely
> block possibility of leaking of informations in all
> situations, if that were technically possible at all. Thus
> an ideal tight protection is imfeasible in my humble view.
> There are on the other hand ethical committees of
> organizations of doctors which deal with cases where some
> of them behave in bad ways. That takes care of the issues
> like the one you mentioned about publishing, if I don't err.
>
> M. K. Shen
Patients should support ethical doctors as well. While it is difficult
for them to openly punish those that aren't, with better communications,
those tempted to be up to no good should fear people finding out who did
what to whom and when.
--
Sign for the White House lawn:
WARNING! Irresponsible Parents Live Here.
--
From: "Dirk Bruere" <[EMAIL PROTECTED]>
Subject: Re: practical birthday paradox issues
Date: Mon, 4 Jun 2001 03:58:18 +0100
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Scott Fluhrer <[EMAIL PROTECTED]> wrote:
>
> [finding birthday collisions]
>
> : But, you say, isn't doing all that infeasible? Yes, at current
technology,
> : it is, and that is why NSA settled for 160 bits output for SHA-1...
>
> If the same rationale applies to SHA-256, SHA-384 and SHA-512
> [http://csrc.nist.gov/cryptval/shs.html] I fear there may have
> been some hardware breakthroughs behind closed doors ;-)
One might make a guess at h/w capability given that the old WW2 custom
electromech system was roughly as powerful as a Pentium 100MHz.
Dirk
--
From: [EMAIL PROTECTED] (JPeschel)
Date: 06 Jun 2001 03:16:23 GMT
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Tim Tyler [EMAIL PROTECTED] writes, in part:
>JPeschel <[EMAIL PROTECTED]> wrote:
>: Tim Tyler [EMAIL PROTECTED] writes, in part:
>
>:>OTPs do *not* have perfect secrecy if messages can be of varying lengths
>:>and the plaintexts and cyphertexts are of equal lengths.
>
>: I don't follow this. It sounds as if you are re-defining an OTP.
>
>What don't you follow about it?
>
>I'm talking about a system involving a one-time random key stream, XORing
>it with the plaintext, and producing a cyphertext the same length as
>the plaintext.
That's an OTP and its secrecy is perfect.
>I am claiming that the result does not have perfect secrecy - assuming a
>reasonable space of variable length files as possible messages.
What you've written immediately above suggests an addiotional property
for an OPT that leads me to believe you are re-defining OTPs.
>This is the system Tom is calling a OTP. He uses it by analogy with CTR
>mode to claim that CTR mode is proven secure with small plaintexts.
Tom, I think, was using the accepted definition.
>I don't much mind what name is given to the system I described.
>I'm not trying to redefine anything.
>--
Names are important; otherwise no one will have a clue what you'r
Cryptography-Digest Digest #532
Cryptography-Digest Digest #532, Volume #13 Tue, 23 Jan 01 16:13:01 EST
Contents:
Re: JPEG infidelity for crypto (Kenneth Almquist)
Re: Kooks (was: NSA and Linux Security) ("Douglas A. Gwyn")
Re: using AES finalists in series? ("Douglas A. Gwyn")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Why Microsoft's Product Activation Stinks ("Joseph Ashwood")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Some Enigma Questions ("David C. Barber")
Re: using AES finalists in series? (Terry Ritter)
Re: Cryptographic Windows APIs or OCX? ("Joseph Ashwood")
Re: collisions risks of applying MD5 or SHA1 to a 48-bit input ("Joseph Ashwood")
From: [EMAIL PROTECTED] (Kenneth Almquist)
Subject: Re: JPEG infidelity for crypto
Date: 23 Jan 2001 20:10:47 GMT
[EMAIL PROTECTED] (John Savard) wrote:
> On Sun, 21 Jan 2001 17:03:18 +0800, Dido Sevilla <[EMAIL PROTECTED]>
> wrote, in part:
>
>> What relation does this have to cryptography? Have you missed saying
>> something?
>
> Well, the relation is obvious: simple forms of steganography, which
> depend on preserving things like the LSB of every single pixel, don't
> work with .JPG files.
Steganography is not covered by the sci.crypt FAQ, but my understanding
is that the term refers to hiding data in messages which look like
something else, the point being to disguise the fact that you are
sending encrypted messages. For this purpose, the fact that JPEG is
a lossy compression algorithm is relevant only if the communication
channel applies JPEG compression to all transmitted data. This seems
rather far fetched.
JPEG images would be a good choice for hiding messages precisely because
it is common for multiple compressions of the same scan to appear on the
internet. A typical scheme might work as follows:
1) You and your partner agree on a set of images.
2) When you want to send a message, you select an image and
compression parameters at random. (The compression parameters
should be chosen from a set of "plausible" parameters.)
3) The JPEG image standard specifies that you apply a discrete
cosine transformation, and then round the resulting values
to the nearest integer. (The rounding step makes JPEG lossy.)
Apply the transform, but rather than rounding to the nearest
integer, round up or down based on the next bit of the data to
be hidden. This encodes one bit per pixel.
4) To extract the message, the receiver performs the same discrete
cosine transformation and compares the result with the received
message to determine whether each value was rounded up or down.
If an evesdropper observes multiple copies of the same image being
sent, that might provide a clue that steganography is being used, so
you would want a fairly large number of pictures for this purpose.
The alt.binaries.pictures newsgroups provide a good supply.
> You could complain that we already knew that, and that there are more
> sophisticated (but less efficient) methods of steganography that even
> work with JPEGs; they're mainly used for watermarking.
Watermarking involves modifying an image or other work slightly so
that you can recognize it when you see it again. This is a different
problem than hiding a message. Watermarking systems are designed to
foil deliberate attempts to obscure the watermark by making small
changes to the watermarked copy. The fact that small changes can be
introduced by JPEG compression rather than a deliberate attempt to
obscure the watermark would seem to be irrelevant since protecting
against the latter also protects against the former.
By "small" changes, I mean changes that are not visually obvious. The
example that started this thread was one where the JPEG compression
created visible artifacts. Since these artifacts were not specificly
chosen to obscure a watermark, I suppose the odds are that they would
not affect a typical watermark system.
Note that converting a typical color image to GIF format also loses
information. In a GIF image, each pixel must have a color which
appears in the color map, and the color map is limited to 256 colors.
This typically creates signficant visual artifacts throughout the
image. Of course artificially constructed images (as opposed to
photographic images) can be designed to contain no more than 256
colors. I suspect that a watermark applied to such an image could
be obscured by reducing the watermarked image to 256 colors, and
then fiddling with the low order bits of the color map.
Kenneth Almquist
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]
Cryptography-Digest Digest #532
Cryptography-Digest Digest #532, Volume #12 Fri, 25 Aug 00 07:13:01 EDT
Contents:
SSL implementation for client authentication ([EMAIL PROTECTED])
Re: Bytes, octets, chars, and characters ("G Swaine")
Re: SHA-1 test request (Francois Grieu)
Re: Serious PGP v5 & v6 bug! (David Kennedy CISSP)
Re: Bytes, octets, chars, and characters (Casper H.S. Dik - Network Security
Engineer)
Re: Serious PGP v5 & v6 bug! ("Michel Bouissou")
Re: ADK Bug: Statement from cert.org. (Keith)
senders using the modified certificate have no way to detect the modification
without complicated manual inspection (Keith)
Re: Serious PGP v5 & v6 bug! (Keith)
Re: Serious PGP v5 & v6 bug! (Keith)
Re: blowfish problem (Richard Bos)
Re: The DeCSS ruling - Reverse engineering? (rot26)
Re: Bytes, octets, chars, and characters (AndyC)
From: [EMAIL PROTECTED]
Subject: SSL implementation for client authentication
Date: Fri, 25 Aug 2000 08:11:10 GMT
Hi experts there out,
I am implementing a project in which I have to to a client authenticaton
in a IBM HTTP server.In generl can some one tell me how can I implement
the client authentication or which directives I put in.Please give me
the details and step procedure,and also do I need to generate the key
file database ,since I have read their can be only one instance of the
keyfile Db in the conf file(please clear).if possible I will be very
much obliged if you all can do so.
Thanks
Jagjit
IBM India
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "G Swaine" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,alt.folklore.computers
Subject: Re: Bytes, octets, chars, and characters
Date: Fri, 25 Aug 2000 20:19:01 +1200
Reply-To: "G Swaine" <[EMAIL PROTECTED]>
"Paul Schlyter" <[EMAIL PROTECTED]> wrote ...
> John Savard <[EMAIL PROTECTED]> wrote:
> > Another way to consider the word length of a machine would be to see
> > what alignment restrictions apply to instructions. This makes a
> > System/360 a 16-bit machine, and even a Pentium an 8-bit machine;
> > while this is an unambiguous convention, it doesn't say anything
about
> > the power of the machine or the underlying architecture, so it
hasn't
> > been used.
>
> Using that as a criterion for the word length would have some weird
> effects: it would make the 68000 and 68010 16-bit CPU's, while the
> 68020 and later would be 8-bit CPU's..
The '020 required instructions to be on even addresses, AFAICR
--
Due to the amount of junkmail I've received in the past, this message
has bogus From and ReplyTo names and addresses. I can be contacted via
an intermediary : gem at gem win co nz. I would like to apologise to the
genuine respondents that this may inconvenience.
--
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: SHA-1 test request
Date: Fri, 25 Aug 2000 10:33:00 +0200
[EMAIL PROTECTED] (S. T. L.) wrote:
> I'm trying to improve/debug my SHA1.EXE program that I wrote in C,
> and I need to make sure that it treats huge files properly.
> Could someone (..post..) the hash of a 1,000,000,000 byte
> file consisting of the character 'a' ?
Test vestors for SHA1 have been independently cross-verified by
Jim Gillogly and myself on Aug 1998. Our focus was on messages
with bit length not a multiple of 8. The vectors include an example
over 2^32 bits, see my repost:
<http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=544748495&fmt=text>
As of your 10^9 times the byte 0x61, my implementation gives
D0F3E4F2 F31C665A BBD8F518 E848D5CB 80CA78F7
I second other comments that you should read the file once only.
As of computing the file length, I use something in the line of
unsigned long my_lenL, my_lenH, len; /* at least 32 bits */
/* update my_len with len, expressed in bytes */
my_lenL += len; /* update my_lenL */
if (my_lenL>29);
my_W[15] = (my_lenL<<3)|vn;
I believe this is correct on any ANSI C platform: it is guaranteed
"unsigned long" performs arithmetic mod 2^k for some integer k at
least 32.
As of portability, I recommand that you test your C code on a
variety of environements, including big-endian and little-endian,
and with 16 bit ints.
Francois Grieu
--
From: David Kennedy CISSP <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Fri, 25 Aug 2000 04:43:53 -0400
Reply-To: [EMAIL PROTECTED]
=BEGIN PGP SIGNED MESSAGE=
JL wrote:
>
> > Is it Ralf's opinion that manipulated keys do not reveal the
presence of
> > ADKs?
>
> Not from what I understa
Cryptography-Digest Digest #532
Cryptography-Digest Digest #532, Volume #11 Tue, 11 Apr 00 23:13:01 EDT Contents: Re: Q: Inverse of large, sparse boolean matrix, anyone? (Mok-Kong Shen) Re: General principles of design (Mok-Kong Shen) Re: strength of altered vigenere cipher? (Mok-Kong Shen) Re: Is AES necessary? (Mok-Kong Shen) Re: Q: Inverse of large, sparse boolean matrix, anyone? (Tim Tyler) Re: General principles of design (Mok-Kong Shen) Re: Miami Herald article about ATM ripoffs (O. Lay Merkin) new cipher design idea (Tom St Denis) Re: Compaq invents more efficient RSA?! (David Hopwood) Re: Compaq invents more efficient RSA?! (David A Molnar) Want to be a genius? ([EMAIL PROTECTED]) Re: computer specs, timing and PK Crypto (Steven C. Den Beste) Re: Encode Book? (Tom St Denis) Re: GSM A5/1 Encryption ([EMAIL PROTECTED]) Re: new cipher design idea (Tom St Denis) Introductory Crypto Books (Josh Tompkins) Re: new Echelon article (Diet NSA) Re: 2048 Bit Encryption? (Diet NSA) Re: Compaq invents more efficient RSA?! (David Hopwood) Re: manual cypher (MCTER) (David Hopwood) From: Mok-Kong Shen <[EMAIL PROTECTED]> Subject: Re: Q: Inverse of large, sparse boolean matrix, anyone? Date: Wed, 12 Apr 2000 01:08:34 +0200 Gadi Guy wrote: > > I'm not sure whether my problem is with inverting the matrix > or simply with creating an invertable matrix. I find that > the simple, pivoting Gauss elimination algorithm I copied from > "Numerical Recipes" fails every time. > > It creates 0's in the diagonal and then goes berserk. > > MacKay says: "Such a random sparse matrix is not necessarily > invertable, but there is a probability (for large N) of about > 0.29 that it is." [Good codes based on very sparse matrices, > MacKay and Neal]. For large N, it becomes increasingly expensive > to generate matrices and eliminate them. > > My algorithm fails miserably most of the time, which lead me to > believe that maybe there's something more to inverting boolean > matrices than they teach in numerical analysis. Perhaps I am over cautious. But I do want to avoid a probable language ambiguity. A Boolean matrix is not identical to (though has the same form as) an integer matrix whose elements are either 0 and 1. One uses Boolean arithmetics, e.g. 1 + 1 = 0. A normal library Gaussian elimination subroutine, such as the one in Numerical Recipes, is hence not applicable to a Boolean matrix. I can't give concrete reasons, but I intuitively believe that the probability of your having a singular (non-invertible) sparse Boolean matrix is fairly high, much higher than in case of normal matrices with integer or real-valued elements. If your problem is not inverting a Boolean matrix but inverting a sparse integer matrix whose elements happen to be 0's and 1's, then I would say that the probability of being singular is also high (somewhat lower than in the Boolean case, I guess). But here you can't use the subroutine from Numerical Recipes, since that employs real arithmetics and hence has rounding errors. You have to use a version employing integer arithmetics. But then with the 'normal' Gaussian elimination you would very likely get overflow even with very small dimension of the matrix. With some appropriate techniques you could handle larger matrices without overflow, but only to some fairly limited extent. It is then totally out of the question for matrices of the dimension you gave in your original post. M. K. Shen -- From: Mok-Kong Shen <[EMAIL PROTECTED]> Subject: Re: General principles of design Date: Wed, 12 Apr 2000 01:08:27 +0200 almis wrote: > > Hm. OK > > However; your concept seems to be in conflict with a cryptographic > maxim that states (something like) '...That which cannot be hidden deeply, > should not be hidden at all...' Probably you mean that an algorithm is assumed to be 'known' to the opponent. But the general construction may be known to him, the details may be variable, i.e. parametrized and hence dependent on the key, and hence not exactly known to him. One example is key-dependent S-boxes. He knows the number of the S-Boxes used in the algorithm and where are they situated, but he is ignorant of their contents. There are many other possibilities of variations which we could later have opportunity to discuss in more details. M. K. Shen -- From: Mok-Kong Shen <[EMAIL PROTECTED]> Subject: Re: strength of altered vigenere cipher? Date: Wed, 12 Apr 2000 01:08:46 +0200 Paul Koning wrote: > > For Vigenere, or the mixed alphabet variant you suggest, for each > position in the plaintext each plaintext letter maps to a single > ciphertext letter.
Cryptography-Digest Digest #532
Cryptography-Digest Digest #532, Volume #10 Tue, 9 Nov 99 13:13:04 EST
Contents:
Re: PGP Cracked ?
Re: Signals From Intelligent Space Aliens? Forget About It. (Anthony Stephen Szopa)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (David Bernier)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ([EMAIL PROTECTED])
Re: The story of a small boy --- sealed envelops --- encryption technologies (Best
Wishes)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Richard Herring)
Re: The DVD Hack: What Next? (Terje Mathisen)
Self-certified public key.. ("OTTO")
Re: NOVA: the Code Breakers TONIGHT Nov 9
Re: Proposal: Inexpensive Method of "True Random Data" Generation
Re: Proposal: Inexpensive Method of "True Random Data" Generation
Re: Proposal: Inexpensive Method of "True Random Data" Generation
Re: Proposal: Inexpensive Method of "True Random Data" Generation
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
Re: An encryption proposal from a Newbie... <- A modification (Stefek Zaba)
Re: Can the SETI@home client be protected? (Guy Macon)
Re: Lenstra on key sizes (DJohn37050)
Re: Can the SETI@home client be protected? ("Gary")
Re: An encryption proposal from a Newbie... <- A modification (Mike Partain)
Re: The Code Book Mailing List (Stefek Zaba)
Re: Can the SETI@home client be protected? (Guy Macon)
Re: Signals From Intelligent Space Aliens? Forget About It. ("Doug Gwyn (ISTD/CNS)
" <[EMAIL PROTECTED]>)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Doug Gwyn
(ISTD/CNS) " <[EMAIL PROTECTED]>)
From: [EMAIL PROTECTED] ()
Subject: Re: PGP Cracked ?
Date: 9 Nov 99 11:51:59 GMT
Jim Gillogly ([EMAIL PROTECTED]) wrote:
: Dennis Ritchie wrote:
: > Douglas A. Gwyn wrote, quoting Jerry Coffin:
: > > > Like Ken, AFAIK, he's never said _anything_ to confirm (or,
: > > > admittedly, deny) that it was actually done.
: > > I could swear that they have said the experiment was actually done,
: > > just that it was not in any of the UNIX distributions.
: > I could so swear too.
: So could Ken. Here's an extract of a note he wrote on
: 23 Apr 1995:
: fyi: the self reproducing cpp was
: installed on OUR machine and we
: enticed the "unix support group"
: (precursor to usl) to pick it up
: from us by advertising some
: non-backward compatible feature.
: that meant they had to get the
: binary and source since the source
: would not compile on their binaries.
: they installed it and in a month or
: so, the login command got the trojan
: hourse. later someone there noticed
: something funny in the symbol table
: of cpp and were digging into the
: object to find out what it was. at
: some point, they compiled -S and
: assembled the output. that broke
: the self-reproducer since it was
: disabled on -S. some months later
: the login trojan hourse also went
: away.
: the compiler was never released
: outside.
So this clears it up; this "backdoor" was never a universal feature of
Unix, but the technique was tested - and at least partially inflicted on
some users as well.
: Jim Gillogly
: Hevensday, 17 Blotmath S.R. 1999, 04:24
: 12.19.6.12.5, 6 Chicchan 13 Zac, Second Lord of Night
Dare I guess you're posting from inside Emacs (which, having these date
capabilities, can safely be assumed to by Y2K compliant...)? Although I
didn't realize that even Emacs handled the Shire Reckoning, but I suppose
that was inevitable. (Since the Third Age is now long in the past,
however, I would have thought the year would be long after 1999 in their
epoch.)
John Savard
--
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.military,talk.politics.misc,talk.politics.crypto
Subject: Re: Signals From Intelligent Space Aliens? Forget About It.
Date: Tue, 09 Nov 1999 04:03:17 -0800
Reply-To: [EMAIL PROTECTED]
Scott Erb wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> >
> >
> >But your definition we already have been. The announcement is 60-70
> lightyears
> >out and receeding at a speed we do not ever expect to match.
>
> I think the poster you're responding to has been watching too much sci-fi.
> Last night on Futurama a race of space aliens attacked earth because the
> transmission of "Single Female Lawyer" (a spoof on Ally McBeal -- her name
> on the show was Jenny McNeil) was interrupted and they demanded to know
> what happened. Since their planet is 1000 light
Cryptography-Digest Digest #532
Cryptography-Digest Digest #532, Volume #9 Wed, 12 May 99 01:13:03 EDT
Contents:
Re: Crypto export limits ruled unconstitutional (Bryan Olson)
Re: TwoDeck solution (but it ain't pretty) (Boris Kazak)
Re: Factoring breakthrough? (ca314159)
Re: Factoring breakthrough? (ca314159)
Re: Hello I am paper, please read me. (SCOTT19U.ZIP_GUY)
Re: Arab Terrorists Must Bomb Moscow & Belgrade KKKommunists ("Patrick Patriarca")
Re: Little Irish girl's algorithm? (Nemo999)
Re: Hello I am paper, please read me. (John Savard)
Re: TwoDeck solution (but it ain't pretty) (John Savard)
Re: 128bit Blowfish Info (John Savard)
From: Bryan Olson <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Crypto export limits ruled unconstitutional
Date: Tue, 11 May 1999 18:38:34 -0700
David A Molnar wrote:
>
> cosmo <[EMAIL PROTECTED]> wrote:
> > Can a person publish a flowchart for an algorithm ? How about a program written
> > in pseudocode ? How about a general mathematical description of an encryption
> > algorithm ? How could anyone say that such is not protected by the first
> > ammendment ?
>
> > Does anyone know ?
>
> You can publish anything on paper. There's an exception for academic work.
> This is how PGP's source code managed to legally make it overseas.
> Electronically, it seems like the litmus test is whether or not what you
> publish can perform encryption. So pseudocode doesn't count, but the notes
> from, like, a UML design tool with automated code generation may be getting
> fuzzy.
It's not clear what question that answers. The current export
regulations distinguish between paper and electronic media, but
if the question is about what material has first amendment protection,
then their is no such distinction. The courts have consistantly
affirmed that the same principles that apply to paper apply to
electronic media. The airwaves are something of a special case, since
there is an issue of public ownership.
--Bryan
--
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: TwoDeck solution (but it ain't pretty)
Date: Tue, 11 May 1999 18:55:49 -0400
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> Nobody wants a look at your pathetic "TwoDeck" piece of crap because
> despite your ability to use html->ps/pdf converters, what you say is
> still shit.
>
LadyCow, stop this cunttalk and take a shower - you stink.
--
From: ca314159 <[EMAIL PROTECTED]>
Subject: Re: Factoring breakthrough?
Date: Mon, 10 May 1999 23:52:10 GMT
In article
<[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <7h3sgu$68n$[EMAIL PROTECTED]>,[EMAIL PROTECTED] wrote:
>
> > In article<[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (wtshaw) wrote:
> > I imagine this statement applies to any
> > ciphertext as well.
> > If one knows the constraints of
> > encipherment, one can extract
> > a plaintext from the background noise
> > of the ciphertext.
>
> This is the type of thing you should
> work against in writing algorithms.
> Supposedly, the noise can become more
> prevalent than the message which is
> indistinguishable from variations in the
> noise. Actually, this is quite
> easy to do.
The "noise" can also increase your ability
to percieve a signal when there are
conservative constraints (finite bandwidth etc.)
* Turing's use of "the exception proves
the rule" taken to extremes.
* A slight positional displacement
of dots in a random dot stereogram will
separate a signal from a noisy background
"if you look at it the right way".
* "Stochastic resonance" and "squeezed light".
* It seems at times that quantum physicists will
define a particle just as much by what it
is, as by what it is not (noise and carrier).
* Fuzzy theory (Kosko's subsethood) as well
deals with the overlap of A and not-A;
the violation of the law of non-contradiction.
Most people object to this idea because in
a court of law (and science?) it is not allowed
as a defense. A signal cannot contain noise
in a court of law (the judgement must be
absolute; there is no indecision )
For instance, the early American
politicians recognized that "liberty" and
"justice" are complementary, so they say
"liberty AND justice for all"
not just liberty, or not just justice.
The must be taken together like A and not-A;
like signal and noise.
Here, "liberty" may be construed as the
"signal" of an individual in society
but it
