Trusting the Tools - was Re: Open Source ...

2003-10-11 Thread Bill Frantz
At 8:18 AM -0700 10/7/03, Rich Salz wrote:
Are you validating the toolchain?  (See Ken Thompson's
Turing Aware lecture on trusting trust).

With KeyKOS, we used the argument that since the assembler we were using
was written and distributed before we designed KeyKOS, it was not feasible
to include code to subvert KeyKOS.  How do people feel about this form of
argument?

Cheers - Bill


-
Bill Frantz| There's nothing so clear as a | Periwinkle
(408)356-8506  | vague idea you haven't written | 16345 Englewood Ave
www.pwpconsult.com | down yet. -- Dean Tribble | Los Gatos, CA 95032


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Internal format of RSA private keys in microsoft keystore.

2003-10-11 Thread R.Sriram
Greetings,

In the process of trying to work around some of the limitations
of the m$-CAPI API, I'm trying to decipher the internal representation
of private keys in the default m$ key store, in order to extract
the private key out.
The systems I'm working on are Win2K and XP, both on NTFS.

Google didn't give me much. Has anyone been able to figure out
the format of private key files? You can have a look at
C:/Documents and Settings/username/Application Data/Microsoft/
Crypto/RSA/*/filename
I'm trying this because CryptAcquireContext() dies with the error
NTE_BAD_KEYSET half the time. This is supposed to indicate that the
key container doesn't exist or it could be corrupted. At this point
I'm trying to see if the files are in good shape by reading them
out.
Having come from a Unix world, there may be something obvious I'm
missing out, so please have patience :)
Thanks,
Sriram.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Easy VPNs?

2003-10-11 Thread Ralf-Philipp Weinmann
Ian Grigg [EMAIL PROTECTED] writes:

 I'm curious - my understanding of a VPN was that
 it set up a network that all applications could
 transparently communicate over.
 
 Port forwarding appears not to be that, in
 practice each application has to be reconfigured
 to talk to the appropriate port, or, each port
 has to be forwarded.
 
 Am I missing something here?  If there is an
 easy SSH based strategy for VPNs, what is it?
 
 iang

Well it's not a VPN per se, and it's dependent on the SSH client
you're using but it may help you anyway: When using an OpenSSH [1]
client one can enable dynamic portforwarding (the -D switch or the
DynamicForward option in ssh_config) which gives you a SOCKS server on
the machine you ssh from.

Under un*xy operating systems supporting LD_PRELOAD or similar dynamic
linker options you can then use something like tsocks [2] to make all
dynamically linked (and non-suid) applications performing only
outbound TCP connections use your SOCKS server.  This is sort of a
hack but works pretty good for me.

Something I've done as well in the past is run Slirp[3] on a remote
machine and have an SSH tunnel between Slirp and the PPP daemon on my
local machine. This assumes you have sufficient privileges on the
client machine however. It allows you to do both outbound TCP and UDP
however I do not really advise this strategy because of [4].

Cheers,
Ralf

[1] OpenSSH
http://www.openssh.org
[2] TSOCKS - A transparent SOCKS proxying library
http://tsocks.sourceforge.net
[3] Slirp
http://slirp.sourceforge.net
[4] Why TCP over TCP Is a Bad Idea
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

-- 
Ralf-P. Weinmann [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Easy VPNs?

2003-10-11 Thread Dave Howe
Ian Grigg wrote:
 I'm curious - my understanding of a VPN was that
 it set up a network that all applications could
 transparently communicate over.
spot on.

 Port forwarding appears not to be that, in
 practice each application has to be reconfigured
 to talk to the appropriate port, or, each port
 has to be forwarded.
also correct

 Am I missing something here?  If there is an
 easy SSH based strategy for VPNs, what is it?
what you are missing is joining the dots. the VPN part requires that a
server process be running that intercepts packets destined for the
remote end of the VPN (usually a virtual network card or ip stack shim).
That says nothing about how the data gets from *that* intercept server to
the matching server at the receiving end - the transport method.
IPSec uses an assortment of custom ip types and standard tcp/udp
connections. ssl vpn uses an ssl encrypted tcp/ip connection, but there
is no reason why the two intercept servers couldn't talk to each other
over (for example) a ssh tunnel, zebedee, or whatever else takes its
author's fancy.
In practice, you want the tunnel to have low overhead, so udp is often
used; tcp however traverses nat and pat servers much more easily and the
additional convenience of ssh transport (being an existing, established
standard that uses only a single port and that firewalls - and their
admins - are already familiar with) may be of more value than the more
complex and less well understood (and damned hard to get though anything,
including firewalls) IPSec.

so as I say - think of vpn as two components - intercept (the virtual
network functionality) and transport (a secure, authenticated,
encapsulated communications standard) and how vpn over *anything* becomes
more clear.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Monoculture

2003-10-11 Thread Ben Laurie
Thor Lancelot Simon wrote:

 On Sun, Oct 05, 2003 at 03:04:00PM +0100, Ben Laurie wrote:
 
Thor Lancelot Simon wrote:


On Sat, Oct 04, 2003 at 02:09:10PM +0100, Ben Laurie wrote:


Thor Lancelot Simon wrote:


these operations.  For example, there is no simple way to do the most
common certificate validation operation: take a certificate and an optional
chain, and check that the certificate is signed by an accepted root CA, or
that each certificate in the chain has the signing property and that the
chain reaches that CA -- which would be okay if OpenSSL did the validation
for you automatically, but it doesn't, really.

Err, yes it does, but its not very well documented.


No.  You can't do it in one step, and you have to use functions that are
marked in OpenSSL's header files as not being part of the official API.
mod_ssl has a convenience function that's confusingly named just like the
OpenSSL library functions that deals with this -- of course, it should be
part of OpenSSL itself, but at least as of 0.9.6 it was not.

Would you care to be more explicit?
 
 
 I have to apologize -- I was not entirely correct in my initial statement,
 but without access to the source tree I did most of my OpenSSL work in
 (it belongs to a former employer) it took me a while to retrace my steps
 and realize I was not quite right.
 
 On the client side, though the documentation's poor, you're correct: there
 _is_ a way to validate a certificate and chain you've received from the peer
 in one step.  (I note that there is now reference in the header files to
 some AUTOCHAIN stuff that I don't recall from earlier versions of OpenSSL,
 but that ssl_verify_cert_chain is *still* not part of the public API; it's 
 in ssl_locl.h).

But that's because its used internally (by both clients and servers).

 On the server side (or, indeed, on the client side, if the client side 
 needs to follow a chain to reach a trusted CA, and thus needs to load chain 
 certificates) there's no API for loading a cert and its entire chain in one 
 shot, and indeed to do so AFAICT you must use functions that are not part of 
 the public API.  

Hmmm. You can put multiple certs in a single file, IIRC, and you can
certainly have multiple certs in a directory, with hashed links pointing
to them.

I know for sure chained certs work without screwing around coz I just
tested them whilst adding CRLs to Apache-SSL.

 See SSL_CTX_use_certificate_chain() in the mod_ssl sources (which appears 
 much simpler in mod_ssl 2.8 than what I remember working with -- perhaps the 
 OpenSSL API *has* improved!) and SSL_use_certificate_file, 
 SSL_CTX_use_certificate_file, and SSL_CTX_use_certificate_chain_file in the 
 OpenSSL sources.  And then note that *all* of the example code gets this
 stuff wrong -- if it even bothers to do server certificate validation at
 all.

Regrettably, mod_ssl is not the best guide to the use of OpenSSL - it
often goes about things in a long-winded and inappropriate way (compare
its CRL handling with mine, for example).

 I can't lose my impression that some of the chain-handling functions moved
 from ssl_locl.h to ssl.h between 0.9.6 and 0.9.7 but I don't have a 0.9.6
 tree handy nor the time to sift through it.  Sigh.  I wish I had some of
 my code from the last time I tackled this issue with OpenSSL at hand, but
 unfortunately I don't own it, so I do not.

This could well be true.

 The complexity and instability of the API for this stuff, and the fact that
 we're both rooting around *in the OpenSSL source code* to figure out which
 bits of it are public and which are internal, and in which version of
 OpenSSL, when the operations at hand (loading and validating chains of
 certificates, from the cert for the peer's identity up to the cert from
 which trust derives) is a pretty good example, itself, of why I don't care
 for OpenSSL.

Oh, I totally agree!

 I spent a long time working on the X.509 support in Pluto,
 too, and though I don't really care for it either it does have the decided
 advantage that it appears to be designed in the right direction: from what
 are the end-user's needs? instead of what is the structure of the
 underlying protocol or software abstraction?

I'm not familiar with Pluto.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-11 Thread Ben Laurie
Peter Clay wrote:

 On Thu, 9 Oct 2003, Peter Gutmann wrote:
 
 
I would add to this the observation that rather than writing yet another SSL
library to join the eight hundred or so already out there, it might be more
useful to create a user-friendly management interface to IPsec implementations
to join the zero or so already out there.  The difficulty in setting up any
IPsec tunnel is what's been motivating the creation of (often insecure) non-
IPsec VPN software, so what'd be a lot more helpful than (no offense, but) yet
another SSL implementation is some means of making IPsec easier to use
(although that may not be possible... OK, let's say less painful to use :-).
 
 
 Having spent much of the past few weeks trying to sort out a workable VPN
 solution, I think this is a good but doomed idea. http://vpn.ebootis.de/
 has the best free windows IPsec configuration tool I've found, but that
 doesn't help. Why? Because IPsec traffic is not TCP traffic and therefore
 gets dropped by random networks.
 
 If you want a VPN that road warriors can use, you have to do it with
 IP-over-TCP. Nothing else survives NAT and agressive firewalling, not even
 Microsoft PPTP.

PPTP uses GRE, so aggressive firewalls are likely to kill it, however,
it isn't hard to stop them :-)

However, I've seen UDP surive some fairly aggressive firewalling, and
that's what you really want for a VPN.

 If someone out there wants to write VPN software that becomes widely used,
 then they should make a free IP-over-TCP solution that works on Windows
 and Linux which uses password authentication.

Doesn't OpenVPN have that option?

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: NCipher Takes Hardware Security To Network Level

2003-10-11 Thread Anton Stiglic

- Original Message - 
From: Peter Gutmann [EMAIL PROTECTED]
 [...]

 The problem is
 that what we really need to be able to evaluate is how committed a vendor
is
 to creating a truly secure product.
 [...]

I agree 100% with what you said.  Your 3 group classification seems
accurate.
But the problem is how can people who know nothing about security evaluate
which vendor is most committed to security?
For the moment, FIPS 140 and CC type certifications seem to be the only
means
for these people...  Unfortunately these are still to general and don't
always give
you an accurate measurement of how dedicated to security the vendor was...
This seems to be a big open-problem in practical security!

--Anton

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: [e-lang] Re: Protocol implementation errors

2003-10-11 Thread Bill Frantz
At 5:36 PM -0700 10/5/03, Norman Hardy wrote:
I can't recall Keykos security problems stemming from hostile message
strings in a key invocation.
I don't know why. Perhaps we always expected hostile messages as a
cultural thing.

I think there were several additional reasons for this:

* Most of the strings passed were very simple, consisting of just one
string.  We didn't get much more complex than, for example, the record
collection (which used byte string names to look up data and capabilities).
Its string was:

  * 1 byte - length of name
  * n byte (0-255) name
  * the rest data.

* We did not try to handle infinite length strings.  In general, strings
were limited to 4096 bytes.

* We were programming in 370 assembler, which, IMHO, is better suited to
writing secure code than C.  For example, the string copy primitive in C is
strcpy, where the source string determines the length.  In 370 assembler,
the primitive is MVCL (move long) which takes 5 parameters, the source
address and length, the destination address and length, and the fill
character.  Having to specify those 5 parameters made the issues involved
in a string copy very obvious each time one was coded.

* We did not, as a general rule, have a stack.  As a result, it was less
likely to have program control data (return addresses) and buffers next to
each other, where a buffer overrun could result in both hostile code, and
the necessary changes to the program control data to pass control to it.


At 10:58 PM -0700 10/3/03, Peter Gutmann wrote:
I would say the exact opposite: ASN.1 data, because of its TLV encoding, is
self-describing (c.f. RPC with XDR), which means that it can be submitted to a
static checker that will guarantee that the ASN.1 is well-formed.  In other
words it's possible to employ a simple firewall for ASN.1 that isn't possible
for many other formats (PGP, SSL, ssh, etc etc).  This is exactly what
cryptlib does, I'd be extremely surprised if anything could get past that.
Conversely, of all the PDU-parsing code I've written, the stuff that I worry
about most is that which handles the ad-hoc (a byte here, a unit32 there, a
string there, ...) formats of PGP, SSH, and SSL.  We've already seen half the
SSH implementations in existence taken out by the SSH malformed-packet
vulnerabilities, I can trivially crash programs like pgpdump (my standard PGP
analysis tool) with malformed PGP packets (I've also crashed quite a number of
SSH clients with malformed packets while fiddling with my SSH server code),
and I'm just waiting for someone to do the same thing with SSL packets.  In
terms of safe PDU formats, ASN.1 is the best one to work with in terms of
spotting problems.

I think Peter has convinced me that ASN.1 (by which I mean DER
specifically, since that is the form that the run-time code parses), is
probably not a whole lot worse than the other formats (which also have
shown significant parsing bugs).  While some of the problems come from the
details of the format, most probably come from the complex data structures
that are part of the problem space.  Given that this is a correct
assessment, then we need to think of ways to protect ourselves against the
programs that parse these data.

If we were coding in KeyKOS or EROS, I would put the parsing code in a
separate domain.  To protect against denial of service that domain would
have a limited space bank, a keeper, and a timeout to signal parse failure
to the caller.  To guard against attack, that domain would only have
capabilities to:

* The input string and/or the input byte stream
* No hole creators for the output objects.

Further protection can be built by limiting the privilege of the domains
that use these output objects.  (Note that the cost of a domain call is
very small compared with the cost of a public key operation.)

I don't really know how to apply this approach to a UNIX like system.  I
think for these systems, it might be best to write the parsing code in a
safe language such as Java, Smalltalk, E, Scheme etc.  That would result
in an additional layer of protection from the runtime.  If the cost of
calling into and return from the language is small enough, the extra cost
of the language should be tolerable.  (Having to fire up a Java Virtual
Machine each time could make public key operations look fast.)

Cheers - Bill



-
Bill Frantz| There's nothing so clear as a | Periwinkle
(408)356-8506  | vague idea you haven't written | 16345 Englewood Ave
www.pwpconsult.com | down yet. -- Dean Tribble | Los Gatos, CA 95032


___
e-lang mailing list
[EMAIL PROTECTED]
http://www.eros-os.org/mailman/listinfo/e-lang

-
Bill Frantz| There's nothing so clear as a | Periwinkle
(408)356-8506  | vague idea you haven't written | 16345 Englewood Ave
www.pwpconsult.com | 

Re: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-11 Thread David Honig
At 12:08 AM 10/10/03 +0800, Ng Pheng Siong wrote:
I believe SSL VPNs are easier than IPsec to deploy 

For the former, you give a password or two --maybe
reuse a POP3 that your users already have-- and all your
users get in fairly securely, and you can verify them.  
Easy for them because they already have a browser.  

(And some browsers, I recently found out, will accept a self-cert
for life, as well as remember your passwords.  Can you guess
which company made that convenience-vs-security tradeoff?)

For IPsec, you have to walk each of them through
installing the stack, etc.  Not fun, esp on multiple
platforms.

and operate for the road
warrior accessing corporate resources. This may eventually restrict IPsec's
utility to site-to-site tunneling (useful when, e.g., one wishes to run
OSPF over the tunnel), which _should_ be far easier to configure without
needing the help of some whizbang AI.

Things *should* get easier for IPsec when its part of the default
client system, whether *nix or otherwise.  Then everything reverts
back to simple :-) key management.


He say I know you, you know me
He got x509 he got intrusion detection
He got secure DNS he got spam filter
He say One and one and one is three
Got to be spoofed 'cause he's so hard to see 

From Link Together
J0hn L3nn0n





-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Software protection scheme may boost new game sales

2003-10-11 Thread Steve Schear
Companies are using a new software protection system, called Fade, to
protect their intellectual property from software thieves. Fade is being
introduced by Macrovision, which specializes in digital rights management,
and the British games developer Codemasters. What the program does is make
unauthorized copies of games slowly degrade, by exploiting the systems for
error correction that computers use to cope with CD-ROMs or DVDs that have
become scratched. Software protected by Fade contains fragments of
subversive code designed to seem like scratches, which are then arranged
on the disc in a pattern that will be used to prevent copying. Bruce
Everiss of Codemasters says, The beauty of this is that the degrading copy
becomes a sales promotion tool. People go out and buy an original version.
(New Scientist 10 Oct 2003)
http://www.newscientist.com/news/news.jsp?id=ns4248

steve

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-11 Thread Florian Weimer
David Honig wrote:

 For the former, you give a password or two --maybe
 reuse a POP3 that your users already have-- and all your
 users get in fairly securely, and you can verify them.  
 Easy for them because they already have a browser.  

Has anybody tried to revert the political decision not to support
password-based authentication with IPsec?

[Moderator's note: there was no such political decision to my
 knowledge. In fact, there was a requirement for manual keying from
 very early on in the protocol's life. --Perry]
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


VPN List Announcement

2003-10-11 Thread Ben Laurie
Since I'm sure Perry will eventually get tired of VPNs, before he does I
should announce that I have, at the request of several participants in
the recent discussions, set up a list for VPN theory discussion. It is
currently unmoderated, though I reserve the option to change that if
warranted.

The list can be found here:
https://mailman.aldigital.co.uk/mailman/listinfo/vpn (yes, I know the
certificate has expired).

It will also be reflected into news at gmane.network.vpn.theory.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: NCipher Takes Hardware Security To Network Level

2003-10-11 Thread Ian Grigg
Anton Stiglic wrote:
 
 - Original Message -
 From: Peter Gutmann [EMAIL PROTECTED]
  [...]
 
  The problem is
  that what we really need to be able to evaluate is how committed a vendor
 is
  to creating a truly secure product.
  [...]
 
 I agree 100% with what you said.  Your 3 group classification seems
 accurate.
 But the problem is how can people who know nothing about security evaluate
 which vendor is most committed to security?


(I am guessing you mean, in some sort of objective sense.)

Is there any reason to believe that people who
know nothing about security can actually evaluate
questions about security?

It's often been said that security is an inverted
product.  (I'm scratching to think of the proper
economic term here.)

That is, with security, you can measure easily when
it is letting the good stuff through, but you don't
know when and if and how well it is stopping the bad
stuff *.

The classical answer to difficult to evaluate
products is to concentrate on brand, or independant
assessors.  But, brands are based on revenues, not
on the underlying product.  Hence widespread confusion
as to whether Microsoft delivers secure product - the
brand gets in the way of any objective assessment.

And, independant assessors are generally subvertable
by special interests (mostly, the large incumbents
encourage independant assessors to raise barriers
to keep out low cost providers).  Hence, Peter's
points.  This is a very normal economic pattern, in
fact, it is the expected result.

So, right now, I'd say the answer to that question
is that there is no way for someone who knows nothing
about security to objectively evaluate a security
product.

iang

* In contrast, someone who knows little about cars,
can objectively evaluate a car.  They can take it
for a test drive and see if it feels right.  Using
it is proving it.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Software protection scheme may boost new game sales

2003-10-11 Thread Sunder

Yawn...  This is no different than any of the copy protection schemes
employed in the 1980's on then popular home computers such as the
commodore 64.  

Hindsight is 20/20 and recalls, all of these were broken within weeks if
not months.  Nibbler copiers and other programs were quickly built that
allowed the breaking of all of these systems.  All sorts of error
sectors, duplicate tracks, half tracks, extra tracks, extra sectors,
non-standard sized sectors, tracks written at different speeds, erroneous
checksums, hidden data, and other sorts of weird bits were employed.  All
were broken.  None survived the ages.

In the end, the companies that employed copy protection only managed to
piss off customers who lost their only copy of the software, and created a
market for the copiers and crackers.  The crackers won, the software
companies lost.  

Few of the companies of that era are still in business today.  CEO's,
Vulture Capitalists, and others who have an interest in such schemes would
do well to invest some time in learning about that time, and the results,
for their investments, and dollars will go the same way... the way of the
brontosaurus, the trilobite, and the dodo.

Let them try, if they wish to burn their money.  As far as I'm concerned,
I'll vote with my wallet as usual and only run open source, free software.  
If the moronic kids at whom these titles are aimed have the $50-$70 per
title to waste on self destructing, flavor of the month games, they are
certainly free to spend that money to their heart's desire.


Not a dime from my wallet will wind up in their pockets - except perhaps
indirectly:  the next time I buy my next burger, no, I don't want fries
with that, no, I don't want to supersize it, my $5 eventually makes a
small contribution to the salary of the burger flipper, which in turn is
applied to the purchase of said game.  :)



I've not read the said article just yet, but from that direct quote as
the copy degrades... I can already see the trouble with this scheme:
their copy protection already fails them.  They allow copies to be made
and rely on the fact that the CDR or whatever media, will eventually
degrade, because their code looks like scratches...  Rggghtt.

If you can make one copy, you can make many, and you can certainly store
the ISO in compressed form on a normal CD to make more copies
later.   CDR's are what? $0.20@ these days?

Hell, you can even get one of those virtual CDROM programs to mount the
CD's as if they were CD's, and store the ISO on a hard drive, or DVD-R
instead. Hard drives are already in the 250-500GB range these days.  So
their scheme is already flawed and doomed from the start.

It seems to me that people that engage in treating their customers like
theives to begin with lack a vital ingredient for making money: common
sense.


--Kaos-Keraunos-Kybernetos---
 + ^ + :25Kliters anthrax, 38K liters botulinum toxin, 500 tons of   /|\
  \|/  :sarin, mustard and VX gas, mobile bio-weapons labs, nukular /\|/\
--*--:weapons.. Reasons for war on Iraq - GWB 2003-01-28 speech.  \/|\/
  /|\  :Found to date: 0.  Cost of war: $800,000,000,000 USD.\|/
 + v + :   The look on Sadam's face - priceless!   
[EMAIL PROTECTED] http://www.sunder.net 

On Sat, 11 Oct 2003, Steve Schear wrote:

 Companies are using a new software protection system, called Fade, to
 protect their intellectual property from software thieves. Fade is being
 introduced by Macrovision, which specializes in digital rights management,
 and the British games developer Codemasters. What the program does is make
 unauthorized copies of games slowly degrade, by exploiting the systems for
 error correction that computers use to cope with CD-ROMs or DVDs that have
 become scratched. Software protected by Fade contains fragments of
 subversive code designed to seem like scratches, which are then arranged
 on the disc in a pattern that will be used to prevent copying. Bruce
 Everiss of Codemasters says, The beauty of this is that the degrading copy
 becomes a sales promotion tool. People go out and buy an original version.
 (New Scientist 10 Oct 2003)
 
 http://www.newscientist.com/news/news.jsp?id=ns4248

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]