headers
Tom Leach | 24 Apr 19:48

Hardware crypto accelerators

Anyone out there using HW crypto accelerators for SSL/TLS imap sessions? 
  I'm migrating from a Solaris environment that is using a Sun crypto 
card to a Linux environment where crypto drivers may be more difficult 
to come by and I'm wondering if the speed up in processing power from 
the newer system hardware will offset the need for accelerators?  We're 
a medium sized installation with 300-500 simultaneous sessions.
Just curious what others are doing with crypto and imap.
Tom Leach
leach <at> coas.oregonstate.edu
_______________________________________________
Imap-uw mailing list
Imap-uw <at> u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
Permalink | Reply |
headers
Mark Crispin | 24 Apr 20:48

Re: Hardware crypto accelerators

This is my opinion only:

I believe that a software implementation on a general-purpose processor 
will always have superior price/performance to a special-purpose 
processor; and furthermore that the performance (as opposed to 
price/performance) of a software implementation on a general-purpose 
processor will exceed that of a special-purpose processor before the 
special-purpose processor is fully depreciated.

Advances in general-purpose processors have just been progressing too 
quickly, and the premiums on special-purpose processors are just too high.

Again, this is my opinion only.

On Thu, 24 Apr 2008, Tom Leach wrote:
> Anyone out there using HW crypto accelerators for SSL/TLS imap sessions?  I'm 
> migrating from a Solaris environment that is using a Sun crypto card to a 
> Linux environment where crypto drivers may be more difficult to come by and 
> I'm wondering if the speed up in processing power from the newer system 
> hardware will offset the need for accelerators?  We're a medium sized 
> installation with 300-500 simultaneous sessions.
> Just curious what others are doing with crypto and imap.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
(Continue reading)

Permalink | Reply |
headers
Dirk-Willem van Gulik | 24 Apr 21:54

Re: Hardware crypto accelerators


On Apr 24, 2008, at 8:48 PM, Mark Crispin wrote:
> This is my opinion only:
>
> I believe that a software implementation on a general-purpose  
> processor will always have superior price/performance to a special- 
> purpose processor; and furthermore that the performance (as opposed  
> to price/performance) of a software implementation on a general- 
> purpose processor will exceed that of a special-purpose processor  
> before the special-purpose processor is fully depreciated.
>
> Advances in general-purpose processors have just been progressing  
> too quickly, and the premiums on special-purpose processors are just  
> too high.

While above may well be true for new equipment - I've found adding a  
HiFN card to FreeBSD or OpenBSD or nChiper or CryptoSwift to Solaris  
to just offload the initial setup exchange very close to being a  
"magic silver bullet solution". Which gives you a few months of time  
to plan for a proper upgrade or what not. On MacOSX and Linux the  
situation is far from clear cut - as other issues in the bus, DMA, irq  
handling and IP stack muddle things.

However two things w.r.t. to IMAP -- depending on your situation -  
your connections may be long lived - and if that is the case -  
benefits are not all that noticable (percentages rather than orders).  
If they are not - consider if you can make them long lived. Once they  
are in the 20+ minute length - the SSL overhead is neglectable.  
Secondly - depending on your situation -- dropping down to something  
like RC4 can make quite difference if it is pure flat CPU for very
(Continue reading)

Permalink | Reply |
headers
Chuck Swiger | 24 Apr 20:55

Re: Hardware crypto accelerators

Hi, Tom--

On Apr 24, 2008, at 10:50 AM, Tom Leach wrote:
> Anyone out there using HW crypto accelerators for SSL/TLS imap  
> sessions?  I'm migrating from a Solaris environment that is using a  
> Sun crypto card to a Linux environment where crypto drivers may be  
> more difficult to come by and I'm wondering if the speed up in  
> processing power from the newer system hardware will offset the need  
> for accelerators?  We're a medium sized installation with 300 - 500  
> simultaneous sessions.
> Just curious what others are doing with crypto and imap.

I've used the CryptoSwift hardware with some high-volume SSL  
webservers on Solaris, and I've used various Hi/FN cards under  
FreeBSD.  These devices provide the most benefit to the initial SSL  
connection setup using the ~1024 bit public-key encryption (ie, RSA or  
DSA), and do not help as much for the ~40/128 bit symmetric encryption  
(ie, DES/3DES/RC4/RC5/AES) used later on for the actual data.

In the case of SSL web traffic, you end up setting up and tearing down  
many more connections compared to IMAP usage, which tends to persist  
connections much longer.  Modern 1+ GHz CPUs can generally do  
symmetric crypto faster than at least the lower-end HW crypto  
accelerators, but you can use "openssl speed" to get real numbers for  
the hardware you've got.

(If you're not sure what types of crypto your clients are using,  
running "openssl s_client -connect mail.example.com:imaps", possibly  
with the -debug flag for details, will tell you...)
(Continue reading)

Permalink | Reply |
headers
Tom Leach | 8 May 17:26

Easing restrictBox restrictions

I need to ease the folder name restrictions imposed by restrictBox in 
mailboxfile() but I have a couple of questions.  First off, I have 
restrictBox set to -1 so all flags are set.
Does the restriction of "//" have any meaning if we're not using Samba 
on a Linux system?  I'm trying to see where that would be a path 
security problem but I just don't see an issue unless it could be a cifs 
one.
Second, we're moving from mbox to mix and an older (non-restrictBox set) 
uw_imapd, and I have some people with .. in their folder names.  The 
restriction of ".." is preventing me from converting those boxes (and 
the use of them by the owners) so i was thinking of changing
strstr (name,"..") to strstr (name,"/..") || strstr (name,"../") but I 
wanted opinions on what cases I was missing.  I've tried tossing in %2f 
to see if that would be parsed as a / but so far, it's always be literal 
(foo%2f..%2fbar instead of foo/../bar).
So, opinions on what I'm missing???
Thanks,
Tom Leach
leach <at> coas.oregonstate.edu
_______________________________________________
Imap-uw mailing list
Imap-uw <at> u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
Permalink | Reply |
headers
Mark Crispin | 8 May 20:15

Re: Easing restrictBox restrictions

Tom -

You aren't missing anything.  restrictBox is implemented in a very 
paranoid fashion, and almost certainly can be relaxed safely.

In designing the distribution rules for restrictBox, I didn't go by "what 
is unsafe"; I went by "what might under some set of circumstances (that I 
don't necessarily even know about) be unsafe."  The whole idea being that 
I don't have to deal with some security alert because restrictBox failed 
to check for something.  Arguably, I should go further and prohibit "%" 
under restrictBox as well... ;-)

We don't use restrictBox here.

On Thu, 8 May 2008, Tom Leach wrote:
> I need to ease the folder name restrictions imposed by restrictBox in 
> mailboxfile() but I have a couple of questions.  First off, I have 
> restrictBox set to -1 so all flags are set.
> Does the restriction of "//" have any meaning if we're not using Samba on a 
> Linux system?  I'm trying to see where that would be a path security problem 
> but I just don't see an issue unless it could be a cifs one.
> Second, we're moving from mbox to mix and an older (non-restrictBox set) 
> uw_imapd, and I have some people with .. in their folder names.  The 
> restriction of ".." is preventing me from converting those boxes (and the use 
> of them by the owners) so i was thinking of changing
> strstr (name,"..") to strstr (name,"/..") || strstr (name,"../") but I wanted 
> opinions on what cases I was missing.  I've tried tossing in %2f to see if 
> that would be parsed as a / but so far, it's always be literal 
> (foo%2f..%2fbar instead of foo/../bar).
> So, opinions on what I'm missing???
(Continue reading)

Permalink | Reply |
headers
Bob Atkins | 9 May 01:54

Re: Easing restrictBox restrictions

Tom,

We actually build two versions of imap - the production version with a 
shared library with restrictbox and a also set of statically linked 
admin tools without restrictbox set. This allows us to perform admin 
functions such as the ones you are describing and at the same time, 
limits our customers access when they access our systems.

Mark Crispin wrote:
> Tom -
>
> You aren't missing anything.  restrictBox is implemented in a very 
> paranoid fashion, and almost certainly can be relaxed safely.
>
> In designing the distribution rules for restrictBox, I didn't go by 
> "what is unsafe"; I went by "what might under some set of 
> circumstances (that I don't necessarily even know about) be unsafe."  
> The whole idea being that I don't have to deal with some security 
> alert because restrictBox failed to check for something.  Arguably, I 
> should go further and prohibit "%" under restrictBox as well... ;-)
>
> We don't use restrictBox here.
>
> On Thu, 8 May 2008, Tom Leach wrote:
>> I need to ease the folder name restrictions imposed by restrictBox in 
>> mailboxfile() but I have a couple of questions.  First off, I have 
>> restrictBox set to -1 so all flags are set.
>> Does the restriction of "//" have any meaning if we're not using 
>> Samba on a Linux system?  I'm trying to see where that would be a 
>> path security problem but I just don't see an issue unless it could
(Continue reading)

Permalink | Reply |

Gmane