On Tue, Mar 26, 2013 at 3:47 PM, Niels Möller <[email protected]> wrote:
> I have now read the UMAC spec (RFC 4418) a bit more carefully. I haven't > yet read Niko's code (or any other code, for that matter). Some To put the discussion on some context for the others, I have sent a patch that adds support for the UMAC algorithm. The patch did not made it to the list due to size and was forwarded directly to Niels. btw. It would be nice if the list would notify the poster when messages are being held. In that case I only figured out it was held some days later by checking the archives. Also please use Nikos for my name. The Niko sounds very Italian (and I am not one :). > o Since I have been work with side-channel silence recently, it seems > natural to try to make the POLY function silent, On the other hand, > I'm not sure what the threats are. If the MAC is applied to a secret > message, we may leak some information about the message, I guess? Do you think the current function could provide information on the plaintext? From a quick look it is not obvious to me, but I haven't checked thoroughly. > o I think we ought to handle large messages correctly, which means we > need the POLY function also over the 128-bit prime. Performance is > not terribly important, at least not initially. Note that the current limit on the code is 16MB messages per tag, not per key, so it is oversufficient for all practical uses of a MAC (which is not the same as a hash). It would be nice not to have the limit, but it would be nicer if anyone actually cared about it :) I haven't checked but if adding support for larger messages per tag would reduce performance, but if this is the case I think it would be pretty counter-productive. regards, Nikos _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
