RE: pcanywhere encryption

["Hackett, James" <James.Hackett () cwcom co uk>]

Hi, 

I ha've had some deals with pcanywhere, the problem is not the encryption
the problem is the authentication and audit logging.I found was it uses the
NT authentication for users. If you are not allowing admin access to the
machines that would be ok, as you can create seperate user profiles and
logging. If you are like some people want to use it for remote-admin you
open a can of worms in the sense all machines in the domain are open to
attack by, an ex-employee or malicous user. I leave the rest up to everyone
to see what the problem is.

Can some prove that I am wrong ?




> -----Original Message-----
> From: hermit1 [SMTP:hermits () mac com]
> Sent: 29 January 2001 16:11
> To:   Ben.Grubin () guardent com; firewall-wizards () nfr net
> Subject:      RE: [fw-wiz] pcanywhere encryption
>
> 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

**********************************************************************
This message may contain information which is confidential or privileged.
If you are not the intended recipient, please advise the sender immediately
by reply e-mail and delete this message and any attachments
without retaining a copy.  

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