Cryptography-Digest Digest #988, Volume #8 Thu, 28 Jan 99 13:13:03 EST
Contents:
Re: My comments on Intel's Processor ID Number (Patrick Juola)
Re: Encoding for telephone over Internet (Patrick Juola)
Re: hardRandNumbGen (Patrick Juola)
OOA und OOD (Thomas Mehring)
Re: Comments on Pentium-III (John Savard)
Duke University cracks 40/56 bit in hours ([EMAIL PROTECTED])
Re: Some more technical info on Pentium III serial number ("Michael A. Greenly")
Re: Comments on Pentium-III (fungus)
Re: Pentium III... (fungus)
Re: RC4 question (fungus)
RNG Product Feature Poll (Dan S. Camper)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: My comments on Intel's Processor ID Number
Date: 28 Jan 1999 10:59:43 -0500
In article <78o28s$oat$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> My social securtiy fits more in line with the way the government
>really does things. THEY FUCKING LIE.
>on the bottom of my card it says
>"FOR SOCIAL SECURITY AND TAX PURPOSES-NOT FOR IDENTIFICATION"
>I like to point this out and show the card when I get asked
>in person to use my ID I argue in vain that it is illegal to
>use it for identification....
Um.
Actually, no. It's completely legal to use the NUMBER for identification
purposes. What is not allowed is to use the CARD ITSELF for identification
purposes.
I.e., you can't flash a social security card at the bank teller when
they ask for identification to make sure that you really are the person
to whom the check is written. (Well, all right, you *can*, just as you
could flash a book of matches -- but the tellers would be justified
in not accepting them.)
In cryptographic terms, the social security card isn't a particularly
secure document the way a drivers' licence is. You wouldn't believe
me if I had a note from my mommy claiming that I was Ronald Reagan --
why should you believe me if I had a social security card claiming
that I was?
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Encoding for telephone over Internet
Date: 28 Jan 1999 11:02:42 -0500
In article <ekMr2.181$[EMAIL PROTECTED]>,
Scott A. Berg <[EMAIL PROTECTED]> wrote:
>
>There are many packages for telephone, videophone, FAX, drawing board, etc.
>over the internet. Since all of them resolve at some point to a stream of
>numbers, they would seem to lend themselves well to REALLY secure
>encryption, e.g. OTP.
No, they wouldn't. The amount of pad data you would need to use an
OTP over a telephone would be prohibitive -- and you'd need to exchange
pad data with anyone and everyone you might talk to on the phone.
>Do any commercially available packages for this kind of communication
>actually provide such security?
OTP level? No? "Pretty good"? Yup. PGPfone is out and available
and uses pretty hefty encryption. The advantage of telephone, &c.
is that as the communication is real-time, you usually don't need
as much security -- the communications don't need to stay secret
as long.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: hardRandNumbGen
Date: 28 Jan 1999 11:23:20 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Wed, 27 Jan 1999 16:00:55 -0500, "Trevor Jackson, III"
><[EMAIL PROTECTED]> wrote:
>>For instance, a page of
>>business text is around 2^16 bits (of data, not information). If we divide up
>>the (?)RNG output into samples of this size we can establish a confidence that
>>the samples are statistically random.
>
>Define "statistically random" in terms of finite length numbers.
>
>>If the samples are not statistically
>>random, we can, with statistical confidence, eliminate that RNG as appropriate
>>for key generation.
>
>Define "not statistically random" in terms of finite length numbers.
In terms of finite length numbers, a finite number is not statistically
random if I can predict it (or something about it).
The key word there is "predict." Post hoc analyses don't mean much.
A priori analyses, however, are a good way of showing that, in practice,
a prediction can be made -- by the simple technique of making and
validating a prediction.
Example.
1) You hand me a black box
2) I tell you 'if this thing doesn't put out "about the same" number
of ones and zeros, it's hosed and you're fired.'
3) I run the black box for 100,000 bits and it gives 95% ones.
4) I kick your sorry unemployed ass out of the building.
This is valid. *Technically speaking*, there is approximately one
chance in a godzillion that you are not incompetent, but just unlucky.
In practical terms, this wouldn't happen. I'm throwing out one working
RNG every jillion centuries and firing a lot of charletans.
Statistics are like that -- you can never state something "for sure,"
but you can usually make statements like "a truly random system would
only do that 5% of the time, and so I don't think it's random."
The key point above is the ordering of steps 2 and 3. If I reversed
them -- running the generator and *THEN* deciding what counted as
a test of randomness -- then I'd be dealing with a stacked deck.
There's always some test that *can* be run on *any* finite (or
even infinite) sequence that will cause it to appear non-random.
The trick is whether I can *pre*dict that test before examining the
output, or whether I can only hunt for it after the fact.
And, of course, anything that I test for *might* be the result of
a non-random process that "just happened" to give a good result
for the test. I can never prove that a process is "random," but
I can give measures (confidence intervals), stating that the
amount of a particular sort of non-randomness is likely (with
some probability) to be less than some threshhold.
But I can't prove perfection -- I can never get the threshholds
down to zero, which is why I can't prove "randomness", only the
apparent absence of LOTS of randomness.
-kitten
------------------------------
From: Thomas Mehring <[EMAIL PROTECTED]>
Subject: OOA und OOD
Date: Thu, 28 Jan 1999 17:38:49 +0100
Hallo Tom,
Du solltest Dich vielleicht mal mit Objektorientierter Analyse bzw.
Design besch�ftigen...
bye
Tom
--
______________________________________________________________________
Thomas Mehring Robert Bosch
Multimedia Systeme GmbH&Co. KG
MU/EMS3
P.O. Box 77 77 77
D-31132 Hildesheim (GERMANY)
Phone :+49-5121/49-4521 Fax: +49-5121/49-4230
mailto:[EMAIL PROTECTED]
______________________________________________________________________
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Comments on Pentium-III
Date: Thu, 28 Jan 1999 16:28:41 GMT
"Scott A. Berg" <[EMAIL PROTECTED]> wrote, in part:
>Third, Intel has promised to not keep a database matching serial numbers to
>individuals. If true, it sort of weakens their argument about theft
>protection. After all, how could they start the chain of custody of a
>processor if they don't know which PC vendor they sold it to?
No, no. Intel will keep a database of its trucks shipping processors
to vendors, and the serial numbers of the chips carried - it's only a
database of end-users and serial numbers that won't be kept.
So if a truck is hijacked, Intel will know the serial number of every
Pentium III on board - and if you buy a computer with a hot chip, call
Intel - they'll give you a replacement...and bust the retailer.
Hence, no retailer will try buying hot chips. End of problem.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Duke University cracks 40/56 bit in hours
Date: Thu, 28 Jan 1999 16:39:47 GMT
So Much for
Secure
Shopping
Commentary
Give the multiprocessor
PixelFlow a standard
encryption combination and it
will crack it in less than four
hours. (Michael Dougan/Special
to ABCNEWS.com)
Special to ABCNEWS.com
One of the world�s great
virtual reality labs resides at
the University of North
Carolina in Chapel Hill.
There researchers built a computer,
called PixelFlow, that can render
massive amounts of graphics data to
create realistic three-dimensional
virtual environments.
PixelFlow is a �massively parallel�
computer, equipped with multiple
microprocessors (as opposed to the likely
one-microprocessor machine you are using
to read this column) that can be used to
attack a single problem. It employs what
engineers call �brute force� computing,
replacing elegantly written software with a
tremendous amount of computing power.
The VR business being a little slow
these days, Duke University professor
Gershon Kedem and grad student Yuriko
Ishihara decided to redirect PixelFlow�s
graphics-rendering computing power to
cryptanalysis � the study of codes. (Duke
and UNC are linked in North Carolina�s
famed �Research Triangle.�)
Why not take PixelFlow�s 147,456 8-bit
processors, they wondered, and have them
crack computer passwords?
40-Bit Security Blankets
Much of our browser-mediated activity
over the Internet � including transactions in
which we send our credit-card numbers to
someone � is protected by 40-bit
passwords.
Since there are 1,099,511,627,776
different possible combinations of
40-bit-long strings of 0s and 1s, such codes
are considered essentially uncrackable.
It should be noted that, while much of the
world is migrating to 56-bit keys, the U.S.
government until recently prohibited the
export of such �strong� encryption.
Netscape Navigator and Microsoft
Explorer, and the majority of the Internet�s
commercial sites, continue to feel safe in
relying on the 40-bit standard in protecting
commercial Internet transactions.
With their reconfigured PixelFlow �
renamed CipherFlow for cryptanalysis
purposes � Kedem and Ishihara were able
to check 614,000,000 40-bit combinations
per second. At that speed, they could crack
industry-standard password strings at an
average of 3.75 hours per password.
Not bad for a machine built on early
1990s technology and designed for an
entirely different task.
A Stern Warning
Kedem estimates that a dedicated
decrypting machine could be built for $6
million, then manufactured at $60,000 or
less per machine, and perform far faster.
The point of this exercise, of course, is
to improve the art of encryption and to offer
a stern warning to those promoting the
safety of the Internet. Kedem believes �
and has amply demonstrated � that
assurances of Net security are unwarranted.
But anything fewer than 80 bits, the two
believe, is dangerously vulnerable.
In a Duke University press release,
Kedem notes that �PixelFlow was built with
early 1990s technology � If that machine
were reimplemented in today�s technology,
we could probably crack a 56-bit key in
less than 10 hours.�
Along those lines, the comments of a
reader who passed along the Duke release
seem appropriate: �password and
encrypting don�t mean squat � everything
is compromisible.�
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Michael A. Greenly" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,comp.sys.intel
Subject: Re: Some more technical info on Pentium III serial number
Date: Thu, 28 Jan 1999 10:46:55 -0600
It seems that the simplest answer would be buy an Alpha, or a Mac if
you're really desperate ;)
--
Mike Greenly
[EMAIL PROTECTED]
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Comments on Pentium-III
Date: Thu, 28 Jan 1999 17:46:39 +0100
Bob Manson wrote:
>
> This type of copy protection will create certain problems for
> legitimate users. The obvious one is that if a user has to replace a
> CPU because it fails
...licensee must give 7 (seven) days notice of CPU failure for
transfer clause to be valid.
> It's true that a similar scheme is used on some Unix workstations.
Yes...but this software is usually very low volume and high priced.
Transferring licenses doesn't cause a lot of administrative overhead.
For a mass market product this overhead would become significant.
> In fact, I claim that the Pentium RNG will become more of a hindrance
> than a help, because its pretty likely that it has one or more flaws
> that will cause its output to be predictable in some cases.
I'd give Intel a bit more credit than this. As people have pointed
out, designing a hardware random number generator isn't all that
difficult, and Intel has some of the best brains in the world.
> If it really becomes the sole
> RNG of choice, that means that the majority of applications that rely
> on random numbers as part of their crypto system will eventually be
> compromised.
If the chip uses some sort of noisy diode, then each chip might
even have its own individual biases. This could even vary depending
on whether or not you had the air conditioning switched on that
day, solar flares, the phase of the moon, etc.
You might compromise one chip's output (unlikely), but breaking the
world's communications net will be harder.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Pentium III...
Date: Thu, 28 Jan 1999 17:31:35 +0100
Daniel James wrote:
>
> This will be useful, for example, when the
> police find a A.Felon Esq. in posession of a shedful of used CPUs; it
> will be possible to verify that they were stolen and from whom.
>
...except that the numbers will follow no pattern, and Intel
won't be keeping records of which chips have which numbers
(or so they say).
A distributor could, in theory, take every single chip out of the
box and record all the serial numbers before he puts them in a truck
for transportation. I personally don't think this is very likely....
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: RC4 question
Date: Thu, 28 Jan 1999 17:24:06 +0100
Hai Huang wrote:
>
> I am a newbie in encryption. I downloaded a source code for rc4 encryption,
> and compiled it under Borland c++5.0.
>
> I run the program by type in "rc4 4432411432 <sample.txt >sample1.txt", and
> the program give me a new file called sample1.txt which contains the
> encrypted information. But how do i decrypt sample1.txt back? I tried to
> type in "rc4 4432411432 <sample1.txt >sample2.txt", and sample2.txt contains
> only a fraction of the original data in sample.txt. I don't know what is
> wrong with it. Can anyone tell me what i did wrong? Thanks in advance.
>
stdin and stdout are "text" files by default. This means that feeding
them a binary file (your encrypted data) will cause strange effects.
eg. A value of 26 in the fill will be interpreted as an "end of file".
Also, any character 10 followed by a 13 will be combined to just a 10.
You *might* be able to convert these files to binary mode, but it's
non-standard. Have a look through the docs of your compiler....
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Dan S. Camper)
Subject: RNG Product Feature Poll
Date: Thu, 28 Jan 1999 11:09:22 -0600
All:
My company is developing a hardware random number generator, based on
radioactive decay, which will be a component of a larger turnkey (server)
product. The device is an external peripheral with a serial connection to
the CPU and back-end serial connections that allow you daisy-chain these
RNG devices to provide higher throughput.
The device currently works. It's output is a measly 3K per second, but
the raw data passes Diehard and every other test we've thrown at it. Of
course, that doesn't prove that the output is random, but at least we know
it passes those tests. ;)
We are considering the addition of a hash algorithm to the setup. There
have been messages posted to this newsgroup in the past regarding hashing
hardware RNG outputs, but I haven't been able to discern a consensus on
whether or not an additional hash is a Good Thing.
Basically, we're considering the following options:
1) Don't add a hash. (This is the easy one!)
2) Add a hash routine to the firmware within the RNG.
a) It's always enabled.
b) Enabled with a push button on the device.
3) Add a hash routine in the software on the server.
a) It's always enabled.
b) Optionally enabled via admin interface.
Addendum: If we include a hash in the firmware, which hash algorithm will
be used? If we implement a hash in software, we can offer multiple
algorithms for the administrator to choose from. We are considering both
MD5 and SHA-1. We have also talked about a plug-in type architecture, and
publishing the API for it, so savvy administrators and design their own
hash algorithms.
The purpose of this post is to solicit opinions and commentary and,
hopefully, allow me to gain some kind of consensus regarding the various
options. Of course, we could be barking up the wrong tree, too. It would
even be helpful to realize _that_.
Thanks for your time.
DSC
____________________________________________________________________
Dan S. Camper [EMAIL PROTECTED]
Borrowed Time, Inc.
------------------------------
** 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
******************************
