Cryptography-Digest Digest #990, Volume #8 Thu, 28 Jan 99 17:13:04 EST
Contents:
Re: My comments on Intel's Processor ID Number ("jay")
Re: Comments on Pentium-III (Brad Templeton)
Re: Spread Spectrum ([EMAIL PROTECTED])
Re: My comments on Intel's Processor ID Number (Barry Margolius, NYC)
Diagram of the Enigma's Uhr Box Enlarged (John Savard)
Re: Who will win in AES contest ?? (Hironobu Suzuki)
Re: RNG Product Feature Poll (Albert P. Belle Isle)
Re: Some more technical info on Pentium III serial number (John Savard)
Re: Random numbers generator and Pentium III (R. Knauer)
Re: Blowfish: Affecting strength of algorithm? (Frank Gifford)
Re: Random numbers from a sound card? ("patix")
----------------------------------------------------------------------------
From: "jay" <[EMAIL PROTECTED]>
Subject: Re: My comments on Intel's Processor ID Number
Date: 28 Jan 1999 13:48:47 GMT
chris <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
>
>
> i can't see why people worry about this stealing their privacy
> while they are perfectly happy giving out phone #s and VISA #s on the
> LL Bean or Amazon websites.
>
You are assuming that the *same* people that are freely giving out their CC
are the people most concerned about ID. This is probably not true.
Additionally, you consciously give a CC out to specific sites that you
choose. At other registration sites, people are only known by their name
and password. The externally accessible nature of the PIII would allow
widespread cross-compilation of user data between unrelated sites, without
user consent. This is serious.
Jay
------------------------------
From: [EMAIL PROTECTED] (Brad Templeton)
Subject: Re: Comments on Pentium-III
Date: 28 Jan 1999 12:09:37 PST
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
>
>
>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.
>
Nah, because you assume they want to police it heavily. Any policing
is more than than have now. A software vendor, particularly one of
internet software that can expect a connection, could just have
a form you fill out to move the software to another system, such as a home
system, laptop, or upgraded system. Sure, people could then get a few
stolen copies. They can do that today -- they can do far more than that
today.
The mere fact that people stealing copies would have to register them
on the company web site would discourage 90% of it, and the rest would
not be enough software piracy for the vendor to worry about. It won't
be easy for one copy of the program to be silently duplicated 1000 times,
which is the source of a lot of the piracy they fear.
Yes, it will be possible to hack programs and remove their serial number
checking code and make piratable versions. And no doubt this will happen.
But vendors will still consider that better than what they have today.
They can make it very easy to change CPUs and still be ahead.
And this means you won't be able to turn off the serial number if you want
to run this software. But that doesn't bother me. The only thing that
bothers me is the crazy idea that the web browser would send the serial
number to web pages -- that we must oppose.
--
Brad Templeton http://www.templetons.com/brad/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Spread Spectrum
Date: Thu, 28 Jan 1999 19:58:57 GMT
On 28 Jan 1999 11:38:21 -0800, [EMAIL PROTECTED] (Gregory G Rose)
wrote:
>In article <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
>>and with Frequency Hopping (such as Qualcom's cellular CDMA)
>
>CDMA stands for *Code* Division Multiple Access,
>and is direct sequence spread (chip rate 1.2288
>MHz).
>
>Greg.
>--
>Greg Rose INTERNET: [EMAIL PROTECTED]
>QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470
>Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/
>Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
Thanks.
I was told that CDMA cellular was frequency hopping which is
supposedly much more secure than DS regardless of chipping.
------------------------------
From: [EMAIL PROTECTED] (Barry Margolius, NYC)
Subject: Re: My comments on Intel's Processor ID Number
Date: Thu, 28 Jan 1999 19:29:46 GMT
Seems like you could write a Pentium III emulator that just passes all
instructions on the the actual chip, except for ID related instructions
which it would fraudulently respond to. A small hit, performance wise, but
worth it to some.
-barry
fungus <[EMAIL PROTECTED]> wrote:
>
>
>Bruce Schneier wrote:
>>
>> I wrote a column on Intel's Processor ID number for ZDNet. You can
>> read it at:
>>
>> http://www.zdnet.com/zdnn/stories/comment/0,5859,2194863,00.html
>>
>
>I'm not sure it will be as easy as you say to subvert the ID...
>
>If the new CPU has an opcode to read the register (eg. into AX,
>BX and CX simultaneously), the you don't need to go via the operating
>system to read the ID. In this case, there won't be a "universal hack"
>for the ID number. Each program which reads the ID will have to be
>patched individually by hackers. It would also be very difficult
>to replace a single opcode with code which updates three registers
>all at the same time (though, of course, Intel may not be as devious
>as me....)
>
>If programs need to be individually patched, then it will take a lot
>of work to completely subvert the ID as suggested in your article.
>
>OTOH, I doubt very much if e-commerce sites will use the ID, given
>that not everybody will have a Pentium III, and a cookie would do
>just as well for their purposes.
>
>I still think that the only realistic use for the ID will be for
>authentication on local networks - exactly what Intel said they were
>targeting. Having a built-in ID will make life a lot easier for
>these people.
--
Barry F Margolius, New York City
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Diagram of the Enigma's Uhr Box Enlarged
Date: Thu, 28 Jan 1999 20:34:09 GMT
My page on the Uhr Box, an accessory to the Enigma, has been slightly
modified.
It shows my tentative reconstruction of what the Uhr Box might have
been like, based on some information about it given by Frode Weierud.
(However, he has commented that while my reconstruction may be close,
it isn't quite perfect.)
I've taken my graphical diagram and enlarged it to show all the wires,
and added a second copy with the knob rotated one place. The original
diagram is also present, but the ASCII graphics version is moved off
the page to an accessory page.
These changes are only present on the Xoom site, and the Uhr Box page
there is:
http://members.xoom.com/quadibloc/ro020402.htm
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (Hironobu Suzuki)
Subject: Re: Who will win in AES contest ??
Date: 29 Jan 1999 04:56:03 +0900
>>>>> "Bruce" == Bruce Schneier <[EMAIL PROTECTED]> writes:
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Bruce Schneier)
writes:
Bruce> Yes. But we tried to combine ultraconservative with
Bruce> performance.
I think it's very difficult to compare between serpent and twofish
because serpent has more rounds than twofish. It means serpent is
stronger than twofish. I guess if serpent's rounds become shrink,
serpent is fast as well as twofish (and serpent is strong as well as
twofish). But I appreciate serpent's philosophy that cipher should be
stronger and should have safety margin than we thought.
When I wrote my Linux cipher file system (*1) with AES (serpent), I
read both C source codes which were submitted AES candidate. Serpent's
bit slice technic is beautiful. That's way, I like it :-)
(*1) GPL style public domain and full source code (serpent included)
available from URL http://www.pp.iij4u.or.jp/~h2np
--hironobu
------------------------------
From: [EMAIL PROTECTED] (Albert P. Belle Isle)
Subject: Re: RNG Product Feature Poll
Date: Thu, 28 Jan 1999 20:42:59 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 28 Jan 1999 14:08:31 -0600, [EMAIL PROTECTED] (Dan S. Camper) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>>Dan S. Camper wrote:
>>
>>> All:
>>>
>>> My company is developing a hardware random number generator...
>
>[snip]
>
>>What happens if the RNG circuitry fails such that the output is all zeros or
>>ones? Some kind of hashing is necessary to "preserve the appearance of
>>randomness" while the problem is being investigated. There also must be a
>>method of detecting failure or drift of the hardware.
>
>That is an excellent point. If the hash function is built into the
>firmware, then the test for invalid data would necessarily have to run
>before the hash function mangles the data. I hadn't fully considered that
>point before.
>
>Is there a decent single test that can be used to detect a myriad of
>problems in an output stream? My hunch says no, that we can really only
>check for certain conditions.
>
At a minimum, you should perform all of the Self-Tests specified in
section 4.11 of FIPS PUB 140-1, including
1. The monobit test;
2. the poker test;
3. the runs test;
4. the long run test;
(all four at least at start-up)
and
5. the continuous random number generator (stuck-at) test
(every time you generate a key or IV).
If you don't have a copy, see
http://www.cerberus-sys.com/~infosec/stds/fip140-1.htm#sec4.11
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE
with Forensic Software Countermeasures
http://www.cerberus-sys.com/~infosec/
================================================
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: talk.politics.crypto,comp.sys.intel
Subject: Re: Some more technical info on Pentium III serial number
Date: Thu, 28 Jan 1999 20:54:56 GMT
[EMAIL PROTECTED] (Paul Rubin) wrote, in part:
>EE Times had an article giving a little bit more info on how
>the PIII unique id's work. Not a full description, but more
>than I've seen here on the newsgroup. I'm repeating the URL
>from someone else's Usenet article (sorry, I don't remember whose):
> http://www.eet.com/story/OEG19990127S0011
>I might post a comment or two later.
1) You may find that your browser will not load this page without an
inordinately long delay.
You can read the text of the article, though, via the following
technique:
wait for a minute or so, for the text of the page to load,
hit the "stop" button on your browser,
then select "View Source" from the menu.
(Disabling auto-loading of graphics will probably work too.)
Each paragraph of the article is a single long line of text, so
cutting and pasting into a word processor or something similar is also
required.
2) It is nice that Intel has devised a scheme whereby a web server,
desiring to see people's Pentium III ID numbers, will get an ID signed
by Intel which will then be used to request only a keyed hash of the
ID number from your chip.
Will people be able to see the ID numbers of their own chips, to
ensure they aren't buying stolen property?
What guarantee is there that browser makers will abide by this scheme,
and not also give out unfiltered Pentium III IDs - or, for that
matter, any other information, such as the ID numbers of plug-and-play
PCI cards, someone having claimed they have serial numbers (yes, there
are ID numbers that identify the make and model, but I fail to see the
relevance of a _serial_ number to plug-and-play...)?
3) If the instruction to return ID number is publicly known, then a
browser maker can choose, or not choose, to use the Intel scheme for
providing only a hash of the ID number.
At first, this makes the relevance of "tamper-resistant software" seem
limited. If there is a hash scheme involved, then the original ID
number is not recoverable, from any correct implementation of the hash
scheme. Normally, web sites can't rewrite the browser on my computer.
But then I see what is going on.
The software is tamper resistant to prevent ID number spoofing.
The ID number on the chip is just a serial number, with no signature
by Intel, just as Bruce said.
But a web site _can_ get a guarantee that the ID number is not spoofed
- _if_ they accept getting only a personal hash of the ID number, to
protect user privacy.
Because the software is protected against tampering _by the user_. So
it will only take your real Pentium III ID number, hash it with the
Intel-signed web site identifier of the web site you're visiting, and
give them a personal identifier that can't be tracked but can't be
forged.
4) Incidentally, if "tamper-resistant" software ever had a
tamper-resistance of sufficient strength to be comparable to
cryptosecurity, one would have the ability to do almost anything in
the public-key field without using public-key algorithms.
It helps, of course, if you're the chipmaker.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random numbers generator and Pentium III
Date: Thu, 28 Jan 1999 21:00:40 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 28 Jan 1999 15:40:42 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Do you have ANY scientifically precise (quatifiable through exactly
>defined and practically executable measurement methodologies)
>'characterization' of crytp-grade randomness??
Yes.
>Do you have similarly
>'precise' definitions of 'crpyto-grade' and 'randomness'?.
Yes.
>You never
>get to 100% objectivity concerning random number sequences, be
>they obtained hardware or software!
Wrong.
>Statistical tests, being founded
>on mathematical theory, instead of 'intuitions' (such as estimate of
>the 'skill' of the person designing an apparatus as you suggested
>in another thread)
I never suggested any such thing. Do not put words in my mouth,
please.
>provides at least something useful to guide
>one's (by necessity) more or less subjective evaluation, instead
>of depending wholy on assertions not scientifically proved but only
>'believed' by someone. (We want to do science, not religion!)
Whatever.
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: Blowfish: Affecting strength of algorithm?
Date: 28 Jan 1999 16:25:10 -0500
In article <[EMAIL PROTECTED]>,
Uta Loeckx <[EMAIL PROTECTED]> wrote:
>1. Goal description:
>==============
>I have to secure some data of the Geological Survey of Hessen, Germany.
>They have a database with some confidential data which one finds in
>several table columns. Every column is encrypted with a different key,
>but a table can contain several thousand entries. DBAs which are not
>supposed to get the confidential information can read all ciphertext,
>though (no way around it in ORACLE8). Is this a serious potential for
>ciphertext attacks?
A drawback to this kind of encryption is that it may provide an attacker
with lots of ciphertext to decrypt. The software which does the decryption
needs to be well secured so that the column keys are not compromised by
someone copying the software for home use.
Also, with database encryption like this where the server doesn't do the
encryption, you cannot search the database with standard SQL, nor can you
have indexes on those columns. May not be a big deal for your application,
but for some it would be.
>1. I decided for Blowfish. Input data is aligned to the next 8 byte
>border using 00H (I am not sure if this is correct, Markus Hahn's
>implementation uses 20H=whitespaces, but I couldn't find anything about
>padding in Blowfish paper). One more 8-byte-block is appended containing
>the original data length in bytes as a 64bit-integer.
Possibly better (less storage) is to append a '1' bit to the end of the
data and then append as many '0' bits to fill out a block. This way, the
data is a block multiple and you can quickly determine the final length of
the original data when decrypting. If data size is not a problem, you could
go further and append even more '0' bits so that the length of the data
cannot be known for a certainty.
>2. The table columns may contain repetitive data like names or dates or
>wages. Since ECB would produce the same ciphertext for same plaintexts,
>I decided to use CipherBlockChaining. Now I'm not sure if the way the
>initialization vector is produced has influence on Blowfish strength. I
>do it the following way in Java:
>A Random object is created using the computer clock. Then every time
>data is encrypted, the Random object produces a 64bit value which should
>be equally distributed (see Java1.2APIdocumentation).
>This value gets XORed with the 18 PBoxes of Blowfish's expanded key,
>always putting two of these boxes together to produce 64bits. I actually
>thought, that this might improve security because no one knows the PBox
>values if he/she doesn't know the key, but one might guess the system
>time. This is my main question: is this random enough for encryption???
Well, you have to store that Random object into the row - otherwise you can
never get the data back. So instead of modifying Blowfish, use that random
object as the IV for CBC mode. Using the time is not necessarily bad,
although it may leak information in the sense that I may know that row X
was inserted before row Y but before row Z... You could use a counter
for the IV. But there would have to be an IV for each row in your table.
>Any hints on better ways of implementing this thing are appreciated
>Andreas
The security lies in the software instead of the server. So if you can
secure all of the potential client programs, you may be OK. But database
performance will suffer if you ever want to find common data in different
tables - since you would have to load the entire table(s) from the server,
decrypt and write your own comparison routines. If you are willing to
sacrifice performance and some usability, the approach above may work.
Another thought is that if a key gets compromised, you may need some way
to reencrypt the data with a new key. It all depends on the threat model
you have.
-Giff
--
[EMAIL PROTECTED] Too busy for a .sig
------------------------------
From: "patix" <[EMAIL PROTECTED]>
Subject: Re: Random numbers from a sound card?
Date: Thu, 28 Jan 1999 21:36:44 GMT
[EMAIL PROTECTED] wrote in message
<78q96o$ka6$[EMAIL PROTECTED]>...
>In article <[EMAIL PROTECTED]>,
>
>There is a big difference. Eve does not know the local, instantaneious
>electromagnetic conditions around my receiver, nor does she know what
>my local electronics are doing.
>
>The point is that measuring something physical is nothing like
>playing with text streams, unless you you get them via UDP and
>have a real bad link :-)
OK , but if she assume that it is 50Hz (Europe power) and
let 30 KHz from Your monitor display , and if it happen to be true ?
I have question:Haw should we test hardawre random
generator to "be shoure" that it is realy some haw random ?
patix
------------------------------
** 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
******************************
