I'd be interested if there is a way to add Poly1305 in a way that is portable and maintainable for me without a huge amount of work, but it's not clear how to do that. If you take a look at http://cr.yp.to/mac/poly1305_athlon.s, it can't be compiled with MSVC, and I can't even begin to understand it without learning a new language, namely DJB's qhasm. (The last time I tried putting code into Crypto++ that I didn't understand, i.e. the deflate compression code, it went pretty badly in the long run and I ended up having to rewrite it.)
>From what I can tell from your graphs, on Pentium M Crypto++'s VMAC-AES-128 has a higher per-message overhead than Poly1305-AES, but their per-additional-byte cost is pretty close. I'm curious how many messages you are planning to MAC per second, and why? If the per-message overhead is really a serious problem for you, I can look into if anything can be done to reduce it. -------------------------------------------------- From: "zooko" <[EMAIL PROTECTED]> Sent: Tuesday, February 19, 2008 2:04 PM To: "Crypto++ Users" <[EMAIL PROTECTED]> Subject: Re: add Poly1305? > > Dear Wei and Crypto++ folks: > > For people who didn't examine the graphs closely, I should summarize > that they show that DJB's implementation of Poly1305-AES is > substantially faster than Crypto++'s implementation of VMAC-AES-128 > at all measured messages sizes and situations. > > Considering this, and considering Crypto++'s long history of offering > multiple alternate algorithms side-by-side, would you be interested > in including Poly1305? > > Thanks, > > Regards, > > Zooko > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [EMAIL PROTECTED] More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
