// COMPLETE THREAD

No Subject

4 expanded posts ยท every known parent and child

NODE aab1ca3bNo Subject
[ The purpose of this post is to propose an extension of PGP which
  would result in more widespread use of encryption by the public;
  and to provoke discussion about the pros/cons of said proposal ]

  PGP users (mostly, technically adroit e-mail types) are but a
  subset of computer users in general; who in turn are but a subset
  of persons engaging in electronic communication of all kinds (including
  the common telephone); all of whom can be legitimately concerned with
  privacy issues.  If the powers that be are concerned about not being
  able to listen in on PGP users, at least they can take solace in the
  fact that PGP users constitute only a tiny fraction of the populace,
  and hence, in the "big picture", add up to little more than a slight
  irritation. 

  I am proposing that PGP be expanded beyond its present cadre and into
  the 2nd group named above - the army of regular users of pc's equipped
  with data modems.

  The proposal specifically is to extend PGP beyond file encryption
  to generalized stream handling.  Such streams can be consoles &
  keyboards, real-time file transfers, and digitized voice; indeed,
  anything that will pass over a modem or other serial transfer medium.

  In this scenario, a user wishing a secure interchange would simply 
  place a voice call to another party and, upon establishing voice
  contact, request a transition to a modem connection.  Upon invoking
  the new program, the user's modem would go online; it would read the
  party's key from the existing PGP pubkey ring, and use it to perform
  a DH exchange, establishing a secure session.  The program would then
  use a packet protocol to exchange keyboard/console traffic and/or files.
  In one scenario, all key management would continue to be performed with
  the current PGP program; the pubkey ring would be 'read-only' from the
  standpoint of the new app.  Alternatively, key management could be
  blended into the new app to form a true standalone application.

  The appeal behind this approach is that it moves the operational 
  paradigm very close to the present one- namely "pick up the phone
  and dial".  No logins, shells, Elm, Compuserve/Prodigy/FidoNet, etc.
  The user interface could be simple enough for even the most novice
  user to operate.

  Real-time voice encryption would obviously be desirable in lieu of
  a keyboard interface.  Unfortunately, such a capability is not yet
  within the reach of the average pc.  Within a few years it will pro-
  bably be a "done deal", given the movement afoot to put DSP chips
  in all new pc's (e.g. video compression, multimedia support, etc). 
  For now it must suffice to build a solid technical foundation which
  can accommodate voice operation when the requisite hardware becomes
  available.  And until that time, many more users will have access to
  convenient and handy encryption technology.

  [ An aside, WRT voice coding:  I believe the first major opportunity
  to produce a cheap realtime digital voice channel will be the emergence
  of chips/chip sets targeted towards the growing market for digital
  (tapeless) telephone answering machines.  This market is large, and very
  cost sensitive (the perfect combo for opportunistic techno-vultures);
  this should produce cost effective voice coding solutions within a
  short period of time (12 months?), given current technology levels. ]

  Many readers already know that the pieces required to build this new
  program are already in place- and could be drawn together without much
  fuss.  Indeed, a few fledgling attempts have already been made. From the
  PGP sources, the necessary functions would be extracted- to perform key
  lookup, MP arithmetic, DH key exchange, IDEA encryption of comm packets,
  etc.  The resulting library would be linked to the new comm application.
  Each subsequent revision of PGP would retain a make target that would
  build the interface library. 

  The net result of building this application would be to make serious
  levels of security available to more people than ever before - with an
  ease of use also heretofore unknown.  As a result I believe the PGP
  user base could easily expand by at least an order of magnitude.

  Does anyone have a better idea?
  [END]
NODE eebac69ePGP voice encryption
Actually, if somebody wants to start developing PC based voice encryption,
there's a pretty significant installed base of machines that can handle it
already.  By the end of 1992, there were about 3 million machines with sound
cards, by the end of 93 it's projected to reach 6 million.  Anyone that has a
Soundblaster or Soundblaster compatible has both a DAC output and a
microphone input.  On a machine with a 9600 or 14,400 kilobaud modem,
sufficient real-time compression of voice to fit within the modem bandwidth
is a quite reasonable objective.  I know of at least three people in the
computer game industry that have been working on it, and at least one of them
already has functional code.  I'm sure there's a pretty fair number of
Macintoshes out there that have all the hardware to support real-time
encrypted voice communications also, though I don't follow the numbers in the
Mac market these days...
                               Dr. Cat / no .sig, why bore people?
NODE 425da805Re: PGP voice encryption
> 
>    Actually, if somebody wants to start developing PC based voice encryption,
> there's a pretty significant installed base of machines that can handle it
> already.  By the end of 1992, there were about 3 million machines with sound
> cards, by the end of 93 it's projected to reach 6 million.  Anyone that has a
> Soundblaster or Soundblaster compatible has both a DAC output and a
> microphone input.  On a machine with a 9600 or 14,400 kilobaud modem,
> sufficient real-time compression of voice to fit within the modem bandwidth
> is a quite reasonable objective.  I know of at least three people in the
> computer game industry that have been working on it, and at least one of them
> already has functional code.  I'm sure there's a pretty fair number of
> Macintoshes out there that have all the hardware to support real-time
> encrypted voice communications also, though I don't follow the numbers in the
> Mac market these days...

The biggest problem is CPU power.  The compression schemes that work
best are very computationally expensive.  Add to that the fact that
you need to do simultaneous encryption and compression, and if you
want full duplex make that simultaneous encryption, decryption,
compression and decompression.   You also have to send it over the
modem, and probably frame it too.

I'm currently implementing one scheme (LPC) on a DSP chip.  Hopefully
my end product will be <$50.  I plan put its own ADC/DAC chip on
board (to save computer<->DSP bandwidth).  Possibly some
high end CPU's like 486 and 040 could handle the load, but
wouldnt leave much cpu for anything else.
 

>                                Dr. Cat / no .sig, why bore people?
>
NODE 34607dcdRe: your mail
-----BEGIN PGP SIGNED MESSAGE-----

:)   The proposal specifically is to extend PGP beyond file encryption
:)   to generalized stream handling.  Such streams can be consoles &
:)   keyboards, real-time file transfers, and digitized voice; indeed,
:)   anything that will pass over a modem or other serial transfer medium.

This is already being attempted: Ytalk version 2.1 has both a single key
stream encryption feature and a PGP encryption feature ( I haven't been able
to get the PGP encryption feature to work, however.). It is still in beta
testing, but it looks like it will be out soon...

Skye
- --
- -----====> Skye Merlin Poier <====----- 
Undergrad in CMPT/MATH (Virtual Reality)       ||||      ||||
          email: poier@sfu.ca                  p-OO <--> OO-q   THINK
   PGP Public Key available on finger           \==      ==/


-----BEGIN PGP SIGNATURE-----
Version: 2.2

iQCVAgUBLAJrzy0bkpXW3omvAQEwZQQAobdu4F3v9rGfeKTrWTwz0CgLHGj9j1eJ
FTecY3x4H3h4hra3QpztpwidizyOvvbyeJFrPZc0k+lJxYjFkLduiI7F9GpL+jSe
ha10iPcRDUcKxJ74nyVWTupLpnznbYmZaQ7eh7BJi3GNo6M2GeUgccPt7j47F+Fy
lzSvE05eYJw=
=bvHZ
-----END PGP SIGNATURE-----