From: Sean Roach <roach_s@alph.swosu.edu>
Date: Fri, 22 Nov 1996 11:51:01 -0800 (PST)
To: Clay Olbon II <cypherpunks@toad.com
Subject: Re: Mass-market crypto phones
Message-ID: <199611221950.LAA15906@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


At 09:10 AM 11/21/96 -0500, Clay Olbon II wrote:
>A while back, Eric Blossom posted a URL for a mass-market, phone encyrption
>device (http://www.comsec.com/).  The point of this post is to posit a
>scenario based on the implications of this product.  This is speculation
>based on where I think such products should be heading.
>
>I think we need to keep a couple of goals in mind.  The first, is to get
>encrypting phones (or phone add-ons) into Wal-mart, K-mart, etc (where
>probably most Americans now buy their phones).  The prices need to be low
>enough that people will want to buy them (<$100?).  Is this technically
>feasible?  The comsec device from the above URL already demonstrates the
>needed capability.  Is the cost target possible?  My guess is soon, given
>the lowering costs and increasing capabilities of current processors.
>
>The second goal needs to be to push a similar product for cell-phones.  I
>think this will be perhaps an easier sell, given the higher initial cost for
>these phones, and their reduced security.  Perhaps a home device could be
>sold with the cell-phone as a package deal, so that communications with the
>"home base" (i.e your office, home, etc) would be secure.  With the rapid
>growth in cell-phone sales, selling a package such as this might ensure a
>larger user-base of home devices.
>
>Given that these goals are met, I think widespread use of crypto over phone
>lines would become almost inevitable.  However, the fun part would be the
>introduction of such products.  The FUD coming from police, the government,
>etc. would be amazing to behold.
>
At first this seemed to be a challenging goal as public key encryption (at
least the type of which I am aware) requires a public key ring, but then I
thought, what would be the point in real time communitation?
Here is my idea.
The initiating phone sends a public key to the receiving phone.
The receiving phone takes this public key and uses it to prepare the session
key, or perhaps both session keys (one key for each simples circuit), as in PGP.
Both boxes would need to have hybrid circuits in them like the telephone
company uses to filter out the incoming signal from the outgoing signal.
The telephone amplifiers only amplify half of the signal, so it basically
consists of two simplex circuits from the local trunk to the other trunks.
This could be bypassed if the device set between the base and the handset.
Best would be to have the hybrid circuit so that it could work with the more
basic models.
I can only see two problems.
The first problem I can see right now would be randomization, (line noise
sampling?, hold the microphone close to a radio playing static until the LED
starts flashing?)
The second challenge would be getting public key encryption to work with an
analog system.  The device will have to have two analog to digital
converters and two digital to analog converters.  I believe that the
telephone operates with a carrier of about 3000 Hz, thus the box will
probably need to maintain a sampling rate of 1500 Hz or less, if this
frequency will carry voice.  The system will probably need some form of
run-time compression built in as well as sample voice at a low bit depth.
The result, under ideal circumstances will probably be a tinny sound and
loss of fidelity.
The D-A, A-D pair on the telco side could be replaced by a good modem, this
would eliminate some of the problems of the RBOC filters cutting out the
"noise" which would really be signal.
If you set the sampleing rate at 3000 cycles per second, by 8 bits of depth,
you would need to be able to transmit clearly 3000 * 8 bits per second or
24000 bits per second.  That would be 24 KiloBITS per second, about 1/8th
the 28.8 KiloBYTE modems that are commond today.  A 3000 baud modem should
be both cheap and easy to pack into a small package.  This would probably
allow for no compression at 8 bits of sampling depth.
So, the block diagram would be as follows.
                ________________     _______________     ___________
|
                |              | --> |             | --> |         |  Line
to       |
 Line from RBOC | 3000+ Baud   |-----| Public Key  |-----|A-D /D-A |
Telephone     |
----------------| Full Duplex  |     | Encryption  |     |  Pair
|--------------  |
   <--->        | Modem        |-----| Layer       |-----|         |
<--->       |
                |______________| <-- |_____________| <-- |_________|
|



I was thinking that the device could be built into a case about the same
size as a modem or answering machine, possibly a little taller to accomidate
the modem circuit, should a full duplex modem replace the telco end A-D, D-A
pair.
Unfortunately, I have very little experience with circuits.  I can't even
draw out an asyncronis multivibrator right now.  (That is a square wave
generator involving 2 transistors, 4 resistors, and 2 capicitors, not a toy
based around a motor with an off center weight)

P.S. The line on the far right is for alignment, If this line is crooked,
copy and paste the diagram to a standard ASCII editor.  this should
eliminate the pipes and spaces from being shorter than every thing else.