Talk:UMAC (cryptography)

Untitled

I should drop the intro -- Nroets 23:31, 8 Jun 2005 (UTC)

Explaining an edit that I made: hashing (for instance, by evaluating a polynomial over a finite field) followed by one-time pad is not a secure MAC. For instance, the attacker might twiddle the lowest-order bit of the input. This will add (or subtract) 1 to the output, which has a 50% chance of just twiddling the low-order bit there. That would commute with the one-time pad, so the attacker can just twiddle the low-order bit of the MAC also, and he forges a message with probability 1/2. To make the MAC secure, you need a pseudorandom function. -- bitwiseshiftleft

If the attacker twiddle the lowest bit of the plaintext (or input as you call it), it will change roughly half the bits in the output of the dot product (what you call a polynomial). For example if your finite field is MOD 7 and your secret hash function is f(x)=x * 5 MOD 7 and the next value from your OTP is Y, then f(0) XOR Y and f(1) XOR Y will differ in 2 bits. -- Nic Roets 18:30, 7 May 2007 (UTC)

The original publication

This is the original publication by Carter & Wegman : [1] —Preceding unsigned comment added by Nroets (talk • contribs) 11:12, 28 April 2009 (UTC)

Article confuses universal-hash-function-based MACS and the RFC 4418 UMAC algorithm

This page is wrong; no one in cryptography calls all universal-hash-function-based MACS "UMAC." UMAC is a specify one of these: http://fastcrypto.org/umac/ 128.138.242.57 (talk) 05:16, 29 April 2010 (UTC)

I was fooled at first (UMAC is good), but this looked to simple. This is broken! But having this using the UMAC name can be dangerous. --RogerJL (talk) 10:50, 8 March 2011 (UTC)

Reviewing the source - for short messages the complete key won't be used. For example a three byte message will only use the first three bytes of the key - effectively limiting the keyspace to 24 bits... My gut feeling is that all bytes in the key should always be used. Padding message with zeroes will not help as the r1, r2, r3 will never be modified -> i.e. same output will be produced. Article should mention padding (to same size as key) and its pitfalls (do not use only zeroes) --RogerJL (talk) 23:57, 7 March 2011 (UTC)

You are right in the sense that an attacker can take any message, append zeros at the end and use the old MAC. However, since most message formats either contain a length field, or are the serialization of some structure / object, this is not a concern.

If you want to pad, then zeros will work perfectly well. The guarantee still holds: The probability of an attacker correctly guessing the MAC is one in 2²⁴. -- Nic Roets (talk) 01:41, 8 March 2011 (UTC)

That was not my concern! My concern is that if you can intercept a short message (<=3 bytes). You can find the tree first letters of the true password by brute force. Once you have found them wait for slightly longer message (4..6 bytes). Break the next tree letters... repeat... If you can intercept two short messages then NO padding will help, nor will any nonce. As they only contributes to xoring with a constants. After the key is broken any message can be forged... --RogerJL (talk) 09:08, 8 March 2011 (UTC)

It is even worse! If you can intercept two messages that only differ in one triplet. Then all the other triplets can be viewed as a constant. And you can break the secret key for the differing section. --RogerJL (talk) 10:50, 8 March 2011 (UTC)

Did you consider the "nonce" ? The caller must initialize result[0], result[1] and result[2] with 3 secret bytes. Ideally those 3 bytes should come from a one time pad. If they come from an OTP, then an attacker observing every message and every MAC will learn absolutely nothing about "secret". -- Nic Roets (talk) 21:05, 8 March 2011 (UTC)

Unless you change nonce for EVERY (different) message this crypto will easily broken. I have source that breaks it. To break it you do not need to know the start values for the result array. You have to ensure that atleast two things differ for EVERY message - start value is one, each block that differs is another. With two differences you have 2^24*2^24=2^48 values to work through using brute force. To process all 2^24 takes less than 4 s on my computer - and I see lots of optimization potential in the code. One second per group of 2^24 is not at all unrealistic, you can probably do a lot better. — Preceding unsigned comment added by RogerJL (talk • contribs) 08:14, 9 March 2011 (UTC)

I change the nonce every time. In fact I use up 24 bits of my OTP for every message I send. So 24 MB of flash will only last one million messages. The message are numbered and the OTP index is calculated from them. The message number need not be included in the UMAC calculation. It is good practice to check that the message numbers from the sender will always increase, but this requirement can be relaxed if the messages contain a secure timestamp.

XORing with f(nonce) is effectively "encrypting the hash". If the encryption is good, then an attacker can learn nothing about the hash. -- Nic Roets (talk) 01:13, 11 March 2011 (UTC)

Requested move 10 October 2024

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: moved. (closed by non-admin page mover) Frost 12:37, 17 October 2024 (UTC)

---

• UMAC → UMAC (cryptography)
• UMAC (disambiguation) → UMAC

– I don't think UMAC has a primary topic, and even if it does it's University of Macau, not this article. Hence, the dab should get the base name. Danski454 (talk) 11:56, 10 October 2024 (UTC)

• Support: Aside the University of Macau, there is also the Upper Midwest Athletic Conference. The cryptography topic is not very clearly notable, or at least not more than all the other candidate topics combined. —⁠ ⁠BarrelProof (talk) 22:04, 10 October 2024 (UTC)
• Support. I agree there's no primary topic here. Shhhnotsoloud (talk) 10:28, 11 October 2024 (UTC)
• Support, no PRIMARY.--Ortizesp (talk) 13:26, 11 October 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.