RE: pcanywhere encryption

[hermit1 <hermits () mac com>]

Other documentation claims that pcAnywhere generates two (2) public and two 
private keys at the beginning of each session, one set by each 
end.  Apparently I just took the statement about generating "a unique 
public key" too literally.  Since I think I do understand the ideas behind 
public key encryption (one of my professors made us to the math, long ago), 
I couldn't understand how one unique public key could be utilized safely, 
so I figured that pcAnywhere was either doing something other than what the 
manual said or its encryption method was incredibly unsecure.

hermit1


At 12:57 PM 1/27/01 -0500, Ben.Grubin () guardent com wrote:
>  >
> > I wouldn't bother people with this, except Symantec tech support claims to
> > know nothing about how their encryption works.  (Actually, they claim 
> their
> > product does not do encryption, it merely passes the data to Microsoft
> > programs for encryption when appropriate.  Doesn't that make you feel 
> safe?)
>
> It's what Microsoft's Crypto API was designed for.  There is quite a
> selection of perfectly reasonable algorithms that plug in.
>
> >
> > My organization is looking into ways of expanding remote access
> > capabilities.  One program we are trying is pcAnywhere from Symantec.  The
> > documentation claims there are 4 levels of encryption available:
> > 1.  None  -  Symantec recommends against using this
> > 2.  pcAnywhere  -  Symantec also recommends against using this
> > 3.  Symmetric key  -  recommended
> > 4.  Public key  -   recommended as stronger than #3.  But as near as I can
> > tell, this has the same level of encryption as #3 except you need a
> >  certificate setup to use it.
> >
> > For symmetric keys, the manual states "pcAnywhere generates a
> > unique public key and uses this key to encrypt and safely pass the
> > symmetric key used to encrypt the session."
> >
>
> Precisely.  My guess is #3 is just generating a public/private
> kepair, whereas #4 is able to utilize your existing X.509
> certificates.  Your certs might be more secure in that the keypairs
> it generates on its own might be of a low keylength.
>
> > Since there is no provision for selecting how the encrypted key
> > gets  decrypted by which client or server (there is no statement
> > about which end of the connection generates the keys), the only 
> conclusion I
> > can draw is that the "unique public key" can be decrypted by ANY
> > pcAnywhere host or client anywhere.  Well, I can draw another 
> conclusion that
> > both the public and private keys are sent at the same time, but that
> > procedure seems even more stupid than my first conclusion.
> >
>
> You don't seem to understand the nature of a public/private keypair
> or the persuant exchange.  The public key is not used for decryption.
>  It is used for ENcryption of the data destined for the host that
> sent the key.  That's why it's safe to send that key over the wire in
> the clear, which is precisely what happens.  Each side of the
> connection generates a public/private keypair, and sends the public
> key to the other side.  Now each side can use that public key to
> encrypt the data to the other, which posesses the matching private
> key.
>
> > Can anyone help out by explaining what Symantec is actually
> > doing to set up
> > encrypted sessions?  Symantec can't explain it.
> >
>
> That's because the manual already did.  They probably had no idea
> what you were asking.  Software support desks are inherently for
> those that can't read the manual.  Since you already did, you knew as
> much, if not more, than they did.
>
> Cheers,
> Ben

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards