1994-08-06 - fast 386 DES code figures

Header Data

From: hughes@ah.com (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: f585c90626f769edf2af7f5686d9ad2f4c758a6137a8d435d2841d0496eef25a
Message ID: <9408061625.AA16701@ah.com>
Reply To: <199408060726.AAA00390@unix.ka9q.ampr.org>
UTC Datetime: 1994-08-06 16:54:18 UTC
Raw Date: Sat, 6 Aug 94 09:54:18 PDT

Raw message

From: hughes@ah.com (Eric Hughes)
Date: Sat, 6 Aug 94 09:54:18 PDT
To: cypherpunks@toad.com
Subject: fast 386 DES code figures
In-Reply-To: <199408060726.AAA00390@unix.ka9q.ampr.org>
Message-ID: <9408061625.AA16701@ah.com>
MIME-Version: 1.0
Content-Type: text/plain


Phil Karn wonders where all the speed comes from in reports of fast
software DES.

I believe that the really fast DES variants use extremely large
computed-at-key-init S-box tables.  As I recall, these implementations
tend to pay for it in terms of setup time, which makes them less that
completely appropriate for multiple IP encryption, each with its own
key and where only a few dozen encryptions are done per packet.  The
cost to change keys is paid for either in use of memory for multiple
precomputed S-box sets (an attendant swapping) or in a high key-setup
to encryption ratio.

For a link cipher where the key doesn't change much, these fast
implementations are right.  For a situation where keys change
frequently, they may not be a system win.

Thanks to Perry Metzger for alerting me to this issue.

Eric





Thread