Re: San Jose Mercury News declares encryption battle over

>From the article
	<URL:http://www.sjmercury.com/business/compute/encrypt1115.htm>:

> Under the plan computer makers could equip their machines, including
> personal computers, with electronic ''locks'' of almost any strength. A
> single computer model with strong built-in encryption could legally be
> sold in both domestic and foreign markets.
> 
> The key is that the encryption circuitry would be inactive in exported
> machines, unless both buyer and seller obtained all legally required
> licenses to turn it on.
> 
> Domestic customers, and export buyers with a license, would get a special
> key card to turn on the encryption, according to HP. Manufacturers would
> thus be relieved of the burden of making different computers for export
> than for domestic use.

So it sounds like the idea is to build crypto around card tokens.  I think
HP has been pushing this for some time.  The question is, will this somehow
become the only way to get access to crypto?

Unlike the earlier IBM/CIA announcement, this time Netscape and Microsoft
have apparently been brought on board.  That is a lot worse because these
companies are where most people are going to get their crypto in the future.
If they have open standards, we can make good crypto available.  But if
this announcement signals some kind of closing of the system so that only
hardware tokens will be used, it could become a lot harder to make strong
crypto available.

There are also the economic questions about how much these key cards are
going to cost, and whether they are going to be routinely supplied with
computers or an extra cost item that consumers have to go out and buy.
If the latter, a lot of people won't bother, and we'll just have that much
larger a barrier to widespread use of crypto.

It is certainly very disturbing to see these new moves.  Obviously a great
deal of behind the scenes negotiations and pressure has been occuring.
You have to wonder why Netscape, for example, would forego the opportunity
to differentiate themselves from rival Microsoft by positioning their product
as the one which refuses to bow to government pressure on crypto.

It's also not clear what the hardware manufacturers get out of this.
Their sales overseas have never been blocked.  There has been no demand
for custom crypto hardware.  I don't see how they have been harmed by an
inability to ship computers with built-in encryption hardware.  Granted
there are some possible applications for such systems but I don't see the
market demand which would drive this decision.

Hal

At 11:13 AM -0800 11/16/96, Hal Finney wrote:
>>From the article
>	<URL:http://www.sjmercury.com/business/compute/encrypt1115.htm>:
...
>> The key is that the encryption circuitry would be inactive in exported
>> machines, unless both buyer and seller obtained all legally required
>> licenses to turn it on.
>>
>> Domestic customers, and export buyers with a license, would get a special
>> key card to turn on the encryption, according to HP. Manufacturers would
>> thus be relieved of the burden of making different computers for export
>> than for domestic use.
>
>So it sounds like the idea is to build crypto around card tokens.  I think
>HP has been pushing this for some time.  The question is, will this somehow
>become the only way to get access to crypto?

And this is the "nightmare scenario" we have talked of for so long: make a
method ubiquitous, but with bones thrown to domestic users...then take away
the bones.

Namely, once the infrastructure is deployed, once most electronic commerce
is handled via card tokens (and card readers are actually pretty cheap, and
volume will drive the price down further), the President can cite some kind
of national emergency, or widespread tax evasion, or whatnot, to announce
that beginning on suc-and-such a date all cards must be licensed, even to
domestic users.

(Many of us thought this has always been the strategy with supposedly
voluntary programs, which Clipper was, of course. Our principal objection
was not that the FBI would use Clipperphones, but that the technology and
related announcements were quite clearly oriented toward getting lots of
people to use the technology, thus establishing de facto access to keys.)

>It is certainly very disturbing to see these new moves.  Obviously a great
>deal of behind the scenes negotiations and pressure has been occuring.

The history of the whole crypto debate these last several years has been
the history of a series of behind-the-scenes meetings, pressurings, and
eventual cave-ins. In all of the iterations of Clippper, we heard about the
programs after corporate "buy-ins" had occurred. (Though in the case of
Clipper, there were some "trial balloons" floated six months earlier, as
you may recall.)

The only hope I see is that in each of these iterations, a different set of
companies got burned by the experience: AT&T, TIS, IBM/Lotus, and now the
latest round of players. (Each of these losers from defunct early rounds of
the Great Clipper Race must feel jilted.)

This one may be the Final Solution to the Crypto Problem, given the
building crescendo of crypto news, the new Congress and new term for the
President,  and the simultaneous announcement of the new Emergency Order
and the RSA-HP-Intel-Microsoft-etc. deal. Hardly coincidental.

Be afraid. Be very afraid.

--Tim May

"The government announcement is disastrous," said Jim Bidzos,.."We warned IBM
that the National Security Agency would try to twist their technology."
[NYT, 1996-10-02]
We got computers, we're tapping phone lines, I know that that ain't allowed.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^1,257,787-1 | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

Hal Finney wrote:
> >From the article
> <URL:http://www.sjmercury.com/business/compute/encrypt1115.htm>:
> > Under the plan computer makers could equip their machines, including
> > personal computers, with electronic ''locks'' of almost any strength. A
> > single computer model with strong built-in encryption could legally be
> > sold in both domestic and foreign markets.
> > The key is that the encryption circuitry would be inactive in exported
> > machines, unless both buyer and seller obtained all legally required
> > licenses to turn it on.
> > Domestic customers, and export buyers with a license, would get a special
> > key card to turn on the encryption, according to HP. Manufacturers would
> > thus be relieved of the burden of making different computers for export
> > than for domestic use.

> So it sounds like the idea is to build crypto around card tokens.  I think
> HP has been pushing this for some time.  The question is, will this somehow
> become the only way to get access to crypto?

[snip]

Point 1: HP (if you follow their history) would love to do something
exactly like this.  Microsloth and several hardware vendors (including
HP) are currently working on handheld computers which run a subset of
Win95 (called Pegasus), which are due out this year.  If this project
flies, they'll surely graduate it to laptops, to portable phones and
pagers, etc. etc.  Building a certain amount of the O/S into ROM has
its advantages....

Point 2: I've said something like this before, but here's a place where
it could mean something.  If c-punks and others could divvy up as many
of the supporting functions of "strong" crypto as possible, and issue
them in a set of commonly-available libraries for any and all programmers,
along with source code, then an application programmer (theoretically)
could order up some of these libraries and write some useful crypto code
in short order.  This would be much better than taking on thousands of
lines of source code directly.  This would also allow several vendors to
issue similar libraries, and surely someone on the Net could arrange
for comparitive product reviews.

This way, once you have a product up and running, if you (for example)
would like to replace the XYZ function with something a little better,
without impacting the rest of the code, you could order a replacement
for that function and plug it in, perhaps with no code modifications.

-----BEGIN PGP SIGNED MESSAGE-----

In <328E8BEC.2D76@gte.net>, on 11/16/96 
   at 07:52 PM, Dale Thorn <dthorn@gte.net> said:

::Point 2: I've said something like this before, but here's a place where
::it could mean something.  If c-punks and others could divvy up as many
::of the supporting functions of "strong" crypto as possible, and issue
::them in a set of commonly-available libraries for any and all programmers,
::along with source code, then an application programmer (theoretically)
::could order up some of these libraries and write some useful crypto code
::in short order.  
::
        one of the best proposals in many years --we have all made good 
    use of library code over the years, unless the simpleton coder has a
    obsessive-compulsive masochistic need to write an extra 20-50,000 
    lines of 'reinvent the wheel' code.

        there are several linkable libraries floating around, with 
    multiple types, etc.  the only one I looked at a couple of years
    ago needed some extensive work on its calling and return
    conventions --ever hear of structures?

::This would be much better than taking on thousands of
::lines of source code directly.  This would also allow several vendors to
::issue similar libraries, and surely someone on the Net could arrange
::for comparitive product reviews.

::This way, once you have a product up and running, if you (for example)
::would like to replace the XYZ function with something a little better,
::without impacting the rest of the code, you could order a replacement
::for that function and plug it in, perhaps with no code modifications.
::
        ah, yes.  reusable code for disposable programmers!

        and, I agree with the premise on widespread free distribution
    add sand to the governent grease.  make sure every college has 
    complete project kits for free and we will have a new generation of
    expert cryto-application programmers within 5 years. 
        
        needless to say,the workbook needs to mix in a subtle dose of
    freedom of speech, &c.  don't espouse our usual anarchy, etc. or 
    the school admins (always on the leaing edge of the liberals) will
    have none of it.

        every one else puts in for government money to fund these kind
    of developments --make them their junk, but lose it all at 
    distribution --or have a separate organization deal with the 
    logistics.  once you have the product, and for every platform, the
    rest of it is standard word-of-mouth, something for nothing, and
    "fun."  call the package 'voodoo' and ship with a doll fashioned 
    after Bubba  --prestuck with pins.

            -attila

- --
        maybe there is an analogy:

        militias:       the only way they'll take my weapon
                        is from my cooling, smoking hand....

        prez:           the only way they'll take my executive privileges
                        is to vote me out of office --IF I consent to leave.

                <attila>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1
Comment: Encrypted with 2.6.3i. Requires 2.6 or later.

iQCVAwUBMo7CHb04kQrCC2kFAQHgLAP+MjgD0/ekgiQF1VBkhWQ+JOG0PrYRXg+p
F+l8zViJAigJbYwGxRlDEYm4Kl8z1ktNigLlr6t0uPbEmX4c5KPtDl4tEokrTsMk
uxLz8GB6zlKBGuDoBylbGNIGYUTXWaNhYcFL8bOcu+uRSAETsaAiPKynEkwFsigU
bgFenDTzMhc=
=1K7E
-----END PGP SIGNATURE-----

attila@primenet.com wrote:
>    at 07:52 PM, Dale Thorn <dthorn@gte.net> said:
> ::Point 2: I've said something like this before, but here's a place where
> ::it could mean something.  If c-punks and others could divvy up as many
> ::of the supporting functions of "strong" crypto as possible, and issue
> ::them in a set of commonly-available libraries for any and all programmers,
> ::along with source code, then an application programmer (theoretically)
> ::could order up some of these libraries and write some useful crypto code
> ::in short order.

>         one of the best proposals in many years --we have all made good
>     use of library code over the years, unless the simpleton coder has a
>     obsessive-compulsive masochistic need to write an extra 20-50,000
>     lines of 'reinvent the wheel' code.

[remaining text deleted]

I wouldn't bother the list with this kind of suggestion except that,
since so many subscribers feel the situation of freedom -vs- the new
federal urgency to shut down crypto is getting desperate, I urge a
desperate solution, i.e., an unparalleled level of cooperation.

As a personal preference, assuming no government involvement, I would
recommend more creativity and choices, but....

I agree wholeheartedly.  In fact, to make it easier to find
libraries, I created a page with links to 7 libraries with at least
one pubic key system & one private key system included.

www.homeport.org/~adam/crypto

	The tools are out there.

Adam


attila@primenet.com wrote:
| In <328E8BEC.2D76@gte.net>, on 11/16/96
|    at 07:52 PM, Dale Thorn <dthorn@gte.net> said:
| 
| ::Point 2: I've said something like this before, but here's a place where
| ::it could mean something.  If c-punks and others could divvy up as many
| ::of the supporting functions of "strong" crypto as possible, and issue
| ::them in a set of commonly-available libraries for any and all programmers,
| ::along with source code, then an application programmer (theoretically)
| ::could order up some of these libraries and write some useful crypto code
| ::in short order.
| ::
|         one of the best proposals in many years --we have all made good
|     use of library code over the years, unless the simpleton coder has a
|     obsessive-compulsive masochistic need to write an extra 20-50,000
|     lines of 'reinvent the wheel' code.
| 
|         there are several linkable libraries floating around, with
|     multiple types, etc.  the only one I looked at a couple of years
|     ago needed some extensive work on its calling and return
|     conventions --ever hear of structures?


-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

In a note to cypherpunks, Hal Finney comments on the new crypto
initiative:
>
>It's also not clear what the hardware manufacturers get out of this.
>Their sales overseas have never been blocked.  There has been no demand
>for custom crypto hardware.  I don't see how they have been harmed by an
>inability to ship computers with built-in encryption hardware.  Granted
>there are some possible applications for such systems but I don't see the
>market demand which would drive this decision.
>

I'm not sure if I can answer this but, at last week's SF cypherpunks
meeting, an Intel engineer asked whether there might be any interest
in a computer chip with some sort of encryption mechanism built
into the chip. As I understand it, this chip would process an
encrypted instruction stream. I.e., it could not execute a program
unless the "key" for that program was first loaded into the chip.

An interesting idea: does anyone have more information?

Martin Minow
minow@apple.com

Martin Minow <minow@apple.com> writes:
> In a note to cypherpunks, Hal Finney comments on the new crypto
> initiative:
> >
> >It's also not clear what the hardware manufacturers get out of this.
> >Their sales overseas have never been blocked.  There has been no demand
> >for custom crypto hardware.  I don't see how they have been harmed by an
> >inability to ship computers with built-in encryption hardware.  Granted
> >there are some possible applications for such systems but I don't see the
> >market demand which would drive this decision.
> >
> 
> I'm not sure if I can answer this but, at last week's SF cypherpunks
> meeting, an Intel engineer asked whether there might be any interest
> in a computer chip with some sort of encryption mechanism built
> into the chip. As I understand it, this chip would process an
> encrypted instruction stream. I.e., it could not execute a program
> unless the "key" for that program was first loaded into the chip.
> 
> An interesting idea: does anyone have more information?

It is a dangerous idea.  I speculated on this on the list some time
ago.  What we don't want is a clipper CPU which is using skipjack to
decrypt the instruction stream at run-time.  It opens up all sorts of
flexibility for GAK, software copyright protection, and means that
people won't be able to see what code they are running on their own
CPU.

I think it would be a negative technology from a cypherpunks
perspective, particularly if the USG has anything to do with it.

Adam
--
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`