[Djigzo users] Customer experience

Martijn Brinkers martijn at djigzo.com
Wed Jun 17 22:42:53 CEST 2009


Hi Eamonn,

I forgot to comment on the PDF password length.

You are right in that the PDF encryption is less secure because the 
password has to be long enough to withstand an off-line brute-force 
attack. The length of the generated password can be set under the 
advanced settings. The longer the better but less user friendly. The 
generated password is encoded using base32 (A-Z and six digits 2-7) . 
The main advantage is that it's easier to read for humans and therefore 
less error prone (the 1 is not used so it cannot be misread as the 
letter l).
If you require 128-bits of a random you have to set the password length 
to 16 (16*8=128) so that's a long password to type.
If your security requirements need 128-bits security it's better to use 
something like S/MIME.

Kind regards,

Martijn Brinkers

Eamonn McGonigle wrote:
> Hi Martijn,
> 
> I have been playing with Djigzo for a couple of months now and I think 
> it is fantastic...so let me start by saying thanks for your hard work on 
> it and for releasing it to the open-source community.
> 
> If you are looking for votes (!), I think #2 below is a real winner.  I 
> have been evaluating Djigzo in comparison to Cisco's Ironport for a 
> number of encryption requirements.  While the "gateway-to-gateway" 
> S/MIME capabilities of Djigzo are ideal, I also have a requirement for 
> clientless support which Ironport's PXE does very nicely (but at a steep 
> price).  There appear to be a few other products out there covering the 
> same ground (the ZixDirect at www.zixcorp.com and Trend Micro Private 
> Post from Trend Micro, to pick two examples).  The PDF encryption in 
> Djigzo doesn't meet the requirements because to achieve an adequate key 
> length would require typing in a password so long that users would never 
> find it acceptable.  I considered modifying your code to lengthen the 
> PDF encryption password and increase the "alphabet" from which password 
> characters were drawn but dropped the idea when I worked out how long 
> the password would need to be to achieve even 128-bit key strength.  I 
> would therefore be delighted to see Djigzo offer the kind of clientless 
> capability you outline.
> 
> If I may venture a suggestion, I would have a slight concern about the 
> idea that the encrypted blob is pushed up to the server where the 
> decryption key is stored for decryption.  I would suggest that it is not 
> ideal to have the decryption key and the encrypted content both on this 
> server.  I know Cisco's Ironport works slightly differently.  The user 
> receives the message in a HTML wrapper similar to what you describe 
> below. When he logs onto the server, a script in his browser downloads 
> the decryption key which is then used to decrypt the blob locally on the 
> user's PC (done by a bunch of Javascript code which comes down with the 
> HTML wrapper).  This approach has the advantage that the message content 
> is never actually stored on the key server...only the decryption key 
> (which is pretty useless without the message content).  I guess the 
> obvious counter-argument is that the message is encrypted on this server 
> in the first instance so uploading it again for decryption isn't a 
> dramatic dilution of the security (once the encrypted message content 
> isn't actually stored on the same server as the decryption keys). 
> 
> Best Wishes,
> Eamonn
> 
> 
> 
> Martijn Brinkers wrote:
>> Hi Dan,
>>
>> Dan Banach wrote:
>>   
>>>    Sorry it's taken some time to respond. We deal with a wide range of
>>> email recipients (large companies, small offices, individuals, etc.)
>>> with a wide range of email encryption knowledge, so the ideal encryption
>>> solution for us would be very flexible. Not only flexible for outgoing
>>> mail, but also incoming mail as well. Some users/business' use PGP,
>>> others use certs and some use the various other options. Being able to
>>> communicate with them all is very helpful.
>>>     
>> Right now now I'm working on Blackberry S/MIME support for BIS users 
>> (for BES users there is already S/MIME email). Once that is finished I 
>> will start working on new major features. There are some features I 
>> would like to start working on but I'm not sure which one that should be.
>>
>> Two main new features I was thinking about are:
>>
>> 1. PGP support
>> 2. Client-less email encryption
>>
>> Nr 1 is clear. I will briefly explain nr 2.
>>
>> Client-less
>>
>> Currently Djigzo supports S/MIME and PDF encryption. Recipients that do 
>> not want are cannot receive S/MIME or encrypted PDFs are currently not 
>> supported. The new encryption functionality I would like to add is the 
>> following:
>>
>> If an email sent to an external recipient needs to be encrypted and the 
>> recipient cannot receive S/MIME email of an encrypted PDF the email will 
>> be converted to a .html file. The original plain-text message (and 
>> attachments) will be encrypted with a certificate for the external 
>> recipient and added to the .html. The .html will be added to a general 
>> message (which does not contain any sensitive information) and sent to 
>> the recipient. The recipient opens the .html message in the email client 
>> (can for example be hotmail). The .html will open a SSL connection to 
>> the companies Djigzo server (which can be a dedicated server just for 
>> the portal). The Djigzo server will show a login page. The recipient now 
>> has to login. After the login the recipients browser will push the 
>> encrypted 'blob' (contained in the HTML) to the portal. The portal will 
>> decrypt the message with the private key of the recipient (which is 
>> stored on the companies Djigzo server). The recipient can now read the 
>> message and download any attachments (the portal uses SSL for secure 
>> access).
>> The main advantage is that the recipient only requires a browser. The 
>> encrypted data is stored locally on the recipients system (there is no 
>> long term copy on the Djigzo server). An attacker needs access to the 
>> locally stored .html file AND the portal password to read the message.
>> The message is encrypted with the same algorithm as a S/MIME message. 
>> The only difference is that it's encoded inside a .html file.
>> A disadvantage is that the Djigzo server needs to be accessible to 
>> external recipients.
>>
>>
>> Right now I'm leaning towards implementing feature 2 but it could be 
>> that you or any other Djigzo user has another preference or request for 
>> a feature. If so I'm all ears :)
>>
>>
>>   
>>>  I
>>> think another great feature you could include would be to grant internal
>>> users the ability to manage their own decryption profiles. They should
>>> be able to add/create there own certs/keys and create their own
>>> passwords. Ideally it is tied into the directory via ldap or something
>>> so authentication and user information is seamless.
>>>
>>>     
>> One problem is that currently the settings for an external user are 
>> shared by all internal users. So, if internal user A changes settings 
>> for external user E internal user B will also be affected. Do you want 
>> the user list to be different for each internal user?
>> Right now you can add admins with different roles. You can add an admin 
>> that can add keys etc. but not change the MTA settings,
>>
>>
>>
>> Kind regards,
>>
>> Martijn
>> _______________________________________________
>> Users mailing list
>> Users at lists.djigzo.com
>> http://lists.djigzo.com/lists/listinfo/users
>>
>>   
> _______________________________________________
> Users mailing list
> Users at lists.djigzo.com
> http://lists.djigzo.com/lists/listinfo/users
> 


-- 
Djigzo open source email encryption



More information about the Users mailing list