Re: AES Modes
Quoting Brian Gladman [EMAIL PROTECTED]: Ian Grigg wrote: Jack Lloyd also passed along lots of good comments I'd like to forward (having gained permission) FTR. I've edited them for brevity and pertinence. [snip] I'm obviously being naive here ... I had thought that the combined mode would be faster, as it would run through the data once only, and that AES seems to clip along faster than SHA1. AFAIK all of the modes that use only one block cipher invocation per block of input are patented. EAX+CCM both use two AES operations per block, and byte-for-byte SHA-1 is 2-5x faster than AES (at least in the implementations I've seen/used/written), so using AES+HMAC is probably going to be faster than AES/EAX or AES/CCM. The obvious exception being boxes with hardware AES chips and slow CPUs (eg, an ARM7 with an AES coprocessor), where AES will of course be much faster than SHA-1. Maybe my C implementation of SHA1 is hopeless but I get SHA1 on an x86 at about 17 cycles per byte (over 100,000 bytes) and AES in C at 21 cycles per byte. So I would put these two algorihms at about the same speed in C. In consequence I rather suspect that the 'two encryptions per block' cost might also apply to combined modes when AES is used with HMAC-SHA1. Are you running on a P4? ASM for sha1 on a P4 takes about 11.9 cycles per byte. The P4 is a very touchy x86 implementation. On most other architectures I nearly always see a bit less than 2 times faster sha1 vs AES. On AMD64, asm, I have AES-cbc at 12.2 cycles per byte and sha1 at 6.8. This is about as good a CPU as it gets (IPC near 3 for both implementations). eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES Modes
Eric Young wrote: Quoting Brian Gladman [EMAIL PROTECTED]: Ian Grigg wrote: Jack Lloyd also passed along lots of good comments I'd like to forward (having gained permission) FTR. I've edited them for brevity and pertinence. [snip] I'm obviously being naive here ... I had thought that the combined mode would be faster, as it would run through the data once only, and that AES seems to clip along faster than SHA1. AFAIK all of the modes that use only one block cipher invocation per block of input are patented. EAX+CCM both use two AES operations per block, and byte-for-byte SHA-1 is 2-5x faster than AES (at least in the implementations I've seen/used/written), so using AES+HMAC is probably going to be faster than AES/EAX or AES/CCM. The obvious exception being boxes with hardware AES chips and slow CPUs (eg, an ARM7 with an AES coprocessor), where AES will of course be much faster than SHA-1. Maybe my C implementation of SHA1 is hopeless but I get SHA1 on an x86 at about 17 cycles per byte (over 100,000 bytes) and AES in C at 21 cycles per byte. So I would put these two algorihms at about the same speed in C. In consequence I rather suspect that the 'two encryptions per block' cost might also apply to combined modes when AES is used with HMAC-SHA1. Are you running on a P4? ASM for sha1 on a P4 takes about 11.9 cycles per byte. The P4 is a very touchy x86 implementation. On most other architectures I nearly always see a bit less than 2 times faster sha1 vs AES. On AMD64, asm, I have AES-cbc at 12.2 cycles per byte and sha1 at 6.8. This is about as good a CPU as it gets (IPC near 3 for both implementations). The SHA1 figure is for a P3 using VC++ set to generate code that will run on all Pentium family machines. I have not optimised the C code for any particular machine. 17/12 for C/ASM is a bit worse than I would have hoped for but is not that bad. I would not be surprised to see an average AES/SHA1 speed comparison in the 1.5:2.5 range but I was a bit surprised to see Jack's 2.0:5.0 range. I will have to see if VC++ can be coaxed down from 17 cycles per byte for SHA1 without giving up on code that runs on all Pentium compatible machines :-) Brian Gladman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Tor 0.0.9pre3 is out (fwd from [EMAIL PROTECTED])
--- begin forwarded text Date: Thu, 14 Oct 2004 12:45:03 +0200 From: Eugen Leitl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Tor 0.0.9pre3 is out (fwd from [EMAIL PROTECTED]) User-Agent: Mutt/1.4i Sender: [EMAIL PROTECTED] From: Roger Dingledine [EMAIL PROTECTED] Subject: Tor 0.0.9pre3 is out To: [EMAIL PROTECTED] Date: Thu, 14 Oct 2004 06:36:18 -0400 Reply-To: [EMAIL PROTECTED] Along with the bugfixes from 0.0.8.1, plus more bugfixes, this release makes the dirservers file obsolete (finally) in favor of config option lines to specify the location and fingerprint of each dirserver you want to trust. We also now support the use of an http proxy for fetching directories. tarball: http://freehaven.net/tor/dist/tor-0.0.9pre3.tar.gz signature: http://freehaven.net/tor/dist/tor-0.0.9pre3.tar.gz.asc (use -dPr tor-0_0_9pre3 if you want to check out from cvs) o Bugfixes on 0.0.8.1: - Better torrc example lines for dirbindaddress and orbindaddress. - Improved bounds checking on parsed ints (e.g. config options and the ones we find in directories.) - Better handling of size_t vs int, so we're more robust on 64 bit platforms. - Fix the rest of the bug where a newly started OR would appear as unverified even after we've added his fingerprint and hupped the dirserver. - Fix a bug from 0.0.7: when read() failed on a stream, we would close it without sending back an end. So 'connection refused' would simply be ignored and the user would get no response. o Bugfixes on 0.0.9pre2: - Serving the cached-on-disk directory to people is bad. We now provide no directory until we've fetched a fresh one. - Workaround for bug on windows where cached-directories get crlf corruption. - Make get_default_conf_file() work on older windows too. - If we write a *:* exit policy line in the descriptor, don't write any more exit policy lines. o Features: - Use only 0.0.9pre1 and later servers for resolve cells. - Make the dirservers file obsolete. - Include a dir-signing-key token in directories to tell the parsing entity which key is being used to sign. - Remove the built-in bulky default dirservers string. - New config option Dirserver %s:%d [fingerprint], which can be repeated as many times as needed. If no dirservers specified, default to moria1,moria2,tor26. - Make moria2 advertise a dirport of 80, so people behind firewalls will be able to get a directory. - Http proxy support - Dirservers translate requests for http://%s:%d/x to /x - You can specify HttpProxy %s[:%d] and all dir fetches will be routed through this host. - Clients ask for /tor/x rather than /x for new enough dirservers. This way we can one day coexist peacefully with apache. - Clients specify a Host: %s%d http header, to be compatible with more proxies, and so running squid on an exit node can work. -- -- Eugen* Leitl a href=http://leitl.org;leitl/a __ ICBM: 48.07078, 11.61144http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature] --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Crypto blogs?
Does anyone have pointers to crypto related weblogs? Bruce Schneier recently announced that Crypto-Gram would be coming out incrementally in blog form at http://www.schneier.com/blog/. I follow Ian Grigg's Financial Cryptography blog, http://www.financialcryptography.com/. Recently I learned about Adam Shostack's http://www.emergentchaos.com/, although it seems to be more security than crypto. Any other good ones? Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
