Re: Why is RMAC resistant to birthday attacks?
On Mon, 21 Oct 2002, Aram Perez wrote: [EMAIL PROTECTED] wrote: While you are correct in the general case, I have worked on a system where Alice could only generate MACs and Bob could only verify MACs. The hardware was designed so that Alice could not verify MACs and Bob could not generate MACs even though they shared the same key (that was only known to the hardware). This is interesting, but it does not help me to understand what threat model is addressed RMAC, or more generally how do birthday attacks play out against (shared secret) keyed MAC algorithms. The details of the RMAC algorithm itselft are not at issue here, I want to understand the problem so I can use the solution under the right conditions. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
On Tue, 22 Oct 2002, Ed Gerck wrote: Short answer: Because the MAC tag is doubled in size. I know, but this is not my question. Longer answer: The birthday paradox says that if the MAC tag has t bits, only 2^(t/2) queries to the MAC oracle are likely needed in order to discover two messages with the same tag, i.e., a collision, from which forgeries could easily be constructed. So the threat model assumes that there is a MAC oracle. What is a practical realization of such an oracle? Does Eve simply wait for (or entice) Alice to send enough (intercepted) messages to Bob? Are there any other birthday attack scenarios for keyed MAC? In many applications the collection sufficiently many messages between Alice and Bob is simply out of the question. In such cases if Eve cannot mount the attack independently and cannot collect 2^(n/2) messages from Alice to Bob, presumably RMAC does not offer an advantage over any other keyed MAC. I am not confused by the RMAC algorithm or so the associated work factor estimates, I want to understand the assumptions (threat models) behind the work factor estimates. Does the above look right? -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Why is RMAC resistant to birthday attacks?
The RMAC FIPS draft does not appear to explicitly state when RMAC is useful. What is the scenario in which (presumably unlike some other keyed MAC algorithms) RMAC is resistant to birthday attacks? More broadly for an arbitrary keyed MAC (in a plausible application!) how does the birthday attack come into play? With unkeyed message digests encrypted by a public key, the attacks are clear, Alice sends Bob message A, Bob agrees to message A, and signs it. Later Alice claims that Bob signed message B. The birthday paradox helps Alice because she can generate lots of minor variants of each message, generate ~sqrt(2^n) hashes of each and have a good shot at finding a collision. With keyed MACs Alice and Bob share the same secretkeys, either can freely generate messages with correct MAC values, so the MAC cannot be used as evidence to a third party that Alice is the signer of the message. In this case the attacker is clearly not either Alice or Bob. So Eve wants to convince Bob that a message really is from Alice. What does Eve do? Does Eve somehow entice Alice to send ~sqrt(2^n) messages to Bob? How does the birthday attack come into play when the attacker cannot independently test potential collisions? Please pardon the naive question, I just want to understand the premises of the problem to which RMAC is a solution. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's Time to Abandon Insecure Languages
This is more indicative of CERT's focus than the relative frequency of security issues. The fact that a large fraction of e-commerce merchants let you set the price for the goods you buy is in practice a larger threat than the widely publicized buffer overflows. Semantic security bugs in individual web sites do not rate highly enough on Cert's seismograph, but are in practice far more common. My evidence: http://www.cert.org/advisories/ -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's Time to Abandon Insecure Languages
CERT is far from a comprehensive source of security bug reports. Does anyone have statistics of bug types for Bugtraq or Mitre's CVE? I get daily bug reports via FS/ISAC. Most of these are not sufficiently severe or broadly applicable to be CERT advisories. These are mostly application logic issues, but the evidence is I must admit anecdotal. I don't have survey results. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
