RE: Mass-market crypto phones

_______________________________________________________________________________
From: Adam Shostack on Fri, Nov 22, 1996 1:21

>

>	I'd just like to second what Lucky wrote at the end of his
>very nice summation of the crypto phone hardware issues.  Eric's phones
>have damn good voice quality in secure mode.

I should probably make it more clear that my comment referred to price, NOT
quality.  I'm sure it is a wonderful product (I haven't tried it myself),
but I believe the price tag was at or around $1000.  My comments on the 
hardware used was for demostration purposes, not for saying anything was
wrong with the design strategy.  In fact, I thought it was a perfectly fine
strategy, and easy(ish) to implement.  Basically, it took the dedicated
computer you would need for phone encryption and put it in a cheaper box.

To be honest, I thought he had a good idea.  I just wouldn't want to pay
$1000 for phone encryption.  But, it's rare I have conversations where I
need that much security.  I'm sure the product is worth it; it's just out
of my price range.  And probably out of the price range of the average user.

PM

USER ERROR: REPLACE AND STRIKE ANY KEY WHEN READY

On 22 Nov 1996, Mullen Patrick wrote:
> To be honest, I thought he had a good idea.  I just wouldn't want to pay
> $1000 for phone encryption.  But, it's rare I have conversations where I
> need that much security.  I'm sure the product is worth it; it's just out
> of my price range.  And probably out of the price range of the average user.

It was a good idea. It just is facing some very hard engineering 
challenges. Using software based voice encryption products 
may work for you. By all means, do give them a try. PGPfone has a codec 
for use with an ISDN or better. If you have such a fast line, the voice 
quality is fine. Note that a fast IP connection may or may not suffice. 

Here is why:

Other than bandwidth, the other essential property of the link is constant 
and preferably low delay. I did not mention this in my original 
tutorial, since this
1. We were assuming use over a regular POTS, which already has fairly 
constant delay.
2. There is nothing any codec can do to make up for variable delays.

The reason is simple. If the delay is not constant, such as if you are 
sending UDP packets over the Internet new problems arise. One packet 
may take 50ms and the next packet may take 250ms, if it doesn't just get lost along the 
way. Packets may also arrive out of sequence. One might think the answer 
to this is simply a large buffer at the receiving end. Make the buffer 
large enough, to be reasonably sure that the packets will all be there, say 
500ms. Assuming no other delays, that would mean that you have a 1/2 
second delay between the person saying a word and you hearing it. 
Multiply this by two, since the other side would have the same buffer, 
and you have 1 second delays. Too long for a conversation. And then there 
is echo cancellation. But I'll spare you this. ;-)

--Lucky