Cryptography-Digest Digest #43, Volume #11 Thu, 3 Feb 00 06:13:01 EST
Contents:
Re: How to password protect files on distribution CD (Vernon Schryver)
Re: Court cases on DVD hacking is a problem for all of us (Highdesertman)
Re: Court cases on DVD hacking is a problem for all of us (Highdesertman)
Re: How to choose public-key e on RSA? ("Peter L. Montgomery")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Crossposted-To: alt.security.pgp,comp.security.unix
Subject: Re: How to password protect files on distribution CD
Date: 2 Feb 2000 11:54:56 -0700
(I'm combining two somewhat long replies to make it easier for non-participants
to ignore both of them.)
In article <[EMAIL PROTECTED]>,
Alan J Rosenthal <[EMAIL PROTECTED]> wrote:
> ...
>>If you want that something close to that mode, then use the MAC address
>>of an Ethernet board, and treat the Ethernet board like an old fashioned
>>dongle.
>
>I did mention MAC addresses later in my article, but if you're contemplating
>the replacement of the entire computer, well, the ethernet hardware is part of
>the computer. Not necessarily on a separate card at all, and besides you
>might want to replace your ethernet card while replacing the rest of your
>computer, or the ethernet card might break and you might replace it, ...
Use a $25 10BASE-T ISA card not even connected to a network.
>Also, as I understand it, the ethernet standard specifies that the
>MAC address is part of the computer, not specifically the ethernet hardware
>and ideally not; and in fact most non-personal-computers have their MAC
>address somewhere else on the motherboard; it doesn't change when you
>exchange ethernet cards; it DOES change when you change motherboards and
>use the old ethernet card.
In fact, most large non-PC's have some of their MAC addresses in separate
boards. The notion of a "motherboard" is limited to small systems and
now to systems the speed or price of PC. Big systems tend to have more
than one board containing CPUs.
You have the IEEE rule backwards. A MAC address is not allowed to be used
as the serial number of a computer, although more than one outfit does
exactly that, at least with the least significant bits of a MAC address.
In some situations I've seen, the MAC address along with the system serial
number and other stuff are not on what you might call the motherboard,
but in a write-once chip on the board carrying the connectors in which
the main CPU board(s) is(are) plugged. This is so that the main board(s)
containing CPU(s), some cache(s), and sometimes some main memory can be
replaced without changing the system serial number. I've seen this is
done for the convenience of system vendor's maintenance organization, but
it also helps third party, node-locked software and license managers.
(of course, I'm not talking about PC's)
The practice of a major UNIX vendor of using a single MAC address for more
than Ethernet interface on a single machine is technically wrong in the
sense that it has long caused serious problems on networks. If for some
reason two interfaces with the same MAC address are connected to the same
broadcast domain, Very Bad Things happen. Bridges get confused. ARP
doesn't work. IP addressing breaks down. Customers complain.
That a single host owns all of the interfaces with the MAC address
prevents none of those Very Bad Things.
> ...
>>I think most software vendors that are charging real money (i.e. not
>>shareware pricing) prefer to know when you buy a new computer and many
>>even prefer to force you to buy a new license. (I'm reporting not
>>commending the attitudes of some business and sales people
>
>IMHO they oughtn't be able to do this. And I also think it's a privacy
>violation for them to be able to find out stuff about your computer.
>They should sell you N licences, period. And reselling them shouldn't
>legally be able to be prohibited by the company except for specific reasons
>(e.g. some software might be available only to doctors/cops/etc).
I mostly agree with that, but there are reasonable arguments to the
contrary. When you think you're buying fancy software, you're often buying
a service instead of software. For example, you might buy a service
consisting of 500 simulated hours of the operation of an integrated
circuit. It's easy for the vendor to sell you a 1-year license for a
system of X MIPS that can simulate 500 hours in a year of real time. If
you run that software on a system 10 times faster, you'd get more of that
simulating service than you paid for.
> ..
>write, when that software is being used by legitimate, paying users.
>
>>There is no alternative to somehow collecting real money for some of my code.
>
>Well, this is simply not true, but it's not really on topic for this
>newsgroup. (Professional programmers existed prior to the commercialization
>of software.)
Really? "Commercialized software" existed by the early-60's in the sense
of tapes and decks from third parties bought for money. (I know because
I saw some old stuff when I became a professional programmer in the
late-60's.) I think that as soon as there were commercial computers,
there were outfits selling software for money. What would you call the
pre-programmed control boards for card sorters that were sold in the 50's
but "commercialized software"?
When practical, ommercializd software is far better than the only workable
alternative, which is having all code be custom jobs. You either pay me
by the hour and run my code on only your systems, or you pay me (or my
boss) for a non-exclusive write to run my code on your system and allow
other people to buy similar rights. I think the second mode serves users
better. It allows competition among solutions to problems (e.g. Netscape
vs. IE) that is impossible otherwise. It also reduces the price of
software by as much as many 1,000,000's of times.
> ...
>The reason that the PGP key collision possibility is not a problem is that
>it doesn't matter unless detected by a human. More fundamentally, suppose
>someone just chooses a random whatever-bit number and just happens to guess
>your private key? The answer is that the probability has been calculated and
>has been judged to be acceptably low.
Some of that is mostly true, but it applies equally to globally unique
ID's, from Ethernet MAC addresses to ID's for node locking software.
>But in the typical use of the term "globally-unique ID" in this way, no
>probabilities have been calculated and no judgement has been made. People
>just throw in a lot of factors and hope.
That is simply wrong. As others have said, barring bugs many people have
looked for and not found, and assuming non-broken PC hardware, the chances
of two PGP keys being the same is smaller than the chances of an astroid
hitting the earth and wiping out all big mammals including humans between
the time you start reading this sentence and the time you finish.
As someone who has been involved in assigning Ethernet MAC addreseses to
computers, I know that the observed occurance of duplicate MAC addresses
is far more frequent than one in 100,000,000, not to mention the odds that
the Big One will strike in in the next few seconds. My personal
observations of ID assignment problems say it is more frequent than 1 in
1,000,000, but maybe I've just been unlucky..
>You create a genuine globally-unique ID based on procedures and analysis.
>Then, as you go on to point out, you might have a flaw in the execution
>of these procedures. But similarly, programs have bugs. It doesn't mean
>that we give up programming; we try to write bug-free programs using careful
>methodology.
Competent programmers use various methods to minimize the mistakes (bugs)
we inevitably make, but just as important, we know that bugs will be
present in our own and other's code, and write our code to minimize the
effects of bugs.
> Similarly, we should try to assign genuinely globally-unique
>IDs, when necessary, based on procedures and the careful execution of them.
>Rather than just throwing in a lot of random factors and hoping, which is more
>like the current industry-standard many-bugs-producing programming techniques.
It is far more practical to design a random number generator with a mean
time between failures of more than 1,000,000,000 bits than to design
administrative procedures to assign globally unique serial numbers or ID's
with a mean time between human failures of 1,000,000 ID's. The probabilty
that two 100 bit strings from a properly designed random number generator
will be the same is much more than 1,000,000,000,000,000,000,0000 times
less probable that the a hiccup by any ID assigning system.
>>On the other hand, in the real world, things like MAC addresses that have
>>actual mechanisms aren't always unique. ...
>
>I'm not saying you ignore these factors. I'm saying you start with solid
>theory, then you modify as needed for practical reasons, and then you end up
>with a scheme which works in theory AND in practice. Otherwise you typically
>end up with a system which works in neither.
"In theory there is no difference between theory and practice, but in
practice there is." In your theory, you can design a procedure that
involves human actions to generate chips containing Ethernet MAC addresses
or globally unique ID's that will not have duplicates with a probability
of less than 1 in 100,000,000. Based on my professional experience, your
theory is wrong by orders of magnitude.
Yes, humans are always involved, if only by telling the computers
where too look for the database of previously assigned numbers or just
the highest previous number.
Yes, therein lies the tale of more than one real life instance of
duplicate Ethernet MAC addresses. And no, there is no real fix.
Sometimes the operators really do need to repeat exactly a process
to try to figure out what went wrong before. And no, if the rerun
generates different numbers, it isn't a rerun and might not uncover the
problem.
There are other ways such processes can and do fail.
....
In article <[EMAIL PROTECTED]>,
Eric Lee Green <[EMAIL PROTECTED]> wrote:
] ...
]AGH! Please don't do that. Within the past year we have updated major portions
]of our corporate network from 10baseT to 100baseT, ...
]cheapo-cards don't work properly in 100BaseT Full Duplex mode, meaning yet
]more cards replaced :-(.
]
]Our server load is taken up by SCO Unix (being retired) and Linux on Intel
]boxes, though we have numerous other platforms in our porting lab. We would
]not be pleased if our $30,000 accounting and manufacturing system broke
]because we upgraded our server :-(.
So leave the old 10BASE-T card in your server unconnected or connected to
a little used control or administrative network. (You do have such a net
for the security and administrative obvious reasons, right?) If that
really, honestly doesn't work, then consider
- the least inconvenient and unreliable ways to get a MAC address on a
WIN32 box is to ask for what Microsoft calls a GUI. Think about the
implications of that on the many licensing and registration mechanisms
that use WIN32 GUI's. In other words, node locking is already widely
based on MAC addresses.
- your license may limit the bandwidth or number of network connections
or other aspects of the host, and so you ought to contact the vendor
even if your package is still working.
- there may be things in your $30,000 package that will break for purely
technical reasons when you add network inferfaces or change their
nature or speed. (E.g. some of what you wrote about hubs sounds
inimical to multicasting)
- if the license terms do allow upgrades of your hardware, then your
vendor will be more than happy to provide a new key based on the
new identity of your server.
- for more than 20 years, reasonable computer systems, including all that
I've been involved in designing, have had appliation-readable serial
numbers. That PC's don't yet, and due to foolishness about the P-III
ID won't for a while longer, doesn't say much about the systems that
many people still buy to run $30,000 software. Do you know that your
$30,000 package is not already "node locked" to your server using
the server's software-readable serial number other than its MAC
address?
]I don't know what my management would do, but I suspect it would NOT be
]polite, at a minimum with irate demands that you fix the problem, and if that
]failed, a lawsuit filed under Arizona consumer fraud laws (note that no
]license contract can supercede the law... otherwise, deed restrictions which
]state that "this property may not be sold to blacks, Hispanics, or Indians"
]would be enforcible).
That is an distinctly silly pile of nonsense. I hope it was a
mistake instead of typical.
] That's the kind of nonsense that led to the whole
]"cracking" business in the first place -- i.e., where copy protection was
]prohibiting people from installing their programs that they had purchased onto
]their hard drives, back in the mid 80's. It really sucked to have spent
]hundreds of dollars on a word processor, only to find that you had to run it
]off a bog-slow 5 1/4" floppy every time you wanted to load it, despite having
]a nice fast 50-ms access time 30mb RLL hard drive (that costed $1,000!) in
]your computer :-).
There is some truth in that. Hoever, "cracking" as well as copy protection
started well before the mid-1980's and before 5 1/4" floppies. (I built
a node locking scheme in the 1970's.) That bad salescritters and marketoons
get too greedy and make their software locks too much hassle because
they think customers are as dishonest as themselves and to try to squeeze
that last 20% of revenue without using lawyers implies as much about
the idea of copy protection as Windows 9* does about the idea of computers
that don't crash daily. That most of the old copy protection schemes were
stupid (e.g. non-standard bits on floppies) does not imply that all copy
protection is stupid. The only people who make the blanket statement that
all copy protection is bad are those without clues about their own lack
of clues and those who aren't even honest about their dishonesty.
]If the goal is to keep honest people honest (and really, that's the only
]worthwhile goal here), a "normal" license manager which relies on the user
]typing in valid license data (valid as checked vs. an RSA public key or a MD5
]hashed shared key) will do that, without peeving current and future customers.
What "normal" license manage does not not involve a hardware serial number
or signature of some kind? All of the commercial license managers I've
seen use either a hardware system serial number (including a dongle), a
MAC address, or an IP address. Given the advent of CIDR and non-portable
IP addresses on one side and RFC 1918 addresses and NAT boxes on the other,
node locking to an IP address makes even less than the very little sense
it made 10-15 years ago when it was common.
The fatal difficulty with any scheme not based on hardware is that it is
too easy to copy all files of an application, including files containing
generated hashes. An honest customer that accidentally copies a $30,000
package onto a new system for a new or spun-off subsidiary or distant
office, and finds that no new key is required will probably forget to call
the vendor for another key.
If the hardware does not have something like the P-III ID, then a MAC
address is fair second choice. It is worse but usable. I don't know
of a third choice that is effective enough but not too much hassle.
I think that dongles, whether the original on the system bus or connected
via parallel port, serial port, USB, or in series with the keyboard are
too much hassle, including too unreliable. For a hint of that, get
technical information from current dongle vendors and notice that they
tell you to try to read all the dongles a bunch of times before deciding
the dongle is absent or has the wrong number. Then there is the cost
of the dongle itself.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Highdesertman)
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: Thu, 03 Feb 2000 10:22:58 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 31 Jan 2000 01:12:01 -0700, Jerry Coffin <[EMAIL PROTECTED]>
wrote:
>In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>> And let me reiterate by quoting the meat of my original post:
>>
>> "Sorry boys, but you can't have it both ways. You can't say that you
>> have the right to crack a proprietary software encryption system and
>> distribute that information, and then demand the right to absolute
>> privacy of our own data."
>
>You're ignoring one _extremely_ simple concept: the concept of
>ownership. I'm allowed to keep MY information private for the simple
>reason that it's MINE. If I decide to sell my private data, then I've
>given up the right to absolute privacy over that data. If, OTOH, I
>don't sell/give away/whatever my right to my data, then yes, I really
>CAN demand the right to absolute privacy.
>
>The question here is whether I can sell something, and still demand
>the right to privacy, with the consumer only allowed to use the data
>in exactly the way I say he can. This is a long-standing question,
>and there's a long-standing tradition of copyright law to define
>exactly what rights can be retained by the original owner, and what
>rights are rendered to the consumer in such a transaction. The
>consumer is NOT given the right to duplicate the data and sell it to
>the others (except with extreme limitations) but IS given the right to
>examine it in nearly any way (s)he chooses, specifically INCLUDING
>reverse engineering to produce a compatible product.
>
>--
> Later,
> Jerry.
>
>The universe is a figment of its own imagination.
When encryption is used to protect copyrighted material, that
encryption itself, if not already protected under the law, *should* be
protected under the law. I am not a lawyer, and so, I will not argue
the finer points of copyright law. However, I will say the following:
this is a case in which a proprietary copyright system designed to
protect intellectual property was stolen from it's rightful owners via
reverse engineering, and published publicly. When you buy a DVD, you
are buying the right to play it in your home privately, and there are
very specific limitations to what you can do (which are spelled out in
the warning screen each time you play it). You may not play it
publicly for profit, you may not license it to others for public or
private viewing ( there are some exceptions for the video rental
industry which I won't get into here), and you certainly do not have
the right to openly publish the code that was designed to prevent the
theft of the contents of that DVD.
Come on folks, surely I am not the only encryption buff in this
newsgroup that can see that publishing a private encryption algorythim
designed to protect intellectual property from theft is, at the very
least, *wrong* if not legally prohibited?
cheers,
Mathew
------------------------------
From: [EMAIL PROTECTED] (Highdesertman)
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: Thu, 03 Feb 2000 10:28:00 GMT
Reply-To: [EMAIL PROTECTED]
Ok. I yeild the floor to my esteemed newsgroup peers. I seem to be the
only individual here that sees something wrong in taking that which
does not belong to you.
cheers,
Mathew
On Mon, 31 Jan 2000 00:33:41 -0700, Jerry Coffin <[EMAIL PROTECTED]>
wrote:
>In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>
>[ ... ]
>
>> Perception: Any code is fair game to cracking. I have the *right* to
>> reverse engineer, diff analyze or in any way crack anything that is
>> encrypted. In fact, I have a duty to do so, so everyone will know
>> whether or not it is a trustable algorythm.
>>
>> Reality: Aren't we biting our own tails here? We are the community
>> that so strongly defends an individuals right to privacy, yet we deny
>> that right to the DVD industry simply because they are a for-profit
>> industry? It is wrong of us to assume that simply because the owners
>> of the DVD crypto are keeping the code from us, that we have the right
>> to crack it and see what it is.
>
>The law is quite careful to protect your right to reverse engineer
>(code or other mechanisms) to produce compatible products. This is
>true in the US. The EU standards for member countries require that
>reverse engineering for compatibility be protected. In fact, the same
>basic idea is true throughout almost the entire civilized word. The
>only countries about which I'm reasonably uncertain are those that
>simply ignore ALL copyrights (and other such laws).
>
>--
> Later,
> Jerry.
>
>The universe is a figment of its own imagination.
------------------------------
From: "Peter L. Montgomery" <[EMAIL PROTECTED]>
Subject: Re: How to choose public-key e on RSA?
Date: Thu, 3 Feb 2000 10:22:30 GMT
In article <t3nm4.3968$15.28174@news> "Miryadi" <[EMAIL PROTECTED]> writes:
>Hello, Everybody
>
>I have a problem on determining the number of step
>to find public-key, e, on RSA algorithm.
>My procedure in Delphi is like this:
>
>Procedure SearchForE;
>var found: boolean;
>begin
> e:= random(100);
> if e mod 2=0 then e:=e+1;
> found:=false;
> repeat
> if GCD(e, (p-1)*(q-1))=1) then found:=true
> else e:=e+2;
> until found:=true;
>end;
>
>Is it possible to determine how many number I should examine,
>before finding e.
>
Usually e is fixed, for all users. e = 2^16 + 1 = 65537
is common. e = 3 has weaknesses.
If random(100) can return a 1, your code might select e = 1,
for which decryption is easy.
--
E = m c^2. Einstein = Man of the Century. Why the squaring?
[EMAIL PROTECTED] Home: San Rafael, California
Microsoft Research and CWI
------------------------------
** 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
******************************
