Cryptography-Digest Digest #985, Volume #8 Thu, 28 Jan 99 02:13:03 EST
Contents:
Re: Where to start? (AbsolutAF3)
Re: What is left to invent? (Toby Kelsey)
Re: My comments on Intel's Processor ID Number (fungus)
Re: Comments on Pentium-III (Paul Rubin)
Re: Pentium III... (fungus)
Re: Comments on Pentium-III ("Ron McKinnon")
Some more technical info on Pentium III serial number (Paul Rubin)
Re: Some more technical info on Pentium III serial number (John Nagle)
Re: Where to start? (Paul Rubin)
Re: My comments on Intel's Processor ID Number ("Roger Schlafly")
Re: Sanity check on authentication protocol (Antti Huima)
Re: Comments on Pentium-III (Lloyd Miller)
New search utility for this group (BH)
Re: Unicity, DES Unicity and Open-Keys (wtshaw)
Re: Foiling 56-bit export limitations: example with 70-bit DES (wtshaw)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (AbsolutAF3)
Subject: Re: Where to start?
Date: 28 Jan 1999 01:25:45 GMT
>The executable I have allows passwords between 1 and 20
>characters and always seems to generate a cyphertext exactly
>10 characters long.
>
Perahps you know the Author's name or the name of the program? Have you looked
at a dissasembly of it?
------------------------------
From: Toby Kelsey <[EMAIL PROTECTED]>
Subject: Re: What is left to invent?
Date: Mon, 25 Jan 1999 01:52:40 +0000
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes
>Since any cipher can be broken by trying to decode the message with all
>possible keys,
Only if you can identify the plaintext when you see it.
Toby
--
Toby Kelsey
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: My comments on Intel's Processor ID Number
Date: Thu, 28 Jan 1999 03:32:31 +0100
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.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Comments on Pentium-III
Date: Thu, 28 Jan 1999 03:02:49 GMT
In article <x6Kr2.170$[EMAIL PROTECTED]>,
Scott A. Berg <[EMAIL PROTECTED]> wrote:
>First, the processor serial number and the random number generator are two
>separate and independent features. I have read several garbled press
>reports about how the serial number itself is a random number. Of what use
>would randomness be here?
>From some other news post, the serial number is a 96-bit number that
is generated randomly when it is programmed into the chip. The consequence
is that the chips aren't consecutively numbered or anything like that.
If someone buys 100 chips and you get the serial numbers of some of
them, you won't be able to guess the serial numbers of the others even
if you know the chips all came from the same batch.
>Second, embedding a serial number in the processor has some advantages over
>a dongle, but it depends on the application. The dongle offers portability
>to many machines while the embedded number does not. If you want to
>restrict access to truly sensitive information, allow it only from a machine
>chained down to a desk in an office with a guard at the door. With a dongle
>you could: 1) steal the dongle, 2) leave behind cache files filled with
>sensitive information, 3) call from an unsecured phone line, etc., all of
>which compromise security. I don't see one as a replacement for the other
>but rather complementary solutions depending on what you are guarding
>against.
You could pop the cpu out of the socket of most desktop computers...
In fact, I wonder if a 3rd party motherboard chipset (the vendors of
those chipsets are not exactly Intel's friends) could somehow trap the
CPUID instruction and return a user-supplied serial number instead of
the programmed-in one.
>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?
They could keep a database matching serial numbers to PC vendors. PC
vendors are not individuals.
>Finally, another capability of the P-III is a user accessible EEPROM. That
>could be used to burn in identifying information, including machine serial
>numbers to tie a software package to a specific machine.
This is interesting, the first time I've heard it. The eeprom is on
the cpu chip itself, and not in the motherboard chipset? I've heard
elsewhere that the RNG is in the chipset.
Almost all motherboards these days use eeprom to store the bios, and
presumably have a little bit of leftover space. I've thought for a
while that it would be nice if there were bios and chipset support for
storing a little bit of user info in the eeprom.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Pentium III...
Date: Thu, 28 Jan 1999 01:54:58 +0100
handWave wrote:
>
> In 1986 I drew the
> "single poly EPROM cell" on the CAD system, had it processed on a test
> wafer, tested it, and it worked. I told the marketing department about
> it. I wrote it up in my patent notebook. I told them to use it as a
> serial number for the 80386, for key storage and for fabrication lot
> tracking for process analysis.
>
...so you're personally to blame for all this!
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: "Ron McKinnon" <[EMAIL PROTECTED]>
Subject: Re: Comments on Pentium-III
Date: Wed, 27 Jan 1999 18:14:50 -0800
Scott A. Berg wrote in message ...
>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? Besides,
>someone down the line (Dell, Compaq, etc.) could keep their own database
>and, in fact, are more likely to know the identity of the person using that
>machine.
Given that at the current time a stolen CPU cannot be later positively
identified, some form of serial number would seem warranted.
But this could be done by printing or engraving it on the case, perhaps with
a bar-code as well, with then no need whatever to have it programatically
accessible. This approach is of course common practice with many other
products, and would raise no privacy issues.
Since one cannot guarantee that an electronic serial number would be
correctly reported over the net, and since it was proposed to be user
disable-able in any case, Intel et al can't count on this avenue for
detecting stolen chips.
A non-hardware serial number would address the stolen chip issue better,
as serial numbers of alleged stolen CPU's could then be compared visually
or with a bar-code reader without having to plug in the chip anywhere, and
with serial-number tampering more obvious.
------------------------------
Crossposted-To: talk.politics.crypto,comp.sys.intel
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Some more technical info on Pentium III serial number
Date: Thu, 28 Jan 1999 03:49:23 GMT
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.
------------------------------
Crossposted-To: talk.politics.crypto,comp.sys.intel
From: [EMAIL PROTECTED] (John Nagle)
Subject: Re: Some more technical info on Pentium III serial number
Date: Thu, 28 Jan 1999 04:05:58 GMT
[EMAIL PROTECTED] (Paul Rubin) writes:
>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.
Unclear how much of that challenge/response mechanism is
in software.
Incidentally, is everyone aware that all ISA PNP cards have a
serial number? It's essential to the way ISA PNP cards are recognized.
John Nagle
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Where to start?
Date: Thu, 28 Jan 1999 03:08:02 GMT
In article <Q%Nr2.963$[EMAIL PROTECTED]>,
Jerry Jeremiah <[EMAIL PROTECTED]> wrote:
>I need to know the encryption algorithm to do this. Given that I
>can get the program to show me the cyphertext of any particular
>string, how long would it take me to figure out the algorithm?
In cryptography that is called a chosen plaintext attack. If the
algorithm is any good at all (i.e. it's using real cryptography and
not just doing something silly), it will resist that type of attack
and you (or anyone else) will never figure it out unless you use other
means than treating the executable as a black box and just comparing
its inputs and outputs.
If you think the program is doing something cryptographically
nontrivial, your best bet is to analyze (disassemble) the executable.
That basically means cutting the box open and see what it's doing
inside.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: My comments on Intel's Processor ID Number
Date: Tue, 26 Jan 1999 21:37:52 -0800
Bruce Schneier wrote in message <[EMAIL PROTECTED]>...
>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
Your analogy is to a national ID number which is on a card that no
one examines. Hence it is useless for identification, you argue.
But that is almost precisely what we have. I have a Social Security
number, but I have never shown my card to anyone because I lost
it long ago. And yet my SSN is still used for identification.
------------------------------
From: Antti Huima <[EMAIL PROTECTED]>
Subject: Re: Sanity check on authentication protocol
Date: 27 Jan 1999 07:42:38 +0200
[EMAIL PROTECTED] writes:
> > > This protocol can be summarized as follows:
> > >
> > > A --> B: A, R_A
> > > B --> A: {K, R_A, R_B}_S
> > > A --> B: {R_B}_S
> >
> > If you want to do better you could send in the second message HASH(S |
> > R_A) or something similar instead of R_A. Namely, you do not need to
> > send R_A, it is enough that Alice is able to verify that Bob knows it.
> > If you do it in some reasonable way like this, the known-plaintext
> > problem diminishes.
>
> But this does not protect against an attack on S. An attacker guessing S
> can easily compute HASH(S | R_A) and so check his guess. The same seems
> to be true for any other variation I can think of. It seems that what is
> required is something that cannot be computed even after all plaintexts
> are laid bare after being decrypted by S. This is why DH-EKE uses
> Diffie-Hellman.
I recognize the first point as somewhat valid and had it already in
mind when I posted my previous message. The validity depends on
whether or not the *whole* S is used as the encryption key or only
some part of it. For example, if the master secret S is 512 bits, one
hash of it could be used as the encryption key and another one inside
HASH(S | R_A).
It is completely true that if S is e.g. 56 bits and the decryption is
DES, the hashing scheme adds not very much.
> > The other problem with this protocol is that you need to change the
> > shared secret often. Because the shared secret is used to encrypt
> > messages with some redundancy (e.g. the known R_A in the original
> > version), it is possible that the key used in the second and third
> > messages gets eventually cracked. At this point the cracker can
> > masquerade as the server as long as he wishes. To lessen this risk,
> > change the effective shared secret periodically. Here is one
> > suggestion to give an idea:
> >
> > Let S_1 be a shared secret.
> >
> > Add a nonce R_C that is sent in plain by B in the second message:
> >
> > B --> A: {K, R_A, R_B}_S, R_C
> >
> > User S = HASH(S_1|R_A|R_C) as the encryption key.
> >
> > In this way, the encryption key will be every time different. Still,
> > only Bob and Alice can know it because it is derived from the "master"
> > shared secret S_1.
>
> I think you should be careful here. It's possible for an active adversary
> to replace R_C by something else and so screw-up the update process, giving
> A and B different ideas about what the shared secret is, and maybe making
> it impossible for them to resynchronize - a dastardly DoS attack!. To
> incorporate this idea I think the protocol needs to be made more explicit
> in terms of verifying and accepting (by both A and B) the updated secret.
As I mentioned earlier, the protocol needs anyway to use strong MACs.
Perhaps they can cover R_C true. However, the DoS attack point is not
very interesting because you can as well just scramble the encrypted
data.
--
Antti ([EMAIL PROTECTED])
* The blood of Christ cleanses from all sin. *
------------------------------
From: [EMAIL PROTECTED] (Lloyd Miller)
Subject: Re: Comments on Pentium-III
Date: Thu, 28 Jan 1999 05:33:17 GMT
Ron McKinnon ([EMAIL PROTECTED]) wrote:
: Since one cannot guarantee that an electronic serial number would be
: correctly reported over the net, and since it was proposed to be user
: disable-able in any case, Intel et al can't count on this avenue for
: detecting stolen chips.
Think more in terms of "pop in a boot floppy and press reset" to check
if a CPU is part of a stolen batch, rather than an internet
query-response. It would allow quick spot checks without the need to
take off the cover and look under the fan and heat sink for engraved
serial numbers.
--
Lloyd Miller, Calgary
[EMAIL PROTECTED]
Terminal Insomniac
------------------------------
From: BH <[EMAIL PROTECTED]>
Subject: New search utility for this group
Date: Wed, 27 Jan 1999 11:45:47 -0500
New search utility for this group
at:
http://patriot.net/~bhakiz/
Please check it out.
B. H.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Unicity, DES Unicity and Open-Keys
Date: Wed, 27 Jan 1999 23:33:48 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> >
>
> > I've stumbling more onto, lets us say, novel means of simple, basic
> > compression, more information in fewer characters. The idea is to vary
> > such methods and incorporate them more closely with the encryption
> > itself....these best described as "bucket" ciphers, somewhere between
> > block and stream ciphers, are still in the scratch paper phase, and will
> > be explained in detail once they start being born...implemented.
>
> I am looking forward to your design. A couple of tiny comments:
> (1) one couldn't get better compression than along the lines of
> Huffman (variants possible) unless one resorts to code books
> (including 'public' code books, if such can be realized) (2) combining
> stream and block encoding appears to be useful (see my WEAK3).
I'm looking forward to them too, but don't hold your breath. First, I
need to rip through the current series of ciphers, 30-40, maybe....two
more done, since I last mentioned them. Considering the usefulness of the
unicity concept, other than qualitative, I wonder what it would be for any
or all of these weird ones I'm doing, when it is obvious that some are
stronger or weaker than others.
>
> > >
> > > More generally: It is commonly assumed that the analyst knows the
> > > encryption scheme one uses. But this is reasonable if one repeatedly
> > > uses the same scheme. If one has a fairly large set of schemes to be
> > > chosen according to a secret schedule, then the analyst has first of
> > > all to figure out the scheme actually being used, i.e. he has a much
> > > higher work load. I believe all this could be subsumed under the
> > > paradigm 'Security through variability', which underlies, in
> > > particular, those algorithms that are parameter-dependent (analogous
> > > to parametrized data types in programming languages; the parameters
> > > can be regarded as kind of 'key extensions' which is of interest
> > > in the context of the Wassenaar regulation).
> >
> > What is needed is a multitude of algorithms, with view as to what output
> > is produced. Recently, I began posting some rather simple, probably dumb,
> > ciphers, whose goal is more than anything to add more straw to the pile.
>
> With parametrized ciphers, choosing different parameters gives you
> different ciphers, even though these work on the same basic
> principles.
>
Yes, this is true. And, there is nothing like building them to see that
you need to futher define, eliminate, or add various parameters. Like I
said sometimes, a cipher is only born when it works. Trying to make
something generic is a good ideal, but it seems that something custom
always pops up where you think it shouldn't.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Wed, 27 Jan 1999 23:18:15 -0600
In article <78mv0l$oih$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (wtshaw) wrote:
>
> > For instance, why not parse a body of plaintext into several parts, short
> > block transposition style, using several different DES alternately to
> > encrypt the reassembled input data. You could do it in such a manner that
> > would reduce the amount of original running plaintext snippits to less
> > than required for solution of a single DES key, and the sequence and
> > number of DES keys could be secret, as well as the keys themselves.
>
> Will not work. DES unicity is **only** two letters of text. Please see the
> paper quoted -- Sections 6 and 7 -- http://www.mcg.org.br/unicity.htm
Then parse things down to single letters. This extra algorithm would be a
chained algorithm in effect.
>
> It is a mistake in the literature to consider DES unicity to be 20 bytes (3
> blocks of DES) for compressed English. The formula is simply not valid in that
> range as proved in the paper.
>
You need not be hamstrung with simple ASCII as the source for your bits,
as you could generate them from something else than base 128, which is
about the poorest one to encrypt text directly from that there is.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
** 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
******************************
