Endpoint Encryption

The idea is pretty simple NetShare is supposed to encrypt files and DropBox is supposed to place the encrypted files on internet so they can be shared with friends.

The problem is also simple NetShare is decrypting the files as DropBox requests them and DropBox is sending the unencrypted files onto their website.

This is obviously a serious flaw in the PGP NetShare program and to fix it I told to bascially spend bla bla money on universal server just so I can tell NetShare to *block* decryption for DropBox.exe what?? Is that some kind of joke?

Looked at the PGPPrefs.xml and it contains the following lines:

      <key>applicationBlackListContent</key>
      <string></string>

      <key>enableApplicationBlackList</key>
      <false></false>

 

However no matter what I put in these XML values the blacklist will NOT activate.

I want to know what I must place into the XML file to cause Dropbox.exe to get blocked by NetShare.

I know its possible to do that its just a matter of knowing what to put into these boxes...

Can somebody help out?

My e-mail is:

uberfox@hotmail.com

Thanks!!

Come on throw me a bone here.... A bit of help would be nice...

I dont want to have to compile my own PGP binaries with a built in *FIX* for DropBox in my NetShare build....

 

We actually have a new release, Symantec Encryption Management Server (formerly PGP Universal Server) - SEMS - 3.3 and Symantec Encryption Desktop (formerly PGP Desktop) 10.3 which will be coming out very soon and it will have built in Dropbox support for Symantec FileShare Encryption (formerly PGP Netshare) where you can configure the settings on the Symantec Encryption Management Server for your consumer policies.

Hi Ben, I understood the question was more - Why can this not be supported in a un-managed environment. The problem is that PGP, or today, Symantec Encryption File Share (10.3.0) displays to the enduser a perfectly encrypted environment on all clients connected to the Dropbox account. All files on the clients are encrypted with 'File Share', but all files in the Cloud are unencrypted and transparent without the enduser being aware. This is at all no good and a security flaw in the software as the enduser gets no warning or any indication of that all his/her files are stored in transparent format in the Cloud. As you have specifically addressed Dropbox as a key integration function with Symantec Encryption 10.3.0 - why only in the Managed environment? In doing so, you probably fail to address the majority of customers - our SMEs - that use Dropbox as a filesharing/cross-office Cloud-storage, at the same time not wanting to spend time/effort and money on running their own Managed Environment for e.g. Symantec Encryption Platform. In Europe 98% of all business are SMEs.... We today sucessfully run File Share in Dropbox over a multitude of clients in different countries. All in an non-Managet Environment - BUT it requires a well trained behaivour of not running PGP-Services and Dropbox-Sync simultaniously. It's a bit too much "hands-on", but still the encryption platform is excellent with the key-infrastructure etc. However, having a Dropbox integration also in a non-Managed environmnet would be excellent - and probably a key-trigger function for your business. Any ideas or future plans on this? /M

Symantec Encryption Desktop 10.3 supports dropbox in an unmanaged environment.  It's just all policies have to be set locally as there's no server managing all the clients.  You can upgrade all your PGP Netshare endpoints and configure the dropbox option on there.  Here is the mention in the 10,3 changenotes:

 

 

 

Hi, I am not sure this is correct. I have installed Symantec Encryption version 10.3.0 as un-managed clients on three clients. The are all licensed for "File Share" (prev. PGP NetShare). When running both Dropbox and Symantec Encryption services in parallel, which should be the normal way of working I find that; - Files on all the clients are encrypted. - When logging onto Dropbox.com web account - Files are non-encrypted and transparent. Bringing up help&support in the Symantec Encryption 10.3.0 we read the following; The integration of Symantec File Share Encryption and Dropbox requires the installation of the following software: - Symantec Encryption Desktop, v. 10.3.0, on a managed client, licensed for Symantec File Share Encryption - Dropbox, v. 1.4.11 The software can be installed in any sequence. This is further understood if trying to install a viewer on an iOS-device, as e.g. Symantec's viewer requires you to enter login credentials for your Management Key Server.... So, please tell me about plans for integrating Dropbox with Symantec Encryption platform in a non-managed environment, which will potentially address a large market. /M

I know for a fact the Symantec File Encryptor only works in a managed environment, but the way I read those change notes that Dropbox would work with unmanaged clients, i haven't tested it mind.

I read the documentation as Symantec Encryption File Share works in a managed environment.

I can understand the added value in a managed environment, but not the reason for excluding the functionality in a non-managed environment. Would be relatively easy to add this function also for a non-managed environment. Well, together with some text or caution about end-users have to care themselves for using same set of keys and roles on all clients etc. But otherwise quite straight forward - and a huge market potential...

/M

 

 

I know that there is an answer to your question on blacklisting netshare.exe. I have seen it used before. Send me a private message on the forum here by clicking on my name PGP_Ben and sending me a message. I am not at work right now. But when I get your message I will research this for you.

Thanks

I have done so.

/M

Received?

 

OK I tested the new 10.3.

My files say they are encrypted but when I view them on DropBox website etc they are NOT encrypted.

I find this situation totally sickening and I'm greatly upset with Symantec for ruining PGP like this.

I have been told I must buy the managed PGP crap so I can block the dropbox exe from decrypting the file when sending it off to the internet.

BUY more stuff to get something that should just be working anyway? What maddness is this? Is Symantec becomming Adobe?.

EIther somebody provides me with a working solution to this problem immediately or I will transfer over all my files and drives and friends from PGP to one of the many alternatives (which do work with DropBox I might add).

Months ago when I first posted this I was cool about it hell I was happy when I was told a fix was comming in 10.3.

But 10.3 is here and there is still no fix I'm most unhappy about this.

Fix it ffs!

Does some crazy person think *normal* people don't use dropbox so it should be a corporate admin server bla bla to use dropbox and pgp?

I got news for you its not 1998 anymore... You will be hard pressed to find a single person who ISNT using dropbox on their phone/pc.

Why store all your valuable stuff on dropbox without encrypted it?

Currently i have to put my stuff in dropbox as .pgp encrypted files and virtual disks.

So much for easy and transparent protection huh.

Yea I'm pretty annoyed this isn't fixed for consumers only for corporations....

No answer in over 10 days? Even the president of the united states of america has enough time to answer a single question from a single individual in 10 days.

I found converting to GnuPG to be the most best solution since it does everything you need PGP for and has extensions that allow it to work with DropBox.

As a bonus its open source and you can compile it yourself knowing there is no backdoors and you can set it to create RSA keys such as the epic 16,384 BIT and there is a source mod to give it AES-512 encryption.

So this inaction and lack of user friendliness by PGP has caused me to sit around and sweat for months and finally take action into my own hands and find an alternative product that actually *works*.

Thanks for nothing.... I wasn't asking for miracles here just a way to use DropBox with PGP.

I will reconsider PGP when it supports 16,384 BIT RSA keys and DropBox (AES-512 would be great too).

AES-512 is a pointless encryption protocol.  Even 256 is completely uncrackable from a brute force perspective.

I'm aware of the strength of AES-256.

However just remember the days when 56-bit encryption was seen as uncrackable and impossible with any amount of computing power... Today computers crack that in 30 seconds.

Who is to say AES-256 is going to remain computationally unfeasible in the future? At least AES-512 is overkill and overkill is what you want when it comes to security and privacy.

The weaklink in PGP is the RSA not the AES (technically) I think it would be wise for PGP to incorporate up to 16,384 BIT RSA keys just to be future proof for a long time coming.

I know a LOT of organizations are still using 2048 bit keys but I wouldnt trust a 2048 bit key.

I belive 1024bit keys have been cracked by the NSA I'm sure 2048 is safe for time being.

I want to feel safe for a lengthy future 16,384 bit would provide that confidence due to the insane computing power required to crack it.

PGP seems slow to adapt to change where as other products tend to stay on edge I personally like PGP the best and I do hope they fix DropBox for consumer not just Enterprise customers (which they did) and add higher RSA keys in.

And still nobody has given me a fix for PGP and DropBox..... Still waiting on that.... Yup...

I understand your frustration regarding using PGP with DropBox.  I wish I had a good answer for you.

I do want to comment on your use of large RSA key sizes.  I would recommend instead that you use a P-521 ECC key.  A 521-bit ECC key has equivalent strength to a 15360-bit RSA key.  (Source:  http://www.nsa.gov/business/programs/elliptic_curve.shtml)  ECC keys are also a better choice for resistence against quantum computing attacks.

You can't yet generate an ECC key using Symantec Encryption Desktop, though such keys should be fully supported (you can import and use such a key that you generated using PGP Command Line or GnuPGP). Creation support will be turned on in a future release, once adoption of products that support ECC keys is a little more widespread.

Regards,

 

Thats interesting! I always knew the weaklink was the RSA wanted a way to improve it but you say the 521-bit ECC is as good as a super size RSA? I didn't know that.

I got the command line tools and generated a like key:

pgp --gen-key "UberFoX <uberfox@hotmail.com>" --key-type ECC --encryption-bits 521 --passphrase changeme --signing-bits 521

Is this correct? It seems to generate the key instantly.... Where as 16,384 bit RSA key would take 10 minutes to generate....

Does that mean I did something wrong? Or what is happening here?

Also how do I generate a seperate sign and encryption for the ECC key? Its bad form to use the same subkey for both jobs.

Yep, that's pretty much it.  And yes, an RSA key that large takes a _long_ time to generate (you need to find some pretty big random prime numbers), but the much smaller ECC key can be generated much more quickly.

You get an ECDSA topkey for data and userid signing, and a separeate ECSVD (Shared Value Derivation) subkey for encryption (similar to DSA/DH keys).

In theory you should be able to generate the key with a separate ECDSA signing subkey, or create one after the fact.  However, when I try to do that, I'm getting an error... something I'll look into.

Regards,

This is true, when quantum computing comes out of the laboratory into reality, Encryption needs to be mighty quick in order to change, as a quantum computer can crack anything that current encryption standards throws out