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
t
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
Adam Back <[EMAIL PROTECTED]> wrote:
> But the salt doesn't increase the MAC length. It just frustrates
> attempts to collect message+MAC pairs to find a collision.
[...]
> There is still probability 1/2^m of finding a collision given two
> random messages, whether the salt has size 0 or 64.
No,
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. S
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 def
> 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.
>
>
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
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
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 l
[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 a
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 t
[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 MA
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, a
Wei Dai wrote:
> 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 Jan
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 s
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
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
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
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 Septe
Sidney Markowitz wrote:
> "bear" <[EMAIL PROTECTED]> asked:
> > But why does that buy me the ability to "easily" make a forgery?
>
> It doesn't. As described in the paper all you can do with it is the following:
>
> Mallory discovers that a message from Alice "Buy a carton of milk" and another
>
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
"bear" <[EMAIL PROTECTED]> asked:
> But why does that buy me the ability to "easily" make a forgery?
It doesn't. As described in the paper all you can do with it is the following:
Mallory discovers that a message from Alice "Buy a carton of milk" and another
message from Alice "Get a dozen eggs"
On Tue, 22 Oct 2002, Nelson Minar wrote:
> I doubt it, though. Even a paper-thin shred of hardware protection is
> enough to prevent 99% of the people from circumventing DRM technology.
> Joe Sixpack isn't going to install a mod chip, and his local computer
> store can't do it for him for fear of
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 dou
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 col
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 collision, from which forgeries
could easily be
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 t
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 genera
28 matches
Mail list logo
