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
On Tue, 22 Oct 2002, Ed Gerck wrote:
Short answer: Because the MAC tag is doubled in size.
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
Adam Back says:
Providing almost no hardware defenses while going to extra-ordinary
efforts to provide top notch software defenses doesn't make sense if
the machine owner is a threat.
So maybe the Palladium folks really mean it when they say the purpose
of Palladium is not to enable DRM?
I doubt
On Tue, Oct 22, 2002 at 11:09:41AM -0700, bear wrote:
Now Bob sends Alice 2^32 messages (and Alice's key-management
software totally doesn't notice that the key has been worn to
a nub and prompt her to revoke it). Reviewing his files, Bob
finds that he has a January 21 document and a
bear wrote:
On Tue, 22 Oct 2002, Ed Gerck wrote:
Short answer: Because the MAC tag is doubled in size.
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
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
Ed Gerck [EMAIL PROTECTED]
It does to (as you can read in the paper). BTW, the easily applies to the
case
WITHOUT salt
Well, to be really pedantic the paper never says that it is easy only that
it has a work factor of the square root of the number of possible MAC strings
without salt, and that
[EMAIL PROTECTED] wrote:
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.
;-) your question was Why is RMAC resistant to birthday attacks?
Longer answer: The birthday paradox says that if the MAC tag has
On Tue, Oct 22, 2002 at 12:31:47PM -0700, Ed Gerck wrote:
My earlier comment to bear applies here as well -- this attack can be avoided
if only a subset of the MAC tag is used
I can't seem to find your earlier comment. It probably hasn't gone through
the mailing list yet.
I don't see how
[EMAIL PROTECTED]
I want to understand the assumptions (threat models) behind the
work factor estimates. Does the above look right?
I just realized something about the salt in the RMAC algorithm, although it
may have been obvious to everyone else:
RMAC is equivalent to a HMAC hash-based MAC
Wei Dai wrote:
On Tue, Oct 22, 2002 at 12:31:47PM -0700, Ed Gerck wrote:
My earlier comment to bear applies here as well -- this attack can be avoided
if only a subset of the MAC tag is used
I can't seem to find your earlier comment. It probably hasn't gone through
the mailing list
But the salt doesn't increase the MAC length. It just frustrates
attempts to collect message+MAC pairs to find a collision. Think of
it like a salt on unix passwords. You can still brute force one
particular target in the same time, but the salt reduces your scope
for pre-computation.
There is
Sidney Markowitz wrote:
[EMAIL PROTECTED]
I want to understand the assumptions (threat models) behind the
work factor estimates. Does the above look right?
I just realized something about the salt in the RMAC algorithm, although it
may have been obvious to everyone else:
RMAC is
Ed Gerck [EMAIL PROTECTED] said:
No -- these are all independent things. One can build an RMAC wih SHA-1.
An RMAC does not have to use an HMAC scheme. One can also have an
HMAC hash-based MAC algorithm using a block cipher, that is not an RMAC.
Some quotes from the paper:
This paper defines
At 03:05 PM 10/22/2002 -0400, Wei Dai wrote:
Call the Jan 21 document x, and the Sept 30 document y. Now Bob knows
MAC_Alice(x | z) = MAC_Alice(y | z) for all z, because the internal states
of the MAC after processing x and y are the same and therefore will remain
equal given identical suffixes.
Sidney Markowitz wrote:
Ed Gerck [EMAIL PROTECTED] said:
That's is not the reason it was devised. The reason is to prevent a birthday
attack for 2^(t/2) tries on a MAC using a t-bit key. Needless to say, it also makes
harder to try a brute force attack.
RMAC was devised for the reason
Ed Gerck [EMAIL PROTECTED] wrote:
A minor nit, but sometimes looking into why
things were devised is helpful.
What I explained can be found in
http://csrc.nist.gov/encryption/modes/workshop2/report.pdf
Thank you, that was really helpful in seeing the motivation for the work that led to
the
Remote attestation does indeed require Palladium to be secure against
the local user.
However my point is while they seem to have done a good job of
providing software security for the remote attestation function, it
seems at this point that hardware security is laughable.
So they disclaim in
On Tue, Oct 22, 2002 at 04:52:16PM +0100, Adam Back wrote:
So they disclaim in the talk announce that Palladium is not intended
to be secure against hardware attacks:
| Palladium is not designed to provide defenses against
| hardware-based attacks that originate from someone in control of
On Tue, 22 Oct 2002, Rick Wash wrote:
Hardware-based attacks cannot be redistributed. If I figure out how
to hack my system, I can post instructions on the web but it still
requires techinical competence on your end if you want to hack your
system too.
While this doesn't help a whole lot
At 4:52 PM +0100 10/22/02, Adam Back wrote:
Remote attestation does indeed require Palladium to be secure against
the local user.
However my point is while they seem to have done a good job of
providing software security for the remote attestation function, it
seems at this point that hardware
Software-based attacks are redistributable. Once I write a program
that hacks a computer, I can give that program to anyone to use. I
can even give it to everyone, and then anyone could use it. The
expertise necessary can be abstracted away into a program even my
mother could use.
22 matches
Mail list logo
