[Djigzo users] Customer experience

Dan Banach dbanach at OAMRI.com
Mon Jun 22 23:52:50 CEST 2009


This brings up an interesting topic of discussion. Is the IBE method
used by IronPort and others any more secure than the PDF encryption? I
personally don't think IBE offers the same level of security as true
128-bit encryption because public/known info (email address, etc.) acts
as part of the key negotiation, once one has the encrypted payload and
this known info you have most of the puzzle. Personally, I think PDF
with a strong password is on the same level as the IBE based products. 

Just my $.02, I'd be curious what others thought.




Thanks,
 
Dan

-----Original Message-----
From: users-bounces at lists.djigzo.com
[mailto:users-bounces at lists.djigzo.com] On Behalf Of Martijn Brinkers
Sent: Wednesday, June 17, 2009 3:43 PM
To: Eamonn McGonigle
Cc: Users at lists.djigzo.com
Subject: Re: [Djigzo users] Customer experience

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
_______________________________________________
Users mailing list
Users at lists.djigzo.com
http://lists.djigzo.com/lists/listinfo/users



More information about the Users mailing list