Cryptography-Digest Digest #154
Cryptography-Digest Digest #154, Volume #14 Sun, 15 Apr 01 17:13:00 EDT
Contents:
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: NSA is funding stegano detection (Walter Roberson)
Re: Reusing A One Time Pad ("Tom St Denis")
Re: LFSR Security ("Trevor L. Jackson, III")
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: LFSR Security ("Trevor L. Jackson, III")
Re: Remark on multiplication mod 2^n (Mok-Kong Shen)
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: C Encryption ("Trevor L. Jackson, III")
Re: Advantages of attackers and defenders ("AY")
Re: LFSR Security (Graywane)
Re: Reusing A One Time Pad ("Tom St Denis")
Re: Reusing A One Time Pad ("Tom St Denis")
Re: Password tool! ("Logan Raarup")
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: Reusing A One Time Pad ("Mark G Wolf")
Why Not OTP ? (Frank Gerlach)
From: "Mark G Wolf" [EMAIL PROTECTED]
Subject: Re: Reusing A One Time Pad
Date: Sun, 15 Apr 2001 15:26:06 -0500
If no bit position within the pad is used to encrypt more than one
message,
it's secure (in the information theoritical sense).
If you ever reuse a single bit position within the pad, it's not secure
(in
theory, and usually in practice as well).
I understand that. And let me take a moment to say that practicality often
gets lost in theory. Even if I was absolutely sure of that one bit, it
wouldn't really do me much good even for a 7-bit ASCII four letter word.
Let me give another example. Let's say I encoded "EAT AT JOES" with pieces
of my one time pad 10 times, and once out of those ten times I reused the
same bits to encode the first "E". One "E" is not very useful, assuming you
can even tell it's part of my message. Remember you don't have my one time
pad.
--
From: [EMAIL PROTECTED] (Walter Roberson)
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: 15 Apr 2001 20:34:10 GMT
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
:I'd have thought that detection of otherwise well constructed
:steganography would be based on statistical analysis of the degree of
:entropy or randomness in the data. Any unencrypted image, or other
:file, intended to convey information is by definition not random.
On the other hand, the data may be compressed. Compression works
by reducing redundancy, so the compressed data is "more random".
Any compression algorithm that leaves statistically-detectable
correlation in its file, could theoretically be improved [but improving
the algorithm might be difficult as a practical matter.]
: So
:GIFs, JPEGs etc are not random. It would be perfectly feasible to
:analyze a huge quantity of such files (ones without hidden messages)
:to establish their statistical properties - in particular the degree
:of randomness.
Not really. "Degree of randomness" has no objective meaning. There
is only "degree of randomness compared to a particular model." And
there isn't just *one* model for GIFs, JPEGs etc.; there is an
indefinite series of models depending on subject matter, equipment
and so on.
:Then one could focus on statistical comparisons of
:files being sent by others with a view to establishing whether there
:is any probability that the degree of randomness is more or less than
:expected.
Yes, but by the time you account statistically for all of those
different models, the statistical measure is going to have to be
very loose -- unable to detect anything but the most obvious
hidden information.
:On this basis, I suspect that those using steganography in pictures
:should:
:1) use messages that are small relative to the container
:2) send images containing messages infrequently
:3) send lots of images which contain no messages
Alternately, have *every* image contain a message, but make it very
difficult to tell which messages are spurious. Perhaps even use
a multi-level code in which the "outer" message was relatively
innocuous and explicable/deniable. For example you could even give
them full source to the image encoding algorithm... source that just happens
to have a "bug" that picks up an "uninitialized" block of memory
(whose contents you very subtly prime if you have something to send.)
And so on.
--
From: "Tom St Denis" [EMAIL PROTECTED]
Subject: Re: Reusing A One Time Pad
Date: Sun, 15 Apr 2001 20:34:11 GMT
"Mark G Wolf" [EMAIL PROTECTED] wrote in message
news:9bd06m$6o6o$[EMAIL PROTECTED]...
If no bit position within the pad is used to encrypt more than one
message,
it's secure (in the information theoritical sense).
If you ever reuse a single bit position w
Cryptography-Digest Digest #154
Cryptography-Digest Digest #154, Volume #13 Tue, 14 Nov 00 08:13:00 EST
Contents:
Re: XOR Software Utility (freeware) available from Ciphile Software ("Midnight's Own
Fire")
Re: XOR Software Utility (freeware) available from Ciphile Software ("Midnight's Own
Fire")
Re: Hash used in prepaid phone cards. (those who know me have no need of my name)
Re: Hash used in prepaid phone cards. (Ariel Burbaickij)
Re: DES advice ("kihdip")
Re: DES advice (Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?=)
Re: Algorithm with minimum RAM usage? (Paul Rubin)
Re: Algorithm with minimum RAM usage? (Paul Rubin)
Re: Algorithm with minimum RAM usage? (Guy Macon)
Re: hardness of monoid word problem? (stanislav shalunov)
Re: "Secrets and Lies" at 50% off (Paul Crowley)
Re: Anyone done/doing Schneier's self-study cryptanalysis course? (Paul Crowley)
XORred zipfile chunks = random? ([EMAIL PROTECTED])
Re: Why remote electronic voting is a bad idea (was voting through pgp) (Tommy the
Terrorist)
Re: On an idea of John Savard (Tom St Denis)
Re: XORred zipfile chunks = random? (Tom St Denis)
Re: I would like your opinion on this (Tom St Denis)
Re: PGP still the no1? (Tom St Denis)
Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (d)
Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (d)
From: "Midnight's Own Fire" [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Tue, 14 Nov 2000 05:17:55 GMT
root1657 [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Anthony Stephen Szopa wrote:
If you know what you are talking about then you must have resources
to check the behavior of the software while it is running: such as
a firewall or virus protection?
Some are free, you know.
Give us some proof if you can.
Or are you too pathetically feeble minded?
First off... if I were doing what you seem to be doing... I'd burry the
damned thing so deep... that it would not manifest itself in anyway... for a
while.
Without even having seen the program, or it's code, i would caution anyone
against using a program written or endorced by a person with an attitude
like
that. It just gives off a "malicious code" vibe
xxx
No kidding... but the file size itself does that.
--
From: "Midnight's Own Fire" [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Tue, 14 Nov 2000 05:17:55 GMT
Tom St Denis [EMAIL PROTECTED] wrote in message
news:8ua38p$bk4$[EMAIL PROTECTED]...
That's insane... learn how to trim executable sizes...
At http://www.geocities.com/tomstdenis/files/xor.c is a copy of the
same program that does most common error handling (read/write errors,
invalid file opens, etc...)... except for forgetting a "return 0;" at
the end of main()I think it's a complete application.
It's only 9kb when compiled with Turbo C 2.01...
Tom
bet I could write it in vb in just under 7k. maybe not tho... heh.
--
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Hash used in prepaid phone cards.
Date: Tue, 14 Nov 2000 05:42:25 -
[EMAIL PROTECTED] divulged:
Question: What is the standard(or most ofen) hash function
used to discriminate between valid and invalid
PIN-number very quickly?
there is probably no hashing being done, just a database lookup. (the
database system will probably use a hash to locate the key bucket.)
--
okay, have a sig then
--
From: Ariel Burbaickij [EMAIL PROTECTED]
Subject: Re: Hash used in prepaid phone cards.
Date: Tue, 14 Nov 2000 08:22:18 +0100
those who know me have no need of my name wrote:
[EMAIL PROTECTED] divulged:
Question: What is the standard(or most ofen) hash function
used to discriminate between valid and invalid
PIN-number very quickly?
there is probably no hashing being done, just a database lookup. (the
database system will probably use a hash to locate the key bucket.)
--
okay, have a sig then
Well but you somehow have to fill your database (just random number
generator
? )or something more deeper ?
--
From: "kihdip" [EMAIL PROTECTED]
Subject: Re: DES advice
Date: Tue, 14 Nov 2000 08:27:14 +0100
You'll find test-vectors in this document:
http://csrc.nist.gov/nistpubs/800-17.pdf
At page 134 you'll find round results.
Kim
--
From: Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?= [EMAIL PROTECTED]
Subject: Re: DES advice
Date: Tue, 14 Nov 2000
Cryptography-Digest Digest #154
Cryptography-Digest Digest #154, Volume #12 Mon, 3 Jul 00 19:13:01 EDT
Contents:
Quantum Computing (Was: Newbie question about factoring) ("Paul E. Black")
Re: Decrypting MD5 (Steve Rush)
Re: cray and time needed to attack (Jerry Coffin)
Re: A thought on OTPs (Simon Johnson)
Re: Cooking up MAC keys (David A. Wagner)
Re: cray and time needed to attack (jungle)
Re: Hashing Function (not cryptographically secure) (David A. Wagner)
Re: Hashing Function (not cryptographically secure) (David A. Wagner)
Re: cray and time needed to attack ("Douglas A. Gwyn")
Re: Blowfish for signatures? (David A Molnar)
Re: Security of this F-Function (David A. Wagner)
Re: A thought on OTPs ("Tony T. Warnock")
Re: A thought on OTPs ("Joseph Ashwood")
TC5 Completed Paper (tomstd)
Re: A thought on OTPs (S. T. L.)
Re: Encryption and IBM's 12 teraflop MPC.. ("Harvey Rook")
Re: Security of this F-Function (Simon Johnson)
Re: A thought on OTPs ("Douglas A. Gwyn")
Re: Compression Encryption in FISHYLAND (Kurt Shoens)
Re: TC5 Completed Paper ("Joseph Ashwood")
Re: SCOTT19U.ZIP_GUY PLONK! (Simon Johnson)
Re: Quantum Computing (Was: Newbie question about factoring) (Nick Maclaren)
Re: Security of this F-Function ("Joseph Ashwood")
From: "Paul E. Black" [EMAIL PROTECTED]
Crossposted-To: comp.theory
Subject: Quantum Computing (Was: Newbie question about factoring)
Date: Mon, 03 Jul 2000 15:20:31 -0400
Nick Maclaren wrote:
However, some people believe that building a quantum computer is
an exponentially complex problem,
Interesting. Could you give more details, for instance, who believes
that or what goes into it? For instance, is it that designing a
quantum computer is exponentially complicated, or constructing it
(an exponential number of steps needed)?
-paul-
--
Paul E. Black ([EMAIL PROTECTED])
--
From: [EMAIL PROTECTED] (Steve Rush)
Subject: Re: Decrypting MD5
Date: 03 Jul 2000 20:31:07 GMT
Eh ? Where did you get that idea from ?
A hard to predict key schedule is in no way a guarantee for a good
cipher,
But I was referring to cyphers built around secure hash functions. These are
essentially stream cyphers that use the hash function to generate the
keystream. If you do it right, you get a good cypher.
==
==
If it's spam, it's a scam. Don't do business with Net abusers.
--
From: Jerry Coffin [EMAIL PROTECTED]
Subject: Re: cray and time needed to attack
Date: Mon, 3 Jul 2000 14:36:57 -0600
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] says...
i want to know how many time is need to a cray to crack a:
1° 128 bit key with idea
2° 1024 bit key with blowfish
A Cray would NOT be the weapon of choice in either of these attacks.
Instead, you'd want to use specialized custom hardware. Unless
somebody finds a HUGE break in the ciphers themselves it doesn't make
any real difference though: it would take millions of years to
exhaust the keyspace of either one. Oh, and just FWIW, Blowfish only
accepts keys of up to 448 bits, but even at that nothing approaching
a practical attack is known at the present time.
3° 128 bit key with RSA
By contrast, this is so trivial that there's no real reason to use a
Cray at all -- with an average desktop or laptop, factoring a 128-bit
number will take less time than it takes you to type in the number.
If you intended to say 128 decimal digits instead of 128 bits, then
at least you've got something secure enough that you might consider
sing it. Somebody with plenty of talent and money could still break
it, but the best people and computers available would still take a
few months to do the job.
4° 1024 bit key with DH
This borders on being theoretically possible with present technology,
but the attacker would have to be willing to dump millions of dollars
into the project, and even at that it would NOT be completed very
quickly -- think in terms of years, not months.
--
Later,
Jerry.
The universe is a figment of its own imagination.
--
From: Simon Johnson [EMAIL PROTECTED]
Subject: Re: A thought on OTPs
Date: Mon, 03 Jul 2000 20:30:51 GMT
In article [EMAIL PROTECTED],
"Douglas A. Gwyn" [EMAIL PROTECTED] wrote:
Darren New wrote:
As I said, this doesn't really change anything, but for people who
have
trouble seeing why the OTP is provably secure, the idea that the
first thing
you generate is the cyphertext and the second thing you generate is
the key
might be interesting.
More likely it is just confusing, since it abuses the standard
usage for the terms "key" and "ciphertext".
I agree with you, but
Cryptography-Digest Digest #154
Cryptography-Digest Digest #154, Volume #11 Fri, 18 Feb 00 19:13:01 EST
Contents:
Re: VB Crypto (Glenn Larsson)
The Online Banking Flaw... (John Savard)
Re: EOF in cipher??? ("Trevor Jackson, III")
Re: VB Crypto (Jerry Coffin)
Re: code still unbroken ("Chuck Davis")
Re: EOF in cipher??? ("Trevor Jackson, III")
Re: EOF in cipher??? ("Trevor Jackson, III")
Re: Processor speeds. ("Trevor Jackson, III")
Re: Keys Passwords. ("Trevor Jackson, III")
Re: Question about OTPs (Bryan Olson)
Re: VB Crypto ("Brian Bosh")
Re: Using virtually any cipher as public key system? (Anton Stiglic)
Re: Question about OTPs (John Savard)
Re: Question about OTPs (Bryan Olson)
Re: EOF in cipher??? (JPeschel)
Re: NSA Linux and the GPL ("Adam Durana")
Re: VB Crypto ("Joseph Ashwood")
Re: Using virtually any cipher as public key system? (John Savard)
NIST publishes AES source code on web (David Crick)
Re: VB Crypto ("Kasper Pedersen")
Re: EOF in cipher??? (John Myre)
Re: EOF in cipher??? (John Myre)
From: Glenn Larsson [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: VB Crypto
Date: Fri, 18 Feb 2000 22:09:40 +0100
[EMAIL PROTECTED] wrote:
Well then you'll be happy to know that VB7...
Have MS invented large integer support yet or are we still in the
stonage with the 2^32 limitation? (i mean HELLO! it's Y2K ALREADY!)
(at least Bill learned that "640 kb" lession...)
I'm personally tired of all the pointless features Ms is putting
into VBA instead of developing it so one can use it for what's
discussed in this channel, hence VB apps can never be secured.
(VC++ really could use a 2^128 boost too..)
/Glenn
_
Spammers will be reported to their government and
Internet Service Provider along with possible legal
reprocussions of violating the Swedish "Personal
Information Act" of 1998. (PUL 1998:204)
This is punishable by a fine or 6 month to 2 years
imprisonment (Paragraph 49)
--
From: [EMAIL PROTECTED] (John Savard)
Subject: The Online Banking Flaw...
Date: Fri, 18 Feb 2000 14:40:39 GMT
In the latest Crypto-Gram, we have a story about a firm that offered
online banking services.
One could start an account with a bank transfer, and to get money
withdrawn from your bank account, all you needed to do was supply the
account number, and other numbers visible on checks for that account.
Now, it is clear the firm did make a bad decision, in that not
requiring more proof of account ownership allowed fraudulent
transactions.
However, since the firm *didn't* have proof people wanting to transfer
money from a bank account to the firm had the right to withdraw money
from those accounts, why is it the firm was able to _get_ that money
from the banks, since, if it didn't recieve the proof from the people
opening accounts with them, obviously it didn't have that proof to
show to the banks? To me, therefore, it seems that there is a
fundamental vulnerability in the whole banking system, without which
X.com would not have had the _opportunity_ to make the mistake that it
did.
Because of this vulnerability, one can still withdraw money from
anyone's account with just the numbers on the bottom of his check: but
instead of opening a new account with an online banking company, one
just has to go to a little more trouble: one has to start one's own
online banking company.
John Savard (jsavardatecndotabdotca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
--
Date: Fri, 18 Feb 2000 16:49:42 -0500
From: "Trevor Jackson, III" [EMAIL PROTECTED]
Subject: Re: EOF in cipher???
Mok-Kong Shen wrote:
Runu Knips schrieb:
"Trevor Jackson, III" schrieb:
Mok-Kong Shen wrote:
To be sure that I didn't misunderstand, I like to ask whether the
code (from KR):
while ((C = getc(fp)) != EOF)
.
needs to be modified or using rb is sufficient for taking care of
the presence of any bit combinations in the file. Thanks.
The issue is the type of the variable C. To operate correctly it must
be an int not a char.
Unfortunately, the above code will run on many systems without
problems until fp is a binary file which happends to contain
the code 0xff, which is equal to (signed char)-1 (on machines
with 8 bits for a character).
I have read quite a lot in this thread but, because of non-unanimity
of opinions expressed, am still not sure of what is to be done
correctly. Could some experts please post a piece of C or C++ code
for writing AND reading binary stuffs to/from a file (byte sequences
containing arbitrary bit combinations) that are standard conforming
and guaranteed to work on all systems (together with things to be
Cryptography-Digest Digest #154
Cryptography-Digest Digest #154, Volume #10 Wed, 1 Sep 99 14:13:03 EDT
Contents:
Re: RC4 question ("Yuriy Stul")
Re: What if RSA / factoring really breaks? (Jean-Jacques Quisquater)
Re: Implementing crypto algorithms in Fortran. ("Tony T. Warnock")
Plaintext block size ("Kwong Chan")
Re: "Cause and Effect" ("Tony T. Warnock")
Re: What if RSA / factoring really breaks? (SCOTT19U.ZIP_GUY)
Re: One to One Compression updated (SCOTT19U.ZIP_GUY)
Re: Matrix Exponentiation (Herman Rubin)
Members Only Key Exchange (Gary)
Pincodes ("JuDa$")
Re: n-ary Huffman Template Algorithm (Mok-Kong Shen)
Re: What if RSA / factoring really breaks? (SCOTT19U.ZIP_GUY)
Re: Implementing crypto algorithms in Fortran. (Mok-Kong Shen)
Re: WT Shaw temporarily sidelined (Medical Electronics Lab)
THINK PEOPLE (SCOTT19U.ZIP_GUY)
Re: Standaarden in België (Mok-Kong Shen)
Re: Schneier/Publsied Algorithms ([EMAIL PROTECTED])
Re: Statue for Enigma hero (Aidan Skinner)
Password Encrytion Algo ([EMAIL PROTECTED])
Re: RC4 question (Kent Briggs)
From: "Yuriy Stul" [EMAIL PROTECTED]
Subject: Re: RC4 question
Date: Wed, 1 Sep 1999 13:19:58 +0200
David Bourgeois [EMAIL PROTECTED] wrote in message
news:7qiqb1$aiq$[EMAIL PROTECTED]...
I sincerely apologize in advance for this newbie question. I am
programmer
by hobby only and am trying to understand RC4 better.
struct rc4_key {
unsigned char state[256];
unsigned x, y;
};
If this is the structure for an RC4 key - what makes it 40-bit or 128-bit?
Key length what will be used for initializing of key (function
RC4_set_key(...)
Why isn't it (256 x 8)
2048-bit?
Is it that when calling the function:
void prepare_key(unsigned char *keydata, unsigned len, struct
rc4_key *key)
Yes.
only 5-bytes are used in "keydata" and the len = 5? (assuming 40-bit
implemenation).
Thanks
--
Regards
Yuriy Stul
mailto:[EMAIL PROTECTED] http://www.tashilon.com
--
From: Jean-Jacques Quisquater [EMAIL PROTECTED]
Subject: Re: What if RSA / factoring really breaks?
Date: Wed, 01 Sep 1999 17:08:25 +0200
Any debate about cryptography is difficult. Why?
Because we are not speaking about the same things
while using the same words.
Examples?
(1) "DES is insecure"
That's not correct: What we know is:
The state of the art in computation and the length
of one key of DES is such that in a chosen plaintext
attack we break it in 1 day. That are the facts.
The algorithm DES itself is not broken at all.
(2) "Factorization is insecure because quantum computing is
doing it in polytime"
While the theory is very nice we are waiting for the crucial
experiment.
Now compare (1) and (2): the facts and implementations
are exhaustive search of 56 bits in one case,
factorisation of numbers of few bits in the other one.
That's not the same story.
Same story with the TWINKLE from Adi Shamir. We saw conclusions
for today based on implementations of tomorrow: then logically
the conclusion is only valid for tomorrow?
We have several parameters to put together:
- the facts and the experiments:
- the theoretical improvements and their possible implementations
and use at a large scale with a realistic schedule:
- the "law" of Moore.
Be careful to apply each step one time and to put the improvements
at the right place.
Jean-Jacques,
--
From: "Tony T. Warnock" [EMAIL PROTECTED]
Subject: Re: Implementing crypto algorithms in Fortran.
Date: Wed, 01 Sep 1999 08:40:58 -0600
Reply-To: [EMAIL PROTECTED]
Steven Alexander wrote:
Thanks, I appreciate the help. One more question though: How do I handle
addition/subtraction with signed integers in Fortran so that they will
behave like unsigned integers in C? TEA for instance uses a slew of
addition operations, how would I use them without causing unforseen results.
If you have any old Fortran source that would illustrate this I would
appreciate it. Thanks again in advance.
-steven
I'm not familiar with TEA but most Fortran's treat integers as modulo the base.
For example, with 32-bit integers, the numbers 0-2147483647 are treated as
posivive and 2147483648-4294967295 as negative. Most hardware does not interrupt
on integer overflow so the results act like base 2^32 arithmetic. If your
numbers are small, there is no problem. If you need to check on sizes, just
check first for negative then for sizes. The same problem arises when sorting.
Comparisons may give incorrect results when there is an overflow. Assembly
language may have the same problem. In addition, if the sum of two positive
numbers is negative, there has been overflow, etc.
Tony
--
From: "Kwong Chan" [EMAIL PROTECTED]
Subject:
Cryptography-Digest Digest #154
Cryptography-Digest Digest #154, Volume #9 Sat, 27 Feb 99 20:13:05 EST
Contents:
Re: Question on Pentium III unique ID ("Robert C. Paulsen, Jr.")
Re: Question on Pentium III unique ID (Myself)
Re: True Randomness - DOES NOT EXIST!!! (BRAD KRANE)
Re: Randomness based consciousness?. (Was: Re: *** Where Does The Randomness Come
From ?!? *** ) (Seisei Yamaguchi)
Re: Skipjack anyone?
Re: True Randomness - DOES NOT EXIST!!! (BRAD KRANE)
Re: True Randomness - DOES NOT EXIST!!! (BRAD KRANE)
Re: True Randomness - DOES NOT EXIST!!! (BRAD KRANE)
Re: Unicity of English, was Re: New high-security 56-bit DES: Less-DES
([EMAIL PROTECTED])
Re: True Randomness - DOES NOT EXIST!!! ("Trevor Jackson, III")
From: "Robert C. Paulsen, Jr." [EMAIL PROTECTED]
Subject: Re: Question on Pentium III unique ID
Date: Sat, 27 Feb 1999 16:52:41 -0600
Roger Schlafly wrote:
Myself wrote in message [EMAIL PROTECTED]...
And plug-n-play cards also have unique serial numbers. There's nothing
new about uniquely identifiable PCs. The only interesting thing about
the P3 is the publicity and standardization that comes with Intel's
massive influence.
And the fact that Intel announced that it intends to distribute software
that surreptitiously uses the ID to identify people on the internet.
That part I hadn't heard. Any reference I can look at?
--
Robert Paulsen http://paulsen.home.texas.net
If my return address contains "ZAP." please remove it. Sorry for the
inconvenience but the unsolicited email is getting out of control.
--
From: [EMAIL PROTECTED] (Myself)
Subject: Re: Question on Pentium III unique ID
Date: Sat, 27 Feb 1999 23:08:07 GMT
On Sat, 27 Feb 1999 11:08:24 -0800, thermal and electromagnetic action
caused "Roger Schlafly" [EMAIL PROTECTED]'s brain to produce the
following pseudorandom thought:
Myself wrote in message [EMAIL PROTECTED]...
And plug-n-play cards also have unique serial numbers. There's nothing
new about uniquely identifiable PCs. The only interesting thing about
the P3 is the publicity and standardization that comes with Intel's
massive influence.
And the fact that Intel announced that it intends to distribute software
that surreptitiously uses the ID to identify people on the internet.
The question is: how hard is it to spoof a response? Their software is
going to either:
1) send the ID in the clear, with no attempt to guarantee that it's
really Intel's program saying so
2) attempt to cryptographically prove that the number being sent was
retrieved by Intel's unmodified program
In the first case, I'd give it about 6 hours before someone comes up
with a spoofer.. This ought to really play hell with servers. Just
like a recursive CGI that returns a million bogus emails to spam
spiders, you could conduct a million transactions each with a
different faked ID, and fill up big brother's database very quickly.
In the second case.. and this is something that's interested me for a
while (ever since I learned what a dongle was), how can a piece of
software authenticate itself and prove that it hasn't been modified?
I'd imagine that any encryption keys would be available to anyone with
a disassembler, and if that's the case couldn't a similar-looking
program be written, which would produce output that the server can't
distinguish as having come from a modified program?
-Myself-
--
From: BRAD KRANE [EMAIL PROTECTED]
Subject: Re: True Randomness - DOES NOT EXIST!!!
Date: Sat, 27 Feb 1999 23:43:26 GMT
No offence taken ;)
~NuclearMayhem~
John Briggs wrote:
In article [EMAIL PROTECTED], BRAD KRANE [EMAIL PROTECTED] writes:
Now Brad Krane seems to be claiming that the universe evolves in a
deterministic fashion from some starting state so that everything
that happens is, in principle, completely determined by that starting
state. While I disagree with this view, it is both self-consistent
and consisent with the experimental evidence. (It's hard to falsify
non-local hidden-variable theories).
Ever wonder why there are prophits that can tell you whats going to happen
thousands of
years from now with surprising certanty and hay there even right exactly right
about whats going
to happen in lets say 1000 years.
I kindly ask you to explain this.
Sorry. I didn't mean to fling stones at your religion. Calm down
and I promise not to do it again.
John Briggs [EMAIL PROTECTED]
--
From: [EMAIL PROTECTED] (Seisei Yamaguchi)
Crossposted-To:
sci.skeptic,sci.philosophy.meta,sci.psychology.theory,alt.hypnosis,sci.logic
Subject: Re: Randomness based consciousness?. (Was: Re: *** Where Does The Randomness
Come From ?!? *** )
Date: 22 Feb 1999 08:
