1996-11-22 - RE: Mass-market crypto phones

Header Data

From: Lucky Green <shamrock@netcom.com>
To: Mullen Patrick <Mullen.Patrick@mail.ndhm.gtegsc.com>
Message Hash: d5610940d85c805833a189fe236c89c38ac6b9c41b32147cb7d6f3524008642b
Message ID: <Pine.3.89.9611221147.A7402-0100000@netcom6>
Reply To: <n1363459702.71040@mail.ndhm.gtegsc.com>
UTC Datetime: 1996-11-22 19:47:27 UTC
Raw Date: Fri, 22 Nov 1996 11:47:27 -0800 (PST)

Raw message

From: Lucky Green <shamrock@netcom.com>
Date: Fri, 22 Nov 1996 11:47:27 -0800 (PST)
To: Mullen Patrick <Mullen.Patrick@mail.ndhm.gtegsc.com>
Subject: RE: Mass-market crypto phones
In-Reply-To: <n1363459702.71040@mail.ndhm.gtegsc.com>
Message-ID: <Pine.3.89.9611221147.A7402-0100000@netcom6>
MIME-Version: 1.0
Content-Type: text/plain


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





Thread