Prev: Steganography: 100's or 1000's of Apps. Available
Next: custom Run-time packer
From: Greg Rose on 8 Jun 2010 00:16
In article <130e63aa-70ac-4915-887e-7080db496cb6(a)42g2000prb.googlegroups.com>,
jbriggs444 <jbriggs444(a)gmail.com> wrote:
>_IF_ you could trust that the unkeyed hash code is authentic then
>what possibilities exist for the associated message to match the
>hash and yet fail to be authentic?

If you can trust it to be authentic, you don't
need a MAC. But I think you're just being sloppy
with your terminology.

>It seems to me that the message must be authentic in this case,
>barring a successful pre-image attack on the hash.
>
>Yes, I understand that if you cannot trust the provenance of the
>hash then you're down to integrity without authenticity. You can
>trust that message came to you intact from the sender
>you just don't know who the real sender is. Anybody could
>have generated a message and a hash and offered them both
>up.

Yes, that's the point. If you can alter the
message and the hash, you can replace the message
with something that looks valid but isn't what the
real person sent.

>And yes, I understand that if you can trust the hash, you must
>have a trusted communications channel -- why not just use it?
>[Maybe it's low bandwidth].
>
>Or am I still missing the point?

You seem to be approaching it.

Greg.

--
From: Tom St Denis on 8 Jun 2010 06:38
On Jun 7, 4:42 pm, jbriggs444 <jbriggs...(a)gmail.com> wrote:
> _IF_ you could trust that the unkeyed hash code is authentic then
> what possibilities exist for the associated message to match the
> hash and yet fail to be authentic?

All hashes are unkeyed. Can we please use the proper terminology in
this discussion? MACs are keyed, hashes are not.

If you know with 100% certainty that the hash was delivered intact
then you have guaranteed integrity, it's still not authenticity.
Authenticity means "Person $A vouches for this content." Which
requires some form of private credential. In the above example, more
or less, you know that the hash stored matches the data stored, but
anyone can generate the hash and data. So you don't know who vouched
for it.

> Yes, I understand that if you cannot trust the provenance of the
> hash then you're down to integrity without authenticity.  You can
> trust that message came to you intact from the sender
> you just don't know who the real sender is.  Anybody could
> have generated a message and a hash and offered them both
> up.

Bingo.

> And yes, I understand that if you can trust the hash, you must
> have a trusted communications channel -- why not just use it?
> [Maybe it's low bandwidth].
>
> Or am I still missing the point?

Well the OP is asking why they don't just use an unkeyed HMAC instead
of a hash. The point is an unkeyed [or known key] MAC is no better
than a hash and in some cases it's actually worse.

Tom
From: Maaartin on 8 Jun 2010 07:04
On Jun 8, 12:38 pm, Tom St Denis <t...(a)iahu.ca> wrote:
> On Jun 7, 4:42 pm, jbriggs444 <jbriggs...(a)gmail.com> wrote:
>
> > _IF_ you could trust that the unkeyed hash code is authentic then
> > what possibilities exist for the associated message to match the
> > hash and yet fail to be authentic?
>
> All hashes are unkeyed.  Can we please use the proper terminology in
> this discussion?  MACs are keyed, hashes are not.

Google gives about 28,200 results for "keyed hash", and it's used in
RFCs, by FIPS, ANSI, and by some well-known cryptographers. It seems
to be the term for any hash-based MAC. The HMAC defining paper is
called "Keying Hash Functions for Message Authentication".

> Well the OP is asking why they don't just use an unkeyed HMAC instead
> of a hash.  The point is an unkeyed [or known key] MAC is no better
> than a hash and in some cases it's actually worse.

Could you elaborate on this? I don't think i could happen for HMAC,
but I'm no expert.

I wonder what security gives us the hash on download pages. It could
be useful for checking that the file wasn't modified (e.g., by a
virus) after the download, it could be useful if the download page was
https with the very download made (for efficiency reasons) by http
only, but this is not the case.
From: Bryan on 8 Jun 2010 08:25
Tom St Denis wrote:
> jbriggs444 wrote:
> > _IF_ you could trust that the unkeyed hash code is authentic then
> > what possibilities exist for the associated message to match the
> > hash and yet fail to be authentic?
>
> All hashes are unkeyed.  Can we please use the proper terminology in
> this discussion?  MACs are keyed, hashes are not.

We seem to have agreement on that. "It's just a question about
terminology, after all," jbriggs444 wrote. I'm not convinced that's
all the question was, but J's term "unkeyed hash" was just to
emphasize that the hashing operation does not involve a key.

> If you know with 100% certainty that the hash was delivered intact
> then you have guaranteed integrity, it's still not authenticity.

That's not what jbriggs444 said. If you trust the hash is *authentic*,
then you can use it to authenticate the message.

> Authenticity means "Person $A vouches for this content."  Which
> requires some form of private credential.  In the above example, more
> or less, you know that the hash stored matches the data stored, but
> anyone can generate the hash and data.  So you don't know who vouched
> for it.

I'm kind of uneasy about the integrity/authenticity distinction. It
seems to mislead people more than it clarifies anything. The important
factor is the adversarial environment. If we ignore the adversarial
element, the goal is simply robustness in the face of communication
errors and authenticity does not come up.

In the face of possible enemy action, integrity and authenticity are
inseparable. I don't much care that my friend sent a message if the
version I receive was changed by the enemy. I don't care if a message
was delivered intact if might actually have been forged by the enemy.

> Well the OP is asking why they don't just use an unkeyed HMAC instead
> of a hash.  The point is an unkeyed [or known key] MAC is no better
> than a hash and in some cases it's actually worse.

That's not how I read it. The OP seemed to be citing the use of
cryptographic hashes in open-source file distribution, and asking why
other applications do not use a hash in place of a MAC. I think
there's a serious misconception there.

Why do sites such as SourceForge provide cryptographic hash digests of
the distribution files they host? I know of two good reasons: One is
that the hash can check against random communication errors. The other
is to allow users to download the distribution files from less
trustworthy sites, then use the digest from SourceForge to verify that
they got the same thing.

Here's the scary part: Many otherwise smart people download the
distribution files and the cryptographic digests from *the same* site,
and when they check the digests they think they're doing something to
verify security. I suspect the OP question was based on just such a
misconception.

Also, this thread should probably note that in 2004 Xiaoyun Wang,
Dengguo Feng, Xuejia Lai, and Hongbo Yu broke MD5. The attacks have
gotten better since.


--
--Bryan Olson
From: Tom St Denis on 8 Jun 2010 08:28
On Jun 8, 7:04 am, Maaartin <grajc...(a)seznam.cz> wrote:
> Google gives about 28,200 results for "keyed hash", and it's used in
> RFCs, by FIPS, ANSI, and by some well-known cryptographers. It seems
> to be the term for any hash-based MAC. The HMAC defining paper is
> called "Keying Hash Functions for Message Authentication".

Keying Hash Functions != Keyed Hash. It's turning a hash function
INTO a MAC.

SHA-256 for instance, is in no way keyed. Nor is any other
cryptographic hash.

BTW, Google is not authoritative of what is real and not. "Jesus is
real" returned 73 million hits.

> Could you elaborate on this? I don't think i could happen for HMAC,
> but I'm no expert.

I already pointed out universal hashing.

> I wonder what security gives us the hash on download pages. It could
> be useful for checking that the file wasn't modified (e.g., by a
> virus) after the download, it could be useful if the download page was
> https with the very download made (for efficiency reasons) by http
> only, but this is not the case.

The point is just to make sure the file is intact, it's not meant to
thwart active attackers. When you're sending a 600MB image via TCP
it's entirely possible [though unlikely] that a checksum fails to
identify a bad packet. It was more relevant back in the days of dial-
up and less so nowadays where packet reliability over the world is
fairly high.

Some distros also include GPG signatures for authenticity, assuming
you trust their public key as well...

Tom
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Steganography: 100's or 1000's of Apps. Available
Next: custom Run-time packer