SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: Security Gateways



    
    Did somebody attempt to design specialized hardware to do UMAC?
    
    Julo
    
    Jim McKinney <jmck+@ece.cmu.edu>@ece.cmu.edu on 03-08-2001 21:55:06
    
    Please respond to Jim McKinney <jmck+@ece.cmu.edu>
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  RE: Security Gateways
    
    
    
    
    Approved: sskm1
    
    > 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
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:05 2001
6315 messages in chronological order