Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
General
GeneralPortable MacsHardwareNetworking
Applications
Mac ApplicationsEudoraFirefox / MozillaInternet ExplorerOutlook ExpressMS OfficeEntourageExcelPowerPointWordVirtual PCMedia PlayerOther MS Products
Programming
Mac ProgrammingCodeWarriorPerl
Country Specific
Australian Mac GroupUK Mac Group

Mac Forum / General / Networking / September 2004



Tip: Looking for answers? Try searching our database.

encryption vs. scrambling

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Timothy Miller - 22 Sep 2004 16:30 GMT
Good morning,

In a couple of previous threads, I've asked about possibilities for
encrypting the audio and/or video portion of videoconferences. I sort of
struck out, except for Skype, which offers an encrypted audio and text
instant messenger application. It's intended primarily for increasing
the security of voice over IP phone calls.

I wondered why products like those I seek aren't available.

Further inquiry reveals that audio and/or video encryption would likely
bog down the CPU and overwhelm the bandwidth of a DSL connection.

Agree?

This raises the distinction between encryption and scrambling. If I'm
not mistaken, encryption usually implies public key encryption. It's
pretty secure and neither user needs to know the other user's password.
It demands a lot of the CPU and multiplies the number of packets needed
to send the same message.

So, maybe I'm looking for "scrambling" cabability in video conferencing.
If I've got the terminology right, scrambling means both users would
employ the same previously chosen password. The scrambling code could be
more easily broken, but it would still be way more secure than an
unscrambled videoconference. Scrambling the audio and/or video and/or
text portions of the conference would require far less CPU overhead and
would not have much effect on the bandwidth needed to send the data back
and forth.

Did I get this right?

If there is no way to encrypt the audio and/or video in a
videoconference, is there a way to scramble it?

Alternately, how hard would it be to write a utility to do something
like this? Like if I wanted to hire someone to write such an utility? It
would scramble the audio and/or video on the local machine, before it
reached the videoconferencing app. Accordingly, it might work with a
variety of audio/video conferencing applications. I imagine off the
shelf scrambling algorithms are available. If some utility like this is
available for Linux, it might not be too hard to port it to OS X.

Thanks in advance,

Tim
Thant Tessman - 22 Sep 2004 17:53 GMT
[...]

> This raises the distinction between encryption and scrambling. If I'm
> not mistaken, encryption usually implies public key encryption. It's
> pretty secure and neither user needs to know the other user's password.
> It demands a lot of the CPU and multiplies the number of packets needed
> to send the same message.

Usually, public-key encryption (which is very computationally expensive)
is used to send a private key which is subsequently used to do what you
call "scrambling" (which is not computationally expensive). If you
really want to know about this stuff beyond using someone else's VPN
software, read "Applied Cryptography" by Bruce Schneier.

-thant
William Goedicke - 22 Sep 2004 18:13 GMT
Dear Timothy -

>>>>> "Timothy" == Timothy Miller <noname@nospam.com> writes:

   Timothy> I've asked about possibilities for encrypting the audio
   Timothy> and/or video portion of videoconferences.  I wondered why
   Timothy> products like those I seek aren't available.

It sounds like you want an ssh/ssl tunnel.  
See http://rsug.itd.umich.edu/software/fugu/

   Timothy> Further inquiry reveals that audio and/or video
   Timothy> encryption would likely bog down the CPU and overwhelm
   Timothy> the bandwidth of a DSL connection.

   Timothy> Agree?

No.

   Timothy> This raises the distinction between encryption and
   Timothy> scrambling. If I'm not mistaken, encryption usually
   Timothy> implies public key encryption. It's pretty secure and
   Timothy> neither user needs to know the other user's password. It
   Timothy> demands a lot of the CPU and multiplies the number of
   Timothy> packets needed to send the same message.

   Timothy> So, maybe I'm looking for "scrambling" cabability in
   Timothy> video conferencing. If I've got the terminology right,
   Timothy> scrambling means both users would employ the same
   Timothy> previously chosen password. The scrambling code could be
   Timothy> more easily broken, but it would still be way more secure
   Timothy> than an unscrambled videoconference. Scrambling the audio
   Timothy> and/or video and/or text portions of the conference would
   Timothy> require far less CPU overhead and would not have much
   Timothy> effect on the bandwidth needed to send the data back and
   Timothy> forth.

   Timothy> Did I get this right?

No.  Your description of "encryption" is fairly OK albeit a little
simplistic (often a good thing).  But what you call "scrambling" is
better refered to as "symmetric key" encryption.

Difficulty to decrypt is independent of which type of encryption you're
using.  It is true that encrypting things so they're harder to decrypt
requires more CPU cycles.

Hope this helps.

    Yours -      Billy

============================================================
    William Goedicke     goedicke@goedsole.com            
    Cell 617-510-7244    http://www.goedsole.com:8080      
============================================================

         Lest we forget:

use XML::Simple;
use DBI;
use LWP;
use Graph;

        - William Goedicke
Timothy Miller - 23 Sep 2004 16:28 GMT
> Dear Timothy -
>
[quoted text clipped - 6 lines]
> It sounds like you want an ssh/ssl tunnel.  
> See http://rsug.itd.umich.edu/software/fugu/

Thankya, William,

I looked at the Fugu site. I partly understand it... I think.

Is there a comparable and compatible product for Windows XP? (seems
likely...)

Is this really as easy as it sounds?

In my long and exasperating history  as a computer user, nothing is ever
as easy as it sounds -- because I'm basically a non-technical user.
Computering isn't my job, it isn't my hobby, and I have no tech support
department to turn to. I'm a sole proprietor.

Does Fugu require a ssh-capable router? If so, how many consumer-level
routers have that capability? Is tricky router-configuring also necessary?

Thanks,

Tim
Frédérique & Hervé Sai nct - 22 Sep 2004 18:35 GMT
(...)
> If there is no way to encrypt the audio and/or video in a
> videoconference, is there a way to scramble it?

I won't be of any help to advise or develop scrambling plugins for
videoconferences, but if you don't find any solution you may wish to
consider VPNs (virtual private networks).

By establishing a VPN between you and your partners you may use almost
any videoconf app (the ones that allow you to connect directly to your
correspondent) through the VPN.

Incidentally, this would also allow to test the theory according to
which video throughput being encrypted will bog your CPU down :-)

Hervé

Signature

Frédérique & Hervé Sainct, h.sainct@laposte.net
Frédérique's initial is missing in front of the above address
l'initiale de Frédérique manque devant l'adresse email ci-dessus

Kevin McMurtrie - 23 Sep 2004 07:03 GMT
> Good morning,
>
[quoted text clipped - 16 lines]
> It demands a lot of the CPU and multiplies the number of packets needed
> to send the same message.

Not really.  There are many forms of encryption, some of them use little
CPU time while still being secure enough for most uses.  Essentially the
encryption algorithm looks like this:

key -> code generator -> mixer <-> encrypted data
            plain data <--^

The mixer has to be good enough to not reveal the plain input data or
encryption codes, even when the input data contains obvious patterns.  
It usually does this by spreading the data over a wide area so patterns
are obscured.  The code generator has to be good enough that a
reasonable number of past cracked codes does not lead to the prediction
of future codes or key regeneration.

The most secure encryption algorithms are not only good technically, but
they are so computationally expensive that guessing the decryption key
is not practical.  Less secure encryption algorithms have much higher
throughputs so it is more possible for somebody to guess the key with
brute force guessing.

> So, maybe I'm looking for "scrambling" cabability in video conferencing.
> If I've got the terminology right, scrambling means both users would
[quoted text clipped - 6 lines]
>
> Did I get this right?

No.

> If there is no way to encrypt the audio and/or video in a
> videoconference, is there a way to scramble it?
[quoted text clipped - 10 lines]
>
> Tim

MacOS X comes with the SSH utilities.  One of its features is tunneling
a port of TCP data over the encrypted socket.  The throughput is very
high, it supports compression, and it's reasonably secure when some
precautions are taken.  The encryption can be handled by separate
machines if each side has a secure LAN.  Look at the -L and -R options
of ssh.  For using separate encryption machines on a secure LAN, look at
the -g option.
Timothy Miller - 23 Sep 2004 16:12 GMT
>>Good morning,
>>
[quoted text clipped - 8 lines]
>>Further inquiry reveals that audio and/or video encryption would likely
>>bog down the CPU and overwhelm the bandwidth of a DSL connection.

Hi,

Okay, thanks to all on this thread. I won't bother you no more. It looks
like I'm out gas, pending the development of new technology or a new
product.

A couple of comments. I did some reading about ssh tunneling and VPN.
For instance, Steve Jobs wrote a few pages on these topics in "the
missing manual" for OS X. It didn't seem very encouraging. Jobs
indicated that these technologies are not really suitable for the
non-technical user. Plug and play they are not.

One method -- I can't remember which one -- maybe both -- requires a
server, or at least a router, that supports the technology. Some routers
enable it, many don't. One method-- maybe both -- is intended primarily
for large servers with many users, not one-on-one relatively casual
communication. No user friendly GUIs for either. Maybe a user friendly
GUI will turn up eventually.

I could probably figure out how to use one or the other, but most of my
clients would not be very geeky. They will have figured out how to
video-conference. They might have figured out how to port map their
DSL/Cable routers to enable videoconferencing. That would be their max,
technically, with occasional exceptions. They would not be motivated to
geek around a lot more so they could videoconference securely with me.

For my mad scheme to work, I have to make it easy for my clients. So
neither ssh tunneling nor VPN sounds very promising.

If I've misunderstood or overlooked the obvious, please toss me a clue
before I sink into the sea of ignorance for the last time.

Unless something unexpected happens, I'll return to the default plan.
I'll use Skype, a new VOIP and IM application that encrypts text and
audio. I'll simultaneously employ unencrypted video over a separate
channel. (Skype doesn't support video.) If the CPU and home-user
broadband are adequate, that will be okay.

If that doesn't work, I'll use a conventional telephone connection for
the audio, plus unencrypted video. My professional associate considers
conventional telephone connections acceptably secure.

(BTW, that seems ridiculous to me. Eavesdropping on another telephone in
the same home, simple telephone bugging devices, telephone company
technicians and operators, etc., are all easy procedures. Not to mention
eavesdropping on cordless phones, cell phones, etc.)

Someone warned me that unencrypted video could be insecure because of
the possibility of lip-reading. Interesting point. I suspect a slighly
slow or jerky frame rate would make lip reading impossible.

BTW, the hypothetical exchange of a symmetrical key would be done by
telephone or encrypted IM or something like that. That seems reasonably
secure.

Cheers,

Tim
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.