Subject: RE: Security Gateways

From: Venkat Rangan <[email-masked]>
Date: Sat, 4 Aug 2001 16:37:08 -0700

Milan,

Rather than run the algorithm on a PPC core, you can get a native core as
listed here. When integrated into a Xilinx Virtex FPGA (XCV400-6) it gives
3Gbps processing for DES. AES is usually an order of magnitude faster, and
if you convert FPGA to ASIC, you may be looking at 2x to 4x improvement.

http://www.free-ip.com/DES

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

-----Original Message-----
From: Merhar, Milan [mailto:[email-masked]]
Sent: Friday, August 03, 2001 10:44 AM
To: 'Bernard Aboba'; 'Williams, Jim'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Security Gateways

> Bernard Aboba wrote:
> 
> Integrity protection via new MACs such as UMAC is *not* 
> expensive. This is
> a myth. See http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html 
>

Bernard,

Thanks for the pointer to some current research in this area.

That paper gave cycles/byte numbers for their algorithm, on 
a Pentium III and PowerPC.  For now, I'll comment on the PPC 
numbers, because that family is available as an embeddable core
that can be integrated into hardware, while the Pentium III is not. 
For 1500-byte messages, it looks like UMAC will take between 
2.7 and 3.7 CPU clocks per byte (estimates, as no numbers 
were given for the full UMAC function on PPC).  

That indicates that I'd have to run my core at 600-800 Mhz 
to handle a single full duplex Gigabit Ethernet port, assuming
I have the packets in memory that's fast enough to not stall the 
CPU, and that there's some way of getting packets into and out 
of that memory without interfering with the CPU.

I grant you that is "do-able," and it certainly is less expensive 
than HMAC-SHA1, but I wouldn't call it "cheap."  At least for 
some portion of the audience here, "cheap" may be measured by how 
many thousands of gates the implementation adds to the existing 
data path logic, and "fast" by how many gate delays were 
introduced into that path. 

So, I guess that puts me in agreement with Jim William's 
comments; security protocols MUST be supported, and 
supported in the context of a single standard, 
not a "de jure" standard and a "de facto" alternative.
And, if that means the standard must embrace non-monolithic 
"system level" compliance, then let's figure out how to 
do that properly, rather than declaring it illegal and hoping 
it will go away.

- milan

---

From: Stephen Bailey <[email-masked]>
Date: Mon, 06 Aug 2001 04:37:37 -0400

Venkat,

> it gives 3Gbps processing for DES

Thanks for the link.

Forgive my potential ignorance, but I'm not sure this number is
meaningful.  They say it would be problematic to adapt their fast mode
implementation to CBC, which is what IPSec requires.  The slow mode
variant, which they say is easily adaptable to CBE runs at 130
Mbits/s.  Furthermore, they admit that they don't even have a story on
fast 3DES/CBC, which what I thought was de rigeur these days.

Hopefully, somebody will correct any of misunderstanding I might have
in this regard.

Thanks,
  Steph